Pattern 19 (Case to Environment - Push)
FLASH animation of Data Interaction - Case to Environment - Push-Oriented pattern
Description
The ability of a case to initiate the passing of data elements to a resource or service in the operational environment.
Example
At its conclusion, each case of the Perform Reconciliation workflow passes its results to the Corporate Audit database for permanent storage.
Motivation
An alternative (or possible extension) to task-level data passing is to provide facilities for passing data at the level of the case.
Overview
The various options for this approach to data passing are illustrated in Figure 15. This pattern is analogous to pattern 15 except that it operates in the context of a process instance.
Figure 15: Data interaction between cases and the operating environment
Context
There are no specific context conditions associated with this pattern.
Implementation
This pattern has not been widely observed in the PAIS evaluated. Its implementation requires explicit support by an offering for case-initiated data passing which is independent of the task instances that comprise the case. Maximal flexibility for this pattern is gained through the use of a rule-based approach to the triggering of the data passing action. Potential invocation criteria include state-based conditions (e.g. case initiation, case completion), data-based conditions (e.g. pass the data element when a nominated data condition is satisfied) and temporal conditions (e.g. emit the value of a data element periodically during case execution). FLOWer provides a mechanism for synchronizing case data elements with an external database through the use of mapping constructs which are triggered for each activity in a plan. This provides a mechanism for providing external visibility of data elements during the execution of a case.
Issues
The main issue associated with this pattern is determining an appropriate time to undertake the "push" action of the data element from the case to the environment.
Solutions
There are many points during case execution at which the external communication of a data element does not seem to be sensible. In the case of FLOWer, this action occurs at the conclusion of a specific task (or tasks) within the case. It would also seem to be appropriate at the conclusion of a case.
Evaluation Criteria
An offering achieves full support if it satisfies the context criterion for the pattern.
Product Evaluation
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.
Product/Language |
Version |
Score |
Motivation |
---|---|---|---|
Staffware | 9 | - | Not supported |
Websphere MQ Workflow | 3.4 | - | Not supported |
FLOWer | 3.0 | + | Supported via the mapping construct using Out/Out&Insert type |
COSA | 4.2 | - | Not supported |
XPDL | 1.0 | - | Not reported |
BPEL4WS | 1.1 | - | Not supported |
BPMN | 1.0 | - | Not supported. Message flows can indeed be drawn between the boundaries of two pools, one representing the Process the Case instantiates, and other one representing the Environment. However, the semantics of this construct does not capture data exchange at any moment during the execution of the case |
UML | 2.0 | - | Not supported |
Oracle BPEL | 10.1.2 | - | Not supported |
jBPM | 3.1.4 | - | jBPM does not support this pattern. |
OpenWFE | 1.7.3 | - | OpenWFE does not support this pattern. |
Enhydra Shark | 2 | - | Enhydra Shark can be configured to export all its persistence data to an external database, such as Oracle, DB2, mySQL. This is done through Tool Agents. However, in the evaluated version of the tool, the predefined Tool Agents implementing this connectivity are not available. Therefore, any support for this pattern is considered to be missing. |
Summary of Evaluation
+ Rating |
+/- Rating |
---|---|
|
|