All,
I have been thinking about the Parallel steps some more and I drew some pictures to help the discussion. I am glad that we are moving the properties into the steps and out of the common properties, because it is forcing us to see some of these issues.
From a BPMN perspective, at the end of a parallel step there is an aggregation point, as shown in the following example:
But we do not have the concept of an "End Parallel Step", nor do I think that actually works in code. But we can replicate the concept of an aggregation point with the on_completion property.
In this next example the on_completion is OPTIONAL and thus the various branches can just END when they are done. Meaning, there is no aggregation point at the end of the Parallel step. My question is, do we want to allow this kind of behavior? My guess is no, because we say that the branches have to end and then processing continues at the Parallel Step.
In the next two examples you can see that we have the on_completion, aka an aggregation point. In these cases the on_completion is REQUIRED. The first example just immediately ENDs after the Parallel processing is done. The second example has an Action step that takes place after the Parallel step is done, aka after the aggregation point.
With all of these though, I am not sure what to do, if for example Branch 3.2 fails, does that failure need to roll up into the Parallel step so that back out procedures can run? If not, I am not sure how you could do a condition after the aggregation point to see if cleanup / backout procedures need to run. Maybe you would need to set some sort of variable? If so, we should include an example.
But I also like the simplicity of not having on_success and on_failure at the parallel step level. But if they are, then all of them would need to be able to be defined, unlike what we have today, where you can not use both at the same time. Something for us to talk through during our next call.
I would like to talk through each of the conditional logic steps during our call, asking the questions for each one that I have brought up above. So please think through those examples and come prepared to discuss. Yes, we are going to need to also tweak some of the descriptions to make all of this clear for implementers. I did not see this until we started moving the properties out of the common properties. So I am GLAD we did.
Bret