Common Errors and recommendations when using inclusive gateways and parallelism.
Inclusive gateways allow the configuration of parallelisms, very useful in business processes. This flexibility and power, as a counterpart, are prone to misconfiguration of the processes.
An incorrect configuration of the process can leave process instances stuck in a gateway and require manual intervention from Flokzu team to reactivate them.
Any process modeled in BPMN is prone to design errors. Some of them can be detected at design time. For example, if after an exclusive gateway, there are no conditions for the outgoing "arrows", Flokzu will display an appropriate error and will not allow that process to be deployed. This way we can correct it at design time. However, not all errors can be detected when designing the BPMN diagram.
Some process misconfigurations, and particularly when there are inclusive gateways and parallelisms, cannot be detected at design time. The error will arise at runtime, with a real process instance. Therefore, extreme care should be taken and always test the process in the Sandbox before deploying to production.
Please consider this BPMN diagram:
This diagram may at first glance appear to be correctly modeled. And in fact, it could run correctly in some scenarios, without producing any errors. Let's analyze a possible execution.
By creating an instance of the process, the first inclusive gateway divides the flow, creating two tokens. Suppose task T2 is completed before task T1, so the token from the lower branch is waiting at the second inclusive gateway. Then task T1 is completed. If the exclusive gateway condition evaluates B, then the flow works perfectly. Note that the tokens are waiting at the second inclusive gateway as desired. And when both tokens get there, the process continues, creating the T3 task and successfully completing it. This execution would look like this:
However, the same diagram produces erroneous executions, simply if one of the process variables causes the exclusive gateway to evaluate A (instead of B). Note that when T2 is completed, the token in this lower branch will wait at the second inclusive gateway. But the token that was on the top branch evaluates A on the exclusive gateway and finishes. Then, the token from the lower branch, will be waiting forever at the inclusive gateway. Since there is no other token in this process instance, the lower token will never leave, and the process instance will never end.
In this case, the main problem derives from the fact that under some conditions in the flow, a token can be finished, and never reach the inclusive gateway that waits for it. When we use an inclusive gateway to divide the process into two or more paths and thus generate two or more tokens, and if we then have an inclusive gateway joining those paths, we must make sure that we do not finish tokens between them.
It is recommended that you don't use End-Events between two inclusive gateways. If they are essential, use them very carefully. Their bad configuration can lead to a token finishing, and let another one waiting forever in an inclusive gateway.
Please consider this BPMN diagram:
At first glance, it is not trivial to realize that the conditions of the exclusive gateway are not mutually exclusive, nor are they complete. That is, there are values for the variables A and B that would make both conditions met, only one, or none at all. We can be lucky, and with the values of varA = 8 and varB = 15, only the way down would be taken and the execution would successfully end:
On the other hand, if the values of the variables were varA = 12 and varB = 15 the token of the lower branch will be waiting in the second inclusive gateway forever, since the token that went through the upper branch cannot leave task T1 until the conditions are modified so that there is an exit condition (the configuration of the conditions does not cover all possible cases):
It could also happen, for example if varA = 8 and varB = 25 that both conditions of the exclusive gateway are met, in which case we cannot be sure which way the token will go, producing unexpected results.
It is very important when using conditions on gateways that they are mutually exclusive and complete. Especially when after those gateways, there are other inclusive gateways where the tokens can wait forever.
Consider this diagram:
As in the previous case, it is not easy to determine that the output conditions of the inclusive gateway are mutually exclusive and complete. We can be lucky and have successful executions of the process. For example if varA = 8 and varB = 15 the execution would be:
The risk is that with other values of the variables, for example varA = 8 and varB = 30 both conditions of the exclusive gateway are met, so two tokens are generated. One of them meets the one that was waiting in the last exclusive gateway, and the task T3 is created. However, the other token goes to task T1, and the process instance does not actually end since that token is alive in a valid task. This is probably not the desired behavior:
It is recommended that if loops are used between two inclusive gates, no new tokens are created on them. It must be ensured that in all cases, no situations can occur where tokens remain in the loop, while the process instance moves out of the inclusive gate that joins the previously separated branches.
Inclusive gateways are very powerful, and allow something vital in business processes such as parallel working. However, they must be carefully configured to avoid undesired situations, or tokens that are left waiting for something that will never happen.
The examples proposed in this article were specially designed for didactic purposes to exemplify potential problems. In real life, the processes are much more complex, with tens or hundreds of tasks and gateways. In those cases, it is very difficult to identify errors or bad configurations. For this reason it is very important to apply the recommendations at the moment of designing the process, avoiding the bad practices identified here.
An incorrect configuration of the process can leave process instances stuck in a gateway and require manual intervention from Flokzu team to reactivate them.
Any process modeled in BPMN is prone to design errors. Some of them can be detected at design time. For example, if after an exclusive gateway, there are no conditions for the outgoing "arrows", Flokzu will display an appropriate error and will not allow that process to be deployed. This way we can correct it at design time. However, not all errors can be detected when designing the BPMN diagram.
Some process misconfigurations, and particularly when there are inclusive gateways and parallelisms, cannot be detected at design time. The error will arise at runtime, with a real process instance. Therefore, extreme care should be taken and always test the process in the Sandbox before deploying to production.
End events between inclusive gateways
Please consider this BPMN diagram:
This diagram may at first glance appear to be correctly modeled. And in fact, it could run correctly in some scenarios, without producing any errors. Let's analyze a possible execution.
By creating an instance of the process, the first inclusive gateway divides the flow, creating two tokens. Suppose task T2 is completed before task T1, so the token from the lower branch is waiting at the second inclusive gateway. Then task T1 is completed. If the exclusive gateway condition evaluates B, then the flow works perfectly. Note that the tokens are waiting at the second inclusive gateway as desired. And when both tokens get there, the process continues, creating the T3 task and successfully completing it. This execution would look like this:
However, the same diagram produces erroneous executions, simply if one of the process variables causes the exclusive gateway to evaluate A (instead of B). Note that when T2 is completed, the token in this lower branch will wait at the second inclusive gateway. But the token that was on the top branch evaluates A on the exclusive gateway and finishes. Then, the token from the lower branch, will be waiting forever at the inclusive gateway. Since there is no other token in this process instance, the lower token will never leave, and the process instance will never end.
In this case, the main problem derives from the fact that under some conditions in the flow, a token can be finished, and never reach the inclusive gateway that waits for it. When we use an inclusive gateway to divide the process into two or more paths and thus generate two or more tokens, and if we then have an inclusive gateway joining those paths, we must make sure that we do not finish tokens between them.
It is recommended that you don't use End-Events between two inclusive gateways. If they are essential, use them very carefully. Their bad configuration can lead to a token finishing, and let another one waiting forever in an inclusive gateway.
Non mutually exclusive or incomplete gateways conditions
Please consider this BPMN diagram:
At first glance, it is not trivial to realize that the conditions of the exclusive gateway are not mutually exclusive, nor are they complete. That is, there are values for the variables A and B that would make both conditions met, only one, or none at all. We can be lucky, and with the values of varA = 8 and varB = 15, only the way down would be taken and the execution would successfully end:
On the other hand, if the values of the variables were varA = 12 and varB = 15 the token of the lower branch will be waiting in the second inclusive gateway forever, since the token that went through the upper branch cannot leave task T1 until the conditions are modified so that there is an exit condition (the configuration of the conditions does not cover all possible cases):
It could also happen, for example if varA = 8 and varB = 25 that both conditions of the exclusive gateway are met, in which case we cannot be sure which way the token will go, producing unexpected results.
It is very important when using conditions on gateways that they are mutually exclusive and complete. Especially when after those gateways, there are other inclusive gateways where the tokens can wait forever.
Loops between inclusive gateways
Consider this diagram:
As in the previous case, it is not easy to determine that the output conditions of the inclusive gateway are mutually exclusive and complete. We can be lucky and have successful executions of the process. For example if varA = 8 and varB = 15 the execution would be:
The risk is that with other values of the variables, for example varA = 8 and varB = 30 both conditions of the exclusive gateway are met, so two tokens are generated. One of them meets the one that was waiting in the last exclusive gateway, and the task T3 is created. However, the other token goes to task T1, and the process instance does not actually end since that token is alive in a valid task. This is probably not the desired behavior:
It is recommended that if loops are used between two inclusive gates, no new tokens are created on them. It must be ensured that in all cases, no situations can occur where tokens remain in the loop, while the process instance moves out of the inclusive gate that joins the previously separated branches.
Conclusion
Inclusive gateways are very powerful, and allow something vital in business processes such as parallel working. However, they must be carefully configured to avoid undesired situations, or tokens that are left waiting for something that will never happen.
The examples proposed in this article were specially designed for didactic purposes to exemplify potential problems. In real life, the processes are much more complex, with tens or hundreds of tasks and gateways. In those cases, it is very difficult to identify errors or bad configurations. For this reason it is very important to apply the recommendations at the moment of designing the process, avoiding the bad practices identified here.
Updated on: 10/05/2022
Thank you!