BPMN 2.0 Gateways

From Training Material
Jump to navigation Jump to search

Gateways Overview

  • Gateways are used to control how Sequence Flows interact as they converge and diverge within a Process
  • If the flow does not need to be controlled, then a Gateway is not needed
  • The term “Gateway” implies that there is a gating mechanism that either allows or disallows passage through the Gateway
    • as tokens arrive at a Gateway, they can be:
      • merged together on input and/or
      • split apart on output as the Gateway mechanisms are invoked.

[split apart on inflow and merged on outflow ?]

  • Gateways, like Activities, are capable of consuming or generating additional tokens, effectively controlling the execution semantics of a given Process
  • The main difference is that Gateways do not represent ‘work’ being done and they are considered to have zero effect on the operational measures of the Process being executed (cost, time, etc.).
  • Gateways can define all the types of Business Process Sequence Flow behavior:
    • Decisions/branching (exclusive, inclusive, complex)
    • merging, forking, joining

Exclusive Gateway

  • A diverging Exclusive Gateway (Decision) is used to create alternative paths within a Process flow
  • Only one of the paths can be taken, this means the gateway is exclusive
  • A Decision can be thought of as a question that is asked at a particular point in the Process
  • The question has a defined set of alternative answers
  • Each answer is associated with a condition Expression that is associated with a Gateway’s outgoing Sequence Flows




Element merging exclusive gateway.png

Inclusive Gateway

  • A diverging Inclusive Gateway (Inclusive Decision) can be used to create alternative but also parallel paths within a Process flow
  • Unlike the Exclusive Gateway, all condition Expressions are evaluated
  • The true evaluation of one condition Expression does not exclude the evaluation of other condition Expressions
  • All Sequence Flows with a true evaluation will be traversed by a token
  • Since each path is considered to be independent, all combinations of the paths MAY be taken, from zero to all
  • However, it should be designed so that at least one path is taken.


Element decision inclusive conditional sequence flow.png

Parallel Gateway

  • A Parallel Gateway is used to synchronize (combine) parallel flows and to create parallel flows
  • A Parallel Gateway creates parallel paths without checking any conditions; each outgoing Sequence Flow receives a token upon execution of this Gateway
  • For incoming flows, the Parallel Gateway will wait for all incoming flows before triggering the flow through its outgoing Sequence Flows

Element fork multiple outgoing.png


Element join.png


Complex Gateway

  • The Complex Gateway can be used to model complex synchronization behavior
  • An Expression activationCondition is used to describe the precise behavior.
  • For example, this Expression could specify that tokens on three out of five incoming Sequence Flows are needed to activate the Gateway
  • What tokens are produced by the Gateway is determined by conditions on the outgoing Sequence Flows as in the split behavior of the InclusiveGateway
  • If tokens arrive later on the two remaining Sequence Flows, those tokens cause a reset of the Gateway and

new token can be produced on the outgoing Sequence Flows

  • To determine whether it needs to wait for additional tokens before it can reset, the Gateway uses the synchronization semantics of the Inclusive Gateway



Event-Based Gateway

Element event based multiple intermediate gateway.png

  • The Event-Based Gateway represents a branching point in the Process where the alternative paths that follow the Gateway are based on Events that occur
  • This is opposed to the evaluation of Expressions using Process data (as with an Exclusive or Inclusive Gateway which are Data Based)
  • A specific Event, usually the receipt of a Message, determines the path that will be taken
  • Basically, the decision is made by another Participant, based on data that is not visible to Process, thus, requiring the use of the Event-Based Gateway.


  • A company is waiting for a response from a customer they will perform one set of Activities if the

customer responds “Yes” and another set of Activities if the customer responds “No.”

  • The customer’s response determines which path is taken
  • The identity of the Message determines which path is taken
  • That is, the “Yes” Message and the “No” Message are different Messages—i.e., they are not the same Message with different values within a property of the Message

  • The receipt of the Message can be modeled with an Intermediate Event with a Message trigger or a Receive Task
  • In addition to Messages, other triggers for Intermediate Events can be used, such as Timers



Start Event Gateway

Figure10-118-exclusive-event-based-gateway-to-start-process.png Figure10-119-parallel-event-based-gateway-to-start-process.png

  • Event Gateways can be used to instantiate a Process
  • By default the Gateway’s instantiate attribute is false, but if set to true, then the Process is instantiated when the first Event of the Gateway’s configuration is triggered.



Parallel Instantiation