Blog

enterprise-architecture

Video Series: BPMN Sub Process Types

bpmn-19-bpmn-process-diagrams

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.

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.