Catching message event from multi instance pool

I understand your gateway in process A behaves like a parallel gateway and produces 1 token on each branch?

I understand that D will be performed 3 days after process instantiation, no matter if a message from an instance of B is received? Or do you intend to say that "must terminate" implies killing the token on the D branch? In this case your end event would have to be a "Terminate" end event.

Any further messages generated by an instance of B would be discarded, since they don't find the process A waiting at the Intermediate Receive Message Event.

if you have a Terminate end event and while C is being performed the timer event times out, D will be performed and it will become a race, if C or D finishes first and kills the other activity. You get a similar race condition, if while processing D a message arrives and activity C is started.

Without a terminate event the timer D would expire, but the message receive event will continue waiting for the first message. A simple end event consumes the process tokens as they arrive and the process ends with the consumption of the last token.

Here is an example how you might achieve what you want.

This is quite elegant, because the timer event directly kills the activity of waiting for messages and continues with D. No risk of C being started by an incoming message while processing D. And neither will the timer trigger after a message was received in time.

Hi,

I cannot agree to the analysis of M. Zschuckelt. The model of Rufus is quite correct. In the model the event-based gateway is used. The semantic is defined as an exclusive decision, i.e. the outgoing sequence flow is activated depending on the triggering of the first event ("first wins"). All other branches are discarded (alternative branching). It is not a parallel behaviour und you do not need to delete a token by a terminate end event. The gateway and the events together are defined as one "construct".

What does not work from my understanding is the combination with the multiple instance pool B. What is the business background? When the first message is thrown by process B or 3 days are gone, process A is terminated. That means a further instantiating of process B that generates a throwing message does not find a target, as process A no longer exists.

Regards

Klemens

Thanks a lot for the answer. In your solution, after the first message was received on time, could activity C be triggered again by the arrival of a message from another instance of pool B? Does your solution guarantee that activity C is executed only once, when the first message arrives?

Thanks a lot for the answer. In the solution proposed by the analysis of M. Zschuckelt, after the first message was received on time, could activity C be triggered again by the arrival of a message from another instance of pool B? Does your solution guarantee that activity C is executed only once, when the first message arrives?

Thanks, Klemens. I just learnt something. Actually this event-based gateway seems to work very much like the XOR rule in EPC, where the following events show which path to take. It's different syntactic sugar compared with my solution. Maybe this would be one element of solving this part of the migration problem from EPC to BPMN.

Hello Rufus,

I just learnt, that both solutions would guarantee that only the first message is processed if it arrives within the set timeframe. I'd say now that both solutions are equivalent. So it is a matter of taste which modelling style you prefer.

Best regards,

M. Zschuckelt

In the solution proposed by the analysis of M. Zschuckelt, after the first message was received on time, could activity C be triggered again by the arrival of a message from another instance of pool B? 

No, as I stated before, this does not work either with your solution (event based Gateway) nor with the equivalent solution of M.Zschuckelt based on a boundary intermediate event. After the first message has arrived, the process A is terminated.

Maybe I can help, when you explain the business background.

Regards

Klemens

You cannot compare an event-based gateway with a XOR rule in EPC. The sequence flow is based in EPC and BPMN on data that come from functions or tasks. An event-based gateway is an exception in BPMN where the decision, which branch will be followed in the sequence flow, is based on the occurence of an event coming from outside (another process or a collaboration partner) or based on a timer event. This construct cannot exist in EPC, because EPC does not know pools and collaboration between pools by message flows. A predecessor of a XOR operator in EPC must be a function where the decision is made which alternativ sequence flow will be chosen.

Regards

Klemens

Hi, in my specific case, what I want is for activity C to be executed only once, when the first message arrives. After that the process must terminate. So I assume both solutions presented are correct?

In my scenario I have a manager (pool A) and 3 supervisors (pool B). The manager sends a message to each of the supervisors. Supervisors can do nothing, or express a contrary opinion by message. The message is sent to the manager, and upon first receipt of this message, the manager must perform activity C and then the process ends.
If none of the supervisors expresses a contrary opinion, after 3 days the manager proceeds to carry out activity D. The process in question is a sub-process in the context of an approval process for articles to be published in a journal.

thanks a lot for helping

regards

Hi, in my specific case, what I want is for activity C to be executed only once, when the first message arrives. After that the process must terminate. So I assume both solutions presented are correct?

thanks a lot for helping

regards

Ok, I understand, that process B ist instantiated 3 times for the three supervisors. Let's assume supervisor 1 does nothing. Supervisor 2 has a contrary opinion within the three days. In process A activity C is executed and process A is terminated afterwards. But that does not mean that the open process B of supervisor 3 is also terminated. Processes in pools are existing independently.

Regards

Klemens

See above. An open instance in pool B is not terminated by the end of process A. Both processes communicate by message flows but exist independently.

Regards

Klemens

Yes, I agree with you, Klemens. And thank you very much for your enlighting contributions, also regarding the off-topic discussion I sparked.

Assuming, that the 3 supervisors all have the same role, I find it unusual to use the multi-instance pool at all. If the assumption is correct, that the first supervisor wins in picking the task and submitting his opinion to A and the other 2 supervisors are happy that the first one did the job, I would choose a very simple model in a single pool:

With this design the first supervisor that picks up the task is the one who will finish it - hopefully in time. When one supervisor starts working on the task it would disappear from the inbox of the other supervisors having the same role.

The story would be different, if the supervisors actually have different roles, e. g. one checks the grammar, the next the "political correctness" (some call it censorship) and the third one checks the facts. In this case you probably would like A to take into consideration all potential feedbacks from the supervisors and all supervisors get a different supervision task pertaining to their role. This could also be done in a single process (Pool), but it would be more complex.

thank you so much!

regards