Designers > K2 Designer for Visual Studio > Design Tools > Toolbox > Working with Rules > Destination Rule > Plan Per Slot - No Destinations | Send feedback |
The Plan per slot (no destinations) method is reserved for server events based activities. In this case, destinations cannot be configured and the server creates one activity instance per slot. Activity data can be initialized and used for each instance. This allows each slot to have its own instance of non shared activity data fields. This method has two options available:
Option 1
In the first option, the number of slots are specified. The slots field can contain text or Process data, Activity data, XML or SmartObject data. Optionally, initialization data can be used which may consist of XML repeating nodes or SmartObject GetList data. As an example, this could be used for a parent process to start a variable number of child processes using IPC events.
Initialization data may contain any unique data that the activity requires. If a SmartObject GetList method or repeating XML node is specified for the initialization data, the server retrieves the next value for each slot, but only until it has reached the number of specified slots. Using the list field, it returns the next record until all the slots are filled while at the same time using the property specified as the initialization data for the new child process as an example.
Option 2
In this option, the number of slots are configured using SmartObject GetList data or repeating XML, which means that the number of slots is equal to the number of records returned by the GetList Method or elements in a repeating XML node that is mapped to this field. When the runtime activity starts, the server gets the number of records or XML elements and starts that many instances of the activity for example a number of child processes started through an IPC Event.
Using the list field, the server creates a slot for each item returned while at the same time using the property specified as the initialization data for the new child process as an example
|
In this scenario, Option 2 of this method is discussed
We have a customer who is recruiting people with specific skills. In order to provide them with details as to who is available with the required skills, we've created a SmartBox SmartObject with details related to potential candidates and built processes around this SmartObject to identify candidates who conform to the specified requirements.
Our customer would like details on the candidates with Programming and InfoPath skills. After completion of the process, a Custom Report can be created using the Report Designer in K2 Workspace. By using the filtering option in the Report Designer Wizard, only those candidates who conform to the specified requirements will be displayed and can be exported into another format to suit the customer's needs.
The following diagram shows the process flow between the parent and child processes.
Fig. 1. Process Flow diagram
Destination Rule Options | |
---|---|
Process Name | PotentialCandidates (Parent Process) |
Activity Plan Option | Plan per slot (no destinations) |
Select the number of slots to be created | False |
Select a list field to determine how many slots should be created | True |
List field | Candidates.Get List.ID |
Slot(s) assigned to (Value found in the Activity Destination Instance>Instance Data) | Each ID retrieved from the Candidates SmartObject in the PotentialCandidates process |
Total number of slots | Depending on the number of ID's retrieved from the Candidates SmartObject as used in the PotentialCandidates process |
Outcome | The server creates one activity instance per slot. Activity data can be initialized and used for each slot |
We selected the Candidates.Get List.ID list field on the Destination Rule Options page as shown below. This will enable the server to create a slot for each item returned while at the same time using the property specified as the initialization data for the new child process.
Fig. 2. Destination Rule Options page
The process is started manually by a user who has Administration rights on the K2 Workflow Server. The K2 Processes and a detailed description of the setup of these processes are shown below these steps. The following steps are performed by the server:
The following K2 Features are used in this scenario and specific references are made to the Processes and SmartObject as described in the steps above should you wish to recreate this scenario:
Feature | Description |
---|---|
Candidates SmartObject |
Contains properties that are required to send and receive information between the parent and child processes |
PotentialCandidates (Parent Process) |
Links to the child process via an IPC event to send and receive information to and from the child process |
CheckAvailabilityandSkills (Child Process) |
Links to the parent process via an IPC event to send and receive information to and from the parent process |
This SmartObject contains the following Properties:
Activity 1
Activity 2
Activity 3
Process
Activity 1
Activity 2
Activity 3