Pattern 35 (Cancelling Partial Join for Multiple Instances)
Within a given process instance, multiple concurrent instances of a task (say m) can be created. The required number of instances is known when the first task instance commences. Once n of the task instances have completed (where n is less than m), the next task in the process is triggered and the remaining m-n instances are cancelled.
Run 500 instances of the Protein Test task with distinct samples. Once 400 of these have completed, cancel the remaining instances and initiate the next task.
This pattern provides a variant of the Multiple Instances with a prior Runtime Knowledge pattern that expedites process throughput by both allowing the process to continue to the next task once a specified number (n) of the multiple instance tasks have completed and also cancels any remaining task instances negating the need to expend any further effort executing them.
Figure 53 illustrates the operation of this pattern. It is similar in form to that for the Static Partial Join for Multiple Instances pattern (WCP34) but functions in a different way once the join has fired. At this point any remaining instances which have not already commenced are "bypassed" by allowing the skip task to execute in their place. The skip task executes almost instantaneously for those and the pattern is almost immediately able to reset.
Figure 53: Static cancelling partial join implementation for multiple instances
This pattern shares four context conditions with the Static Partial Join for Multiple Instances pattern: (1) the number of concurrent task instances (denoted by the variable m in Figure 52) is known prior to task commencement and (2) the number of tasks that need to complete before subsequent tasks in the process model can be triggered (denoted by variable n in Figure 52) is known prior to task commencement.
This pattern relies on the availability of a Cancel Task or Cancel Region capability within an offering and at least one of these patterns needs to be supported for this pattern to be facilitated. As for WCP34, both BPMN and XPDL appear to offer support for this pattern by associating an error type intermediate trigger with the multiple instance task. Immediately following this task is a task that issues a cancel event effectively terminating any remaining task instances once the first n of them have completed. However it is unclear how the ComplexMI_FlowCondition should be specified to allow the cancellation to be triggered once n task instances have completed.
Full support for this pattern is demonstrated by any offering which provides a construct which satisfies the description when used in a context satisfying the context assumption. An offering achieves partial support if there is any ambiguity associated with the implementation of the pattern (e.g. if it is unclear how the join condition is specified).
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||3.4||-||Not supported. There is no direct support for multiple instance activities.|
|FLOWer||3.51||-||Not supported. Dynamic subplans can have an auto complete condition however this is only evaluated when all subplans have completed.|
|COSA||5.1||-||Multiple instance activities are not supported.|
|iPlanet||3.0||-||No support for multiple instance activities.|
|SAP Workflow||4.6c||-||Not supported. Via "dynamic processing with a multi-line container element" it is possible to create an instance for each row in a table. However, these instances are supposed to complete.|
|BPEL||1.1||-||No support for multiple activity instances.|
|Websphere Integration Developer||6.0||-||No support for multiple activity instances.|
|Oracle BPEL||10.1.2||-||No support for multiple activity instances.|
|BPMN||1.0||+/-||Notionally achievable via a MI task (as for WCP34) which has an error type intermediate event trigger at the boundary. Immediately after the MI task is an activity that issues a cancel event to terminate any remaining MI activities. However the same issue arises as for WCP34 in that it is unclear how the ComplexMI_FlowCondition should be specified.|
|XPDL||2.0||+/-||Notionally achievable via a MI task which has an error type intermediate event trigger at the boundary. Immediately after the MI activity is an activity that issues a cancel event to terminate any remaining MI activities. However as for WCP34, it is unclear how the ComplexMI_FlowCondition is actually specified.|
|UML ADs||2.0||-||Not supported. A MI activity can only complete when all N instances specified in the ExpansionRegion have completed.|
|EPC (implemented by ARIS toolset 6.2)||-||Not supported.|
|jBPM||3.1.4||-||jBPM does not support this pattern.|
|OpenWFE||1.7.3||+||OpenWFE supports this pattern through the attribute count of the <concurrent-iterator>. Count defines the number of instances of the multiple instances task that need to complete before the synchronization is done and the flow can continue. The attribute remaining is set to "cancel" so that not completed instances get cancelled.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern.|