The rule-based workflow allows the parallel processing of a change request for processors belonging to more than one agent group. For example, you can define an approval step in which both one processor of the controlling department and one processor of the purchasing department need to approve the change request. Both groups of users will receive a work item for the processing of the change request at the same time and can complete their work independent of each other.

Parent Step

The step from which parallel processing starts is called parent step. In contrast to regular change request steps, you assign multiple agent groups to a parent step. For each assigned agent group, a subprocess is started that is executed in parallel. The first step of each subprocess has the same step number as the parent step. Therefore, the step number of the parent step and the agent group number of the subprocess are additionally used to uniquely identify each step in subprocesses. The process that is started initially after the change request was submitted is called root process.

Process Flow in Sub-Processes

Each subprocess is an instance of the rule-based workflow. Subprocesses provide the information of their parent step and the agent group for which they were started. This information is used during the evaluation of the single value decision table for determining the next change request step. Using these parameters in the single value decision table, you separate the configuration of the process flow in the initial process from the process flow in the subprocesses.

Ending of SubProcesses

Subprocesses have to be ended by using a change request step with the process pattern 99 Complete (Sub-)Process.

When all subprocesses have ended, processing continues in the parent step by evaluating the action results of the subprocesses. This is done by a result handler. For example, if any user of the two departments chooses to reject the change request in a subprocess that the overall result of the parent step rejects the change request. Result handlers are implementations of BAdI: Handling of Parallel Results in Rule-Based Workflow in MDG Customizing under  General Settings Process Modeling Workflow Rule-Based Workflow Business Add-Ins and referenced by their service name.

For more information, see the documentation of BAdI: Handling of Parallel Results in Rule-Based Workflow.

Using the actions and steps returned by the subprocesses, the result handler returns a merge step and merge action that are used in the next loop of the rule-based workflow to evaluate the single value decision table.

You need to specify the result handler in the row of the single value decision table that leads to the parent step of the subprocesses. This is done by providing the value B in column Merge Type and the service name of the result handler in column Merge Parameter.

Agent Groups

Agent groups are assigned to change request steps through the condition alias of the single value decision table. User agent groups are defined in the user agent decision table for dialog steps. Non-user agent groups are defined in the non-user agent decision table for background steps. Both types of groups are uniquely identified by their group number and the condition alias.

User Agent Groups

A user agent group specifies the assigned processors of a change request step and the step type of the dialog step. All users assigned to a user agent group will receive a workitem to process the change request step. You can use multiple organizational objects to specify the members of the user agent group. In this case, you need to create a row for each organizational object in the user agent decision table and use the same value in the columns Condition Alias and User Agent Grp No.. This defines a user agent group with multiple rows.

You configure the parallel processing of a change request step by entering different values for User Agent Grp No. and the same condition alias. For each value in User Agent Grp No., a separate subprocess is started.

It is not allowed to have rows with the same condition alias and the same user agent group, but different step type, because a change request step can only have one change request step type. However, it is possible to configure parallel steps that have different change request step types.

Non-User Agent Groups

A non-user agent group specifies the process pattern that should be executed in the background in a change request step. A non-user agent group is defined by entering the condition alias, the agent group, and the process pattern in the non-user agent group decision table.

You configure parallel processing of a change request step by entering different values for the agent group and the same condition alias. For each value in the agent group, a separate subprocess is started to execute the respective process pattern.

It is not allowed to have more than one row with the same values for the condition alias and the agent group, because only one process pattern can be executed in each change request step. However, you can define parallel background steps, in which process patterns are executed in parallel.

It is not allowed to have a row in the non-user agent decision table that has the same values for condition alias and agent group as a row on the user agent decision table, because a change request step can only be either a dialog or a background step. However, you can define two parallel steps, one as a dialog step and the other as a background step.

Phases of Parallel Processing

The phases in which the rule-based workflow handles parallel processing are as follows: