Pattern 13 (From Multiple Instance Task)
The ability to pass data elements from a task which supports multiple execution instances to a subsequent task. The data passing occurs at the conclusion of the multiple instance task. It involves aggregating data elements from all instances of the task and passing them to a subsequent task.
At the conclusion of the various instances of the Record Lap Time task, the list of lap times is passed to the Prepare Grid task.
Each execution instance of a multiple instance task effectively operates independently from other instances and as such, has a requirement to pass on data elements at its conclusion to subsequent tasks.
In general, data is passed from a multiple instance task to subsequent tasks when a certain number of the task instances have concluded. The various scenarios in which this may occur are illustrated in Figure 12. These usually coincide with the passing of control from the multiple instance task although data and control flow do not necessarily need to be fully integrated. In the case where data elements are passed by reference, the location rather than the values are passed on at task completion (obviously this implies that the data values may be accessed by other components of the process prior to completion of the multiple instance task as they reside in shared storage).
There are no specific context conditions associated with this pattern.
FLOWer provides facilities for instance-specific data to be aggregated from a series of task instances and passed to a subsequent task. UML 2.0 ADs support this pattern via the ExpansionRegion construct.
One issue that arises with multiple instance tasks is identifying the point at which the output data elements from them are available (in some aggregate form) to subsequent tasks.
In the case of FLOWer, this issue is dependent on where the data elements are accessed from. The FLOWer engine allows parallel task instances to access output data elements from other instances even if these instances have not yet completed (i.e. the values obtained, if any, may not be final). However subsequent task instances (i.e. those after the multiple instance task), can rely on the complete composite data element being available. UML 2.0 ADs only allow data to be aggregated when all task instances are complete and this data element is only available once aggregation has occurred.
An offering achieves full support if it has a construct that 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.
|Staffware||9||-||Multiple instance tasks not supported|
|Websphere MQ Workflow||3.4||-||No support for multiple instances|
|FLOWer||3.0||+||As for Pattern 12|
|XPDL||1.0||-||No support for multiple instances|
|UML||2.0||+||Directly supported by the ExpansionRegion construct (where the ExpansionKind mode is set to parallel).|
|Oracle BPEL||10.1.2||+/-||For non-directly supported MI task, a certain number of instances should be complete before the data is passed to the next task|
|jBPM||3.1.4||-||jBPM does not support this pattern as it lacks a notion for multiple instances tasks.|
|OpenWFE||1.7.3||-||OpenWFE does not support data interaction from multiple instances tasks. After the completion of such a task only the values of the last instance to complete (or the first, depending on the specification) are stored.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern as it lacks (multiple instances) task data.|
Summary of Evaluation