Forking sub-processes from processes (work items)

Tags: not added yet

Forking sub-processes from processes (work items)

Processes in CodeBeamer are represented by work items.
Typical work items like requirements, tasks, tests or bugs are executed sequentially, according to their defined workflow.

But there may also be more complex scenarios, where you want to execute specific process steps in parallel (split/fork) and only continue (join) with the (main) process after all these parallel (sub-) tasks are completed.

[!ParallelTasks.png!]

Solution pattern

To accomplish such scenarios in CodeBeamer, you need two types of work items (Trackers):

One for the main processes and
One for (each type of) sub processes

In the Main Process, you need to define a specific "Wait" state where sub-processes should be forked before and joined after.
In our example this status is called "Wait", but you should name this according to the type of sub-proccess you execute.
E.g. if your sub-processes are "Approvals" the state could be named "In Approval" or "Approval in Progress", for "Votings" the name could be "In Voting".

To fork/split/spawn sub-processes from a main process, you configure a

Create new Upstream-Downstream referring items action for the state transition, that leads into the appropriate "Wait" state.

The sub-process must also have a reference field, that contains the reference to the main process. This reference is needed for the sub-process to call back to the main process upon completion.

These callbacks will be typically configured in the sub-process state transitions, that lead to a final (sub-process) state and they should trigger the appropriate (wake up) transition of the main process.

In our example, for the main process to be Approved, all sub processes must have been Approved.
Therefore we need to configure a Guard (gate) for the "Approve" transition of the main process, that will block this state transition unless all sub-processes are finished and none of the sub-processes was rejected.

Because the main process is Rejected as soon as one of the child processes gets Rejected, we do not need a Guard/gate for the transition to "Rejected" on the main process.

WorkflowDemo template

You can download and install this sample scenario as a Project Template:

Processes is the main process tracker
Approvals is the sub process tracker

The Main "Processes" workflow is configured like this:

[!MainProcessFSM.png!]

The Create new Upstream-Downstream referring items action is configured for the "Verify" transition:

[!MainProcessVerify.png!]

The Guard to check that all sub-processes have finished and none of them was Rejected:

[!MainApprovalGuard.png!]

is attached to the "Approve" transition:

[!MainProcessApprove.png!]

The "Approvals" sub-process workflow is configured like this:

[!SubProcessFSM.png!]

The callbacks to the main process are configured in the "Accept" transition:

[!SubProcessApprove.png!]

and in the "Reject" transition:

[!SubProcessReject.png!]

Please also note, that in the "Accept" transition also the field "Resolution" of the "Approval" sub-process (itself) is set to "Fixed" (which was given the meaning "Successful").
This is a little but important trick, in order to allow the Main "Process" Approve Guard to distinguish between "Accepted" sub-processes (successful) and "Rejected" sub-processes (unsuccessful).