Pattern 39 (Chained Execution)
The ability to automatically start the next work item in a case once the previous one has completed. The transition to Chained Execution mode is at the instigation of the resource.
Immediately commence the next work item in the Emergency Rescue Coordination process when the preceding one has completed.
The rationale for this pattern is that case throughput is expedited when a resource is allocated sequential work items within a case and when a work item is completed, its successor is immediately initiated. This has the effect of keeping the resource constantly progressing a given case.
Chained Execution involves a resource undertaking work items in the same case in "chained mode" such that the completion of one work item immediately triggers its successor which is immediately placed in the resource's work list with a started status. This pattern is illustrated by the transition R:chained_execution in Figure 7. It is important to note that this transition is represented by a dashed line because it jumps from one work item to another, i.e., it links the life-cycles of two different work items.
There are no specific context conditions associated with this pattern.
In order to implement this pattern effectively, the majority (if not all) of the work items for a given case need to be allocated to the same resource and it must execute them in a strict sequential order. This approach to work distribution is best addressed by a case handling system and not surprisingly FLOWer offers direct support for it. The manner in which work items are initiated in BPMN and UML 2.0 ADs (i.e. as soon as the required number of initiating tokens are received) implies that this pattern is the default behaviour exhibited during process execution.
Chained Execution offers a means of achieving rapid throughput for a given case however in order to ensure that this does not result in an arbitrary delay of other cases, it is important that cases are distributed across the widest possible range of resources and that the distribution only occurs when a resource is ready to undertake a new case.
This issue is managed in FLOWer by defining Work Profiles that distribute cases appropriately and ensuring that resources only request new case allocation when they are ready to commence the associated work items.
An offering achieves full support if it satisfies the description for the pattern.
To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.
|Websphere MQ Workflow||3.4||-||Not supported|
|FLOWer||3.0||+||Directly supported by Open Action Mode setting|
|BPMN||1.0||+||Once an activity is completed, subsequent activity(ies) receive a control flow token and are triggered immediately when the specified Start Quantity of tokens is reached|
|UML||2.0||+||Directly supported. Once an action is completed, subsequent actions receive a control-flow token and are triggered immediately|
|Oracle BPEL||10.1.2||-||Although Oracle BPEL PM offers the "continue task" pattern which allows one workflow to be continued with another workflow, the transition between the workflows is not automatic and requires a work item to be selected for the worklist. Therefore, Oracle BPEL PM offers no support for this pattern|
|jBPM||3.1.4||-||jBPM does not support this pattern, as a work item can not be started by the system. A resource alone can initiate the execution of a work item.|
|OpenWFE||1.7.3||-||OpenWFE does not support this pattern as a work item can not be started by the system. A resource alone can initiate the execution of a work item.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern.|
Summary of Evaluation