The attached project demonstrates issues with the current implementation of parallel flows.
To get parallel flows working correctly the BPMN must be laid out with the parallel flows denoted by gateways

Omitting the forking gateway which is permitted by the BPMN spec results in the parallel flows being omitted from the execution.

Omitting the merge gateway which is also permitted by the spec results in an implicit merge or sync contrary to the spec see post about earlier release here .. http://bpms.intalio.com/forums/intalio-bpms-5.2-beta/workflow-pattern-...


The project provides 4 BPMs tracing the flow through the process which can be run directly in BPMS from the console.

David

David,
Thanks for the testing that was very useful.

Actually we do support implicit merge, the case that you have did not detect it because of a bug. That will be fixed in the next release.

The implicit fork however is not supported yet and I have created an enhancement request for it.

Thanks for taking the time to trying all that.

Cheers!

Speaking of that I would like to seize the opportunity to emphasize on a "Best Practice" technique that we strongly recommend our users to respect: " Always use Explicit gateways". It is also a best practice according to the BPMN1.1 spec: ( section 10.2.1.1 Forking Flow).

It is a best practice because keeps the diagram clear and easy to read and avoids confusion. Of course, in simple diagrams like the one here that does not matter much, but in complex ones with 10 parallel paths that will be very useful.

Of course, that does not mean that we are not going to support it.

Thanks

I do not think that the specification should be read as giving the "best practice" tag to "always use best practice".
From the spec...



In addition, some modelers may wish to create a “best practice” where
Parallel Gateways are always used for creating parallel paths.my emphasis

I do agree that it is clearer modelling but is not necessarily an appropriate requirement to place on business people. Business analysts, especially at early iterations of process design, may see the activity as creating the parallel flows and may not want to be explicitly synchronising these flows ... a later iteration of the process design may break down the activity that is the source of the uncontrolled parallel flows so that the parallel flows start independently.

David

I did not say "Always use gateways". I said there is a best practice that says "Always use gateways" which are two different things. Otherwise this would contradict with the fact that we support people who do not want to use the best practice.

Business analysts, especially at early iterations of process design, may see the activity as creating the parallel flows and may not want to be explicitly synchronizing these flows

Are you talking about the explicit/implicit fork? because I don't see what synchronizing means in this context ? we talk about synchronization only in the merge . Am I missing something?

... there is a best practice that says "Always use gateways" ...
I accept that. There are circumstances when I would adopt it as best practice for organisations that I am involved in. I am glad that you are going to implement the spec in this case because the best case is NOT universally accepted nor is it regarded as the best practice in the spec. In the mean time I am happy to put the gateways in to get Intalio to generate correct BPEL code.

With or without the gateway, the parallel flows will start at the same instant. However the gateway can be seen as setting that instant independently of the activity ahead of it.

If an activity that is followed by parallel flows is refactored or broken down, it may become possible to initiate those parallel flows independently (making the overall process faster perhaps). The gateway may inhibit such design refinement because it explicitly states the forking point is outside the activity.

Perhaps I am seeing an issue where none will exist in practice but I think we should be wary of "best practice" until there is a significant body of practice to choose from ... I do not think that we are there yet!
David