Designers > K2 Designer for Visual Studio > Design Tools > Toolbox > Working with Rules > Destination Rule > Destination Rule-Destination Rule Options | Send feedback |
Contextualized Assistance: Destination Rule Planning Scenarios |
The Advanced Mode offers three scenarios when planning Client Event instances. The first Destination Rule option screen is used to determine the planning method that will be used.
Fig.1 Default Activity Wizard - Destination Rule Options wizard screen
The Plan just once method of planning a destination rule is the default method of planning an activity. When using the default method, only one activity instance is instantiated. All events / modules contained in the instance will only execute once. Only one task item is created and rights assigned to the single task item.
One or more slots can be made available to interact / action the client event, see Destination Rule Options-Continued. All destination users receive their worklist items simultaneously. The number of slots will be set on the Activity Instance Destination, and all the Destinations defined in the Destination Rule will be copied to the Destinations collection of the Activity Instance Destination.
Because only one Activity Instance Destination exists, the Client Event will only execute once. This is why there will only be one Worklist header and one Serial number. So all destinations will have access to the same serial number (Activity Instance Destination). Each response from the user will update the Activity Instance Destination XML/data fields. A slot will be created for that user and the XML/data field values will be copied to the slot and depending on the action performed, the slot will be completed, or remain Open to the user.
The activity instance will complete when all slots are completed or when the succeeding rule is true.The activity instance will expire when the succeeding rule is false.
When using roles instead of individual users as the destination, task items are assigned to the role name rather than the individuals in the roles.
All destinations are planned for the lifetime of an activity, thus a user can participate only once for the activity in the process
The primary advantage to this option is performance owing to only one activity instance being instantiated. The pitfall as described below may occur
This option will create an Activity Instance Destination for every Destination. The events will be executed once for every Activity Instance Destination. Each destination will have its own Serial number, and because a client event is executed, each destination will have its own Worklist Header. The slot property for the Activity Instance Destination will always be set to 1. This slot property should not be confused with the one configured in the Destination Rule, which is the total number of slots for the Activity Instance. One or more slots can be made available to interact / action the client event, see Destination Rule Options-Continued.
The Destinations Collection for the Activity Instance Destination will contain only one Destination. When a user responds to the Worklist Item, the Activity Instance Destination XML/data fields are updated, a slot is created for the user and the XML/data fields are copied to the slot for that user and depending on the action performed, the slot will be completed, or remain Open to the user. If the slot is completed and because of the Activity Instance Destination slot property = 1, the event Succeeding rule is executed and will evaluate to true (All slots = completed) and the Activity Instance Destination will continue to execute the remaining event instances, and eventually the Succeeding rule of the Activity Instance Destination will execute. This will repeat until all Activity Instance Destinations are completed or the first time the Succeeding Rule evaluates to true.
One task item is created per destination with the rights assigned to each destination for each task item.
All destination users receive their worklist items simultaneously.
When using roles instead of individual users as the destination, task items are assigned to the role name rather than the individuals in the roles
All destinations are planned for the lifetime of an activity
The server creates one activity instance per destination, but does so in a serial manner, one instance at a time, and in the order the destination sets were designed. The server creates one task item per destination at a time, and assigns rights to each task item. The next instance will be created only after the previous event is completed by the previous destination user.
Worklist items are received sequentially; where they are received in the order that they appear in the Destination user listing, once the previous destination user has actioned his Client event instance.
The server will not evaluate a succeeding rule on the activity until all activity instances are completed
When a role is used as a destination, instances are created in the order in which the role membership is returned from the server query. If a specific order is required, rather use individual users instead, and specify the users in the desired order.
Each destinations' slots are planned only after the previous destination has completed their slots, thus a user can participate more than once for the activity in the process
This option works exactly the same as Plan per destination, except that there are no destinations configured for this option. The Activity Instance Destination rule will still execute as normal, but the destinations are ignored. The slot count will be used to determine how many Activity Instance Destinations should be created. This option will normally be used in conjunction with server events or IPC events that require no user action. Because there are no Destinations and no Client Events, no Worklist Headers will exist. So there is no need to create Slots when the Serial Number is completed.
As an example, this could be used for a parent process to start a variable number of child processes using IPC events. In this case, all configured destinations are ignored and the server creates one activity instance per slot. Activity data can be initialized and used for each slot. This allows each slot to have its own instance of the activity data fields.
In this method, the number of slots can be configured using activity or list data, which means that the number of slots is equal to the number of nodes in the XML field that is mapped to this field. When the runtime activity starts, the server decides how many instances of the IPC process, for example, need to be started.
Initialization data may contain any unique data that the IPC needs per child call. If a SmartObject Get List 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, 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.
Planning Method | |
---|---|
Plan Just Once | One activity instance is instantiated. All events / modules contained in the instance will only execute once |
Plan per destination |
As an alternative, plan per destination instantiates more than one activity instance either
Limitations to the number of times the Event item executes can be imposed be allocating slots |
Plan per slot (no destinations) | This option is used in conjunction with an IPC Event or server events |