Hello, I’m trying to model the following situation (I don’t know if it’s the correct way, I’m a BPMN novice).
In practice I need to start a process instance when one of the two messages arrive (they can arrive in any order) and then I need to execute some logic when all the messages had arrived. I need to generalize this concept to n events (where n >= 2) so this seemed the most meaningful representation. Apart from the BPMN modeling I’m wondering how to implement this in the event listeners; should I use message correlation to start / find matching process instance? Can you give me an example if exists?
Thank you so much!
According to BPMN2 standard, it is possible to start process with event based gateway, but as far as i know, Camunda does not have this mechanic (correct me if im wrong). We had some similar issue where we could not ensure order of messages and we resolved it like this:
This is partly correct
A process cannot be started from an event based gateway in camunda or in the BPMN standard - although there is another symbol (that looks similar) that would give you this functionality but Camunda doesn’t support it. The solution given by @JohnArray is a very good option.
I’m not talking about number of messages, rather the number of message types. Suppose I have more than 3 message types, just drawing the diagram is not straightforward.
@cecchisandrone you might consider using one type of message and distinguish messages by adding variables, this would simplify above model to single message and would scale easily however it wont be as readable as above.
I would suggest simply doing it this way. In the first model, you need a start event. I think you’re on the right track because it appears you are updating a file with the event. However, consider that in your model the token will immediately be passed to the join gateway and nothing will happen, and since the “message arrived” task has completed the gateway won’t fired again. You have a deadlock, as “both messages arrived” task will never fire.
In the second instance, you also end up with a deadlock. Say for example message one arrives. The system immediately creates an event then passes the token to the exclusive join gateway. The gateway immediately passes the token along to the next join gateway. Unless you incorrectly overload the gateway to include code to determine if all the needed messages arrives, the token is put into an endless loop.
