skip to content

In BPMN 2.0, what exactly does a converging inclusive gateway wait for, and why is its synchronisation harder than a parallel join's?

level: seniorimportance: nice to knowfreq 25%

answer

  1. only branches that can still arrive
  2. look upstream, not just at inputs
  3. non-local semantics
  4. complex gateway reuses it for reset

basics

~20 s

In BPMN 2.0 a converging inclusive gateway waits for any token that can still reach its empty inputs. A parallel join checks only its own inputs; the inclusive join must inspect paths across the whole model, so it is non-local and hard to verify.

solid answer

~50 s

A converging **inclusive** gateway synchronises **only the branches that were started**. The specification's rule is path-based: the gateway fires when at least one incoming flow has a token and every token elsewhere in the model that could still reach one of its **empty** inputs, without passing through the gateway, could also reach an input that **already** has a token. In practice: it keeps waiting while an upstream token may still arrive, and fires once none can. A parallel join is **local**: it just checks whether each of its own inputs has a token. The inclusive join is **non-local**: it depends on where every token in the instance is and which paths exist, which is costly to compute, fragile in loops and easy to misread. In the claim process, if the inclusive split started only the medical-report branch, the join fires when that report arrives; if it started both, it waits for both.

go deeper

for a junior

Recall that an inclusive join waits only for the branches that were actually started by the matching inclusive split.

for a middle

Explain why neither a parallel join nor an exclusive merge can close an inclusive split correctly, using token counts.

for a senior

Explain the non-local rule, why it is costly and fragile in unstructured or looping models, and restrict inclusive joins to structured blocks.

for a principal

Decide whether a process library may use inclusive and complex joins at all, trading expressiveness against analysability and consistent behaviour across tools.

## The problem the inclusive join solves A diverging inclusive gateway in BPMN 2.0 (OMG formal/13-12-09) starts **some** of its branches: every branch whose condition is true. In the insurance-claim process, "Claimant injured?" and "Theft or collision?" may start a medical-report branch, a police-report branch, or both. The branches must meet again before "Assess liability". The join must wait for **exactly the branches that were started**: - a parallel join would wait for both, deadlocking whenever only one report was requested; - an exclusive merge would pass the first report through and then again the second, running the assessment twice. The converging **inclusive** gateway is BPMN's answer: it waits for tokens that are still on their way and for no others. ## The rule in the specification The execution semantics (Table 13.3) activate an inclusive gateway when: 1. **at least one** incoming sequence flow has a token, and 2. for **every** directed path of sequence flow that starts at a flow with a token somewhere in the diagram, ends at an incoming flow of the gateway that has **no** token, and does not pass through the gateway itself, 3. there is **also** a directed path from that same token to an incoming flow of the gateway that **has** a token, again not passing through the gateway. Informally: the gateway may fire once no token could still arrive at an input that is empty, except tokens that could just as well reach an input already occupied. When it fires, it consumes one token from each incoming flow that has one, then evaluates its outgoing conditions like an inclusive split. ## Why it is harder than a parallel join | | Parallel join | Inclusive join | |---|---|---| | Looks at | its own incoming flows | the positions of all tokens and the paths of the whole model | | Decision | "does every input have a token?" | "can any token still reach an empty input?" | | Locality | **local** | **non-local** | | Cost | constant per check | a reachability analysis over the process graph | | Behaviour in loops | clear | subtle: tokens looping back may or may not count as still coming | The consequences for modellers and for anyone executing models: - **Implementation cost.** Deciding whether to fire needs graph reachability from every token, re-evaluated as tokens move. - **Readability.** Whether the join fires cannot be seen by looking at the join; the reader must reason about the whole model. - **Unstructured models.** When the inclusive split and join do not form a clean block, or tokens from elsewhere can reach the join, its behaviour becomes hard to predict. The safe practice is to use an inclusive join only to close a **matching inclusive split** in a structured block. ## The complex gateway, at a glance The **complex gateway** (asterisk marker) covers synchronisation the others cannot express, such as "continue after two of three expert opinions". Its `activationCondition`, which may refer to the number of tokens on each incoming flow, decides when it fires. - When the condition becomes true, it consumes the tokens present and produces tokens according to its outgoing conditions, like an inclusive split, then switches from **waiting for start** to **waiting for reset**. - It then waits for the remaining branches, using the **inclusive gateway's synchronisation rule** to know which of them can still arrive, and resets once they have. - If the activation condition never becomes true, tokens are blocked at the gateway, which the specification warns may deadlock the whole process. ## Practical guidance - Close inclusive splits with inclusive joins in structured blocks; avoid feeding an inclusive join from unrelated parts of the model. - Where a subset of branches is known in advance, a parallel block per case may be clearer than one inclusive block. - Use the complex gateway sparingly and document its activation condition in the diagram.

  • In BPMN 2.0, what does a complex gateway do once its activation condition has fired?
    It switches from waiting for start to waiting for reset. It waits for tokens on the remaining incoming flows that can still arrive, judged by the inclusive gateway's synchronisation rule, consumes them when they come, may produce further tokens depending on its outgoing conditions, and returns to waiting for start.
  • In BPMN 2.0, can an inclusive split start no branch at all?
    In principle any combination from zero to all may be taken, but the specification says the model should ensure at least one is taken. If no condition is true, the default flow gets the token; with no default, the gateway throws an exception.

A parallel join is a host who waits until every chair at the table is filled; an inclusive join is a host who checks the guest list and the road outside, and starts dinner once nobody else who was invited can still arrive.

saying these in an interview costs you the question

  • An inclusive join waits for every incoming branch, like a parallel join.
  • An inclusive join fires as soon as the first token arrives.
  • An inclusive join only needs to look at its own incoming flows.
  • A complex gateway can never deadlock a process.
  • Any inclusive split may be safely closed with a parallel join.