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 visbility, transactional scope, the handling of internal and external exceptions of events.
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,
Besides simple sub-processes, BPMN defines three special types of sub-processes
A call, event based and transaction.
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.
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.
An event sub-process is started by an event, like a time condition or message received.
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.
An Event sub-process should be drawn with a single thin dotted line.
A Transactional sub-process is a double-lined object, and controlled through a transaction protocol. A transactional sub-process can result in three outcomes. Successful completion is modelled with a normal sequence flow that leaves the transaction.
Failed completion is modelled 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.
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.