[BPMN2] How to implement uncontrolled sequence flow behaving

[camunda]

I try to figure out how the PVM works internally and how to implement this requirement best:

In BPMN if a task (activity) has more than one outgoing flow (transition), than this is an "uncontrolled sequence flow" which leads to parallelizing. So it behaves like a parallel gateway / fork!

So for every task the flow semantic must be: If there is more than one outgoing flow, ALL must be used. This should be done somewhere generic.

I think the ExecutionImpl.proceed() would be a good place, but this is PVM internal, I cannot overwrite that in the language, right?

Or maybe try to leverage the ExecuteActivity as a AtomicOperation?

Or try to do it in a abstract super class of all activities? Which seems to be a bit complicated, but possible (so I have to add the logic from the fork after the execution of the activity).

Any good ideas for that?

Thank god the uncontrolled joining is like it is default in the PVM -> XOR-Join.

Thanks
Bernd

P.S: I commit a failing test case with a uncontrolled sequence flow as Fork and two tasks, if somebody cannot stop himself from coding ;-)

[camunda]

Hmm, maybe overwriting and exchangig the "ExecuteActivity" isn't the worst idea?

[camunda]

damn it, it is final :-/ Otherwise it works, I just hacked it right away and removed the final ;-) I exchanged the execution.proceed() with fork(execution)...

But maybe Tom or Jorram have some ideas how to do that correctly?

[kukeltje]

Maybe it is a good idea for the time-being to just make it work and file a jira issue for a real solution. That way it can work for everybody by using the source, but the issue is not forgotten.

And now we are into languages anyway:
"als het niet kan zoals het moet, dan moet het maar zoals het kan" is what we say in Dutch. (finding a proper translation I came across: if it ain't dutch it ain't much. Something completely different, but just as true) 1 Heineken for each proper translation as google fails miserably

[kukeltje]

"camunda" wrote:
P.S: I commit a failing test case with a uncontrolled sequence flow as Fork and two tasks, if somebody cannot stop himself from coding ;-)

If this test was the only thing failing ;-)
- dueDate -> duedate, but named queries not updatred jbpm.execution.hbm.xml : Koen
- AbstractTaskBinding in jbpm.bpmn.flownodes.xml which does not exist (yet?) : Bernd

And the strange thing is, I do not see hudson failing yet...Or is there a delay?

Oh... I take up the challenge... coding continues

[tom.baeyens]

the real solution is to implement it in the BPMN activity base class.

add a method to the BpmnActivity like leaveBpmnActivity(ExecutionImpl execution)

changing the pvm in this respect is not desirable. the generic behaviour of the proceed is something that i think over time should be faded out. activities should be explicit in what they want to see happening. combined default behaviour like in the proceed is always process language specific. so it doesn't belong in the pvm proceed. it belongs in the process language specific base classes.

(ps you already might have noticed that in our own implementations, it is best to use the impl classes and not the interfaces)

[tom.baeyens]

btw, if bpmn would have had the synchronizing default, it is not more difficult then the parallel outgoing default. it's all a matter of methods in the base activity classes. during pvm research i experimented with extra support for these concepts. (synchronizers and propagators) turns out that all the convenience support that is build in for one use case is inconvenience for another use case. eventually it all boils down to implementating the runtime behaviour of an activity. so pvm should only have one method to implement that behaviour.

[camunda]

Ronald wrote:

- AbstractTaskBinding in jbpm.bpmn.flownodes.xml which does not exist (yet?) : Bernd

Sorry, my fault. committed it now.

[camunda]

Tom wrote:

add a method to the BpmnActivity like leaveBpmnActivity(ExecutionImpl execution)

Okay, but how does it get called? Where do I include the call to this method?

Tom wrote:

so it doesn't belong in the pvm proceed. it belongs in the process language specific base classes.

Agreed.

Ronald wrote:

Maybe it is a good idea for the time-being to just make it work and file a jira issue for a real solution. That way it can work for everybody by using the source, but the issue is not forgotten.

It required a change in the PVM code base, this I don't want to commit easily. In the bpmn module I wouldn't hestitate to do ;-)

Tom wrote:

(ps you already might have noticed that in our own implementations, it is best to use the impl classes and not the interfaces)

Yes, I did ;-)

Ah, and for the test cases I again missed the processInstance.getActivityName() method in the interface... See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=158168

[kukeltje]

"camunda" wrote:

Ronald wrote:

- AbstractTaskBinding in jbpm.bpmn.flownodes.xml which does not exist (yet?) : Bernd

Sorry, my fault. committed it now.

:-) Thought there was a lot more in there. Created a real abstract class and a separate TaskBinding,changed the UserTask and ManualTask to extend it and will move stuff up there where possible.

[koen.aers]

"ronald" wrote:

- dueDate -> duedate, but named queries not updatred jbpm.execution.hbm.xml : Koen

Sorry guys, I committed the additional change. I ran the tests this time and they give me green light...

Cheers,
Koen

[kukeltje]

the real solution is to implement it in the BPMN activity base class.

add a method to the BpmnActivity like leaveBpmnActivity(ExecutionImpl execution)

I'll do that. Filed https://jira.jboss.org/jira/browse/JBPM-2458

(ps you already might have noticed that in our own implementations, it is best to use the impl classes and not the interfaces)

The impl of the pvm? Hmm... missed that, maybe because Bernd already did some work before me.

[camunda]

Ronald wrote:

I'm in doubt. I can add a field to BpmnActivity and set that when parsing so the behaviour of forking or not is controlled by that. The other option is to do it in the activity by passing e.g. a boolean parameter to 'leaveBpmnActivity' or have two methods 'leaveForked' and 'leaveSingle' or something. I'll imlpement the one with the boolean parameterd first since that is already in place. Can always be refactored.

I still don't know how we can call the "leaveBpmnActivity". I think we really have to change the PVM there. But i am still a bit reluctant to mess around in the PVM code ;-)

[kukeltje]

Hmm... I think I might be missing something.

My 'issue' was/is that I wanted to make the leaveBpmnActivity in the to generic. I had to pass several parameters to get the correct behaviour for each activity (I'll change that a little this week)

The method itself in the base BpmnActivity in general works. So I'm not sure what your issue is.

[camunda]

But currently you call the leave from the Task.execute, right?

But for not ExternalActivities, the execute shouldn't block, so the "execution.proceed" is called by the PVM, or not?

So the leave doesn't get called correctly for a non ExternalActivity. It should be called by the PVM itself, or not? So what Tom mentioned, the processd shouldn't be implemented in the PVM but delegated to the Activity.

But if the tests are running the green bar maybe supports your solution ;-)