The inclusive gateway evaluates 2 conditions and can go through one or both of the send tasks. We can disregard the rest of the outgoing sequence flows for this problem.
Both send tasks call the same ws and alter the same variable (the state of an object). When both tasks execute in “parallel” my object changes its state twice, but it always work in the same order so my object always ends with the same state (which is good). Is there any way for me to decide that order myself?
That the engine executes the order of the activities consistently in your example is an implementation detail that you should not rely on, as it is not covered by the BPMN spec and can change in the future.
Thanks for the answer, that’s what I imagined, that it was just the way it is implemented. The same “works this way but in theory is indeterministic” logic applies when more than one condition is met in an exclusive gateway right? It will always take the same route but it should be treated as it was random?
In order to determine the outgoing Sequence Flows that receives the token, the conditions are evaluated in order. The first condition that evaluates to true determines the Sequence Flow the token is sent to. No more conditions are henceforth evaluated.
and it leaves open what that order should be.
Re the inclusive gateway case: Another reason why you shouldn’t rely on the order is that introducing asynchronous continuations will change the behavior, i.e. the order of execution holds on each execution branch only until the first wait state or asynchronous continuation is reached. If you make your activities asyncBefore, then the execution order of the sends tasks is not predictable anymore.