Login or Sign up
"#exercise_list, #add_exercise"

Exercises


Add Exercise

"#comment-list, #writenew_annotation"

Annotations

Please to write annotations.


"#tag_list, #add_tags"

Tags

Gateways are used to model control flow branching in BPMN. Gateways split and join sequence flow.

There are four types of Gateways:

  • exlusive,
  • parallel,
  • inclusive and
  • complex Gateways.

Databased XOR-Gateway

Modeling "either/or" situations is done via XOR-Gateways. Depending on conditions exactly one outgoing flow will be chosen, the control flow is split. Conditions are usually expressed by Annotations on the outgoing edges (therefore see http://en.bpmn-community.org/tutorials/13/). It is also possible to specify a Default Flow like an else-Branch in Programming Languages. If none of the conditions applies, Default Flow will be chosen.

Example:
After receiving an order, it shall be checked whether the order is valid. If it is, the order is processed and further steps are taken. If the order is invalid, it shall be rejected. The control flow depends on the validity of the order.


After splitting control flow you may wish to synchronize it later in the process, this is called Join and is modelled using the according Gateway. When joining from an XOR-Split, the Join-Gateway awaits exactly one incoming branch (as the XOR-Split has exactly one outgoing flow).

Example:
After the order was processed or rejected, further steps are taken to close the process. These further steps do not depend on whether the order was valid or not.


AND-Gateway

Modeling "and" situations is done via AND-Gateways. In case of splitting, all outgoing flow simultaneausly get activated.

Example:
When receiving an order, products are shipped while the seller awaits the payment. Both tasks are executed in parallel. The process terminates after both payment is received and products are shipped.


In case of joining, the Gateway awaits all incoming branches (as the AND-Split activates all of the outgoing edges).

Example:
The call will not be terminated until the customer's needs are recorded as well as the issue is entered into the system.


OR-Gateway

Modeling "or" situations (not necessarily either/or) is done via Inclusive-OR-Gateways. In case of splitting, one or more outgoing flows are activated.

Example:
In a Quality Insurance Bureau customers are asked about shipping service and product quality. Customers can rate both criteria positive or negative which leads to 4 possible answers overall (+/+, +/-, -/+, -/-). The two criteria are independant, that means if a customer gave one answer so far, you don't know about how he will rate the other. The Inclusive-OR-Gateway realizes the implied Indepence.


When joining, the Gateway awaits all activated branches. This can be problematic as the process does not "know" if another outgoing flow after the split might get activated (the number of elements to be synchronized is not deterministic - in contrast to XOR- and AND-Gateway).

Example:



Eventbased Gateway

To model decisions that are based on events, the Eventbased (Exclusive) Gateway is used. After such Gateway there shall be two or more Intermediate Events (see also Tutorial about Events) i.e. Message-, Timer-, Condition- and Signal-Events

Example:
Tom wants to have coffee with a friend. He sends him an sms and waits for reply. Depending on his friend's answer (agree or don't agree) he will meet him or he will stay at home.


It is also possible that none of the awaited events will occur, so it is recommended to model also a Timer-Event which represents a Timeout situation. By that the process will guaranteed continue.

Example:
If Tom does not receive any answer within an hour he calls his friend and asks if he received the sms.


Complex Gateway

One or more outgoing flows get activated based on complex conditions or textual descriptions. It should only be used when it is not possible to express the situation with simple Gateways. It leads to misinterpretation and cannot be automatically transformed to executable languages. See also related Best Practice Discussion.

New Gateways in BPMN 2.0

BPMN 2.0 introduces two new Gateways, Exclusive Event-based Gateway (instantiate) and Parallel Event-based Gateway (instantiate). Generally new is their semantic, they stand at the beginning of a process. The Exclusive Event-based Gateway (instantiate) is very similar to the conventional Event-based Gateway, it awaits a sequent specified (Intermediate) Event and controls the flow accordingly. While the traditional Event-based Gateway is used amid a process, the new Exclusive Event-based Gateway (instantiate) - as already mentioned - is used at the beginning of a process.


The seemingly same situation can as well be modeled without the new Gateway, using a plain Start Event and the classic Event-based Gateway


Concerning execution semantics there is one particular difference: in the conventional modeling, the process is started (instanciated and initiated) and awaits an Event to occur whereas the BPMN 2.0 version instanciates the process not until the event is already occured. In most cases this semantic is prefered.

The Parallel Event-based Gateway (instantiate) resembles the just described the Exclusive Event-based Gateway (instantiate) - with the difference that all sequent Events must occur to start the process.

Edit Description

Last edited by Jennifer Cancino on May 2, 2010, 2:07 a.m.


Exercises


Add Exercise

Provide Feedback

Close

Help us to improve usability!

Enter your feedback referring to the current page. Your comments are only visible to the development team.