SAP MDG Process Modelling

Overview

• In SAP MDG, every change to master data is initiated using a change request.
• After a change request is initiated, it needs to be processed before activation or rollback by applying governance rules and collaborations.
• The process model provides the required input (metadata) for change request creation and processing, e.g., workflow, CR steps, and objects that can be processes.
• Submit and activate/rollback are mandatory steps in a change request.
• MDG reuses the SAP Business Workflow component of an underlying SAP business suite.
• SAP MDG workflow is an instance of SAP Business Object BUS2250.
• If the request has parallel processing, then each parallel step of the change request will have one BUS2250 instance.

Define Governance Scope:

• Here we can define governance scope on the entity as well as the attribute level.
• For example, we have kept ‘NO’ to the below custom entity.
• As a result of MDG UI, the UIBB for this entity will only be in read-only mode.

Business Object

• An object is a real-world entity.
• Objects that are used in business processes are business objects.
• It can be tangible or intangible.
• For example, in MDG, we mainly work with business objects such as customers, vendors, business partners, materials, cost centers, profit centers, and G/L accounts.
• In MDG, every entity type 1, UI application, and outbound implementation in DRF should be assigned to business objects.
• MDGIMG -> General Settings -> Data Modeling -> Define Business Object Type Codes.

Business Activity

• Business activity defines the kind of activity or action we are going to perform on which business object.
• Each combination of logical action and business object becomes a business activity.
• MDGIMG -> General Settings -> Process Modeling -> Business Activities -> Create Business Activity

Change Request

• The change request is a key characteristic of the change request that determines how a change request is processed.
• The change request type links a change request to the workflow, data model, and business activity.
• Change requests have the following properties:

Change Request Steps

• CR steps are identified as dialog or background steps in a change request process.
• The process of configuring CR steps differs based on the workflow template used.
• Configuring CR steps involves the following inputs:
• CR Type (for rule-based workflow) or workflow template (for another workflow template)
• CR step numbers and descriptions
• Keys
• In the step in which we enable the key, the system mandates that the user enter the key field value of the changed entity in that particular step.
• Generally, key fields should be entered first, but MDG gave us the flexibility to delay entering key fields until the final step is in process.
• Validation
• The validation checkbox indicates the final execution of all validations.

Properties of CR Steps

• We can control the following things in this configuration:
• How various checks and enrichments are performed.
• Whether entity types and attributes are relevant and required.
• The setup of a different UI for each change request step.

• Enhancements and Checks per Change Request Step
• For each change request step, you can control the behavior of these checks.
• Following is a list of checks done by SAP MDG:
• Basic check
• Authorization check
• Duplicate check
• Validation rules configured in BRFplus
• Validation rules developed using BAdI
• Existence check
• Reuse area check
• We can set the following properties to these checks:
• Sequence: All standard checks will perform at first, so SAP made it default to 0, and duplicates will perform at last, so the sequence is 99.
• Message Output: Some times, the requester who is creating CR may not be an expert in completing various parts of the data. In such scenarios, CR can’t be submitted without addressing the errors. MDG addresses this problem by providing an option to display error messages as warnings for a specific change request step. However, before activation, all checks are performed.
• Relevant: It’s possible to select whether a specific check is relevant for the change request step or not. Except for the basic check, all other checks and enrichments can be set as not relevant if needed.
• Execution: Provides an option to trigger checks either as always executed or only when data is changed. For example, duplicate checks don’t always have to be triggered and can be triggered only when relevant data is changed.

Change Request Action

• CR actions correspond to UI buttons for processing a change request.
• This action can be defined as part of the step type.
• We can create actions using the following properties:
• Description
• Pushbutton Text
• Quick Info Text
• Check
• Note
• Reason 

Change Request Step Types

• Change request step types are used to assign a set of user actions to foreground workflow tasks.
• These step types, once associated with actions, determine the possible user actions on a UI.
• For a workflow that isn’t rule-based, step types are assigned using a Workflow Builder, whereas for a rule-based workflow, step types are assigned using BRFplus.

User Interface Determination

Following is a list of various configurations where UI assignment is configured:

• Change request step level UI assignment.
• UI is assigned to the logical action and business object type combination.
• UI assigned to the change request type.
• UI adaptations such as context-based adaptation, customization, or personalization.

Rule Based Workflow

• Rule-based workflow is already defined in the SAP system.
• We can use the Rule Base Workflow instead of creating our own customized workflow template.
• Using this, we can configure any kind of change request process.
• RBW is configurable using BRF+ decision tables.
• We can define different change request processes in the decision tables of the Business Rules Framework Plus (BRF+).
• We can add or remove change request steps or change the order of the steps without making changes to the workflow template.

Types of Decision Tables

• Single Value Decision Table
• Defines the process flow between the change request steps.
• Based on the previous step, action, and other parameters, this table returns the next step and other parameters.
• Here, the important resultant parameter is condition alias, which links to the other decision table.
• User Agent Decision Table
• Use to determine processors and UI actions for the CR steps.
• Also, determine CR steps that determine possible actions the processor can execute.
• Non-User Agent Decision Table
• This contains the background steps that are involved in the change request process and that don’t have end-user participation.

Decision Tables Column Properties

1. Single Value Decision Table

SR	Columns	Descriptions
Condition Columns
1	CR Previous Step	Contains the previously processed CR step
2	Previous action	Contains the result of the previous user action
3	CR Priority	Contains the current priority of the change request
4	Chg. Req. Reason	contains the reason for this change request
5	CR Rejection Reason	contains the reason for rejection of this change request
6	CR Parent Step	Used for defining parallel workflow process and indicates the step from which parallel processing is indicated
7	Parallel Agt. Grp No	Used for defining parallel workflow process and indicate agent group number of sub-processes.
Result Columns
8	Condition Alias	The condition alias references the other decision table. Each condition alias must be handled using at least one row in either the User Agent DT or Non-user DT.
9	New CR Step	Contain Next step in the process
10	New CR status	Contains the new status for the CR
11	Hours to Completion	Expected No of hrs. for completion of the work item. If not completed, system automatically sends the notification
12	Merge Type	Used for merging the results after parallel processing into higher level process. System only support the merge type B 2calling a BADI method.
13	Merge parameter	Along with merge type with the value of the service name used for the BADI implementation
14	Dyn. Agt. Sel. Service	Service name used for implementation of BADI: Dynamic Selection of Agent in RBWF

2. User Agent Decision Tables

Sr. No	Columns	Description
Conditional Column
1	Condition Alias	Condition alias links the row in this table with corresponding rows in the single value decision table. Used in SVDT to identify the condition which require user action
Result Columns
2	User Agent Group No	Value maintained to identify the user agent maintained in user agent value. For parallel processing, different user agent group no is entered to identify each subprocess with same condition alias.
3	Step Type	Step type defines the possible action for the processor in the CR step. Define the UI action.
4	User Agent Type	Identify the User Agent Type: User, Role, Job, Organizational Unit, Position, or Special User.
5	User Agent Value	Depending on the user agent type, either a user or a group value is maintained. Special values such as LAST (Last Processor), INIT (Requestor of the CR) can also be maintained.

3. Non-User Agent Decision Table

SR	Columns	Descriptions
Conditional Column
1	Condition Alias	Condition alias links the row in this table with corresponding rows in the single value decision table. Used in SVDT to identify the condition which require user action
Result Columns
2	Agent Group	Work along with the process pattern column to identify if there are multiple process pattern for a parallel processing
3	Process Pattern	The process pattern controls the flow of the process and to define what the system shall perform in this CR step.
4	Service Name	The meaning of this parameter depends on the process pattern.

Process Pattern

• The rule-based workflow groups several workflow steps together from basic operations, called process patterns.
• These patterns are used to control the flow of the CR process.
• It defines which background task the system will perform in the CR step.

• Technically, the RBWF runs in a loop.
• In each repetition of the loop, one out of several process patterns is executed.
• The workflow continues to run in the loop until the change request process is ended with the process pattern 99 complete (sub)workflow.

Code	Process Pattern Name	Comments
01	UI Dialog	Used when user interaction needed on CR step, and hence used in User Agent Decision tables. Should not be use in non-user decision table. Special process pattern which always automatically selected if a user agent has been found in the user agent decision table.
02	Call Synchronous Method	Use to include any operation that aren’t provided by SAP.
03	Call Sub-workflow	Used to initiate the sub-workflow name maintained in the Service name column of non-user agent decision table
04	Call Data Replication	Used for initiating the data replication process after the change request is activated.
05	Activation(do not bypass snapshot)	Used for activation of change request. Any changes made to master data tables while the change request are in process trigger failure of activation process, and the result is set for the Previous Action column.
06	Activation (bypass snapshot)	Used for activation of the change request. Unlike process pattern 05, this process pattern activates and overwrites any master data changes made while the change request was in process.
07	Validate Change Request	Used for validating change request data.
08	Roll Back Change Request	Used for initiating roll back of changes made using a change request process.
09	Error	Used for error handling.
10	Complete (Sub)Workflow	Use for indicating the completion of the rule-based workflow