While troubleshooting an apparent error just now, I noticed that all completed instances of a relatively simple process with an AND gateway had failed to execute both of its outgoing paths. The key factor here is that the process chains (unattended) all the way to a Terminate node, presumably because after the user submits their task in this subprocess, they're expected to chain into a followup task back at the parent level.
However I never realized this constraint was in place - that is, the process executes all possible chained paths (up to and including a terminate) before it will execute the other AND gateway outputs. This seems like a bug to me - but am I wrong? Has anyone else noticed this?
I was able to recreate the behavior with this very, very simplified example process, if anyone's having trouble picturing what I'm referring to:
Discussion posts and replies are publicly visible
I have seen this before, especially since you chained the one. It was prioritized and terminated before the other path started. This is why you can't terminate or you have to have them come back together before terminating. I believe it has always been this way, and dare I say, expected.
It may have always been this way without me noticing - so in that respect expected. But it took me by surprise (unsurprisingly, it was set up this way in the system i inherited, so of course it consumed some troubleshooting effort on my part, and since the model in question was slightly more complicated, it caught me off-guard more easily).
Not realized, but not sure if its real bug.Appians defines chaining as "If the completion of a task in a process requires the same user to complete a subsequent task, you can activity-chain the two tasks together in your process model."https://docs.appian.com/suite/help/22.1/Process_Model_Recipes.html-> This means to me, that you define a "please do these tasks in priority then the rest".second - BPMN Best practice -> each AND opening gateway shall have "closing" gateway, which would mean you should have a second AND gateway before your "end event", which would solve your issue as it waits there until all flows arrived before going to the end event.-https://www.visual-paradigm.com/guide/bpmn/bpmn-gateway-types/
Seems like a variant of the classical race-condition to me. While being tricky, I think that this is expected behaviour. This design basically says: "Kill the process instance ASAP ignoring other flows".
Richard Michaelis said:each AND opening gateway shall have "closing" gateway, which would mean you should have a second AND gateway before your "end event",
Good point, I never realized this.
Yeah, you're all probably right - it just took me by surprise.
I think you'll find some very interesting things. Accordingly, if you have an OR gateway, and all the outgoing flows are valid, then the documentation SAYS that one of the flows will be first randomly.
However, when I tried it, I consistently got one of the flows to finish first when attempting to create a race condition. (Fun to have a PM be your random number generator; sad it didn't work.)
Also, say you have AND with 5 different forms chained to it. Which will the user actually see?
AFAIK if you try to chain multiple out flows from an AND, all bets are off. That's sorta congruent with what we saw in my initial results here (though from an opposing perspective, as it were). The only frustrating part is that there's no mention of this in any of the official documentation, at least per what I could find with an initial check.
This is very interesting, I didn't about this behavior about AND condition. good to know.