Show TOC

Background documentationRule-Based Workflow

 

Instead of building your own workflow template, you can use the MDG rule-based workflow. Using the rule-based workflow, you can configure any kind of change request process without having to create and adapt a workflow template. You can define different change request processes in decision tables of the Business Rules Framework plus (BRFplus), which are maintained in Customizing for each change request type. At runtime, the current step, the user interactions, and other parameters in the decision tables determine the process flow of the change request. When you adapt the decision tables in BRFplus, you can add or remove a change request step, or change the order of the steps without changes in the workflow template.

The rule-based workflow uses BRFplus to determine the change request status, the next change request step, and expected agent(s). To make this information available, the system uses the current step, the last action, the priority of the change request, and, where appropriate, the reason of rejection as input parameters. You access the BRFplus application to determine how change requests are processed for a particular change request type in Customizing activity Configure Rule-Based Workflow under Start of the navigation path General Settings Next navigation step Process Modeling Next navigation step Workflow Next navigation step Rule-Based Workflow End of the navigation path. If you process this Customizing activity for a change request type for the first time, the system generates a BRFplus application for each change request type. Each application contains functions, rule-sets, and decision tables. The content of the decision tables defines the change request process.

Three decision tables are available for each change request type:

  • Single Value Decision Table

    The Single Value Decision Table DT_SINGLE_VAL_<change request type> defines the process flow between the change request steps. Based on the previous step, the action, and other parameters, this table returns the next step and other result parameters. The most important result parameter is the condition alias that links to the other decision tables. This decision table has the following condition columns:

    • CR Previous Step

      This parameter contains the previously processed change request step.

    • Previous Action

      This parameter contains the result of the previous system or previous user action.

    • Chng. Req. Priority

      This parameter contains the current priority of the change request.

    • Chng. Req. Reason

      This parameter contains the reason for this change request.

    • CR Rejection Reason

      This parameter contains the reason for rejection of this change request.

    • CR Parent Step and Parallel Agt Grp No.

      These columns are used for parallel processing. Based on the columns, the rule-based workflow determines the next step in the relevant subprocess. The system identifies the relevant subprocess by referring to the values in CR Parent Step and Parallel Agt Grp No.. For more information, see Parallel Processing.

    Based on the data from these condition columns, the system carries out the actions and sets the statuses outlined in the result columns. This decision table has the following result columns:

    • Condition Alias

      The condition alias references the other decision tables. Each condition alias must be handled using at least one row in either the User Agent Decision Table or the Non-User Agent Decision Table.

    • New Chng. Req. Step

      This parameter contains the next step in the process.

    • New CR Status

      This parameter contains the new status for the change request.

    • Hours to Completion

      Once the expected completion time in hours has passed without any of the agents having processed the work item, the system automatically sends a notification.

    • Merge Type and Merge Parameter

      In parallel processing, the merge type and the merge parameter define how the results of the subprocesses are merged back into the higher-level process. The system only supports the merge type B calling a BAdI method. The filter value for the BAdI is determined by the merge parameter. For more information, see Parallel Processing.

    • Dyn Agt Sel Service

      The service name is used to select an implementation of BAdI: Dynamic Selection of Agent in Rule-Based Workflow in MDG Customizing under Start of the navigation path General Settings Next navigation step Process Modeling Next navigation step Workflow Next navigation step Rule-Based Workflow Next navigation step Business Add-Ins End of the navigation path. The implementation can overwrite various result values and determine the user agent groups. You can use this BadI, for example, to determine the processors at runtime based on data in the change request. For more information, see the documentation of BAdI: Dynamic Selection of Agent in Rule-Based Workflow.

  • User Agent Decision Table

    The User Agent Decision Table DT_USER_AGT_GRP_<change request type> determines the processors of the change request step that was returned as the next step by the Single Value Decision Table. It also determines the change request step type that defines the actions processors can execute.

    This table has the following condition column:

    • Condition Alias

      The condition alias links the row in this table with corresponding rows in the Single Value Decision Table.

    This decision table has the following result columns:

    • User Agt Grp No.

      Enter an arbitrary value in the column User Agt Grp No., and enter the processors in the column User Agent Value. If you need more than one entry for User Agent Value to define the processors, enter the same value for User Agent Group and Condition Alias in each row to create one user agent group.

      You configure parallel processing of the 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. For more information, see Parallel Processing.

    • Step Type

      The step type defines the possible actions for the processor in the change request step.

    • User Agent Type and User Agent Value

      Identifies what kind of agent receives the work item in a change request. It can be a single user, an organizational unit, a role, a job, a position, or a special user. The user agent value defines the agents a work item can be sent to. It can be a user ID, or a user group ID. It can also point to rather than directly identify the user agent – for example, with user agent type SU (single user), the user agent value LAST specifies the last processor, and the user agent value INIT specifies the requester of the change request.

  • Non-User Agent Decision Table

    This decision table determines the process patterns for background steps.

    The Non-User Agent Decision Table DT_NON_USER_AGT_GRP_<change request type> contains the background steps that are involved in the change request process and that do not have end user participation.

    This table has the following condition column:

    • Condition Alias

      The condition alias links the row in this table with corresponding rows in the Single Value Decision Table.

    This decision table has the following result columns:

    • Agent Group

      Enter an arbitrary value in this column to execute the operation in column Process Pattern in the background.

      If you are using parallel processing, create a row for each process pattern that is to be executed in a separate subprocess. Choose a different value in this column for each row. For more information, see Parallel Processing.

    • Process Pattern

      The Process Pattern controls the flow of the process and to define what the system is to perform in this change request step. Frequently used values are:

      • 05 Activation (do not bypass snapshot)

        Activates the change request, for example, after final approval.

      • 08 Roll Back Change Request

        Removes all inactive data, for example, after the change request was rejected.

      • 99 Complete (Sub-)Workflow

        Completes a workflow or a sub-workflow. This process pattern is used, for example, in the last step to end the change request process.

      See Process Pattern for a complete list of available process patterns.

    • Service Name

      The meaning of this parameter depends on the process pattern. For example, it contains the workflow template when creating a sub-workflow with process pattern 03 Call Sub-Workflow.

More Information

For information on how to create and enhance your rule-based workflow, see Creating a Basic Change Request Process and Add User-Agent Steps.