Block Structure Rules

As mentioned earlier, the way that brackets work in a mathematical expression is a close analogy for how "blocks" work in a workflow. Recall - there are several types of blocks: Choice, Parallel and Loop. In Cúram workflow:

• Any block-starting constructs (Choice Split, Parallel Split or Loop- Begin Activity) must be terminated by a corresponding block-ending construct (Choice Join, Parallel Join or Loop- End Activity respectively).

  In the case of Splits and Joins - all paths outbound from a split must converge at the corresponding Join.

  Rationale: Requiring Splits and Joins (for example) to be matched improves readability. In a section containing multiple paths, it makes it clear whether a single path (or many) can be followed. This in turn makes it clear whether or not synchronization is required at the point where the paths merge.

  If they were not required to match, it would be possible (easy!) to model processes that would be guaranteed to stall, or ones in which the end of the process could be reached before some activities had finished executing.

• Blocks can be nested within each other (e.g. a Choice Split inside a Loop), but they cannot be interleaved (e.g. None of the transitions from the choice split can go to an activity outside the loop).

  This helps avoid situations that are difficult for the engine to process and are very unintuitive for workflow developers.

  Consider a Loop that contains a Join, where the Join has two inbound transitions: one from an activity inside the loop, the other from an activity outside the loop.

  It is very difficult in this situation to decide how the join synchronization should work. One inbound transition can only fire once, the other can fire multiple times. Any rules for handling such a situation in the would be arbitrary and hence unintuitive.

  Workflows defined using Choice, Parallel and Loop blocks have a clear, simple structure whose meaning can be understood at a glance.