Synchronising tasks finish-to-finish

[pojomonkey]

I've got a process definition that forks in one branch of a prior fork and then the 3 execution paths eventually join back up through 2 consecutive joins:

<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="" name="syncproblem">

 <start-state name="start-state1">
 <transition to="task-node1"></transition>
 </start-state>

 <task-node name="task-node1">
 <transition to="fork1"></transition>
 </task-node>

 <fork name="fork1">
 <transition to="task-node3"></transition>
 <transition to="task-node2" name="to task-node2"></transition>
 </fork>

 <task-node name="task-node2" async="true">
 <transition to="join2"></transition>
 </task-node>

 <task-node name="task-node3">
 <transition to="fork2"></transition>
 </task-node>

 <fork name="fork2" async="true">
 <transition to="task-node4"></transition>
 <transition to="task-node5" name="to task-node5"></transition>
 </fork>

 <task-node name="task-node4" async="true">
 <transition to="join1"></transition>
 </task-node>

 <task-node name="task-node5" async="true">
 <transition to="task-node6"></transition>
 </task-node>

 <task-node name="task-node6" async="true">
 <transition to="join1"></transition>
 </task-node>

 <join name="join1">
 <transition to="join2"></transition>
 </join>

 <join name="join2">
 <transition to="task-node7"></transition>
 </join>

 <task-node name="task-node7">
 <transition to="end-state1"></transition>
 </task-node>

 <end-state name="end-state1"></end-state>

</process-definition>

This all works fine, except that I actually want to make sure that task-node4 does not (cannot) end before task-node6 completes, and similarly, I want task-node2 to delay completion until task-node4 has completed.

The process defintion as shown works ok, and I do get up to 3 tasks in the task list of the jbpm-console, but I can then end any of them in any order, whereas I actually need them to sequence as described above.

Apart from an expression/script condition on the leaving transactions, is there a more elegant way to graph this?

[kukeltje]

uhhmmm... why did you put them in forks if you want them in sequence (at least that is what you describe)?

[pojomonkey]

First of all, there are different tasks to be performed by different actors and furthermore, the tasks are starting at different times.

So they are not 'sequential' as such - there is simply a constraint on them finishing in a particular order.

If I stick them all on a single task node, or put a lot of code behind to organise this ordering, then it makes it much more difficult to change the process through changing the graph. It would also hide this part of the process.

[pojomonkey]

Just to clarify - rather than necessarily finish in a specific order, the tasks must not finish before one (or, in the general case, one or more) other task is finished.

You have queried my use of fork, but are you really saying that fork is only appropriate where the tasks are entirely independent?

As an illustration, in the websale example, is it not reasonable to assume that 'ship item' should not complete before 'wait for money' was completed? Now while the join perhaps implies this synchronisation, the 'ship item' node can fully complete even if 'wait for money' never completes...

[pojomonkey]

Despite now having got various scenarios working with forks, joins and sub-processes, I'm still not clear on how I can achieve finish-to-finish synchronisation except by some logic external to jBPM.

I would welcome any thoughts on this.

[kukeltje]

The join in the websale example implies that the process cannot continue until *both* are finished. It might not be real-world compliant, but that's just how it was designed.

Your finish-to-finish (one cannot finish before the other) requirement imo creates a dead-lock. They both have to finish at exactely the same time. Even with logic outside jBPM, you have the same problem.

Why not simply introduce things like 'prepare shipment' that is where the ship item is now and move the ship item below the join....

[pojomonkey]

I tried putting a condition on a leaving transition - but that just complicates matters.

"kukeltje" wrote:
Why not simply introduce things like 'prepare shipment' that is where the ship item is now and move the ship item below the join....

Interesting thought - I could have a 'start' even before the join(s) and a 'stop' even after the join...

In which case I'll just want an 'event' node - sounds like a 'vanilla' node with an action...

Thanks for the inspiration :)

[kukeltje]

business process automation and the process design that is part of it is about thinking out of the box, the box in this case being the processes as people *perceive* them. Most of the time you cannot do this without business process redesign.

Glad to hear I'm an 'inspirator' :-)

[koen.aers]

"kukeltje" wrote:
Glad to hear I'm an 'inspirator'

You should start a sect, maybe they'll call you an 'instigator' than later :-P

Cheers,
Koen