Open topic with navigation

Parallels in Workflows

Parallels

The Parallel characteristic is used for implementing two or more clusters simultaneously in the workflow. A Parallel state will automatically get the cluster characteristic indicating that it can only contain clusters as its immediate sub-states.

Once the Final states of all the clusters that are immediate children of a parallel have been reached, the parallel is automatically exited upon the next transition.

Exiting a Parallel

Transitions from parallels and Final states in clusters can be simultaneously and automatically triggered by using the formula Parallel ID.done to name the event. This then allows the object in the workflow to move to the next state outside of the parallel.

  1. In the picture below, an object entering into the workflow would first enter into the parallel (as it is also the Initial state), and into the Initial states inside of each cluster simultaneously.
  2. The object would then proceed through both clusters simultaneously until the Final state for each cluster is reached.
  3. Once the object has reached the Final states in all clusters inside of the parallel, it then leaves the parallel and all clusters at the same time and enters into the first state outside of the parallel.
  4. If the event on the transition out of the parallel is named with the formula of Parallel ID.done (in this case State-13.done), the object leaves both Final states in the clusters and the parallel at the same time, and automatically goes to the Review State which is situated outside of the parallel state. If the event is unnamed, or named without this formula, it would have to be manually moved to the Review State.

Note: When going through the workflow, it automatically will look for Parallel ID.done events first to be tried and performed, but if none exist it will then look for transitions with no special named events.

  1. The object then continues through State 2 and ends in Final.
  2. While the object is finished going through the workflow, it will not leave the workflow unless coding is in place to trigger it to leave, or the object is manually removed.

Note: Prefixing an event on a transition with the ID of the state from which the transition goes and a dot ('.') will cause the event to be hidden to users working with the workflow in the workbench. This approach should therefore be used whenever you have a 'system' event that should not be triggerable by human users.

The image below shows an alternate way of configuring a parallel and transition relationship. There is a transition from Initial Cluster out of the parallel straight to Review State. If this transition is performed, the entire parallel and all its sub-states will be exited regardless of which state the object is in for Cluster 2.

Note: Parallel States are used for modeling concurrency and should only have child states with the Cluster Characteristic. Cluster and Parallel States do not typically represent human Tasks.

 

2018, Stibo Systems – Confidential