Structural

Sub processes are used to break complex processes down into logical units of work. They can be embedded within a process, or used to start a completely different process.

Sub Process

A sub process is an activity that contains other workflow element, which form a process in its own right. A sub process is completely defined inside a parent process (that's why it's often called an embedded sub process).

Sub processes have four major use cases:

• Sub processes allow hierarchical modelling.
• Sub-processes provide a convenient way to divide a complex process into logical stages.
• Sub-processes are also a logical place to add timers and other boundary events (although some of these are also supported on tasks).
• A sub process creates a new scope for events. Events that are thrown during execution of the sub process can be caught by a boundary event on the boundary of the sub process, thus creating a scope for that event limited to the sub process.

Using a sub process does impose some constraints:

• A sub process can only have a single basic start event, no other start event types are allowed. A sub process must have at least have one end event.
• Sequence flow cannot cross sub process boundaries.

Example

Here a sub process is used to define two parallel user tasks. Both tasks need to be completed before the execution moves onto the next user task. A boundary timer event will be triggered if either task isn't completed within a set time.

Transactional Sub Processes

Sub processes can be marked as transactional. This groups all activities within the sub process into one transaction. Should one of the activities error, or be cancelled, all activities will be undone.

A transaction can have three different outcomes:

• The transaction is successful. If it is neither cancelled nor terminated by a hazard the transaction sub process is successful and is left using the outgoing sequence flow.
• The transaction is cancelled. If an execution reaches a cancel end event all executions in the sub process are terminated and can be rolled back using compensation activities.
• The transaction is ended by a hazard. Transactional sub process activities are interrupted without any compensation and the execution continues with an intermediate error event.

Event Sub Process

An event sub process is a sub process that is triggered by an event. An event sub process can be added at the process level or at any sub process level. An event sub process can be triggered using message events and error events. The subscription to the start event is created when the scope (process instance or subprocess) hosting the event sub process is created. The subscription is removed when the scope is destroyed.

An event sub process can only be interrupting, which cancels any executions in the current scope. 

An event sub process does not have any incoming or outgoing sequence flows. Since an event sub process is triggered by an event, an incoming sequence flow makes no sense. 

Example

In this example the two disconnected parts are part of the same process definition. If either of the two API calls throws a BPMN error, the error handling sub-process is invoked and the workflow engine will not attempt to continue the main process flow.

Call Activity 

BPMN 2.0 makes a distinction between a regular sub process, often also called embedded sub process, and a call activity, which looks very similar. From a conceptual point of view, both will call a sub process when process execution arrives at the activity.

The difference is that a call activity references a process that is external to the current process definition (ie a separate workflow model), whereas a subprocess is embedded within the original process definition. The main use case for a call activity is to have a reusable process definition that can be called from multiple other process definitions.

When a process execution arrives at the call activity, a new execution is created that is a sub-execution of that execution. This sub-execution is then used to execute the subprocess, potentially creating parallel child executions as within a regular process. The original execution waits until the subprocess has completely ended, and continues the original process afterwards.

Variables in Sub Processes

Starting a sub process using a call activity bypasses the Workflow worker's startProcess function. This means that all of the standard process variables normally present in a process instance are not generated. The sub process will only have the variables you pass to it using the "in parameters". This also means that sub processes do not have business keys

Example

This simplified example shows a call activity with three in parameters, a single out parameter, and how they appear as variables in the parent and target processes.

Parent Model

The call activity targets a process called callactivitytarget.

In Parameters

The call activity creates three variables in the target process when it starts. These variables will have the names you set as their "target". myVariableName is a process variable with the value "myVariableValue" set in a preceding script task - note the two ways of referencing it.

Source is the name of a variable. Source Expression can be a ${...} expression or a string. Target names can be the same as the name of the source variable if you prefer.

Variables in the Target Process

Here you can see the three variables and their values created in the target process by the call activity.

variableSetInTarget was created during the execution of the target process.

Out Parameters

The out parameters take a process variable from the completed target process and make it available in the parent.

And here's how the variable created by the out parameters appears in the parent process: