Recognized Patterns

Version 4

Created by thomas.diesler on Oct 27, 2008 9:37 AM. Last modified by thomas.diesler on Dec 19, 2008 7:18 AM.

These patterns are taken from the Workflow Patterns Initiative. For the status of currently supported patters, have a look at BPMSupportedPatterns

Control-Flow Patterns

Covers the Control-Flow Patterns defined by the Workflow Patterns Initiative.

Basic Control Patterns

This class of patterns captures elementary aspects of process control

Advanced Branching and Synchronization Patterns

A series of patterns which characterise more complex branching and merging concepts which arise in business processes.

Multiple Instances Patterns

Multiple instance patterns describe situations where there are multiple threads of execution active in a process model which relate to the same activity

State-based patterns

State-based patterns reflect situations for which solutions are most easily accomplished in process languages that support the notion of state.

Cancellation Patterns

Patterns that have variants that utilize the concept of activity cancellation where enabled or active activity instance are withdrawn. Various forms of exception handling in processes are also based on cancellation concepts.

Iteration Patterns

The following patterns deal with capturing repetitive behaviour in a workflow.

Termination Patterns

The following patterns deal with the circumstances under which a workflow is considered to be completed.

Trigger Patterns

The following patterns deal with the external signals that may be required to start certain tasks.

Data Patterns

Covers the Data Patterns defined by the Workflow Patterns Initiative.

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.

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

External Data Interaction

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.

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.

Resource Patterns

Covers the Resource Patterns defined by the Workflow Patterns Initiative.

Creation Patterns

Creation Patterns correspond to limitations on the manner in which a work item may be executed. They are specified at design time, usually in relation to a task, and serve to restrict the range of resources that can undertake work items that correspond to the task. They also influence the manner in which a work item can be matched with a resource that is capable of undertaking it.

Push Patterns

Push Patterns characterise situations where newly created work items are proactively offered or allocated to resources by the system. These may occur indirectly by advertising work items to selected resources via a shared work list or directly with work items being allocated to specific resources. In both situations however, it is the system that takes the initiative and causes the distribution process to occur.

Pull Patterns

Pull Patterns correspond to the situation where individual resources are made aware of specific work items, that require execution, either via a direct offer from the system or indirectly through a shared work list. The commitment to undertake a specific task is initiated by the resource itself rather than the system. Generally this results in the work item being placed on the specific work list for the individual resource for later execution although in some cases, the resource may elect to commence execution on the work item immediately.

Detour Patterns

Detour Patterns refer to situations where work item distributions that have been made for resources are interrupted either by the system or at the instigation of the resource. As a consequence of this event, the normal sequence of state transitions for a work item is varied.

Auto-Start Patterns

Auto-start patterns relate to situations where execution of work items is triggered by specific events in the lifecycle of the work item or the related process definition. Such events may include the creation or allocation of the work item, completion of another instance of the same work item or a work item that immediately precedes the one in question.

Visibility Patterns

Visibility Patterns classify the various scopes in which work item availability and commitment are able to be viewed by resources. They give a indication of how open to scrutiny the operation of a PAIS is.

Multiple Resource Patterns

Up to this point, the focus of this catalogue of patterns has been on situations where there is a one-to-one correspondence between the resources and work items in a given allocation or execution. In other words, resources cannot work on different work items simultaneously and it is not possible that multiple resources work on the same work item. In situations where people are not restricted by information technology, there is often a many-to-many correspondence between the resources and work items in a given allocation or execution. Therefore, it may be desirable to support this using process technology. Here we discuss patterns relaxing the one-to-one correspondence between resources and work items that we have assumed previously.

Exception Handling Patterns

Covers the Exception Handling Patterns defined by the Workflow Patterns Initiative.

JBossDeveloper