In a business process, sub-processes have several use cases, including:
- hiding the complexity of a business process
- and defining a contextual scope that can be used for:
- data visibility
- transactional scope
- the handling of internal and external exceptions of events
- or for compensation.
Figure 1: A business process with a sub-process
Figure 2: Hiding the complexity of a business process
Figure 3: Contextual scope – data visibility
Figure 4: Contextual scope – Transactional scope
Figure 5 Contextual scope – internal exceptions
Figure 6: Contextual scope – external exceptions
Besides simple sub-processes, BPMN defines three special types of sub-processes: call, event-based, and transactions.
A call sub-process represents a reusable sub-process. It identifies a point in the process where a global sub-process is used. A call sub-process object must have a thick boundary line.
Figure 7: Call sub-process
An Event based sub-process is used within a process or sub-process. An Event sub-process is not part of the normal flow of its parent process, which means that it has no incoming or outgoing sequence flows.
Figure 8: Event sub-process
An event sub-process is started by an event, like a time condition or message received.
Figure 9: Event sub-process triggered by a timer event
There are two possible consequences to the parent process when an Event sub-process is triggered: Either the parent process can be interrupted, or the parent process can continue its work. This is determined by the type of start event used – interrupting or non-interrupting event.
Figure 10: Event sub-process stops the main process
Figure 11: Event sub-process does not stop the main process
An Event sub-process should be drawn with a single thin dotted line.
Figure 12: Event sub-process visual representation
A Transactional sub-process is a double-lined object, and controlled through a transaction protocol.
Figure 13: Transactional sub-process
A transactional sub-process can result in three outcomes. Successful completion is modelled with a normal sequence flow that leaves the transaction.
Figure 14: Successful completion of a transaction
Failed completion is modeled with a sequence flow starting at a cancel intermediate event. This occurs if any of the pre-determined criteria of failure are met or if an ‘Abort’ message is received. In both cases the non-normal flow is executed, meaning none of the tasks in the transaction are completed.
Figure 15: Cancelling a transaction
Hazard is modelled with a sequence flow starting at an error intermediate event. A hazard means that something went terribly wrong and so a normal success or cancel is not possible. When a hazard occurs, any of the tasks in the transaction end up not being executed or compensated.
Figure 16: Hazard in a transaction