In BPMN 2.0, how does an event-based gateway model a claim that waits for either the claimant's documents or a 14-day timeout, whichever comes first?

## Deciding by events instead of data Most gateways in BPMN 2.0 (OMG formal/13-12-09) decide by evaluating conditions on data the process already has. Sometimes the decision is not in the process's hands: it depends on what **another participant** does, or on **time passing**. The specification's example is waiting for a customer's "yes" or "no": the path is chosen by which message arrives. The **event-based gateway** models exactly this. In workflow-pattern terms it is the **deferred choice**: the choice is postponed until something happens. It is drawn as a gateway diamond whose marker looks like a **catching multiple intermediate event** (a pentagon inside a double circle). ## How the race works 1. The token arrives at the event-based gateway. 2. Every element in the gateway's **configuration**, meaning the targets of its outgoing flows, becomes ready: each catching event starts waiting for its trigger, and each receive task for its message. 3. The **first** of them to be triggered (or, for a receive task, to complete) wins. A token continues along that branch. 4. All the other branches are **withdrawn**: their events stop waiting and their receive tasks are withdrawn without completing. The specification calls the configuration "a race condition where the first Event that is triggered wins". The gateway itself never throws an exception: if nothing ever happens, the token simply waits, which is why a **timer** branch is the usual safety net. ## Configuration rules - The gateway must have **two or more** outgoing sequence flows, and none of them may carry a condition. - The targets must be **intermediate catch events or receive tasks**. - **Message catch events and receive tasks must not be mixed** in the same configuration. - A receive task used there **must not have boundary events** attached. - Only **message, signal, timer, conditional** and **multiple** (made of those) catch events are valid; error, cancel, compensation and link are not. - Each target must have **no other incoming sequence flow** than the one from the gateway. ## The insurance-claim example After "Request supporting documents", the claim process reaches an event-based gateway with two branches: | Branch | Target | If it wins | |---|---|---| | Documents arrive | message catch event "Documents received" | continue to "Assess claim" | | No reply in time | timer catch event, 14 days | continue to "Close claim as incomplete" | If the documents arrive on day 9, the timer is withdrawn; if day 14 comes first, the documents branch is withdrawn, and a later message no longer finds a waiting event. A third branch, a message event "Claim withdrawn by claimant", would join the same race. ## Why an exclusive gateway cannot do this - An **exclusive** gateway evaluates its conditions the moment the token arrives and moves on at once. It cannot wait, so "has the document arrived?" would be evaluated only once. - An **event-based** gateway does not evaluate data at all; the event that occurs is the decision. ## Variants at the start of a process An event-based gateway can also start a process when its `instantiate` attribute is true and it has no incoming flow; the first event creates the instance. With `eventGatewayType` set to **Parallel**, allowed only when `instantiate` is true, the first message creates the instance and the other events stay active and must still occur, with all messages sharing the same correlation information. In the middle of a process an event-based gateway is always exclusive; a normal parallel gateway is used when several events must all occur. ## Mistakes - Putting conditions on the gateway's outgoing flows. - Mixing a receive task with a message event in one race. - Using an exclusive gateway to "check" for a reply, which never waits. - Leaving out a timer branch, so an instance can wait for ever.