Pattern 18 (Task to Environment - Pull)

FLASH animation of Data Interaction - Task to Environment - Pull-Oriented pattern


The ability of a task to receive and respond to requests for data elements from services and resources in the operational environment.


During execution, the Assess Quality task may receive requests for current data from the Quality Audit web service handler. It must provide this service with details of all current data elements.


In some cases, the requests for access to task instance data are initiated by external processes. These requests need to be handled as soon as they are received but should be processed in a manner that minimises any potential impact on the task instance from which they are sourcing data.


The ability to access data from a task instance can be handled in one of three ways:

  1. The offering can provide a means of accessing task instance data from the external environment.
  2. During their execution, tasks instances publish data values to a well-known location e.g. a database that can be accessed externally.
  3. Task instances incorporate facilities to service requests for their data from external processes.


There are no specific context conditions associated with this pattern.


In practice, this facility is not widely supported as an explicit construct by the offerings examined. BPEL provides direct support for the pattern (via the receive construct and event handlers). Staffware provides the EIS Report construct and EIS Case Data Extraction facilities to enable the values of data elements to be requested from cases. COSA provides APIs for getting the values of various types of workflow data elements from the external environment (both at command line level and also programmatically). iPlanet provides facilities for developing "adaptor" and "proxy" tasks through which external data can be requested from within a process instance. BPMN supports this type of interaction using Message Flows. FLOWer provides an indirect solutions via the chp_frm_getfield API call although this method has limited generality.


Similar difficulties exist with the utilization of this pattern to those identified for Pattern 17.


As for Pattern 17.

Evaluation Criteria

An offering achieves full support if it has a construct that satisfies the description for the pattern. It achieves a partial support rating if programmatic extensions are required to facilitate the data passing.

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 +/- Indirectly supported by EIS Reports and EIS Case Data extraction facility
Websphere MQ Workflow 3.4 +/- Indirectly achievable by including communication facilities in program implementations
FLOWer 3.0 +/- Values of data elements in forms associated with tasks can be queried via CHIP library API
COSA 4.2 + Supported via command line and C/COM/Java APIs
XPDL 1.0 - Not reported
BPEL4WS 1.1 +/- Indirectly achievable via the receive/reply constructs or event handlers although the operation requires specific coding
BPMN 1.0 + Captured through a message flow flowing from the boundary of a Pool representing the Environment to a Task followed by a message flow flowing from the same Task back to the Pool representing the Environment
UML 2.0 - Not supported
Oracle BPEL 10.1.2 + Directly supported through <receive> and <reply>
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 does not support this pattern.

Summary of Evaluation

+ Rating

+/- Rating

  1. Direct workflow support for tasks to respond to external requests for data
  1. Achievable via programmatic extensions