An event subprocess may be interrupting or non-interrupting. An interrupting subprocess cancels any executions in the current scope. A non-interrupting event subprocess spawns a new concurrent execution. While an interrupting event subprocess can only be triggered once for each activation of the scope hosting it, a non-interrupting event subprocess can be triggered multiple times. Whether the subprocess is interrupting or non-interrupting is configured using the start event which triggers the event subprocess.

An event subprocess may not have any incoming or outgoing sequence flows. As an event subprocess is triggered by an event, an incoming sequence flow makes no sense. When an event subprocess is ended, either the current scope is ended (in case of an interrupting event subprocess), or the concurrent execution spawned for the non-interrupting subprocess is ended.

It is represented using XML in the same way as an embedded subprocess. Additionally, the attribute triggeredByEvent must have the value :

• Event subprocesses triggered using an Error Start Event, Signal Start Event, Compensation Start Event, Timer Start Event and Message Start Event are supported.

Example

The following is an example of an event subprocess triggered using an Error Start Event. The event subprocess is located at the “process level”, i.e., is scoped to the process instance:

  <startEvent id="catchError">
    <errorEventDefinition errorRef="error" />
  <sequenceFlow id="flow2" sourceRef="catchError" targetRef="taskAfterErrorCatch" />
</subProcess>

As already stated, an event subprocess can also be added to an embedded subprocess. If it is added to an embedded subprocess, it becomes an alternative to a boundary event. Consider the two following process diagrams. In both cases the embedded subprocess throws an error event. Both times the error is caught and handled using a user task.

as opposed to:

• The embedded subprocess is executed using the same execution which executed the scope it is hosted in. This means that an embedded subprocess has access to the variables local to it’s scope. When using a boundary event, the execution created for executing the embedded subprocess is deleted by the sequence flow leaving the boundary event. This means that the variables created by the embedded subprocess are not available anymore.
• When using an event subprocess, the event is completely handled by the subprocess it is added to. When using a boundary event, the event is handled by the parent process.
  These two differences can help you decide whether a boundary event or an embedded subprocess is better suited for solving a particular process modeling / implementation problem.

Camunda Extensions

Additional Resources

• in the BPMN 2.0 Modeling Reference