An alternative join operator for an inclusive gateway

Hello, I read that Camunda does not support the inclusive join. I tried using an “and” join, but the problem is that if tasks B and C are executed, I cannot proceed. Did I do something wrong? If so, how can I solve it alternatively?

Hello @anon64962691 ,

until 8.3, there will be no clean solution. Avoid the inclusive gateway by putting a parallel gateway and then an exclusive gateway before each task. You can then join with the parallel gateway.

Jonathan

1 Like

Thank you. I will try it later today and let you know if it worked.

I did it the way you showed me. In the first task, I have two checkboxes, but somehow it’s not working now. Did I do something wrong?

Hello @anon64962691 ,

the conditional flows will not help you here. Instead, try this:

Jonathan

Thank you. It worked. Can I ask when Camunda 8.3 will be released?

Hello @anon64962691 ,

the release will be on 10 October 2023:

Jonathan

Hi, I do have Camunda 8.3 but the token simulation says that the inclusive gateway is not supported. Will the token simulation be updated at a later stage?

Hi @ahense - there were several issues identified with the implementation of the converging inclusive gateway and it was reverted from the 8.3 release. You can read more on GitHub: Support BPMN Converging Inclusive Gateway · Issue #10031 · camunda/zeebe · GitHub

Thanks @nathan.loding for the reply. Meanwhile, I think it’s release 8.4, the inclusive gateway is implemented, which is great. However, it’s not correct. If I click on “confirmation received” in this token simulation the inclusive gateway is activated although it should wait for the thrid token to arrive.

@ahense - interesting, thanks for the info! Can you share that BPMN XML file here? I’ll work to test it and get bugs filed with the right teams. I suspect it’s just an issue with the simulation rather than with process execution within Zeebe, but always good to double check! (Also, just to confirm, are you testing this in SaaS or a Self Managed instance?)

There’s at least one path that doesn’t arrive at the inclusive join. That might be factoring into the issue.

I remember there being some really in depth discussion on inclusive joins and how calculating the number of tokens expected to arrive was difficult. It might be interesting to see if refactoring the bottom branch into a call activity (with all of the logic moved into there) exhibits the same behavior.

Hi @nathan.loding
yes, no problem:
pattern-38.bpmn (13.6 KB)
I was testing this in the SaaS instance.

Hi @GotnOGuts
I don’t know how the bottom part could be refactored into a call activity.
I also tried to simplify it as here:
pattern-38-modified.bpmn (9.7 KB)

The problem seems to be the event-based gateway.

What about creating an expanded subprocess, and connecting the Inclusive Split “High Value” flow to that Subprocess.

In the Subprocess:
Start → Exclusive Join → Ask for Confirmation → Event Split →
5 Days → Exclusive Join
Confirmation Received → Calculate Cost → End
Modification Received → Make Changes → End

Subprocess then joins into the Inclusive Join.