The problem with which I had to deal with was the problem related to the fact that at some point, before task 1 is done and we are waiting on the gateway, we would receive success/error 2 messages, which would not correlate.
I want to ensure the correctness of the behavior of the program, which is the following here:
After I received success 1 message and working on task 1, if at any point I had received success/error 2 message, I will move forward as specified. If I receive it before I receive success/error 1 message, I don’t want for the process to go along.
Here my issue is with the Event-based gateways, as some of the processes I implement this pattern on are not sub processes with boundary event on error (which will interrupt the subprocess), as this one. And I want to avoid the usage of Termination End Event if possible.
Is there anything this approach could use to avoid the issue of process waiting on unresolved tokens?
Here is an Event Subprocess-bsed solution that I have tried to implement, however, it does not implement the necessary condition on waiting for the tasks to be done, thus while it avoids one part of the problem, related to correlation, the other part that is to ensure that steps of the process are done in a consecutive manner is not ensured.
However, it still does not ensure the desired behavior. While we ensure that messages must be processed in order, messages should only be processed after the task related to them (1/2/3 respectively) is done.
Hello, @Niall,
The current example works well for a subprocesses, since there is a boundary event waiting on an error to be thrown outside.
However, there is a need to ensure similar behavior in another process, which is not a subprocess and thus, cannot have an interrupting boundary event. I know that Termination End Events consume all tokens and end the process when they are reached, but my question for that approach, is there a way to resolve this without the need to adapt Termination End Events?
Would it consume the remaining tokens, since it was my assumption that the Parallel Gateway will remain there, waiting on tokens to arrive, if we to move, in the example, down the failure pass?
@Niall, hello again, I have just checked on leaving the end event as a normal end event, and it seems that the behavior goes as I feared: the process still remains in execution, waiting on the token to arrive to the Parallel Gateway Join. I assume the only way to avoid this is to use Termination End events, if we cannot utilize interrupting boundary events?
Thank you again, after some deliberation, the initial pattern might work.
I might return here to ask about the possible implementation of such behavior via external tasks but for now this question is effectively solved by @Niall
It seems that conditional event based solution would get too cumbersome too fast if we need to ensure the correct steps.
