The BPMN spec says that the modeler should ensure that there is a valid condition to be taken at run time at gateways and the implementation is undefined for the case when there is no valid condition. I can't complain then, when I make this stupid mistake. However, I was surprised by the Intalio implementation of this :

when neither conditions cond 1 nor cond 2 is satisfied, the sequence flows without complaint to "eitherorboth". Is this an intentional feature?
I would actually prefer the execution to crash in a heap rather than silently progress through a path not defined as it would show up in testing!

David

David, the way we model an or gateway in BPEL is like this:
http://pastie.textmate.org/238398

I'll file a bug for this problem. Thanks for reporting it.

Thanks,

Antoine

Another issue at 5.2 with gateways is with overlapping parallel flows demonstrated here . If there is a flow out of a parallel flow which bypasses the join of parallel flows then the join logic is ignored in creation of BPEL.
I am confident that the BPMN is valid and the underlying business logic is reasonable but I cannot see any easy solution so avoiding this construct in BPMN is probably a good idea at present.

David

David,
I have to admit that is a hard use case :)

But from my point of view, I think that the "parallel join" is not used correctly here.

This specific shape is used to synchronize activities, i.e it assumes that all paths merging will be executed and the "parallel join" should make sure they will be synchronized ( i.e all execute before going on)
Which is a very good restriction , because what should the process do if one of those paths will never get executed , terminate ? wait indefinitely"? how would the process know that this path will never be taken ?

This restriction is expressed in BPMN1.1 (section 9.5.5.2) as follows :


To define the parallel nature of this Gateway’s behavior for diverging Sequence Flow:
° All Gates SHALL be selected during performance of the Process.

and in your case , the "join parallel" will not be selected in some cases.

Even if this was allowed, I would strongly discourage it as it is not as obvious as it should be. A diagram should speak for itself, and it took me more than 5 minutes to understand what the flow in this case was.

One more point, I did not really understand the logic of the use case. Can you please explain further what you are trying to achieve?

Thanks

The example is not intended as 'good practice'. It is actually taken from your library of contributions. Although it does not actually demonstrate deadlock, it does show something that is easily drawn but does not work as intended/expected.

I actually think that it is a reasonable expression of a business process that may occur early in analysis. You have two parallel activities returning state and an activity that is performed subject to a conditions in both of them. I agree that this can be redrawn to fit your implementation and interpretation of the spec BUT I don't think this is a good idea for the process analyst especially when describing the AS-IS state. My idealised view of BPMS-centric design would have the process analyst demonstrating the process design is 'complete' by compiling and simulating the operation ... having to introduce constructs that do not map well to real life (however screwed up) makes it difficult to related the simulation with business operation. We really must avoid the business analyst having to think like a javaprogrammer.

I have read the section 9.5.5.2 many times and cannot derive much sense from it but I will leave it to you experts.
David

In section 10.2.1.11 I found some information on how to avoid illegal models. Figure 10.49 - Potentially a dead-locked model , resembles to a great extent to our use case here.
I quote from this section :

In general, the analysis of how Tokens will flow through the model will help find models that cannot be executed
properly. This Token flow analysis will be used to create some of the mappings to BPEL4WS. Since BPEL4WS is
properly executable, if the Token flow analysis cannot create a valid BPEL4WS process, then the model is not structured
correctly

Even when we look at the way you have expressed your problem:

You have two parallel activities returning state and an activity that is performed subject to a conditions in both of them

Just by reading this sentence of yours you can see that the use case is using the "parallel merge" as a way of describing a condition, which is normally supposed to be done using an exclusive gateway.

I do agree that this diagram is still BPMN, however it is a bit far from being the best one in my opinion. Of course, the bug is already filled and if we can find a way to support that kind of diagrams we will do so .

Thanks for sharing the problem with us,this is definitely an interesting discussion.