BPMN2.0 symbol Chinese interpretation (ii)

This is the third day of my participation in Gwen Challenge

Sequence flow symbol Chinese explanation

Sequence flow

describe

A sequence flow is a connector between two elements of a process. After the elements are accessed during process execution, all outgoing sequence flows are followed. This means that the default nature of BPMN 2.0 is parallel: two outgoing sequence flows create two independent parallel execution paths.
legend

Sequence flows are visualized as arrows from source elements to target elements. The arrow always points to the target.

Expressions in XML

The sequence flow needs to have a process-unique ID and references to existing source and target elements.
```
<sequenceFlow id="flow1" sourceRef="theStart" targetRef="theTask" />
Copy the code
```

Conditional sequence flow

describe

A sequence flow can define a condition. When leaving a BPMN 2.0 activity, the default behavior is to evaluate conditions for outgoing sequence flows. When the condition evaluates to true, the outgoing sequence flow is selected. When multiple sequence flows are selected in this manner, multiple executions are generated and the process continues in parallel.

** Note: ** The above applies to BPMN 2.0 activities (and events), but not to gateways. The gateway will process the conditional sequence flow in a specific manner depending on the gateway type.
legend

A conditional sequence flow is visualized as a regular sequence flow with a small diamond at the beginning. The conditional expression is displayed next to the sequence flow.

Expressions in XML

The conditional sequence flow is represented in XML as a regular sequence flow, which contains a conditionExpression child element. Note that currently only tFormalExpressions are supported, and omitting *xsi:type=””* definitions will simply default to supported only expression types.
```
5<sequenceFlow id="flow" sourceRef="theStart" targetRef="theTask">
  <conditionExpression xsi:type="tFormalExpression"><! [CDATA[${order.price > 100 && order.price < 250}]]></conditionExpression>
</sequenceFlow>
Copy the code
```
ConditionalExpressions ** can only be used with UEL at present, ** details on these can be found in the Expressions section. The expression used should resolve to a Boolean value, otherwise an exception will be thrown when evaluating the condition.
- The following example references process variable data in a typical JavaBean style through getters.
```
<conditionExpression xsi:type="tFormalExpression"><! [CDATA[${order.price > 100 && order.price < 250}]]></conditionExpression>
Copy the code
```
- This example calls a method that resolves to a Boolean value.
```
<conditionExpression xsi:type="tFormalExpression"><! [CDATA[${order.isStandardOrder()}]]></conditionExpression>
Copy the code
```

Default sequence flow

describe

All BPMN 2.0 tasks and gateways can have a default sequence flow. This sequence flow is selected as the outgoing sequence flow for the activity if and only if no other sequence flow can be selected. Conditions on the default sequence flow are always ignored.
legend

The default sequence flow is visualized as a regular sequence flow, with a slash marking at the beginning.

Expressions in XML

The default sequence flow for an activity is defined by the default properties for that activity. For example, the following XML fragment shows an exclusive gateway with a default sequence flow, Flow 2. ConditionA and conditionB are selected as the outgoing sequence flow of the gateway only if both conditionA and conditionB are evaluated as false.

<exclusiveGateway id="exclusiveGw" name="Exclusive Gateway" default="flow2" />
<sequenceFlow id="flow1" sourceRef="exclusiveGw" targetRef="task1">
  <conditionExpression xsi:type="tFormalExpression">${conditionA}</conditionExpression>
</sequenceFlow>
<sequenceFlow id="flow2" sourceRef="exclusiveGw" targetRef="task2"/>
<sequenceFlow id="flow3" sourceRef="exclusiveGw" targetRef="task3">
  <conditionExpression xsi:type="tFormalExpression">${conditionB}</conditionExpression>
</sequenceFlow>
Copy the code

Explanation of gateway symbols in Chinese

describe

The gateway is used to control the execution process (or, as described in BPMN 2.0, the execution token). The gateway can consume or generate tokens.

The gateway is graphically displayed as a diamond with an icon inside. The icon shows the gateway type.
legend

Exclusive gateway

describe

Exclusive gateways (also known as XOR gateways or, more professionally, data-based exclusive gateways) are used to model decisions in processes. When the execution reaches this gateway, all outgoing sequence flows are evaluated in the order defined. Select a sequence flow whose condition evaluation is true (or has no set of conditions, conceptually defining * “true” * on the sequence flow) to continue the process.

Note that the semantics of the output sequence flow are different from the general case in BPMN 2.0. In general, all conditional true sequence flows are selected to continue in parallel, while only one sequence flow is selected when exclusive gateways are used. If the condition evaluation for multiple sequence flows is true, the first one (and only that one!) defined in the XML is selected. To continue the process. If the sequence flow cannot be selected, an exception is thrown.
legend

The exclusive gateway is visualized as a typical gateway (that is, a diamond) with an X icon inside, referring to XOR semantics. Note that a gateway without an internal icon defaults to an exclusive gateway. The BPMN 2.0 specification does not allow mixing diamonds with and without an X in the same process definition.

Expressions in XML

The XML representation of an exclusive gateway is straightforward: a single line defines the gateway and conditional expression defined on the outgoing sequence flow. See the section on conditional sequence flows to see which options are available for such expressions.

Take the following model for example:

<exclusiveGateway id="exclusiveGw" name="Exclusive Gateway" />

<sequenceFlow id="flow2" sourceRef="exclusiveGw" targetRef="theTask1">
  <conditionExpression xsi:type="tFormalExpression">${input == 1}</conditionExpression>
</sequenceFlow>

<sequenceFlow id="flow3" sourceRef="exclusiveGw" targetRef="theTask2">
  <conditionExpression xsi:type="tFormalExpression">${input == 2}</conditionExpression>
</sequenceFlow>

<sequenceFlow id="flow4" sourceRef="exclusiveGw" targetRef="theTask3">
  <conditionExpression xsi:type="tFormalExpression">${input == 3}</conditionExpression>
</sequenceFlow>
Copy the code

A parallel gateway

describe

Gateways can also be used to model concurrency in processes. The most direct Gateway for introducing concurrency into a process model is the Parallel Gateway, which allows forking to multiple execution paths or joining multiple incoming execution paths.

Parallel gateways function based on incoming and outgoing sequence flows:
- **fork: ** All outgoing sequence streams are executed in parallel, creating a concurrent execution for each sequence stream.
- ** JOIN: ** All concurrent executions arriving at the parallel gateway wait in the gateway until the execution of each incoming sequence stream arrives. The process then continues through the join gateway.
Note that if the same parallel gateway has multiple incoming and outgoing sequence flows, the parallel gateway can have both fork and join behavior. In this case, the gateway will first join all incoming sequence flows and then split them into multiple concurrent execution paths.

One important difference from other gateway types is that parallel gateways do not evaluate conditions. If conditions are defined on a sequence flow connected to a parallel gateway, they are simply ignored.
legend

Parallel gateway visualization is a gateway with a plus sign inside (diamond), referring to the AND semantics.

Expressions in XML

Defining a parallel gateway requires one line of XML:

<parallelGateway id="myParallelGateway" />
Copy the code

The actual behavior (fork, Join, or both) is defined by the sequence flow connected to the parallel gateway.

For example, the above model boils down to the following XML:

<startEvent id="theStart" />
<sequenceFlow id="flow1" sourceRef="theStart" targetRef="fork" />

<parallelGateway id="fork" />
<sequenceFlow sourceRef="fork" targetRef="receivePayment" />
<sequenceFlow sourceRef="fork" targetRef="shipOrder" />

<userTask id="receivePayment" name="Receive Payment" />
<sequenceFlow sourceRef="receivePayment" targetRef="join" />

<userTask id="shipOrder" name="Ship Order" />
<sequenceFlow sourceRef="shipOrder" targetRef="join" />

<parallelGateway id="join" />
<sequenceFlow sourceRef="join" targetRef="archiveOrder" />

<userTask id="archiveOrder" name="Archive Order" />
<sequenceFlow sourceRef="archiveOrder" targetRef="theEnd" />

<endEvent id="theEnd" />
Copy the code

When these two tasks are complete, the second parallel gateway will join the two executions, and since there is only one output sequence flow, no concurrent execution path will be created and only the archived order task will be active.

Note that parallel gateways do not require equilibrium (that is, the number of matches for incoming/outgoing sequence flows corresponding to parallel gateways). The parallel gateway simply waits for all incoming sequence flows and creates a concurrent execution path for each outgoing sequence flow, independent of the other constructs in the process model. Therefore, the following procedures are legal in BPMN 2.0:

Inclusive gateway

describe

The subsumption gateway can be considered as an exclusive combination and parallel gateway. Just like exclusive gateways, you can define conditions on outgoing sequence flows, and including gateways will evaluate them. But the main difference is that a containment gateway can take multiple sequence flows, just like a parallel gateway.

Includes gateway functionality based on incoming and outgoing sequence flows:
- **fork: ** Evaluates all outgoing sequence flow conditions, and for sequence flow conditions that are evaluated true, the stream executes in parallel, creating a concurrent execution for each sequence flow.
- ** JOIN: ** arrive All concurrent executions containing the gateway wait in the gateway until the execution of each incoming sequence stream with a process token arrives. This is an important difference from parallel gateways. So in other words, the containment gateway will only wait for incoming sequence flows to be executed. After joining, the process continues through the joining include gateway.
Note that if the same include gateway has multiple incoming and outgoing sequence flows, the include gateway can have both fork and join behavior. In this case, the gateway will first join all incoming sequence flows with process tokens and then split them into multiple concurrent execution paths for outgoing sequence flows with a condition to evaluate to true.
legend

The inclusive gateway is visualized as a gateway with a circular symbol inside (a diamond).

Expressions in XML

Defining an inclusive gateway requires one line of XML:
```
<inclusiveGateway id="myInclusiveGateway" />
Copy the code
```
The actual behavior (fork, Join, or both) is defined by the sequence flow connected to the containing gateway.

For example, the above model boils down to the following XML:

<startEvent id="theStart" />
<sequenceFlow id="flow1" sourceRef="theStart" targetRef="fork" />

<inclusiveGateway id="fork" />
<sequenceFlow sourceRef="fork" targetRef="receivePayment" >
  <conditionExpression xsi:type="tFormalExpression">${paymentReceived == false}</conditionExpression>
</sequenceFlow>
<sequenceFlow sourceRef="fork" targetRef="shipOrder" >
  <conditionExpression xsi:type="tFormalExpression">${shipOrder == true}</conditionExpression>
</sequenceFlow>

<userTask id="receivePayment" name="Receive Payment" />
<sequenceFlow sourceRef="receivePayment" targetRef="join" />

<userTask id="shipOrder" name="Ship Order" />
<sequenceFlow sourceRef="shipOrder" targetRef="join" />

<inclusiveGateway id="join" />
<sequenceFlow sourceRef="join" targetRef="archiveOrder" />

<userTask id="archiveOrder" name="Archive Order" />
<sequenceFlow sourceRef="archiveOrder" targetRef="theEnd" />

<endEvent id="theEnd" />
Copy the code

Note that containment gateways do not need to be balanced (that is, the number of matches for incoming/outgoing sequence flows corresponding to containment gateways). The inclusive gateway will simply wait for all incoming sequence flows and create a concurrent execution path for each outgoing sequence flow, independent of other constructs in the process model.

Event-based gateways

Event-based gateways allow decisions to be made based on events. Each outgoing sequence flow of the gateway needs to be connected to an intermediate capture event. When process execution reaches an event-based gateway, the gateway behaves like a wait state: execution is suspended. In addition, an event subscription is created for each outgoing sequence flow.

Note that the sequence flow flowing out of the event-based gateway is different from normal sequence flow. These sequence flows are never really “executed”. Instead, they allow the process engine to determine which events to subscribe to for execution to reach the event-based gateway. The following restrictions apply:

* Event-based gateways must have two or more outgoing sequence flows.

* Event-based gateways must connect only to the type element intermediateCatchEvent. (Activiti does not support receiving tasks behind an event-based gateway.)

* An intermediateCatchEvent connecting to an event-based gateway must have a single incoming sequence flow.

legend

An event-based gateway is visualized as a diamond, like other BPMN gateways, with a special icon inside.

Expressions in XML

The XML element used to define the event-based gateway is eventBasedGateway.
- eg
  
  The following process is an example of an event-based gateway process. When execution reaches the event-based gateway, process execution is paused. In addition, the process instance subscribes to the alert signal event and creates a timer that fires after 10 minutes. This effectively causes the process engine to wait ten minutes for a signal event. If the signal occurs within 10 minutes, the timer is cancelled and the execution continues after the signal. If the signal is not fired, the execution continues after the timer and the signal subscription is unsubscribed.

<definitions id="definitions"
	xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
	xmlns:activiti="http://activiti.org/bpmn"
	targetNamespace="Examples">

	<signal id="alertSignal" name="alert" />

	<process id="catchSignal">

		<startEvent id="start" />

		<sequenceFlow sourceRef="start" targetRef="gw1" />

		<eventBasedGateway id="gw1" />

		<sequenceFlow sourceRef="gw1" targetRef="signalEvent" />
		<sequenceFlow sourceRef="gw1" targetRef="timerEvent" />

		<intermediateCatchEvent id="signalEvent" name="Alert">
			<signalEventDefinition signalRef="alertSignal" />
		</intermediateCatchEvent>

		<intermediateCatchEvent id="timerEvent" name="Alert">
			<timerEventDefinition>
				<timeDuration>PT10M</timeDuration>
			</timerEventDefinition>
		</intermediateCatchEvent>

		<sequenceFlow sourceRef="timerEvent" targetRef="exGw1" />
		<sequenceFlow sourceRef="signalEvent" targetRef="task" />

		<userTask id="task" name="Handle alert"/>

		<exclusiveGateway id="exGw1" />

		<sequenceFlow sourceRef="task" targetRef="exGw1" />
		<sequenceFlow sourceRef="exGw1" targetRef="end" />

		<endEvent id="end" />
</process>
</definitions>
Copy the code

BPMN2.0 symbol Chinese interpretation (ii)

Sequence flow symbol Chinese explanation

Conditional sequence flow

Default sequence flow

Explanation of gateway symbols in Chinese

Exclusive gateway

A parallel gateway

Inclusive gateway

Event-based gateways

Related Posts

Design Pattern XVII – Template method pattern

Java multithreading and High Concurrency (v): Thread pools

Mysql > Select * from ‘mysql’;