[BPMN2] Task-Outcome must be implemented differntly

[camunda]

Hi.

Just wanted to write it down for now: Since BPMN defines more than one outgoing flow as AND-Split (fork), this applies to the UserTask as well.

This means, the XOR semantic from jPDL, where the user selects a outgoing transition, cannot be applied here. In my opinion it must be modelled as conditions on the flow (assume we have Java Expression Language):



#{outcome == "ok"}


#{outcome == "cancel"}


Now the outcome can be set by the task management like in JPDL and it works the same.

Sounds logical?

Cheers
Bernd

[camunda]

Sorry, default mistake ;-)

<userTask id="x" />
<flow name="ok" sourceRef="x" targetRef="y">
 <conditionExpression>#{outcome == "ok"}</conditionExpression>
</flow>
<flow name="cancel" sourceRef="x" targetRef="y">
 <conditionExpression>#{outcome == "cancel"}</conditionExpression>
</flow>

[kukeltje]

wow, we have a noob here in the forum... ;-)

Yes, sounds logical. But this means that signalling via the api should set this variable? or can we have an additional solution that if there is a textual (non formal) condition that when signalling flow name/id is used.

I can implement anything like this, but it has to be very specific. Including things like what if there is no flow that has a condition that evaluates to true. etc...

[tom.baeyens]

i'm not sure if i get the point exactly.

in any case, the parallelism and condition evaluation should go in the leaveBpmnActivity. so that by default, each outgoing transition is evaluated and forked if the condition resolves to true.

another aspect is that we should consider extra services. executionService.signalExecutionById might be fine. But we can also consider adding a BpmnService which allows the user to enter "BPMN" messages that the engine has to react to. This way we can offer the real BPMN terminology to the BPMN users. On the other hand, leveraging the ExecutionService might be easier to get started in the beginning.

[camunda]

Tom wrote:

in any case, the parallelism and condition evaluation should go in the leaveBpmnActivity. so that by default, each outgoing transition is evaluated and forked if the condition resolves to true.

Exactly, this is what I think as well.
I will just set a variable "outcome" in the UserTaskActivity.signal method with the value of the signalName? BPMN spec doesn't say anything about it (or I missed it). I think this is a good solution at least for the moment, what do you think?

Tom wrote:

But we can also consider adding a BpmnService which allows the user to enter "BPMN" messages that the engine has to react to. This way we can offer the real BPMN terminology to the BPMN users.

I would wait if we see the demand for it. For the moment I think the bigger advantage is to have the same API for BPMN or jPDL.

If we want to leverage full BPMN vocabulary we still can write that facade...

Ronald wrote:

wow, we have a noob here in the forum... ;-)

Jajaja ;-)