Pattern 14 (Case to Case)
The passing of data elements from one case of a process during its execution to another case that is executing concurrently.
During execution of a case of the Re-balance Portfolio workflow the best price identified for each security is passed to other cases currently executing.
Where the results obtained during the course of one process instance are likely to be of use to other cases, a means of communicating them to both currently executing and subsequent cases is required.
Direct support for this pattern requires the availability of a function within the PAIS that enables a given case to initiate the communication (and possibly updating) of data elements with a distinct process instance. Alternatively, it is possible to achieve the same outcome indirectly by writing them back to a shared store of persistent data known to both the initiating and receiving cases. This may be either an internally maintained facility at process level or an external data repository (footnote 5). Both of these scenarios are illustrated in Figure 13.
Figure 13: Data interaction between workflow cases
Each of these approaches requires the communicating cases to have a priori knowledge of the location of the data element that is to be used for data passing. They also require the availability of a solution to address the potential concurrency issues that may arise where multiple cases wish to communicate.
There are no specific context conditions associated with this pattern.
COSA is the only offering examined that supports a direct method for communicating data elements between cases. It achieves this using shared "folder" data elements (cf. the Folder Data pattern (WDP-6)). In the case of the other offerings, it is possible to achieve the same result indirectly for each of them using the methods described above.
The main consideration associated with this pattern is in establishing an effective means of linking related cases and their associated data together in a meaningful way.
None of the offerings examined address this need, however there are PAIS that provide solutions to the issue. In Vectus (footnote 6) it is possible to relate cases. There are four types of relationships "parent", "child", "sibling", and "master". These relationships can be used to navigate through cases at runtime. For example, one case can schedule tasks in another flow, terminate a task in another flow, create new cases, etc. It is also possible to share data using a dot notation similar to Object Constraint Language [OMG03]. The "master" relation can be used to create a proxy shared among related cases to show all tasks related to these cases. A similar construct is also present in the BizAgi (footnote 7) product.
An offering achieves full support if it has a construct that satisfies the description for the pattern. It rates as partial support if it is necessary to store the data element in an intermediate location to pass it between cases.
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||+/-||Achievable via script functions|
|Websphere MQ Workflow||3.4||+/-||Indirectly achievable by including case communication facilities in program implementations|
|FLOWer||3.0||+/-||Indirectly supported via external database|
|COSA||4.2||+||Supported via folder data|
|XPDL||1.0||+/-||Indirectly achievable via coordinated web services operations in sending and receiving cases|
|BPEL4WS||1.1||+/-||Indirectly achievable using the invoke construct|
|Oracle BPEL||10.1.2||-||Not supported|
|jBPM||3.1.4||+/-||jBPM partially supports case-to-case interaction, as such interaction is indirectly achieved through programmatic interaction with an external database, for example, by associating an action with a transition. In this way the general form of case-to-case communication, where a case communicates to all the other cases is supported.|
|OpenWFE||1.7.3||+/-||OpenWFE supports case to case data interaction pattern as data can be passed between cases using global variables (of the form //globalVar). This is considered to constitute partial support for the pattern as it results in the more general communication of a data element from one case to all other cases, and not to one specific case as the pattern intends.|
|Enhydra Shark||2||+/-||Enhydra Shark does not support case to case data interaction directly. Such interaction can be realized through use of an external database; However, it is not possible to target the data to a specific instance, as instances are not aware of the existence of concurrent instances. Hence only the more general form of interaction from a case to all other cases is supported.|
Summary of Evaluation