Hi Brian Wallis, I can't think of a real-life use-case for your described situation . Could you explain it, please?
Anyway, Here're my two solutions:
- If those two user-tasks are in such tight constrain, may be they are very similar, We could just combine them into one and using GroupID for user assignment. Then only one can execute the task.
- We can add a script Node after the XOR converging gateway, this script can simply using a flag in the process's global scope variables to mark when the first one past and ignore the other (by direct it to an end), or go to full length of looking for the other task then abort it.
Using single task with group assignment make sense assuming they will produce same output.
If both human tasks must be there I would try following:
- encapsulate that in subprocess and use terminate node after XOR gateway which should the cancel the other active node as soon as first one reaches the terminate end event
- make use of boundary catch signal events attached to both user tasks and then add throw signal even after the user task node that will signal the other to be canceled and move to other location which would be sort of "dead end"
Thanks Maciej, I had come up with a similar solution based on some reading from workflowpatterns.com, this seems to be an example of Pattern 29 (Cancelling Discriminator). I haven't got it to work in jbpm6 yet, probably because I haven't used events in workflows before. I'll post the results when I get it to work.
Quangtin3, I don't have a real world example at the moment, I'm in the process of learning about BPMN workflows with more than the common simple examples so I'm making stuff up.
Got it working. The aborted human task seems to hang around in the list returned from TaskService.getTasksByProcessInstanceId(pid) but it has a status of Status.Exited. The bit of the workflow I have working is like so...
I needed to add the "NoExit" end node as the sub process node requires an outgoing connection for a valid workflow. That end node should never be reached