Workflow Data Patterns

Download of the data patterns paper:

N. Russell, A.H.M. ter Hofstede, D. Edmond, and W.M.P. van der Aalst.
Workflow Data Patterns. (PDF, 423 Kb).
QUT Technical report, FIT-TR-2004-01, Queensland University of Technology, Brisbane, 2004.

Introduction

Workflow systems seek to provide an implementation vehicle for complex, recurring business processes. Notwithstanding this common objective, there are a variety of distinct features offered by commercial workflow management systems. These differences result in significant variations in the ability of distinct tools to represent and implement the plethora of requirements that may arise in contemporary business processes. Many of these requirements recur quite frequently during the requirements analysis activity for workflow systems and abstractions of these requirements serve as a useful means of identifying the key components of workflow languages. Previous work has identified a number of Workflow Control-flow Patterns which characterise the range of control flow constructs that might be encountered when modelling and analysing workflow. In this web site you will find a series of Workflow Data Patterns that aim to capture the various ways in which data is represented and utilised in workflows. By delineating these Patterns in a form that is independent of specific workflow technologies and modelling languages, we are able to provide a comprehensive treatment of the workflow data perspective and we subsequently use these Patterns as the basis for a detailed comparison of a number of commercially available workflow management systems and business process modelling languages.

Before you view the different data patterns, you may wish to examine one of the following options to gain a better understanding of the work presented to you:

  • To get a better understanding of the data characteristics that occur repeatedly in workflow systems, go to the data characterisation web page.
  • To get a better understanding of the basic terms and concepts used in this body of work, go to the workflow structure web page.

Data Visibility

Within the context of a process, there are a variety of distinct ways in which data elements can be defined and utilized. Typically these variations relate to the process construct to which they are anchored and the scope in which they are accessible. More importantly, they directly influence the way in which the data element may be used, e.g. to capture production information, to manage control data or for communication with the external environment. Here we consider each of the potential contexts in which a data construct can be defined and utilized.

  1. Task Data
  2. Block Data
  3. Scope Data
  4. Multiple Instance Data
  5. Case Data
  6. Folder Data
  7. Workflow Data
  8. Environment Data

Data Interaction

Here we examine the various ways in which data elements can be passed between components in a process and how the characteristics of the individual components can influence the manner in which the trafficking of data elements occurs. Of particular interest is the distinction between the communication of data between components within a process as against the data-oriented interaction of a process element with the external environment.

Internal Data Interaction

  1. Data Interaction - Task to Task
  2. Data Interaction - Block Task to Sub-Workflow Decomposition
  3. Data Interaction - Sub-Workflow Decomposition to Block Task
  4. Data Interaction - to Multiple Instance Task
  5. Data Interaction - from Multiple Instance Task
  6. Data Interaction - Case to Case

External Data Interaction

  1. Data Interaction - Task to Environment - Push-Oriented
  2. Data Interaction - Environment to Task - Pull-Oriented
  3. Data Interaction - Environment to Task - Push-Oriented
  4. Data Interaction - Task to Environment - Pull-Oriented
  5. Data Interaction - Case to Environment - Push-Oriented
  6. Data Interaction - Environment to Case - Pull-Oriented
  7. Data Interaction - Environment to Case - Push-Oriented
  8. Data Interaction - Case to Environment - Pull-Oriented
  9. Data Interaction - Workflow to Environment - Push-Oriented
  10. Data Interaction - Environment to Workflow - Pull-Oriented
  11. Data Interaction - Environment to Workflow - Push-Oriented
  12. Data Interaction - Workflow to Environment - Pull-Oriented

Data Transfer Patterns

Here we consider the manner in which the actual transfer of data elements occurs between one process component and another. These patterns serve as an extension to those presented in the Data Interaction patterns and aim to capture the various mechanisms by which data elements can be passed across the interface of a process component.

The specific style of data passing that is used in a given scenario depends on a number of factors including whether the two components share a common address space for data elements, whether it is intended that a distinct copy of an element is passed as against a reference to it and whether the component receiving the data element can expect to have exclusive access to it. These variations give rise to a number of distinct patterns as described below.

  1. Data Transfer by Value - Incoming
  2. Data Transfer by Value - Outgoing
  3. Data Transfer - Copy In/Copy Out
  4. Data Transfer by Reference - Unlocked
  5. Data Transfer by Reference - With Lock
  6. Data Transformation - Input
  7. Data Transformation - Output

Data-based Routing

Whereas the above sections have examined characteristics of data elements in isolation from other process perspectives (i.e. control, resource, etc.), the following patterns capture the various ways in which data elements can interact with other perspectives and influence the overall operation of a process instance.

  1. Task Precondition - Data Existence
  2. Task Precondition - Data Value
  3. Task Postcondition - Data Existence
  4. Task Postcondition - Data Value
  5. Event-based Task Trigger
  6. Data-based Task Trigger
  7. Data-based Routing

Disclaimer

We, the authors and the associated institutions, assume no legal liability or responsibility for the accuracy and completeness of any product-specific information contained in this body of work. All possible efforts have been make to ensure that the results presented are, to the best of our knowledge, up to date and correct.