JBPM 6 Inclusive or Parallel Converging Gateway Release on one path completing

[tonycattlin]

Hi,

I have a question regarding a standard BPM pattern and would like to know the best way to achieve in JBPM 6.

With a diverging inclusive/parallel gateway, that evaluates to >1 path executing, I want to move on from the converging gateway when just one of the paths completes and kill the other path(s). What is the best way to achieve this ?

Scenario 1

- Approval is required before progressing the process, by any one of 3 different groups with 3 different screens

- We use an inclusive gateway which may evaluate to any 3 of the groups approvals (but only one is required for the process to continue)

Scenario 2

- In order for the process to move on either one of the following conditions is met:

     - A human task is completed

     - or a service call is periodically called and returns a specific value

- For this we have a diverging parallel gateway with 2 paths but we want to continue when either one of the 2 completes

Any help would be much appreciated.

cheers

Tony

[tonycattlin]

A Diverging Parallel Gateway with a Converging XOR does the trick :-)

Doesnt cope with the scenario where you want logic on the join (maybe 2 out of 3 need to complete ?) but I'll worry about that another day.

[tonycattlin]

The problem here is that the the paths are left active. The proces moves on after the XOR but the process wont complete until the other paths have been executed and taken to completion. I was hoping they would be aborted :-(

[tonycattlin]

I ended up not having a parallel gateway at all as I believe this pattern is a bit suspect in JBPM.

- I used a Reuseable Process (call) activity to launch a new process asynchronously (Wait For Completion unchecked)

- I passed the process instance id of the calling activity into the async sub process

- Meanwhile the main flow went into an embedded subprocess with a boundary Signal event

- When the called process completes it uses a script activity making use of kcontext.getKieBase().getKieSessions()...getProcessInstance(pid).signalEvent(...) to move the calling process on

- There must be some dehydrating activity (timer or human task for instance) in the called subprocess to release control back to the calling process so it can get to the signal Catch before it is fired in the called process else it will be missed