Hi,
I have a process model where a rule is processed in a script task running parallel to a user input task. At the second AND gate, there are two possible scenarios:
First API Call Path Reaches the AND Gate First: The API path reaches the AND gate before the user submits the task. This scenario works as expected, triggering the next chained User Input Task (UIT) in the process.
User Submits the Task First: The user submits the task before the API path reaches the AND gate. In this case, the next UIT is not triggered as expected.the API call is not an actual API call but an expression rule with dummy data in output
Discussion posts and replies are publicly visible
The behavior you describe (though it would require an ENORMOUSLY slow "api call" node execution time) is expected behavior as far as I can see. FWIW, you would not apply activity chaining on the "bottom" path of the initial "AND" split - it is only needed for the flow through the user-attended node(s).
That said, what exactly is your question?
Thanks Mike, yeah my question is how it is an expected behavior, why in the second case the second UIT is not opening ? is it possible or recommended to do parallel processing like this ?
Activity chaining works only when that chain is not interrupted. When you API call takes longer, the AND node breaks that chained flow for the user. That second task is still assigned to the user who can find it in his task list.
I see, The API call for the node is taking an average of 1.5 seconds, with a specific instance taking 1.2 seconds. However, I’ve noticed when a user has kept a task open for more than a minute, this processing time is still quite high for the node but this works, so I’d like to understand what’s happening behind the scenes and why there is a difference in behavior of these different scenarios where one node is uit and takes time still works as expected and other is script task and breaks the chaining.
I think that a UIT in parallel to an API call joined by an AND with chaining is a problematic design decision. You basically create a race condition between the user and the API, and depending on who is quicker, it works or fails.
The outflow from the API call could merely be a nonterminating END node. If the user is super fast and hits the AND node before the incoming flow from the API call node, the AND node does what it's supposed to do and interrupts the chain to wait for the other incoming flow.
So, if it's not critical that the user not proceed to the next task until the API node is complete, then modify your diagram such that the user's flow isn't blocked if the API is slow. And if there's something critical that should prevent the user from hitting the next task until the API is done, then you will need to build in something more robust than merely blocking them temporarily (at least if you don't want them to experience a chaining drop).