Subprocess

Subprocess

A subprocess is an activity that contains other activities, gateways, events, etc. It forms a process itself and serves as part of a larger process. The subprocess is fully defined within the parent process (which is why it is often called an embedded subprocess).

A subprocess has two main usage scenarios:

• Subprocesses can be modeled hierarchically. Many modeling tools allow collapsing subprocesses to hide all details and only show a high-level end-to-end overview of the business process.
• Subprocesses create new event scopes. Events thrown during subprocess execution can be caught by boundary events on the subprocess boundary, creating a scope limited to the subprocess.

Note the following when using subprocesses:

• A subprocess can only have one empty start event and does not allow other types of start events. Note that the BPMN 2.0 specification allows omitting the start and end events of subprocesses, but Zhixin does not currently support omission.
• Sequence flows cannot cross subprocess boundaries.

Diagram

A subprocess is represented as a standard activity (rounded rectangle). If the subprocess is collapsed, only its name and a plus sign are displayed to show a high-level overview of the process:

If the subprocess is expanded, all steps of the subprocess are displayed within the subprocess:

One of the main reasons for using a subprocess is to define a scope for events.

The following process model demonstrates this usage: the two tasks of investigating hardware and investigating software need to be executed in parallel and need to be completed within a given time limit before the secondary support response. Here, the scope of the timer (i.e., the activity that needs to be completed on time) is limited by the subprocess.

Event Subprocess

The event subprocess is newly defined in BPMN 2.0. An event subprocess is a subprocess triggered by an event. Event subprocesses can be added at the process level or at any subprocess level. Events used to trigger event subprocesses are configured using start events. Therefore, it is known that empty start events cannot be used in event subprocesses. Event subprocesses can be triggered by message events, error events, signal events, timer events, or compensation events. When the host scope of the event subprocess (process instance or subprocess) is created, a subscription to the start event is created. When that scope is destroyed, the subscription is deleted.

Event subprocesses can be interrupting or non-interrupting. An interrupting subprocess cancels any execution within the current scope. A non-interrupting event subprocess creates a new parallel execution. Each activity within the host scope can only trigger one interrupting event subprocess, while a non-interrupting event subprocess can be triggered multiple times. Whether a subprocess is interrupting is configured through the start event that triggers the event subprocess.

Event subprocesses cannot have any incoming or outgoing sequence flows. Event subprocesses are triggered by events, so incoming sequence flows are illogical. When an event subprocess ends, either the current scope ends simultaneously (in the case of an interrupting event subprocess) or the parallel execution created by the non-interrupting subprocess ends.

Diagram

Call Activity (Subprocess)

Although they look very similar, in BPMN 2.0, call activities are different from general subprocesses - usually also called embedded subprocesses. Conceptually, both call a subprocess when the process execution reaches that activity.

The difference is that a call activity references a process external to the process definition, while a subprocess is embedded within the original process definition. The main usage scenario for call activities is to call a reusable process definition in multiple different process definitions.

When the process execution reaches the call activity, a new execution is created as a child execution of the execution that reached the call activity. This child execution is used to execute the subprocess and can also be used to create parallel child executions (similar to behavior in ordinary processes). The parent execution will wait for the subprocess to complete before continuing execution along the original process.

Diagram

A call activity is represented as a subprocess with a thick border (both collapsed and expanded). Depending on the modeling tool, a call activity can be expanded, but by default it appears in collapsed form.