Pattern 2 (Block Data)

FLASH animation of Block Data - Global pattern

FLASH animation of Block Data - Reference pattern

FLASH animation of Block Data - Value pattern


Block tasks (i.e. tasks which can be described in terms of a corresponding subprocess) are able to define data elements which are accessible by each of the components of the corresponding subprocess.


All components of the subprocess which define the Assess Investment Risk block task can utilise the security details data element.


The manner in which a block task is implemented is usually defined via its decomposition into a subprocess. It is desirable that data elements available in the context of the undecomposed block task are available to all of the components that make up the corresponding subprocess. Similarly, it is useful if there is the ability to define new data elements within the context of the subprocess that can be utilised by each of the components during execution.


Figure 3 illustrates both of these scenarios, data element M is declared at the level of the block task C and is accessible both within the block task instance and throughout each of the task instances (X, Y and Z) in the corresponding subprocess. Similarly data element N is declared within the context of the subprocess itself and is available to all task instances in the subprocess. Depending on the actual offering, it may also be accessible at the level of the corresponding block task.

Figure 3: Block level data visibility

Figure 3: Block level data visibility


There are no specific context conditions associated with this pattern.


The concept of block data is widely supported and all of the offerings examined in this survey which supported the notion of subprocesses (footnote 1) implemented it in some form. Staffware allows subprocess to specify their own data elements and also provides facilities for parent processes to pass data elements to subprocesses as formal parameters. In Websphere MQ Workflow, subprocesses can specify additional data elements in the data container that is used for passing data between task instances within the subprocess and restrict their scope to the subprocess. FLOWer, COSA and iPlanet also provide facilities for specifying data elements within the context of a subprocess.


A major consideration in regard to block-structured tasks within a process is the handling of block data visibility where cascading block decompositions are supported and data elements are implicitly inherited by subprocesses. As an example, in the preceding diagram block data sharing would enable a data element declared within the context of task C to be utilised by task X, but if X were also a block task would this data element also be accessible to task instances in the sub-workflow corresponding to X?


One approach to dealing with this issue adopted by workflow tools such as Staffware is to only allow one level of block data inheritance by default i.e. data elements declared in task instance C are implicitly available to X, Y and Z but not to further subprocess decompositions. Where further cascading of data elements is required, then this must be specifically catered for.

COSA allows a subprocess to access all data elements in a parent process and provides for arbitrary levels of cascading (footnote 2), however updates to data elements in subprocess are not automatically propagated back to the parent task.

Evaluation Criteria

An offering achieves full support if it satisfies the description 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 + Directly supported - each (sub)procedure can maintain a distinct set of data fields
Websphere MQ Workflow 3.4 + Supported via global data containers for a process
FLOWer 3.0 + Each plan can have its own data elements
COSA 4.2 + Workflows can be nested and attributes of the form provide a means of supporting block data
XPDL 1.0 + Supported through the block activity construct
BPEL4WS 1.1 - Sub-processes are not supported
BPMN 1.0 + Through the attribute Properties of a Sub-Process. The Properties defined for a Sub-Process are local and accessible to all Sub-Process components.
UML 2.0 + Directly supported through parameters to activities which are accessible to all activity components
Oracle BPEL 10.1.2 - Not supported
jBPM 3.1.4 -

jBPM does not support block data.
- The notion of Super State in jPDL is intended for grouping nodes into logical units and provides hence the semantics of blocks. However, it is not currently possible to in the GPD define the components composing a Super State.
- The notion of Process State in jPDL is introduced for facilitating the invocation of sub-processes which are described in terms of distinct process fragments to the main process definition. However, the use of this construct is problematic when the process definition is done through the GPD. Hence, block data is not yet considered to be supported.

OpenWFE 1.7.3 + OpenWFE supports block data through the notion of sub-processes and local variable binding (i.e. through the notion of ./varname).
Enhydra Shark 2 + Enhydra Shark does support block data through sub-flow variables, which are local for a sub-flow. (They are not visible to the calling process.) It is also possible to define block activities. However, variables in block processes are global for the entire workflow.

Summary of Evaluation

+ Rating

+/- Rating

  1. Data can be explicitly declared at block task level with block task level scoping.
  2. Data support exists within the workflow tool
  3. Facilities exist for formal parameter passing to and from a block
  1. Block data can be indirectly specified via a programmatic implementation of a block task or sub-workflow