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.