topic Re: Behavior in case of fork and no join in Alfresco Archive

Behavior in case of fork and no join

vram — Mon, 23 Jul 2012 18:44:24 GMT

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 be

Re: Behavior in case of fork and no join

ronald_van_kuij — Mon, 23 Jul 2012 21:13:40 GMT

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

Re: Behavior in case of fork and no join

vram — Mon, 23 Jul 2012 22:18:22 GMT

Thanks..

Even in the following case where I use a parallel gateway and two ends, I find the execution in another path also halting when one stop is encountered. Is this also the expected behavior?

Re: Behavior in case of fork and no join

ronald_van_kuij — Mon, 23 Jul 2012 23:26:26 GMT

Hmmm… You have me doubting now. Not only about this latest question, but even the previous one. Currently reading the specs of the end event (10.4.3)…

Re: Behavior in case of fork and no join

ronald_van_kuij — Mon, 23 Jul 2012 23:40:37 GMT

Funny thing is that the behaviour you see is the opposite of http://forums.activiti.org/en/viewtopic.php?f=6&t=3969
This post describes the behaviour I was (kind of) expecting, therefor you made me doubt.

So it alsmost seems that the default behaviour of an end event chaged to a terminate end event… This is I think, not good. Will ping the devs…

Re: Behavior in case of fork and no join

frederikherema1 — Tue, 24 Jul 2012 07:02:43 GMT

I validated this agains the current trunk-build, and BOTH service-tasks are executed after a parallel fork before the process actually ends:


08:58:42,036 FIN  | ConcurrentExecution[6] takes transition (fork)–>(service1)  [org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionNotifyListenerTake]
08:58:42,036 FIN  | ConcurrentExecution[6] executes Activity(service1): org.activiti.engine.impl.bpmn.helper.ClassDelegate  [org.activiti.engine.impl.pvm.runtime.AtomicOperationActivityExecute]
08:58:42,042 FIN  | Leaving activity 'service1'  [org.activiti.engine.impl.bpmn.behavior.BpmnActivityBehavior]
08:58:42,043 FIN  | ConcurrentExecution[6] takes transition (service1)–flow2–>(end1)  [org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionNotifyListenerTake]
08:58:42,043 FIN  | ConcurrentExecution[6] executes Activity(end1): org.activiti.engine.impl.bpmn.behavior.NoneEndEventActivityBehavior  [org.activiti.engine.impl.pvm.runtime.AtomicOperationActivityExecute]
08:58:42,103 FIN  | ProcessInstance[4] takes transition (fork)–>(service2)  [org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionNotifyListenerTake]
08:58:42,103 FIN  | ProcessInstance[4] executes Activity(service2): org.activiti.engine.impl.bpmn.helper.ClassDelegate  [org.activiti.engine.impl.pvm.runtime.AtomicOperationActivityExecute]
08:58:42,104 FIN  | Leaving activity 'service2'  [org.activiti.engine.impl.bpmn.behavior.BpmnActivityBehavior]
08:58:42,104 FIN  | ProcessInstance[4] takes transition (service2)–flow3–>(end2)  [org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionNotifyListenerTake]
08:58:42,104 FIN  | ProcessInstance[4] executes Activity(end2): org.activiti.engine.impl.bpmn.behavior.NoneEndEventActivityBehavior  [org.activiti.engine.impl.pvm.runtime.AtomicOperationActivityExecute]
08:58:42

ConcurrentExecution[6] executes Activity(service1)
ConcurrentExecution[6] executes Activity(end1): org.activiti.engine.impl.bpmn.behavior.NoneEndEventActivityBehavior
ProcessInstance[4] executes Activity(service2)
ConcurrentExecution[6] executes Activity(end1): org.activiti.engine.impl.bpmn.behavior.NoneEndEventActivityBehavior
destroying ProcessInstance[4] [org.activiti.engine.impl.persistence.entity.ExecutionEntity]

Re: Behavior in case of fork and no join

ronald_van_kuij — Tue, 24 Jul 2012 09:39:40 GMT

Thanks Frederik… Then I'm not going crazy. Have no Activiti at hand the comming days to test myself

Re: Behavior in case of fork and no join

frederikherema1 — Tue, 24 Jul 2012 11:17:24 GMT

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

Re: Behavior in case of fork and no join

vram — Tue, 24 Jul 2012 13:20:41 GMT

Thanks Ronald and frederikheremans for helping out.

In this case, for the first figure, would the 'Service Task' (that joins both the flows) wait for both the flows to be complete and then execute only once or would it be executed twice?

Re: Behavior in case of fork and no join

ronald_van_kuij — Tue, 24 Jul 2012 13:25:31 GMT

twice I would suspect and if that is not ok, then put a parallel-join after it. If you want to force it to be twice, put an inclusive gateway behind it.

Re: Behavior in case of fork and no join

ronald_van_kuij — Tue, 24 Jul 2012 13:27:20 GMT

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)

Re: Behavior in case of fork and no join

frederikherema1 — Tue, 24 Jul 2012 13:28:41 GMT

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

Re: Behavior in case of fork and no join

vram — Tue, 24 Jul 2012 13:37:06 GMT

Thanks a lot Ronald for your response …

Re: Behavior in case of fork and no join

ronald_van_kuij — Tue, 24 Jul 2012 13:47:51 GMT

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…

Re: Behavior in case of fork and no join

frederikherema1 — Tue, 24 Jul 2012 13:57:54 GMT

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.

Re: Behavior in case of fork and no join

vram — Tue, 24 Jul 2012 14:20:37 GMT

Thanks Ronald ….That was very helpful

Re: Behavior in case of fork and no join

vram — Tue, 24 Jul 2012 14:40:31 GMT

Thanks a lot frederikheremans .. That helps a lot …