Pattern 10 (Block Task to Sub-Workflow Decomposition)

FLASH animation of Data Interaction - Block Task to Sub-Workflow Decomposition - Explicit Data Passing via Data Channels pattern

FLASH animation of Data Interaction - Block Task to Sub-Workflow Decomposition - Explicit Data Passing via Parameters pattern

FLASH animation of Data Interaction - Block Task to Sub-Workflow Decomposition - Implicit Data Passing pattern

Description

The ability to pass data elements from a block task instance to the corresponding subprocess that defines its implementation. Any data elements that are available to a block task are able to be passed to (or be accessed) in the associated subprocess although only a specifically nominated subset of those data elements are actually passed to the subprocess.

Example

Customer claims data is passed to the Calculate Likely Tax Return block task whose implementation is defined by a series of tasks in the form of a subprocess. The customer claims data is passed to the subprocess and is visible to each of the tasks in the subprocess.

Motivation

In order for subprocesses to be used in an effective manner within a process model, a mechanism is required that allows data elements to be passed to them.

Overview

Most PAIS support the notion of composite or block tasks in some form. These are analogous to the programmatic notion of procedure calls and indicate a task whose implementation is described in further detail at another level of abstraction (typically elsewhere in the process design) using the same range of process constructs. The question that arises when data is passed to a block element is whether it is immediately accessible by all of the tasks that define its actual implementation or if some form of explicit data passing must occur between the block task and the subprocess. Typically one of three approaches is taken to handling the communication of parameters from a block task to the underlying implementation. Each of these is illustrated in Figure 11. The characteristics of each approach are as follows:

Figure 11: Approaches to data interaction from block tasks to corresponding sub-workflows

Context

There are no specific context conditions associated with this pattern.

Implementation

All of the approaches described above have been observed in the offerings examined. The first approach does not involve any actual data passing between block activity and implementation, rather the block level data elements are made accessible to the subprocess. This strategy is utlized by FLOWer, COSA and BPMN for data passing to subprocesses. In all cases, the subprocess is presented with the entire range of data elements utilised by the block task and there is no opportunity to limit the scope of items passed.

The third approach relies on the passing of data elements between tasks to communicate between block task and subprocess. Both Staffware and XPDL utilize this mechanism for passing data elements to subprocesses.

In contrast, the second approach necessitates the creation of new data elements at subprocess level to accept the incoming data values for the block activity. WebSphere MQ follows this strategy and sink and source nodes are used to pass data containers between the parent task and corresponding subprocess. iPlanet does so using parameters based on commonly named process attributes in the parent task and subprocess. BPMN and UML 2.0 ADs can also utilize this approach through InputPropertyMaps expressions (and OutputPropertyMaps where the data passing is from subprocess to parent task) and Parameters respectively.

Issues

One consideration that may arise where the explicit parameter passing approach is adopted is whether the data elements in the block task and the subprocess are independent of each other (i.e. whether they exist in independent address spaces). If they do not, then the potential exists for concurrency issues to arise as tasks executing in parallel update the same data element.

Solutions

This issue can arise with Staffware where subprocess data elements are passed as fields rather than parameters. The resolution to this issue is to map the input fields to fields with distinct names not used elsewhere during execution of the case.

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 it is not possible to limit the range of data elements which are accessible to the subprocess.

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.

Summary of Evaluation