In a drawing like the one in the picture, the expanded subprocess can be triggered more than once thanks to the non-interrupting message boundary event connected to the user task. In the example, while there was 1 active token waiting in the task, 2 separate requests were sent to the expanded subprocess and 2 separate executions was created in the subprocess. As it can be seen from the history view that 1 of the subprocess executions has been completed (note that the token from the completed execution goes to the end of the main process), the other execution with the expanded subprocess is still active.
What I need?: Until all executions entering the expanded subprocess are completed, no token from the expanded subprocess output can go to the end of the main process.
How can this be achieved using only bpmn element types?
I have not been able to find any solution regarding this issue yet.
How can I ensure that a single token will be outputted once from the expanded subprocess after all active tokens in the expanded subprocess are completed?
Actually, what I need here is not whether a new token from the non-interrupting message boundary event should enter the subprocess or not according to activeness state of the the subprocess. The non-interrupting message boundary event on the user task can be triggered N times and new tokens can be created at least N times within the subprocess. The part we need to focus on should be the exit side of the subprocess, I guess. Because I want to be sure that there are no active tokens belonging to the subprocess scope left at the subprocess exit.
I couldn’t find anything in the default BPMN element properties that I could use for this purpose. It needs additional development.
I’m working on a JavaDelegate that checks whether there is an active token belonging to the subprocess scope in the subprocess end event. I’m checking the variable with the conditional intermediate catch event to see if there is any active token left that I set in JavaDelegate. Conditional events seem very suitable for this need, the token will not be moving until a certain case occurs.
By the way, 1 token input to the subprocess does not always mean 1 token output. For example, with parallel gateways in the subprocess, 1 token input may cause more than 1 token output. That’s why it made the most sense to check if anything active in the subprocess scope at the subprocess exit.
Since the outer expanded subprocess will create its own scope, it will not allow any tokens to go out of the subprocess unless all active tokens within its own scope are completed. Please see that even though the “Inner End” event was triggered once, the “Main Task” and “End” events outside the subprocess were never triggered. When all active tokens in the subprocess are completed, the activities of the main process will run. Just like I wanted!
I guess, I thought about too much in details.
Thanks to @Norman_Luering very much for this practical solution!
