Ensuring message correlation in a correct order

This question is reworked for clarity sake:
Initially, this question was asked in Camunda Message Correlation: Ensure steps consecutiveness with the following diagram:

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.

1 Like

Here is a Parallel-Gateway based solution that was suggested in the related topic:

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.

I have attempted to ensure that with a solution such as this:

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.

Thank you in advance for any help!

1 Like

Hi @Salvir

I don’t fully understand your problem - this to me isn’t too clear.

Can you explain in more detail the exactly problem you have with this model?

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?

If you don’t need to throw an error event or to use a termination event there no need to you can just use a regular end event

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.

1 Like