Subproceso de evento

Información general

An event subprocess lets you react to events at the process or subprocess scope. It is not connected to the main sequence flow.

Instead, the engine triggers it when a configured start event occurs while the enclosing scope is active.

Use an event subprocess when you want to:

• Centralize related error handling logic.
• Avoid duplicating boundary error events across multiple tasks.
• Control behavior at the process or subprocess scope.
• React to external messages at runtime.
• Run recovery, logging, or notification logic consistently.

In Maestro, an event subprocess can start with:

• an error start event
• a message start event

Error start event

An error start event triggers the event subprocess when a BPMN error occurs and the error code matches, or when the event is configured as catch-all.

When a BPMN error is thrown, the engine evaluates matching event subprocesses in the same scope before it evaluates boundary error events. This evaluation order gives the event subprocess priority.

Execution behavior

An error start event is always interrupting.

When the error occurs, the engine:

• Triggers the event subprocess.
• Cancels the enclosing process or subprocess scope.
• Stops all active paths within that scope.

Use an error start event when the error invalidates the current execution.

Real-life examples:

• A payment authorization fails due to fraud detection.
• A mandatory compliance validation fails during onboarding.
• A critical system dependency is unavailable.

Error handling without and with an event subprocess

Without an event subprocess	With an event subprocess
You attach boundary error events to individual tasks.	You define one event subprocess at the process or subprocess scope.
You often duplicate similar error logic across multiple tasks.	You centralize related error handling logic in a single place.
Each task controls its own error handling.	The scope controls error handling for all tasks within it.
Maintenance becomes harder as the model grows.	Maintenance becomes simpler because you update error logic in one place.

Impact on existing models

The engine changes behavior only if you add an event subprocess to the same scope.

• Models that use only boundary error events continue to behave as before.
• If you add an event subprocess, it handles generic errors that are not handled by boundary error events in the same scope.
• If no boundary error event matches a thrown error, the engine evaluates the event subprocess.

Do not configure both a boundary error event and an event subprocess to handle the same error reference within the same scope.

Configuration rules

For a given scope (process or subprocess):

• Use only one event subprocess per error code.
• Use only one catch-all event subprocess.

For a given task:

• Use only one boundary error event per error code.
• Use only one catch-all boundary error event.

Evento de inicio de mensaje

A message start event triggers the event subprocess when the engine receives the configured message while the enclosing scope is active.

Execution behavior

The engine listens for the configured message while the enclosing scope is active. When it receives the message, it triggers the event subprocess according to its interrupting or non-interrupting configuration.

Message start events do not override or take priority over other message events. Each message event reacts independently based on its scope and configuration.

Message handling without and with an event subprocess

Without an event subprocess	With an event subprocess
You model message handling inside the main sequence flow.	You define one event subprocess at the process or subprocess scope.
You must route the main flow through intermediate message catch events.	The engine listens for the message while the scope is active.
The main process must explicitly reach the message event to react to it.	The event subprocess can trigger at any time while the scope is active.
Message handling logic becomes tightly coupled to the main flow structure.	Message handling logic remains independent of the main sequence flow.
Changing message behavior may require restructuring the main flow.	You can update message handling without modifying the main flow.
The main flow always pauses at the message event.	You can configure the message start event as interrupting or non-interrupting.

Impact on existing models

The engine changes behavior only if you add a message start event inside an event subprocess.

• Models that do not use an event subprocess continue to behave as before.
• Once you add a message start event, the engine listens for the configured message while the enclosing scope is active.
• If you configure the message start event as interrupting, the engine cancels the enclosing scope when it receives the message.
• If you configure it as non-interrupting, the engine starts the event subprocess in parallel and allows the main flow to continue.

Do not configure multiple message start events with the same message reference in the same scope.

Interrupting vs non-interrupting

You can configure a message start event as interrupting or non-interrupting.

Interrupting

When the engine receives the message, it:

• Triggers the event subprocess.
• Cancels the enclosing process or subprocess scope.
• Stops all active paths within that scope.

Use an interrupting message start event when the message represents an external signal that should stop the current execution.

Real-life examples:

• A customer cancels an order while it is being processed.
• A regulator sends a stop-processing instruction.
• A parent system sends a termination command.

Non-interrupting

When the engine receives the message, it:

• Triggers the event subprocess.
• Keeps the enclosing scope active.
• Runs the event subprocess in parallel.
• Allows the main process to continue.

Use a non-interrupting message start event when the message should trigger additional logic without interrupting the main flow.

Real-life examples:

• A customer updates contact details while onboarding continues.
• A partner system sends additional metadata.
• A notification message triggers audit logging.