- Control-Flow Patterns
- Data Patterns
- Resource Patterns
- Exception Handling 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 Choice
- Structured Synchronizing Merge
- Multiple Merge
- Structured Discriminator
- Blocking Discriminator
- Cancelling Discriminator
- Structured Partial Join
- Blocking Partial Join
- Cancelling Partial Join
- Generalised AND-Join
- Local Synchronizing Merge
- General Synchronizing Merge
- Thread Merge
- Thread Split
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
- Multiple Instances without Synchronization
- Multiple Instances with a Priori Design-Time Knowledge
- Multiple Instances with a Priori Run-Time Knowledge
- Multiple Instances without a Priori Run-Time Knowledge
- Static Partial Join for Multiple Instances
- Cancelling Partial Join for Multiple Instances
- Dynamic Partial Join for Multiple Instances
State-based patterns reflect situations for which solutions are most easily accomplished in process languages that support the notion of state.
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.
- Cancel Task
- Cancel Case
- Cancel Region
- Cancel Multiple Instance Activity
- Complete Multiple Instance Activity
The following patterns deal with capturing repetitive behaviour in a workflow.
The following patterns deal with the circumstances under which a workflow is considered to be completed.
The following patterns deal with the external signals that may be required to start certain tasks.
Covers the Data Patterns defined by the Workflow Patterns Initiative.
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.
- Task Data
- Block Data
- Scope Data
- Multiple Instance Data
- Case Data
- Folder Data
- Workflow Data
- Environment Data
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
- Data Interaction - Task to Task
- Data Interaction - Block Task to Sub-Workflow Decomposition
- Data Interaction - Sub-Workflow Decomposition to Block Task
- Data Interaction - to Multiple Instance Task
- Data Interaction - from Multiple Instance Task
- Data Interaction - Case to Case
External Data Interaction
- Data Interaction - Task to Environment - Push-Oriented
- Data Interaction - Environment to Task - Pull-Oriented
- Data Interaction - Environment to Task - Push-Oriented
- Data Interaction - Task to Environment - Pull-Oriented
- Data Interaction - Case to Environment - Push-Oriented
- Data Interaction - Environment to Case - Pull-Oriented
- Data Interaction - Environment to Case - Push-Oriented
- Data Interaction - Case to Environment - Pull-Oriented
- Data Interaction - Workflow to Environment - Push-Oriented
- Data Interaction - Environment to Workflow - Pull-Oriented
- Data Interaction - Environment to Workflow - Push-Oriented
- 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.
- Data Transfer by Value - Incoming
- Data Transfer by Value - Outgoing
- Data Transfer - Copy In/Copy Out
- Data Transfer by Reference - Unlocked
- Data Transfer by Reference - With Lock
- Data Transformation - Input
- Data Transformation - Output
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.
- Task Precondition - Data Existence
- Task Precondition - Data Value
- Task Postcondition - Data Existence
- Task Postcondition - Data Value
- Event-based Task Trigger
- Data-based Task Trigger
- Data-based Routing
Covers the Resource Patterns defined by the Workflow Patterns Initiative.
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.
- Direct Distribution
- Role-Based Distribution
- Deferred Distribution
- Separation of Duties
- Case Handling
- Retain Familiar
- Capability-Based Distribution
- History-Based Distribution
- Organisational Distribution
- Automatic Execution
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.
- Distribution by Offer - Single Resource
- Distribution by Offer - Multiple Resources
- Distribution by Allocation - Single Resource
- Random Allocation
- Round Robin Allocation
- Shortest Queue
- Early Distribution
- Distribution on Enablement
- Late Distribution
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.
- Resource-Initiated Allocation
- Resource-Initiated Execution - Allocated Work Item
- Resource-Initiated Execution - Offered Work Item
- System-Determined Work Queue Content
- Resource-Determined Work Queue Content
- Selection Autonomy
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.
- Stateful Reallocation
- Stateless Reallocation
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 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.
At Work Item Level
- continue-offer (OCO)
- reoffer (ORO)
- force-fail-o (OFF)
- force-complete-o (OFC)
- continue-allocation (ACA)
- reallocate (ARA)
- reoffer-a (ARO)
- force-fail-a (AFF)
- force-complete-a (AFC)
- continue-execution (SCE)
- restart (SRS)
- reallocate-s (SRA)
- reoffer-s (SRO)
- force-fail (SFF)
- force-complete (SFC)
At Case Level