I have a process which involves both parallel gateways, inclusive gateways and an exclusive gateways which allows the inclusive gateways section to be re-run.
This process currently gets stuck on the inclusive gateway with no way for the process to continue.
I have managed to simplify our more complex process to the following diagram which reproduces the problem
In this example userTask1 is reached and can be completed, but never userTask2, userTask3 or userTask4. The process simply stops at the incoming inclusive gateway. I believe it is waiting for the execution from the parallelgateway to reach it, which will never happen.
The BPMN looks valid to me, but maybe I’m trying to do something thats not allowed. Is this a bug in the Flowable engine? if not how should I achieve this?
The loop back to the exclusive gateway that comes after the first parallel gateway is the problem.
If that loop is executed the join parallel gateway will wait on the other incoming sequence flow to be completed, and that will never happen.
Maybe you can change the parallel gateway to an inclusive gateway fork and join as well and then loop back to the fork inclusive gateway that will then only take the sequence flow to the bottom based on a condition.
Thanks @tijs for your fast response. I think I have rearranged the diagram as you suggested but unfortunately it has the same problem. Here is my new process.
Was this what you were thinking? Do you have any further suggestions?
I’ve now managed to get the process to work. I added an extra subprocess around the inclusivegateway part and then the above process works as expected.
I think this is a good enough workaround for my usecase. I’ll try the same fix on my more complex process and see if I can also get it work work.
The reason why the first two process definitions don’t work is because the inclusive gateway join only continues if there is no execution anymore that can reach it.
The bpmn specification states (if you’re interested: table 13.3) the inclusive gateway activates when there is no execution with a directed path (following the sequenceflow) to the gateway anymore. Note that this directed path does not take in account conditions on the sequence flow.
In your two first examples above the inclusive gateway waits because due to the loop back there is an active execution (in user task 1 or the parallel join) that can reach it by following the sequence flow back to it. A quick fix would be to change the inclusive gateway with parallel gateways, and use an exclusive gateway before the user task to create the user task or not (I agree doesn’t look nice visually).
