Pattern 19 (Case to Environment - Push)

FLASH animation of Data Interaction - Case to Environment - Push-Oriented pattern


The ability of a case to initiate the passing of data elements to a resource or service in the operational environment.


At its conclusion, each case of the Perform Reconciliation workflow passes its results to the Corporate Audit database for permanent storage.


An alternative (or possible extension) to task-level data passing is to provide facilities for passing data at the level of the case.


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

Figure 15: Data interaction between cases and the operating environment


There are no specific context conditions associated with this pattern.


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.


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.


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.





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

  1. Direct workflow support for case-initiated data passing to external applications at any time
  1. Achievable via programmatic extensions