Behavior in case of fork and no join

[vram]

I have a flow as attached with just a fork , but no join.


When I try to run this, I find the flow in the first path(since it is faster) completes and once the end is reached, the entire process is stopped even though the flow in the second loop is mid way through the execution.

Is this the expected behavior? It would be great if someone could clarify on this

[ronald_van_kuij]

Ronald, don't tell me you're looking in the activiti-forum while on holiday, right?

hahahaha no, my laptop is undergoing 'maintenance' and I do not want to configure things on this temporary laptop (not even Linux :-() So I reverted to writing documents (yes in WORD, not OO/LO)

[frederikherema1]

This is expected according to the specs afaik. Add a join after it…

As ronald says, add a join if you want the "service-task" to wait for both flows. If you don't, the first flow that arrives there executes the service-task. The second flow, when completed, does the same, effectively executing the service-task twice.

If you want the behavior of "the first flow that reaches a certain point" to terminate the existing ones, you should take another approach. Eg: Add a sub-process around the part that contains the two paths. Instead of a regular end-event, use a message-thowing one. On the sub-process, add a foundry catching event that cancels the activity (the subprocess with one flow still "waiting" or active) and carry on from there.

Quite sure there are other solutions for this, I'm not that much of an BPMN expert

[vram]

Thanks a lot Ronald for your response …

[ronald_van_kuij]

If you want the behavior of "the first flow that reaches a certain point" to terminate the existing ones, you should take another approach. Eg: Add a sub-process around the part that contains the two paths. Instead of a regular end-event, use a message-thowing one. On the sub-process, add a foundry catching event that cancels the activity (the subprocess with one flow still "waiting" or active) and carry on from there.

This is a use-case I encounter so much, that I find it weird it is not in the spec to cancel just a task. Why do I have to wrap it in a subprocess then??? We created our own service task that can be used to cancel the parallel task. But it gets complicated if there are more… Sigh…

[frederikherema1]

I think this is a better approach: http://activiti.org/userguide/index.html#bpmnEventbasedGateway combined with an exclusive join… As I said, I'm not a BPMN expert, was just thinking out loud from what I know. So there was indeed a better solution for stuff like this. Perhaps joining on an exclusive gateway instead of a parallel may do the trick…

If the signal is not fired, execution continues after the timer and the signal subscription is cancelled.

[vram]

Thanks Ronald ….That was very helpful

[vram]

Thanks a lot frederikheremans .. That helps a lot …