How a INCLUSIVE gateways works in a non symetric diagram?
Hello,
Please visit this process
https://www.dropbox.com/s/hy7l390q6kszqsg/inclusive%20Gateway.jpg?dl=0
In this process, I have this
+------ Blue ? ---> BLUE -------------------------------------- |
S ==> INCLUSIVE (Color) +--- Winter? -----------------> INCLUSE(Final)
+--- Red ?--> INCLUSIVE(Season) |
+--- Spring ? ---------------------|
So, if the process is "Blue + Red + Winter + Spring" it will generate 3 tokens on the FINAL.
If the process is "Red+Winter+Spring", it will generate 3 token on the FINAL
If the process is "Blue", only one token
How Bonita Engine deal with that, and know how many token will arrive on the INCLUSE to open it ?
II / I generate a "loop" : after the INCLUSIVE, if "loop==true", I look back to BLUE and come again on the final. I see in that situation the FINAL does not block the "loop back" token: how it's possible?
Thanks,
Hi,
Inclusive gateways detect all the flows that need to be synchronized and will wait for them to reach the gateway before opening it. This is part of BPMN2 specification.
Here is a simplified version of BPMN 2 by Bonitasoft with an example of the Inclusive Gateway, that might help you: https://www.bonitasoft.com/system/files/documentation_library/ultimate_guide_to_bpmn2_280116.pdf If you are looking for a more in-depth understanding on the gateway behavior you can have a look to the BPMN2 definition (but I should warn you it is a bit difficult to grasp on the first read)
In your example there is no point on waiting for the loop, so the gateway opens as soon as all other tokens arrive. Then afterward if the process loops back, there is no other tokens to wait, so it will go through the gate right away.
Note: from a semantic stand point, I would recommend to design the process differently. First of all it would be better to have a merging gateway for the seasons and one for the colors. Secondly BPMN2 experts usually discourage the loops in a diagram except when using the "loop" kind of task, which in your example would seem more appropriate.
Captain Bonita
Hi,
The information is computed at the merging gateway level (not at the split gateway) and is not stored in database.
If you really want to have a peek at what happens behind the curtains, you can have a look at the source code there: https://github.com/bonitasoft/bonita-engine/blob/5f7f741ad30a8f0c97417ec835dba24a0a127478/bpm/bonita-core/bonita-process-instance/src/main/java/org/bonitasoft/engine/core/process/instance/impl/GatewayInstanceServiceImpl.java#L135
Hope this helps,
Captain Bonita
Comments
Hello,
I checked the code. But I don't see inside where the number of token generated is store.
In a INCLUSIVE gateway, the number of token generated is dynamic. For example, I may have 5 output transitions, but for the case 4432, only 3 tokens.
So, for the rendez-vous, I have to wait 3 tokens: where this information is saved? How? For this case
List
==> Will be 5
List
==> Will be 3
List
==> Will be 2
but then Bonita have to decide the gateway is "activated".
How?
Comments
Hello,
Thank for the comment ", there is no other tokens to wait, so it will go through the gate right away", that is what I suspected.
My question was : how the engine knows how many token it has to wait? I assume the "source" inclusive gateway, who knows the value, store it somewhere. But how does it find the DESTINATION gateway? it may have after some new START/END Inclusive gateway on a path.
And where it is store in the database?
Thank
Hi,
Inclusive gateways detect all the flows that need to be synchronized and will wait for them to reach the gateway before opening it.
That is there is no storage of any information, it is computed by the merging inclusive gateway each time a BPMN flow element is executed and might change the result of the previous computation. For instance, each time a transition arrives to the said merging gateway (there are more triggers than this example).
The algorithm (in a nutshell) is:
Hope this helps,
Captain Bonita