In BPMN 2.0, what distinguishes an embedded sub-process, a call activity and an event sub-process, and when is each used?
answer
- thin, thick, dotted borders
- part of the parent or separately defined
- reuse across processes
- no sequence flow in or out
- triggered start event
basics
~20 sIn BPMN 2.0 an embedded sub-process is part of its parent and shares its data; a call activity (thick border) reuses a separately defined process or global task; an event sub-process (dotted border) has no sequence flow and starts on its own trigger.
solid answer
~50 sAn **embedded sub-process** (thin border) is defined inside its parent: it is started by the parent's token, has only a none start event, and can use the parent's data objects. It groups steps into one scope, for example "Assess application" around credit check and underwriter review. A **call activity** (thick border) calls a **global process or global task** defined on its own, so one "KYC check" process can be reused by loans, accounts and cards; data passes only through its declared inputs and outputs, and errors and escalations from the called process propagate to the call activity's boundary. An **event sub-process** (dotted border, `triggeredByEvent="true"`) sits inside a process with **no incoming or outgoing sequence flow** and has exactly one start event with a trigger; when it fires, it runs in the parent's context and either interrupts the parent or runs alongside it, such as "Customer withdraws application".
go deeper
Recall the borders: thin for embedded, thick for call activity, dotted for event sub-process. Know that only the call activity reuses a separately defined process.
Explain the data rules (shared context versus declared inputs and outputs), the none-only start of an embedded sub-process, and interrupting versus non-interrupting event sub-processes.
Decide where reuse belongs, check that a call activity's interface matches the called process exactly, and place error handling where propagation will actually reach it.
Own the library of callable processes: which procedures are shared, who versions them, and how callers are protected when a shared process changes.
## Three kinds of composite activity BPMN 2.0 (OMG formal/13-12-09) gives three ways to put a process inside a process. They look alike (rounded rectangles, collapsed with a `+` marker) but differ in **where they are defined**, **what starts them** and **what data they see**. The border tells them apart: | Kind | Border | Defined | Started by | Data | |---|---|---|---|---| | Embedded sub-process | single thin line | inside the parent process | the parent's token on its incoming sequence flow | sees the parent's data objects | | Call activity | thick line | separately, as a global process or global task | the parent's token; control transfers to the called element | only its declared inputs and outputs | | Event sub-process | single thin dotted line | inside the parent process or sub-process | its own triggered start event | runs in the parent's context | ## Embedded sub-process The BPMN 2.0 **sub-process** corresponds to BPMN 1.2's embedded sub-process. It is part of the parent's definition and cannot be reused elsewhere. - It is instantiated when a token reaches it, and it has **only a none start event** (or no start event at all). - It defines a **scope**: data objects declared inside it live and die with it, and it can access data objects of its parent, since a data object is reachable from its sibling flow elements and their children. - Its main modelling use is to give a group of steps one boundary for **exception handling**, timers and compensation. In a loan approval, "Assess application" can wrap the credit check and the underwriter review so that one 10-day deadline covers both. ## Call activity The **call activity** corresponds to BPMN 1.2's reusable sub-process. It is a wrapper that transfers control to a **callable element**: a process or a **global task**. - Reuse is the reason to use it. A "KYC check" process maintained once can be called from loan, account-opening and card processes. - Its data interface must **exactly match** the called element's inputs, outputs, input sets and output sets. The called process does not see the caller's data objects. - Errors and escalations thrown in the called process **propagate to the call activity** and can be caught on its boundary. - A called process may have triggered start events of its own; those are ignored when it is called, and its none start event is used. - A call activity that calls a global task shows that task type's marker; one that calls a process looks like a collapsed or expanded sub-process, always with a **thick** border. ## Event sub-process An **event sub-process** is a sub-process with `triggeredByEvent` set to true. It is not part of the normal flow at all. 1. It **must not** have incoming or outgoing sequence flows, and it cannot have boundary events attached. 2. It has **exactly one** start event, and that start event **must have a trigger**. Table 10.86 lists the same triggers as boundary events: message, timer, escalation, error, compensation, conditional, signal, multiple and parallel multiple. 3. It may occur zero, one or many times while its parent is active, and it runs **in the parent's context**, so it can read and change the parent's data. 4. Its start event's `isInterrupting` attribute decides the effect on the parent: **interrupting** (the default) cancels the parent's work; **non-interrupting** runs alongside it, and several instances may run at once. An error start event is always interrupting. In the loan process, "Customer withdraws application" is an interrupting message event sub-process that stops the assessment and closes the case; "Customer updates contact details" is a non-interrupting one that updates the data while assessment continues. ## Choosing between them - The steps belong only to this process and need a common scope: **embedded sub-process**. - The same procedure is used by several processes, or is owned by another team: **call activity**. - Something may happen at any time during a scope and must be handled with access to that scope's data: **event sub-process**.
- In BPMN 2.0, how does an error thrown inside a called process reach the caller?Errors and escalations propagate along the hierarchy from the called element to the call activity, so a boundary error event on the call activity catches it. The called process needs no knowledge of who handles it.
- In BPMN 2.0, why might you choose an event sub-process over a boundary event on an embedded sub-process?An event sub-process runs inside the scope and can read and change the scope's data, and a non-interrupting one leaves the scope running. A boundary event's handler is ordinary flow outside the sub-process, so it cannot reach data objects declared inside it. For 'update contact details during assessment', the event sub-process can change the in-scope data directly.
saying these in an interview costs you the question
- A call activity can use the caller's data objects directly.
- An event sub-process is connected to the main flow by a sequence flow.
- An embedded sub-process can be reused by another process.
- An embedded sub-process may start on a message or timer start event.
- An event sub-process always cancels its parent when triggered.