1. Include gateway

describe

The inclusive gateway can be regarded as an exclusive combination and parallel gateway. As with exclusive gateways, you can define conditions for outbound sequential flows that are evaluated by included gateways. But the main difference is that the inclusive gateway can adopt multiple sequence streams, such as parallel gateway.

The functions of the included gateway are based on the input and output sequence process:

• fork: evaluate all output sequential flow conditions. For sequential flow conditions evaluated as true, follow the flow in parallel and create a concurrent execution for each sequential flow.
• Connection: all concurrent executions arriving at the containing gateway wait at the gateway until each incoming sequence flow with a process token arrives for execution. This is an important difference from parallel gateway. So, in other words, the containment gateway will only wait for the incoming sequence flow to be executed. After joining, the process continues through the joined containing gateway.

Note that if the same inclusive gateway has multiple inbound and outbound sequence flows, the containing gateway can have bifurcation and join behavior. In this case, the gateway will first join all with access
The incoming sequence flow marked by the process is then separated into multiple concurrent execution paths of the outgoing sequence flow with the condition that the calculation result is true.

Graphical representation

An inclusive gateway is considered a gateway (diamond) with a circle symbol inside.

XML representation
Defining an inclusive gateway requires one line of XML:

 <inclusiveGateway id="myInclusiveGateway" />

The actual behavior (bifurcation, connection, 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" />

In the above example, after the process is started, if the process variables paymentReceived == false and shipOrder == true, two tasks will be created. If only one of these process variables is equal to true, only one task will be created. If no condition evaluates to true, an exception is thrown. This can be prevented by specifying a default outgoing sequence flow. In the following example, a task is created, the shipping task:

HashMap<String, Object> variableMap = new HashMap<String, Object>();
variableMap.put("receivedPayment", true);
variableMap.put("shipOrder", true);
ProcessInstance pi = runtimeService.startProcessInstanceByKey("forkJoin");
TaskQuery query = taskService.createTaskQuery()
.processInstanceId(pi.getId())
.orderByTaskName()
.asc();
List<Task> tasks = query.list();
assertEquals(1, tasks.size());
Task task = tasks.get(0);
assertEquals("Ship Order", task.getName());

After this task is completed, the second inclusion gateway will join two executions. Since there is only one outgoing sequence flow, no concurrent execution path will be created, and only the archive sequence task is active.

Note that the inclusive gateway does not need to be balanced (corresponding to the matching number of input / output sequence streams containing the gateway). The inclusive gateway will simply wait for all incoming sequence flows and create parallel execution paths for each outgoing sequence flow, independent of other constructs in the process model.

The above article is from Pangu BPM Research Institute: http://vue.pangubpm.com/
Article translation submission: https://github.com/qiudaoke/flowable-userguide
For more articles, you can focus on WeChat official account: