How to model a parallel join timeout?


#1

Hello,

how would you model the following situation in BPMN?

I have a process model with two parallel paths. The two paths are then joined via a parallel join gateway (+). When both paths arrive at the join, the process is executed further.

I’d like to achieve that one path waits for the other not longer than some amount of time, e.g. 20 sec. If one path (it does not matter which) arrives at the join, and the other one does not arrive within 20 sec after that, I’d like some special action to be executed.

Could you advise on how to do this?

Thank you!


#2

Hi,

Here’s my first attempt, it could be a little over engineered and a more elegant solution may exist, however I believe this effects the behaviour you desire.

This pattern relies on conditional events and a latch pattern…

regards

Rob

Latch.bpmn (18.4 KB)


#3

Thank you Rob! I assumed this should somehow use timer events and event based gateways, but could not think it to the end.

I’d have a question: shouldn’t DoA and DoB have “async after” set to “true” so that the evaluation of the variables in the rule events (“Task X complete == true?”) is done with the correct data?


#4

Hi,

maybe this could work too.

Cheers,
Ingo


#5

Wouldn’t the completion of task A possibly prevent task B from being executed?


#6

I’ve changed the above slightly to ensure it doesn’t interrupt a task:


#7

I like it a lot!


#8

Yes, I also think that’s it.


#9

Hi Niall,

Does this still result in two executions reaching the process end? (One for the main process and flow and potentially one for the escalation flow…)

I wrestled with this a little (ensuring the same semantics as a join) and ended up with a latch pattern…

regards

Rob


#10

Not in this case - The escalation event will only be triggered in the case where a token is waiting at the parallel join an another one is waiting at the task. Canceling both tokens and sending on onward to the rest of the process.
The other scenario is that both tasks are completed before the escalation is triggered in which case the tokes are merged and one token continues via the main flow and the escalation is never triggered.
So i don’t think this pattern could produce 2 tokens leaving the sub process.


#11

Hi Niall,

But in this case, I read it as a non-interrupting conditional event sub-process which has not interrupted the main flow. By throwing an escalation event, I interpret this as creating a new execution. So now I get the escalation execution and the main process flow execution?

Perhaps the escalation catch boundary event interrupts the main flow?

regards

Rob


#12

I would have thought that the escalation will interrupt it, but it’s worth testing - gonna run it now and find out :slight_smile:


#13

I ran it and here’s what happens when i start the process and complete the first task:

If i complete the second task it of course doesn’t end the event sub process:

Eventually the first timer will fire and end the sub-process completely

So i need to add a terminate event in the subprocess to make sure i don’t wait longer than required


#14

Hi Niall,

Great! For some reason I was thinking an escalation was not interrupting…But yes on a boundary it can be modelled as interrupting or not interrupting :slight_smile:

regards

Rob


#15

Hi Niall,

So now your challenge is to implement a best efforts parallel join (which is what I was trying to achieve in my first attempt)…

Requirement is;
Execute two parallel tasks.
Wait for both to complete before proceeding, except if timeout t is exceeded after either task completes. In this case, proceed with the rest of the process, but do not abandon any outstanding/in progress task…

It was the do not abandon any task which led me to use a latch pattern…

:wink:

regards

Rob


#16

Hi Rob,

Regarding your requirements.
The outgoing token of the delayed task completed should not run further through the process I assume. Correct?

Ingo


#17

Hi Ingo,

Yes. The intent is to build a ‘fuzzy parallel join’ as per my first model. This works due to the latch inplementation…

(Im not sure the pattern has practical application…)

regards

Rob


#18

ok, what about this?


#19

Yes, that looks like it meets the spec. :grinning: