SAP MDG NOTES:

SAP MDG Overview:

SAP Master Data Governance (MDG) is a solution for centrally managing and governing master data
across an organization, ensuring consistency, accuracy, and compliance. It helps businesses consolidate,
manage, and govern master data across various systems, including SAP and non-SAP systems
Key aspects of SAP MDG:
Centralized Governance:
Establishes a central ownership regime for all master data, ensuring adherence to business rules and
processes.
Consolidation:
Enables merging, de-duplication, and best record creation to harmonize master data across different
systems.
Data Quality Management:
Provides tools and processes for data cleansing, validation, and monitoring to maintain data quality.
Integration:
Integrates seamlessly with SAP systems, including SAP S/4HANA, and can also be used for non-SAP
systems.
Workflow and Rules:
Offers flexible business-driven workflows and rule frameworks to automate master data management
processes.
Domain-Specific Applications:
Provides predefined applications for specific master data domains like customer, supplier, material, and
financial data, as well as a framework for customer-defined master data.
Benefits:
Improved data consistency, reduced errors, enhanced business decision-making, and increased
operational efficiency.
SAP Master Data Governance (MDG) provides a framework for centrally managing and governing master
data, ensuring consistency and accuracy across different systems. It involves defining data models,
configuring governance processes, and leveraging change requests and workflows for master data
maintenance.
Here's a step-by-step overview of MDG:
1. Establish and Configure:
System Configuration: Set up MDG by configuring the system, loading source data, and creating user
profiles.
Data Modeling: Define the data structure and relationships for the master data domain (e.g., Material,
Business Partner).
Data Validation Rules: Establish rules to ensure data quality and integrity.
2. Data Model:
Entity Types, Attributes, and Relationships: Define the components of your data model, including entities,
their attributes, and how they relate to each other.
3. Change Request Process:
Create Change Requests: Users create change requests to propose changes to master data.
Staging Area: The proposed changes are stored in a staging area, allowing for review and validation.
Workflow: Workflow is used to manage the change request lifecycle, including approval, rejection, and
activation.
4. Data Replication:
Replicate Master Data: After the change request is approved and activated, the updated master data is
replicated to the target systems.
5. Data Quality and Maintenance:
Consolidation: MDG allows for consolidating data from multiple sources, ensuring a single source of truth.
Mass Processing: Perform mass changes to multiple master data records simultaneously.
Data Validation: Enforce data quality rules to ensure data accuracy.
6. Data Import:
Import Master Data: Load data into MDG using various methods, including importing files or connecting to
external systems.
7. Monitoring and Reporting:
Track Change Requests: Monitor the status of change requests and track data changes.
Generate Reports: Generate reports on data quality, change request activity, and other MDG metrics.
Master Data Consolidation:

In SAP Master Data Governance (MDG), consolidation focuses on combining and centralizing master data
from various sources into a single, unified view. This process aims to establish consistent policies,
standards, and procedures for managing master data, ultimately improving data quality and operational
efficiency.
Here's a more detailed look at master data consolidation within SAP MDG:
Key Aspects of SAP MDG Consolidation:
Data Source Integration:
MDG consolidation allows you to integrate master data from different systems and sources, ensuring a
comprehensive and consistent view.
Standardization:
It enables the standardization of master data based on predefined rules and guidelines, ensuring uniformity
and consistency across the organization.
Duplicate Detection and Resolution:
MDG consolidation helps identify and resolve duplicate master data records, preventing inconsistencies
and improving data accuracy.
Best Record Selection:
The consolidation process can determine the "best" or most accurate record among multiple versions of a
master data entry.
Workflow Integration:
Consolidation can be integrated with workflows to streamline the process of creating, modifying, and
approving master data.
Data Quality Management:
MDG consolidation is closely linked to data quality management, ensuring that the consolidated data meets
predefined quality standards.
Benefits of Master Data Consolidation:
Improved Data Quality:
By consolidating and standardizing data, organizations can ensure the accuracy, consistency, and
completeness of their master data.
Enhanced Operational Efficiency:
A unified view of master data simplifies business processes and reduces the risk of errors.
Streamlined Reporting and Analytics:
Clean, consistent data enables more accurate and reliable reporting and analytics.
Reduced Costs:
By eliminating duplicates and inconsistencies, organizations can reduce the cost of data storage,
maintenance, and processing.
How it Works:
Define Master Data Object: Determine the specific type of master data (e.g., customers, materials,
business partners) to be consolidated.
Configure Consolidation Process: Set up the consolidation process, including the steps, rules, and
workflows to be used.
Load Data: Load master data from various sources into the consolidation environment.
Apply Standardization Rules: Apply predefined rules to standardize the data.
Detect and Resolve Duplicates: Identify and resolve duplicate records.
Determine Best Record: Identify and select the best record based on predefined criteria.
Update Target Systems: Update the master data records in the relevant target systems.
File Upload:

You use this Web Dynpro application (USMD_FILE_UPLOAD) to copy master data from a file to the
database tables defined in the data model for Master Data Governance.

Prerequisites
A standard data model has been assigned to you. If a standard data model has not been assigned to you
by means of the user master record, you must assign a data model in this Web Dynpro application by
choosing Change Model.
The file that is to be uploaded is a text file (for example, a CSV file) or an Office Open XML.
Binary files are not supported except for Office Open XML files.
For text-based files, field values can be separated by a semi-colon, tab, comma, or other printable
character. With the exception of the tab, the system does not support hidden characters.
You have saved the file that is to be uploaded on either the presentation server (that is, your local PC) or
the application server.
SAPMDG Implementation Project Steps:

Implementing SAP MDG typically involves a multi-step process, including assessment, data model
creation, UI modeling, change request settings, workflow configuration, and data replication. It's crucial to
define business requirements, create data models, configure UI, set up change request management, and
establish workflows to ensure data governance.
Here's a more detailed breakdown of the SAP MDG implementation process:
1. Project Preparation/Planning:
Define scope, objectives, and timelines for the project.
Identify the master data areas to be governed (e.g., materials, customers, suppliers, business partners).
Understand existing data landscapes and identify areas for improvement.
2. Data Model Creation:
Create the data models for each master data area in MDG.
Define the fields, attributes, and relationships within the models.
Start SAP GUI and log in to transaction 'MDGIMG'.
Specify the business objects and business activities.
Define the access class.
3. UI Modeling:
Design the user interface for MDG, including how users will create, modify, and view master data.
Verify UI Modeling (Optional) - If the data model has been enhanced.
4. Change Request Settings:
Configure change request types and workflow settings for managing data changes.
Define change request settings in Customizing.
Specify change request types to enable account group changes.
5. Workflow Configuration:
Set up workflows for various data management tasks, such as approvals and notifications.
Configure workflow tasks and define the rule-based workflow.
Set up the rule-based workflow.
6. Data Transfer & Replication:
Set up data transfer using DIF (Data Integration Framework) or other methods.
Set up data replication to ensure data consistency across systems.
7. Integration and Testing:
Integrate MDG with other SAP systems and external systems.
Conduct thorough testing to ensure data integrity and functionality.
Verify the UI modeling (Optional).
8. Go-Live and Production Support:
Deploy the MDG solution to the production environment.
Provide ongoing support and maintenance.
Address any issues or bugs that may arise.
Specific MDG areas to consider during implementation:
MDG for Materials:
Configure the material master data in MDG.
Set up the relevant workflows for materials.
Ensure proper data transfer and replication for materials.
MDG for Customers/Suppliers:
Set up the customer and supplier master data in MDG.
Configure workflows for customer and supplier changes.
Ensure proper integration with other systems.
MDG for Business Partners:
Set up the business partner master data in MDG.
Configure workflows for business partner changes.
Ensure proper integration with other systems.

SAP MDG Custom Data Model Steps:

Introduction

Sap MDG provides a robust framework for managing master data. However in some cases, the standard
data models may not fully meet your organization’s requirements. This is where
creating a custom data model comes in handy. İn this blog, we will go through the step-by-step process of
creating a custom bank data model in sap MDG.

Steps for Creating the Custom Bank Data Model

Step 1: Define the Custom Bank Data Model

 Navigate to the Data Model Screen:

To start, you need to create a new data model via transaction MDGIMG under General Settings->
DataModeling->Edit DataModel.

Figure 1 – Edit Data Model

 Create a Custom Data Model:

General Settings-> Data Modeling -> Edit Data Model-> Click on New Entries-> Enter data model
name and Description and save

Figure 2 – Create Data Model

 Create a Custom Attributes:

If required you can entities like Bank with additional attributes, such as bank category or bank type.
Figure 3 – Create Attributes

Step 2: Define the Change Request Type

Nex, you need to define the change request type that will be used for creating and managing the bank data
in this new model.

 Define Change Request Type:

In MDGIMG, navigate to General Settings->Process Modeling->Change Requests-> Create Change
Request Type

Figure 4 – Create Change Request Type

Create a new change request type specifically for your custom model (e.g., ZBNK01).
Assign the custom data model you created to this change request type, ensure that the correct workflow
and approval process are configured for this change request type.

Step 3: Configure the Fiori Catalog and Group

To make your custom model accessible in Fiori configure a catalog and group.

 Create Fiori Catalog and Group:

In the Fiori Launchpad Designer, create a catalog (e.g., zbnkidct ) and create a group (e.g.,
zbnkidgrp).
Figure 5 – Create Fiori Catalog

Step 4: Create a Custom UI in SAP Fiori

Navigate to General Settings->UI Modeling->Manage UI Configurations.

A custom UI in sap fiori will enhance the user experience by providing a structured interface for interacting
with the data model.

Figure 6 – Create Custom UI

Testing

Once the configuration is complete, perform testing to ensure the data model and UI are functioning as
expected.

Figure 7 – Search Result

Figure 8 – Create new bank entry

Figure 9 – BNKA table result

Conclusion

With fiori integration, workflow management field-level, you can ensure a streamlined, user-friendly
experience.

SAP MDG Data Model Enhancement Steps:

Adding Custom Field : This requirement includes extending the standard data model with
custom/enhanced fields that are added to the Standard tables/ custom tables which are linked to the
standard tables.

Example : Adding custom fields 'Country of Ownership' and 'Customer Type' to 'BP_CENTRL' entity of BP
Data Model.

IMPLEMENTATION :

STEP 1 : ADD CUSTOM ATTRIBUTES TO STANDARD DATA MODEL .

Go to MDGIMG->General Settings->Edit Data Model->Select BP->Select Entity type as 'BP_CENTRL'-

>Add 'Country of Ownership' and 'Customer Type' custom fields->Save it and Activate it.
 Fig 1 : Custom fields for MDG DM

STEP 2 : ADD CUSTOM ATTRIBUTES TO ERP TABLE .

Go to SE11->Database Table ( BUT000)->Include fields in 'CI_EEW_BUT000' Structure->

Save it and Activate it.

Fig 2 : Custom Fields added to ECC table

STEP 3 : GENERATE DATA MODEL SPECIFIC STRUCTURES :

Go to MDGIMG->General Settings -> Edit Data Model->Execute Data Model Specific Structures-
>Select BP and Click on Structures->Select Entity Type as 'BP_CENTRL' and click on Generate Data
Model Specific Structures. Check your Structures in 'USMD_DATA_MODEL' in SE38
Report.

Fig 3 : Generating DM specific Structures

STEP 4 : PERFORM SMT MAPPING :

Again input T-Code MDGIMG->General Settings-> Edit Data Model-> Expand Edit Mappings and
Execute Edit Mappings ( You will be navigated to Web Dynpro Application ).

Follow the below steps to do mappings for both 2STA and 2API.

Mapping Name : MDG_BS_BP_MAP_2STA.

Mapping Step : MDG_BS_BP_BP_CENTRL.

1. Click on Details -> Select Transformations-> Give '00001' as order and transformation type as 'Field
Mapping'. Source structure is 'BUS_EI_EXTERN' and Target Structure is
'MDG_BS_BP_BP_CENTRL'.

Fig 4 : SMT Mapping to 2STA .

 Now Perform mapping to 2API. Extend Mapping -> Give Mapping Name as
'BP_BP_CENTRL_2API'.
[Link] on Details -> Select Transformations-> Give '00001' as order and transformation type as 'Field
Mapping'. Source structure is 'MDG_BS_BP_BP_CENTRL' and Target Structure is
'BUS_EI_BUPA_CENTRAL_DATA'. Save it .

Fig 5 : SMT Mapping to 2API.

STEP 4 : ADJUST STAGING IN SE38 :

Go to SE38-> Program Name : USMD_ADJUST_STAGING-> Execute -> Data Model : BP ->Execute

again.

ADDING CUSTOM FIELDS TO UI SCREEN :

Input NWBC T-Code ( Navigated to Web Dynpro Application ) -> Select 'Supplier Governance' Work
area->Click on Search Customer-> New->Organization->Select your CR Type and Click on Ok ( You will be
navigated to New Change Request page.

Steps to Perform :

1. Right click on the UIBB where you want to add Custom fields. Here I am Creating a Separate View for
new fields

Right click->technical settings->click on Application Configuration->Expand Other Functions and Click

on Enhance. Popup will be appeared , enter enhancement name and click on create.
 Fig 6 : Enhancement View
2. There you have to click on +UIBB and add Component, Config ID and Window Name, and do wiring and
all and click on CONFIURE UIBB.

Fig 7 : Configuring OVP Page

3. Create a custom Feeder Class in SE24 and implement the following methods mainly GET_DATA and
GET_DEFINITION method.


 IF_FPM_GUIBB_FORM~GET_DEFINITION :

method IF_FPM_GUIBB_FORM~GET_DEFINITION.
CALL METHOD SUPER->IF_FPM_GUIBB_FORM~GET_DEFINITION
IMPORTING
eo_field_catalog = eo_field_catalog
et_field_description = et_field_description
et_action_definition = et_action_definition
et_special_groups = et_special_groups
et_dnd_definition = et_dnd_definition
es_options = es_options
es_message = es_message
ev_additional_error_info = ev_additional_error_info
.
endmethod.

IF_FPM_GUIBB_FORM~GET_DATA :

method IF_FPM_GUIBB_FORM~GET_DATA.
 CONSTANTS: delete TYPE fpm_event_id VALUE '_DELE_',
create TYPE fpm_event_id VALUE '_CREA_',
hide TYPE wdui_visibility VALUE '01',
c_x TYPE c VALUE 'X'.

CALL METHOD super->if_fpm_guibb_form~get_data

EXPORTING
io_event = io_event
iv_raised_by_own_ui = iv_raised_by_own_ui
it_selected_fields = it_selected_fields
iv_edit_mode = iv_edit_mode
io_extended_ctrl = io_extended_ctrl
IMPORTING
et_messages = et_messages
ev_data_changed = ev_data_changed
ev_field_usage_changed = ev_field_usage_changed
ev_action_usage_changed = ev_action_usage_changed
CHANGING
cs_data = cs_data
ct_field_usage = ct_field_usage
ct_action_usage = ct_action_usage.

LOOP AT ct_action_usage ASSIGNING FIELD-SYMBOL(<action>).

IF <action> IS ASSIGNED.
IF <action>-id = delete OR <action>-id = create.
<action>-visible = hide.* <action>-enabled = ' '.
ev_action_usage_changed = c_x.
ENDIF.
ENDIF.
ENDLOOP.
endmethod.

GET_ENTITY_DATA :

METHOD get_entity_data.
" *!This method is used to read the entity,It adds the texts for fields having search or value helps

DATA: lv_class TYPE jv_jibcl,

lv_text_field TYPE name_komp.

FIELD-SYMBOLS: <lv_key> TYPE any,

<lv_text> TYPE any.

* "Inherit from the parent first,This set all key values.

super->get_entity_data(
EXPORTING
io_access = io_access
CHANGING
cs_data = cs_data ).

"Set the Customer type description.

lv_text_field = 'ZCUS_TYPE' && cl_usmd_generic_genil_text=>gv_text_suffix.

ASSIGN COMPONENT: 'ZCUS_TYPE' OF STRUCTURE cs_data TO <lv_key>,
lv_text_field OF STRUCTURE cs_data TO <lv_text>.
IF <lv_key> IS ASSIGNED AND <lv_key> IS NOT INITIAL AND <lv_text> IS ASSIGNED.
SELECT SINGLE custype_desc FROM zmdm_t_CUS_txt INTO <lv_text>
WHERE langu = sy-langu
AND custype = <lv_key>.
UNASSIGN: <lv_key>, <lv_text>.
ENDIF.
ENDMETHOD.

CREATE_STRUCT_RTTI :

METHOD create_struct_rtti.

.* This method is used to enhance the fieldcatalog.* It adds transient text fields
'<FIELD_NAME>__TXT' in the UIBB

DATA:
lt_components TYPE cl_abap_structdescr=>component_table.

FIELD-SYMBOLS:
<ls_component> LIKE LINE OF lt_components.

super->create_struct_rtti( ).
lt_components = me->mo_struct_rtti->get_components( ).
** Country of Ownership
APPEND INITIAL LINE TO lt_components ASSIGNING <ls_component>.
<ls_component>-name = |ZCTRY_OWN{ cl_usmd_generic_genil_text=>gv_text_suffix }|." Field
Concatenation
<ls_component>-type = cl_abap_elemdescr=>get_string( ). " Data Type
** Customer Type.

APPEND INITIAL LINE TO lt_components ASSIGNING <ls_component>.

<ls_component>-name = |ZCUS_TYPE{ cl_usmd_generic_genil_text=>gv_text_suffix }|. " Field
Concatenation
<ls_component>-type = cl_abap_elemdescr=>get_string( ). " Data Type
"Update the fieldcatalog.
me->mo_struct_rtti = cl_abap_structdescr=>create( lt_components ).
ENDMETHOD.

STEP 5 : ADD THE FEEDER CLASS TO THE CUSTOM UIBB.

Drag the fields which is available under repositories and place it in the respective position and Save it.

1. Cross verify the fields are added on the UI Screen by starting the transaction NWBC and checking
in the respective UI.
 1.

In this way we can enhance the data model by adding the custom fields. I hope this blog post has
given you a better understanding of your options for SAP MDG extensibility .

SAP MDG UIBB:

To create or configure a UIBB (User Interface Building Block) in SAP MDG (Master Data Governance),
you'll typically start by selecting the UIBB button and adding a form component. Then, you'll configure
the UIBB's details, like component, view, and configuration name. After saving, you can access the
configuration editor and further define the UIBB's attributes, such as feeder class and parameters. You
can also add groups and elements to the UIBB within the editor.

Here's a more detailed breakdown of the steps:

1. Adding a Form Component:

Click the UIBB button and choose Add Form Component.

Enter the necessary details for the form GUIBB, including:

Component: FPM\_FORM\_UIBB

View: FORM\_WINDOW

Configuration Name: An appropriate name for your configuration

Save your entries.

Creating and Configuring a Tabbed User Interface Building Block (UIBB) A tabbed UIBB consists of
number of tabs. Each tab can, in turn, be configured to include other UIBBs. Prerequisites In an SAP
development system, you have created a Web Dynpro application and created an initial screen. For
more information, see: Creating an FPM OVP Application Creating and Configuring an Initial Screen
Procedure Creating and Configuring a Tabbed UIBB Choose the UIBB pushbutton and select Tabbed
Component. Enter the following details for the tabbed GUIBB and choose Save. Component:
FPM_TABBED_UIBB View: TABBED_WINDOW Configuration Name: An appropriate configuration
name Choose Configure UIBB. To create the configuration for your UIBB, in the Editor for the Web
Dynpro ABAP Component Configuration screen, choose New. In the Create Configuration dialog box,
enter any required description and confirm your entry. In the Select Package dialog box, enter your
required package and confirm your entry. Creating the Master UIBB Choose Master UIBB. Choose the
Form Component and create a Form UIBB. For more information, see the Creating and Configuring a
Form Component section of the stopic Creating a Form UIBB. Save your entries. Return to the Tabbed
UIBB Component Configuration screen by clicking the link that points to the tabbed UIBB component
configuration. Creating Tabs Choose Tab under the Tabbed UIBB Schema tab. Configure the form or
list as per your requirement under the newly created Tab and add fields. For more information, see
Creating and Configuring a Form UIBB and Creating and Configuring a List UIBB. Save your entries.

SAP MDG Data Replications:

Set Up Data Replication Using ALE with DRF

In Master Data Governance for Material the replication of material master data from MDG Hub to
connected client systems can be scheduled, triggered, and monitored using the Data Replication
Framework (DRF) in concert with the ALE.

Note
If you are using ALE and DRF together to replicate materials you can improve performance by deselecting
the change pointers for the MATMAS message type. You can do this in the Activate Change Pointers for
Message Types configuration activity. You should only do this if all your MDG systems are integrated
using ALE and DRF together. If you use ALE without DRF in one or more connected systems
do not disable the change pointers.

The following customizing is relevant for data replication:

ALE (See Set Up Data Replication Using ALE above)

Enterprise Search (See Set Up Search above)

Key Mapping (See Key Mapping in section Adapting Master Data Governance for
Material below)

ALE Audit (See Customizing for ALE Audit in section Adapting Master Data Governance for
Material below)

Data Replication Framework (DRF)

The following process outlines the steps required to perform the customizing for the last point above, Data
Replication Framework (DRF).

Customizing for Data Replication Framework (DRF)

Run transaction MDGIMG and navigate to Classic Mode in SAP MDG Central
Governance Central Governance for Material Activate Business Transaction Events and
select the Application Active checkbox for the MDGM Application Indicator to enable MDG
Material with DRF. For more information, see SAP Note 2700769 .

Run transaction DRFIMG and navigate to Enhance Default Settings for Outbound
Implementation Define Parameters to check if the outbound parameter PACK_SIZE_BULK is
available.

The following information should be available for this parameter:

Outbound Parameter Description Data Type Value Length

PACK_SIZE_BULK Package Size for Bulk Messages Integer 10

Select the parameter and open the Outbound Parameter Value view. Check that the parameter
value is 1000.

Use transaction DRFIMG to check if the filter objects below have been defined. Select Enhance
Default Settings for Outbound Implementation Define Filter Objects to view the filter object
definitions. Check that the main filter object, MDG_BS_MAT is available.

Use transaction DRFIMG to check if the outbound

implementations I_MAT, I_MAT_V2 and 194_3 have been defined. Select Enhance Default
Settings for Outbound Implementation Define Outbound Implementations.

Choose Assign Segment Filter Objects and confirm that the following settings are made for each
implementation.

Type Technical Name Description

 Segment Filter Object F_MAT1 Plant segment of material

Segment Filter Object F_MAT2 Sales segment of material

Segment Filter Object F_MAT3 Storage segment of Material

Segment Filter Object F_MAT4 Tax class segment of material

Segment Filter Object F_MAT5 Valuation segment of material

Segment Filter Object F_MAT6 Class segment of material

Define the technical settings for the business system.

Enter transaction DRFIMG and navigate to Define Custom Settings for Data
Replication Define Technical Settings Define Technical Settings for Business
Systems.

In the Business System field specify the receiver system. In the Logical System field enter
the Logical System used for IDoc communication. In the RFC Destination field enter the
RFC destination to be used for RFC communication with the receiver system.

Select the entry and open the Define Bus. Systems, BOs view.

In the BO Type field enter the business object type 194. In the Output Mode field Object-
Dependent Default is the default entry. You can optionally use, Direct Output, where
changes are directly transferred to a target system.

Select the entry and double-click on Define Bus. Systems, BOs, Communication
Channel. In the Communication Channel field enter the means you want to use to transmit
data to the applications. In the Key Harm. field specify if you want your keys harmonized
between the hub and the client systems.

Create the replication model and assign it to the outbound implementation as follows:

Enter transaction DRFIMG.

Navigate to Data Replication Define Custom Settings for Data Replication Define
Replication Models.

Select Define Replication Model and then select New Entries.

Enter a replication model and a description. In the Log Days field, you may enter the
number of days after which you want an Application Log to expire. In the Data Model field,
enter MM.

Select the newly defined replication model and choose Assign Outbound Implementation.

Choose New Entries.

Assign the outbound implementation I_MAT or I_MAT_V2. I_MAT sends

only MATMAS and CLFMAS messages; I_MAT_V2 sends MATMAS, CLFMAS, DOLMAS, E
CMREV, and MATQM messages.

Assign a target system for the outbound implementation.

Assign the outbound parameter PACK_SIZE_BULK to the outbound implementation with

the Outbound Parameter Value 1000.

Save and activate the replication model.

SAP MDG Process Modelling:

SAP Master Data Governance (MDG) is a state-of-the-art master data management solution,
providing out-of-the-box, domain-specific master data governance to centrally create, change, and
distribute, or to consolidate master data across your complete enterprise system landscape.

SAP MDG allows for both the central creation and maintenance of enterprise master data as well as for the
consolidation of data from multiple sources into the SAP MDG application. The SAP MDG solution allows
organizations to use delivered content and to perform a governance framework to build strong master data
governance processes (including data transparency and quality across multiple ERP) to suit their business
requirements.

SAP Master Data Governance

SAP MDG allows organisation to govern below enterprise Attributes.

1. Finance Master Data — MDG-F

Key financial data, including such areas as SAP General Ledger (G/L) accounts/chart of accounts, cost
centers, profit centers, and hierarchies are maintained

2. Material Master Data — MDG-M

Material master-relevant data are maintained across all key areas, including material descriptions, units of
measure, classification data, quality data, sales data, plant data, and storage and warehouse data.

3. Enterprise asset Master Data — MDG-A

Enterprise asset management governance content has been developed on the SAP MDG platform by the
SAP partner Utopia as a solution extension to SAP MDG. Mostly used in SAP PM (Plant Maintenance)

4. Business Partner Master Data — Supplier (MDG-S) Customer (MDG-C)

Common business partner attributes are maintained, for example, name, address, bank details, tax
numbers, as well as the relevant business partner role. Business partner in SAP involves in both Supplier
and Customer.

Supplier: general data, company code data, and purchasing data.

Customer: general data, company code data, and sales area data.

SAP MDG Components:

SAP MDG Provides below components to for enterprise solutioning.

1. UI Framework

2. Workflows (Rule Based Workflow BRF+)

3. Data Modeling (Standard and Custom Data Model)

4. Process Modeling (Change Requests, Workflows)

5. Staging Area (Change request data stores here until request workflow completed successfully.)

6. Search and Duplicate Check

7. Data Replication

8. Data Validation and derivation

Process Modeling:

Process Modeling explains end-to-end master data maintenance process is set up in SAP MDG from a
central master data governance point of view. MDG is setting up an E2E process to perform CRUD
operation on master data objects.

Process Modeling involve mainly with below areas

1. Change request

2. Workflow

Change Request:

· It’s a type of change that made to SAP master data objects on a relevant process such as
create/change/block/unblock/replicate.

· Change request support master data CRUD operations associating with a predefined business rule.

· We can perform data duplication/quality check/validation/derivation in a change request.

The IMG path for configuring a change request type is, Transaction MDGIMG -> General Settings ->
Process Modeling -> Change Requests
NWBC — Transaction to start the change request for master data.

Edit Statuses of Change Requests:

User can define which status a change request can hold while processing the business workflow steps.
Below are the SAP standard driven Change request Status.
The statuses 05 Final Check Approved and 06 Final Check Rejected have the meaning that a change
request is finalized and cannot be changed any more.

Any other status has the meaning that a change request is still open for processing.

Create Change Request Type:

Here we can create our own change request type by coping the standard change request and assign the
rule-based workflow template WS60800086.

Configure Properties of Change Request Step:

This will allow user to define the settings for execution of change request. The following are typical tasks you
can complete for a change request step:

 Enrich parts of data, by assigning an enrichment spot.

 Ensure validations occur by assigning checks.
 Specify which fields are relevant, and which relevant fields are required, by setting field properties.
 Assign a different Web Dynpro application to the standard one configured for the data model.

Workflow:
Workflow in MDG is part of Process Modeling in SAP MDG. Workflow definition is an integral part of SAP
MDG change request processing. SAP MDG uses workflows to manage central governance scenarios; as
such, a workflow template is specified as part of the change request type configuration. SAP delivers object
type BUS2250 (SAP MDG change request) for workflows associated with change [Link] a change
request has been made to a business activity (linked to a logical action of Data Model BP, business object
147 — business partner/266 — supplier, Supplier Create Process SUP1/VLP1), at that time system will
create change request based on configuration maintained and process the change request based on defined
business rule.

What did we learn?

1. What is master data governance in SAP. How it works?

2. Process Modeling concepts in SAP MDG.
3. Different aspects of Process Modeling.

Workflow configuration in SAP MDG

SAP Business Workflow is used to process change requests in Master Data Governance
(MDG). You have the option to use standard or custom workflow templates when defining a
change request type. If you choose standard templates you can customize predefined change
request process flows. If you choose custom templates you can create your own process with
the workflow builder of SAP Business Workflow. Alternatively, you can use the MDG rule-based
workflow, which is based on one generic workflow template. You can configure your particular
change request process with BRFplus decision tables. Using the rule-based workflow you can
add or remove a change request step or change the order of the steps without the need to
change anything in the workflow template by adapting the BRFplus decision tables.
Prerequisites You have performed the basic workflow setup as described in the document
Workflow Set-Up. Activities Standard Workflow Template Choose an appropriate template by
examining its documentation. Create the change request type and enter the chosen workflow
template. Perform further configuration according to the requirements of the template, for
example, assign processors to the change request steps. Custom Workflow Template Create
the workflow template. Define the change request steps in the MDG Customizing. Create the
change request type and enter your custom workflow template. Perform further configuration,
according to the requirements of the template, for example assign processors to the change
request steps. Rule-based workflow Create the change request type. Define change request
steps in MDG Customizing. Create decision tables.

Set Up the Workflow

This section describes how to make the Customizing settings required to run the workflow for the approval
process in MDG-C.

You define the workflow settings in Customizing for Master Data Governance under Classic Mode in
SAP MDG Central Governance General Settings Process Modeling Workflow.

Activate type linkage

To activate the type linkage, run the following activity in Customizing for Master Data
Governance: Classic Mode in SAP MDG Central Governance General Settings Process
Modeling Workflow Activate Event Type Linkage

Ensure that the object type BUS2250 has the following settings:

Event: CREATED

Receiver Type: (blank)

Type linkage active: yes

 Enable event queue: deactivated

The type linkage indicator must not be active for all other receiver types of object type BUS2250
and event CREATED. This receiver type is defined via the receiver type function
module USMD_WF_RECEIVER_TYPE. Make sure that receiver function
module SWW_WI_CREATE_VIA_EVENT_IBF is entered.

Note
To enter the receiver type function module or if you need to change the settings, mark the according
line in the table and choose Goto Details.

Configure workflow tasks.

To configure workflow tasks, run the following activity in Customizing for Master Data
Governance: Classic Mode in SAP MDG Central Governance General Settings Process
Modeling Workflow Configure Workflow Tasks

Go to application component CA-MDG-AF and choose Assign Agents.

All activities (denoted by TS*) that are not set as Background Task need to be set
to General Task. To do so, select the activity, choose Attributes, and change to General
Task.

Repeat the procedure for all non-background activities within the CA-MDG-APP-
BP application component.

Check number of workflow steps

To define the workflow steps for the workflows assigned to your change request types
(which shall be assigned to a processor), run the following activity in Customizing for Master
Data Governance: Classic Mode in SAP MDG Central Governance General
Settings Process Modeling Workflow Other MDG Workflows Define Change
Request Step Numbers

If you use the change request types delivered with MDG-C, the following workflow steps are
delivered:

WS54300003. Step 0, 1, 2, 3

WS46000023: Step 0, 1, 2, 3, 4, 5

WS46000027: Step 0, 1, 2, 3, 4

WS60800095: Step 0, 1, 2, 3, 4, 5

WS72100006: Step 0, 1, 2, 3

Create organizational unit or change staff assignments for organizational unit

Create an organizational unit with transaction PPOCW or change staff assignments for an
organizational unit with transaction PPOME. Users who will process the workflow steps have to be
assigned to this organizational unit.

Check or set up the business rule framework plus (BRFplus)

To check the business rule framework plus (BRFplus) run the following activity in
Customizing for Master Data Governance: Classic Mode in SAP MDG Central
Governance Central Governance for Customer Workflow Assign Processor to
Workflow Step Number in BRFplus for Customer

Note
If the system does not contain the Customizing
application MDG_BS_ECC_CUSTOMER_WF_CUSTM export it from client 000 using
transaction SCC1.
Note
To copy the content of the decision table GET_AGENT, do the following:
Prerequisite: In transaction BRF+ under Personalize the User Mode Expert is selected.
Run transaction BRF+ in the source client and search
for Name MDG_BS_ECC_CUSTOMER_WF_CUSTM.
In the search result list
expand MDG_BS_ECC_CUSTOMER_WF_CUSTM Expression Decision
Table GET_AGENT and open GET_AGENT with a double click.
Choose Additional Actions Export to Excel to download the data.
In your target client repeat the steps 1 and 2 to open the decision
table GET_AGENT.
Choose Additional Actions Import from Excel to upload the data.

To assign processors to workflow step numbers run the following activity in Customizing
for Master Data Governance: Classic Mode in SAP MDG Central Governance Central
Governance for Customer Workflow Assign Processor to Workflow Step Number in
BRFplus for Customer

1.
Assign processors, for example users or organizational units, for all change request types
and their created workflow steps.

2.
The following table shows an example of the change request types and their workflow steps.

3.
Change Request Type Workflow Step Number Object Object ID
Type

CUST1P2 01 Approval O OrgUnit-

(WS54400001) ID

CUST1P2 04 Revision after Rejection O OrgUnit-

(WS54400001) ID

CUST1P2 05 Subworkflow: Data Maintenance O OrgUnit-

(WS54400001) ID

CUST1P2 06 Subworkflow: Approval O OrgUnit-

(WS54400001) ID

CUST1P2 07 Decision: Activation Despite O OrgUnit-

(WS54400001) Discrepancy ID

4.
Note:
The change request type CUST1P2 supports distributed workflow for customers. It is
delivered with the business function Master Data Governance for Customer 7.0 Feature
Pack.
5.
Note:
For the change request types CUSTL1 (lean request UI for ERP customers) and CUSTL1P2
(distributed workflow for ERP customers) that are also delivered with the business
function Master Data Governance for Customer 7.0 Feature Pack processors are assigned
to workflow step numbers in the same [Link] processors to workflow steps (Simple
Workflow)

To assign the object ID of the organizational units to the workflow step number, run the
following activity in Customizing for Master Data Governance: Classic Mode in SAP
MDG Central Governance General Settings Process Modeling Workflow Other MDG
Workflows Assign Processor to Change Request Step Number (Simple Workflow)

Assign processors, for example users or organizational units, for all change request types
and their created workflow steps.

SAP MDG Versions:

Key SAP MDG Versions:

SAP MDG on SAP S/4HANA: This is the primary on-premise version, integrating with the
S/4HANA platform. It's available in both Private Cloud and Public Cloud deployments.

SAP MDG Cloud Edition: This is a cloud-based version offered as a Software as a Service
(SaaS) solution. It supports central governance and data quality management for business
partners.

SAP MDG, cloud edition (production): This refers to the cloud-based production environment
for SAP MDG.

SAP MDG on SAP S/4HANA (SAP S/4HANA 2023 FPS 02): This specific version is used for
on-premise deployments.

SAP MDG on SAP ERP 6.0: This version is a historical version that ran on SAP ERP 6.0.

SAP NetWeaver Master Data Management (MDM): This is an older version that has been
largely phased out in favor of MDG on S/4HANA.

Other Notable Versions:

SAP Master Data Governance 8.0, 9.0, 9.1, 9.2:

These are specific releases within the on-premise MDG framework, often used in
conjunction with SAP S/4HANA.

SAP S/4HANA Cloud Private Edition:

This deployment option allows for dedicated environments that combine the benefits of on-
premise and cloud setups.

SAP S/4HANA Cloud Public Edition:

This offers a cloud-based solution for managing master data within the S/4HANA ecosystem.

Material Master Data: MARA - General Data, material type MAKT- Short Texts, descriptions
MARM- Conversion Factors MVKE - Sales Org, distribution channel MLAN - Sales data, tax
indicator, tax MARC - classification MBEW - Plant Planning Data MLGN - Valuation Data
MLGT - Warehouse Management Inventory Data MVER - Warehouse Management Storage
Type MAPR - Data MARD - Consumption Data MCHA - Pointer for Forecast Data MCHB -
Storage location data Purchasing: EKPO - Purchasing Document Item EKKO - Purchasing
Document Header EBAN - Purchase Requisition EKBE - History per Purchasing Document
EKET - Scheduling Agreement Schedule Lines EINE - Purchasing Info Record: Purchasing
Organization Data EKKN - Account Assignment in Purchasing Document EINA - Purchasing
Info Record: General Data EKES - Vendor Confirmations EBKN - Purchase Requisition
Account Assignment EORD - Purchasing Source List T024 - Purchasing Groups EKBZ -
History per Purchasing Document: Delivery Costs AMPL - Table of Approved Manufacturer
Parts EKAN - Vendor Address: Purchasing Document Inventory Management: MSEG -
Document Segment: Material MKPF - Header: Material Document RESB -
Reservation/dependent requirements MARI - Short document: material movement ISEG -
Physical Inventory Document Items RKPF - Document Header: Reservation T156 -
Movement Type IKPF - Header: Physical Inventory Document T156T - Movement Type Text
CHVW - Table CHVW for Batch Where-Used List T156SY - Mvt Type: Qty/Value Update:
System Table; Rel. 4.6A MMIM_REP_PRINT - Print Settings, Reporting MM-IM T156S -
Movement Type: Quantities/Value Posting (Until Rel. 4.5B) T156W - Posting string values
T156M - Posting String: Quantity Invoice Control: RSEG - Document Item: Incoming Invoice
RBKP - Document Header: Invoice Receipt BSIM - Secondary Index, Documents for
Material RKWA - Consignment Withdrawals RBCO - Document Item, Incoming Invoice,
Account Assignment RBKP_BLOCKED - Logistics Invoice Verification: Blocked Invoices
RBKP_V - Generierte Tabelle zu einem View V_169P_MB - Generierte Tabelle zu einem
View T149D - Global Valuation Types RBDRSEG - Batch IV: Invoice Document Items RBTX
- Taxes: Incoming Invoice RBWS - Withholding Tax Data, Incoming Invoice RBKPB - Invoice
Document Header (Batch Invoice Verification) RBDIFFKO - Invoice Verification - Conditions
RBEX - Persistent Key Figures Header and Item

Relationships:

1. Leading Relationships:

Define a hierarchical structure within the data model.

Type-1 entity types can lead other Type-1 and Type-4 entity types.

Type-4 entity types must be linked to a leading Type-1 entity type.

The leading entity type serves as the primary entity for processing master data with change
requests.

2. Qualifying Relationships:

Enrich the keys of other entity types with additional attributes.

Type-2 and Type-3 entity types can qualify Type-1 and Type-4 entity types.

The qualifying entity type enhances the key of the qualified entity type.

For example, a company code can be a qualifying entity type, adding company code-
dependent data to a supplier.

3. Referencing Relationships:

Create a reference from one entity type to another.

The key of the referenced entity type becomes an attribute of the referencing entity type.

For example, a physical address might reference a country entity type, rather than storing
the country code as an attribute.

Key Concepts:Entity Types:

These are the fundamental building blocks of the data model, representing different types of
master data (e.g., customer, supplier, product).

Storage and Use Types:

These categorize entity types, influencing how they are stored and used within MDG, and
dictate which types of relationships are permitted.
Data Model:The overall structure of an MDG application, defining entity types, their
relationships, and attributes.

1. Leading Relationships:

These relationships establish a hierarchical structure, where a "leading" entity type is

associated with one or more "dependent" entity types.

The leading entity type is considered the "root" or "owner" of the dependent entity types.

Type-1 entity types can lead other type-1 and type-4 entity types.

Type-4 entity types must always be linked to a leading type-1 entity type.

Example: A "Customer" (Type-1) can lead to a "Customer Address" (Type-4).

The key of the leading entity becomes a key field in the database tables of the dependent
entity type.

2. Qualifying Relationships:

These relationships extend the key of an entity type using attributes from another entity type.

Type-2 and type-3 entity types can be used to "qualify" or enhance the keys of type-1 and
type-4 entity types.

The key of a type-4 entity must be enhanced by at least one type-1, type-2, or type-3 entity.

Example: A "Supplier" (Type-1) can be qualified by a "Company Code" (Type-2), resulting in

company-code-specific data for the supplier.

The attributes of the qualifying entity become non-key fields in the check table of the entity
being qualified.

3. Referencing Relationships:

These relationships establish a link between two entity types where the key of one entity
type becomes an attribute of the other.

The "referencing" entity type refers to the "referenced" entity type at runtime.

Example: A "Physical Address" entity can have a referencing relationship to a "Country"

entity, where the country key becomes an attribute of the physical address.

The description of the relationship becomes a non-key field in the check table of the
referencing entity.

Examples:

Leading:

A "Material" (Type-1) can lead to "Material Plant" (Type-4), where each material is
associated with one or more plants.

Qualifying:

A "Customer" (Type-1) can be qualified by a "Sales Organization" (Type-2), resulting in sales

organization-specific customer data.

Referencing:

An "Address" (Type-1) can have a referencing relationship with a "Country" (Type-3), where
the country information is stored in the Country entity and referenced by the Address.
 CVI Steps:

1. Activation of the Business Partner (BP) Data Model.

2. Activate Business Configuration Set.
3. Create Number Range Interval for Cleansing Application.
4. Define Number Ranges for Supplier Account Groups per Target System.
5. Configure Change Request Settings.
6. Specify Change Request Types to Enable Account Group Change.

To set up the customer/vendor integration (CVI), see the Customizing documentation under Master Data
Governance under Classic Mode in SAP MDG Central Governance Central Governance for
Supplier Integration with Vendor Master in ERP Set up Customer Vendor Integration for MDG for
Supplier.

Step 1 – Define Account Group

Define Account Groups For Customers & Vendors

 Step 2 – Create Number Ranges

Create Number Ranges for Customer Accounts & Vendor Accounts

Step 3 – Assign Number Ranges

Assign Number Ranges to Customer & Vendor Account Groups

Step 4 – BP Number Range Creation

Define Number Range for Business Partners

Step 5 – Assign BP Number Ranges

Define BP Grouping & Assign Number Range

Step 6 – Number Assignment

Number Assignment for Direction BP to Customer & BP to Vendor

Step 7 – Create your first BP in S4 HANA

Create your first BP representing Vendor in S4 HANA

Create your first BP representing Customer in S4 HANA

n SAP Master Data Governance (MDG), key mapping and value mapping are used to define relationships
between objects and values in different systems.
Mapping type Description

Key mapping Maps identifiers and codes between systems

Value mapping Maps attribute values between systems

Key mapping
 Used for Master Data objects like customers, vendors, and materials
 Required when working with multiple connected systems
 Can be defined in Customizing for Master Data Governance

Value mapping
 Used for company codes, sales areas, and regions
 Can be used to ensure correct ODM/ISO codes are distributed to systems
 Can be configured in the Development system and transported to Production
You can maintain key mapping and value mapping using the tools in the SAP MDG system. These tools
include:
 CSV templates for each mapping entity
 A function for mass uploading and downloading mappings
 An error log that shows discrepancies and issues
You can also use value mapping to map system-internal code values to the code values of an external list.

Access class is like a bridge between MDG staging area and active area.

Search active area data - use access class

Reuse ERP validation - use access class (MDG validation Badi is designed for non-ERP validation logic)

Reuse ERP authorization objects - use access class

MDG data activation and transfer to active area - use access class 'Save' method
Handler class is like a enhancement spot of access class. SAP provided the entrance to register custom
handler classes to change standard access class behaviors. Handler class only worked for BP model.

Feeder Class: In SAP Master Data Governance (MDG), a feeder class acts as a bridge between the
application and the User Interface Building Block (UIBB). It's responsible for providing the necessary data
and logic to populate the UIBB at runtime, including layout, field definitions, and data retrieval.

Key Responsibilities of a Feeder Class:

Data Handling:

The feeder class retrieves and prepares data from the underlying application model to be displayed in the
UIBB.

Layout Definition:

It defines the structure, layout, and field catalog of the UIBB, specifying how data will be presented.

Event Handling:

The feeder class handles events and actions within the UIBB, such as button clicks or data changes, and
forwards them to the application.

Communication with UIBB:

It communicates with the UIBB to populate data, manage layout, and handle events.

Generic UIBB Functionality:

Feeder classes are designed to work with generic UIBBs, providing a flexible and configurable way to build
user interfaces in SAP MDG.

How it Works:

UIBB Configuration: The UIBB is configured to use a specific feeder class.

Data Retrieval: The feeder class retrieves data based on the UIBB's configuration and the current
application context.

Data Formatting: The feeder class formats the data as needed for display within the UIBB.

UIBB Population: The UIBB then uses the formatted data and layout information provided by the feeder
class to render the user interface.

Event Handling: When the user interacts with the UIBB, the feeder class handles the event and forwards it
to the application model.

In essence, the feeder class acts as the "brain" behind a UIBB, providing the logic and data necessary to
create a functional and user-friendly interface within SAP MDG.

Custom BADI:

To create a custom BADI in SAP MDG, you'll first need to define the BADI's interface and methods using
SE18. Then, you'll create BADI implementations in SE19, which will contain the actual code to be executed
when the BADI is called. Finally, you'll need to configure the BADI in MDGIMG to ensure it's used correctly
for your specific MDG process.

Here's a more detailed breakdown:

1. Creating the BADI Definition:

SE18:

Go to transaction SE18 (Business Add-in) and create a new BADI definition.

Define the Interface:

Within the BADI definition, you'll define an interface that specifies the methods and parameters of your
BADI. This interface is like a contract that defines how the BADI can be used.

Method Definition:

Within the interface, you define the methods that will be available for use in your BADI implementations.
Each method should have a clear name, a description, and a list of parameters (input, output, and possibly
modification parameters).

Multiple Use:

Consider whether you want your BADI to be "multiple use". This allows for multiple implementations of the
same BADI to be active at the same time.

Filter-Based BADI:

If you need different behavior based on specific criteria, you can create a filter-dependent BADI. This allows
you to specify filters that determine which BADI implementation is executed.

2. Creating BADI Implementations:

SE19:

After creating the BADI definition, you'll need to create implementations for your BADI in transaction SE19
(Business Add-in Implementation).

Implementation Code:

In each implementation, you'll write the ABAP code that will be executed when the corresponding method in
the BADI interface is called.

Activation:

After writing the code, you'll need to activate the implementation to make it active and usable.

3. Configuring in MDGIMG:

MDGIMG:

Navigate to transaction MDGIMG (Master Data Governance Implementation Guide).

General Settings:

Go to "General Settings" and then to "Data Quality and Search".

Define Validations and Derivations:

Under "Data Quality and Search," you'll find options to define validations and derivations using BADI.

Business Add-ins:

Within "Define Validations and Derivations," you can find the BADI section where you can configure your
custom BADI.

Assign Implementation:

You'll need to assign the BADI implementation to specific MDG processes or scenarios where you want it
to be executed.
Key Considerations for MDG:

MDG Processes:

Carefully consider which MDG processes or scenarios your BADI needs to be used within. You'll need to
configure the BADI accordingly.

BRFplus:

If your BADI interacts with BRFplus rules, ensure you have the correct BADI implementations and
configuration.

Data Quality and Search:

If your BADI is related to data quality or search, make sure it's properly integrated with the relevant MDG
settings.

Testing:

Thoroughly test your BADI to ensure it functions as expected and doesn't cause any issues with existing
MDG processes.

Condition Alias:

In SAP Master Data Governance (MDG), a condition alias is a short, alphanumeric code used to represent
a specific condition or action within a rule-based workflow. It's a reference point that links decision tables to
define the next steps in a change request process. These aliases are defined in the User Agent Decision
Table (DT_USER_AGT_GRP_MAT01) and Non-User Agent Decision Table
(DT_NON_USER_AGT_GRP_MAT01) and used within the Single Value Decision Table
(DT_SINGLE_VAL_MAT01) to determine actions and workflow steps.

Explanation:

BRF+ Decision Tables:

MDG uses the Business Rule Framework plus (BRF+) to define and execute rules, including change
request workflows.

Decision Table Structure:

DT_SINGLE_VAL_MAT01: This table contains the condition aliases that trigger specific actions or steps in
the workflow.

DT_USER_AGT_GRP_MAT01: This table defines user agents and their roles in the workflow, including the
condition alias that triggers their involvement.

DT_NON_USER_AGT_GRP_MAT01: This table defines automated or background steps in the workflow,

also linked to condition aliases.

Linking Condition Aliases:

A condition alias in DT_SINGLE_VAL_MAT01 will link to corresponding entries in either

DT_USER_AGT_GRP_MAT01 or DT_NON_USER_AGT_GRP_MAT01, directing the workflow.

Purpose:

Condition aliases allow for a more structured and manageable way to define and track the flow of change
requests within MDG, especially when there are multiple steps and actions involved.

Example:

Imagine a change request process for materials:

A user initiates a change request (step 00).

The system checks the previous action and condition alias, leading to a specific next step (e.g., step 90 for
Final Check).

The condition alias associated with the previous action determines if the workflow should proceed to a user
agent step (e.g., a user needs to review and approve the change) or an automated step (e.g., the system
automatically updates the material master).

In this example, a condition alias like "FC" (Final Check) might be used in DT_SINGLE_VAL_MAT01 to
point to the appropriate entries in DT_USER_AGT_GRP_MAT01 or DT_NON_USER_AGT_GRP_MAT01,
depending on whether a user or the system needs to handle the next step.

GENIL:

In SAP Master Data Governance (MDG), GenIL (Generic Interaction Layer) acts as a bridge between the
Business Object Layer (BOL) and the user interface (UI), facilitating data interaction and management.
GenIL is crucial for MDG UIs, handling data access and interaction with the backend system.

Here's a more detailed explanation:

GenIL as a Bridge:

GenIL connects the BOL model, which represents the business objects and their relationships, with the UI
components that display and manipulate the data.

Data Management:

GenIL manages the data flow between the UI and the backend system, including tasks like creating,
reading, updating, and deleting (CRUD) operations on master data objects.

Standard vs. Custom GenIL:

SAP provides standard GenIL components for standard MDG data models, while custom data models in
the customer namespace utilize the system-generated CL_USMD_GENERIC_GENIL_ADAPTER class,
according to SAP Help Portal.

Component Types: GenIL components include:

ZSP\_ZT: Handles UI for single object processing of custom data model entity types.

ZMP\_ZT: Handles UI for multi-record processing of custom data model entity types.

Data Model Integration:

GenIL models help integrate fields from the data model into the UI, ensuring a seamless user experience.

Connectivity Framework:

The GenIL connectivity framework allows access to GenIL implementations from the Java framework, as
described in SAP Help Portal.

Proxy and Data Container:

The GenIL connectivity framework uses a proxy for communication between the Java framework and the
ABAP GenIL backend and a data container to hold data retrieved from the backend, as explained in SAP
Help Portal.

SPI:

In SAP Master Data Governance (MDG), the Service Provider Infrastructure (SPI) acts as a layer that
facilitates interaction between the UI (Floorplan Manager) and the backend data. It essentially connects the
application backend with the UI layer, enabling data access and manipulation. MDG leverages SPI to
manage master data, including materials, in a governed and structured manner.

Key aspects of SPI in MDG:

UI Integration:

SPI helps integrate the UI (using Floorplan Manager) with the backend database, enabling users to interact
with master data.

Data Exposure:

It provides a technology-independent layer for exposing business data, meaning it can be used across
different UI technologies.

Application Backend Access:

SPI enables applications to access and modify data in the backend system.

MDG_MAT:

The SAP Master Data Governance material domain SPI application is identified by the Application Building
Block ID (ABBID) MDG_MAT.

Metadata Provider:

SPI uses a Metadata Provider to define the structure of the data being exposed, ensuring that applications
know how to interact with it.

Service Provider:

SPI uses a Service Provider to manage the actual data access and manipulation.

Customization:

SPI can be enhanced and customized to meet specific business requirements, such as adding custom
fields or modifying the UI.

In essence, SPI in MDG serves as the bridge between the UI and the master data, allowing users to
interact with and manage master data in a governed and efficient manner.

FLEX MODE:

In SAP MDG, Flex mode provides a flexible approach to master data governance, especially when
integrating with multiple SAP and non-SAP systems. It allows for local data management, where business
units can maintain their own master data records independently. Unlike Reuse mode, Flex mode doesn't
automatically replicate data to SAP ERP tables after activation, requiring manual replication setup.

Key characteristics of Flex mode:

Local Data Management:

Business units can manage their master data independently.

No Automatic Replication:

Data is not automatically replicated to SAP ERP tables after activation, requiring separate replication setup.

Suitable for Custom Objects:

Can be used for custom objects where the data structure may not align with existing ERP tables.

MDG-F Example:

SAP MDG Financials (MDG-F) utilizes Flex mode to manage financial master data, storing data in MDG
tables and replicating to ERP only when needed.

Example Scenario:
Imagine a company with multiple business units each managing their own specific products. They decide to
use Flex mode in MDG for product master data. Each business unit can independently create and maintain
product records in MDG. When a new product is created in MDG, the data is stored in the staging area.
After approval, the active data is stored within MDG's generated tables. If this product data needs to be
used in other SAP systems or non-SAP systems, replication would be manually set up from MDG to those
target systems.

REUSE MODE:

In SAP Master Data Governance (MDG), Reuse Mode utilizes existing SAP S/4HANA or SAP ERP tables
(like MARA, MARC, MARD for material master) to store both active and inactive data. When a change
request is activated, the data is directly updated in these tables. This approach simplifies data management
by reusing existing data structures.

Here's a more detailed explanation:

Centralized Data Management:

Reuse Mode emphasizes central governance, ensuring data consistency and quality by using a single,
authoritative source for master data.

Direct Updates:

Once a change request is activated, the data is directly written into the standard SAP ERP tables.

Simplified Replication:

In Reuse Mode, data updates are directly reflected in the SAP ERP tables, potentially simplifying replication
to other systems if needed.

Example:

For Material Master data, MDG-M can use tables like MARA, MARC, and MARD in SAP ERP to store the
activated data.

Key Considerations:

Custom Data Models:

While Reuse Mode leverages existing tables, it also allows for custom extensions of those tables to
accommodate specific business requirements.

Data Replication:

If MDG is deployed in a co-deployment scenario or if data needs to be replicated to other systems, the Data
Replication Framework (DRF) can be used.

Flex Mode vs. Reuse Mode:

In contrast to Flex Mode, which stores active and inactive data in separate MDG tables and requires
replication, Reuse Mode directly updates the SAP ERP tables.

In essence, Reuse Mode provides a streamlined way to manage master data by leveraging existing SAP
infrastructure and ensuring consistency across systems.

HUB and CO Deployment:

In SAP Master Data Governance (MDG), hub deployment uses a dedicated system to manage master
data, while co-deployment integrates MDG into an existing SAP system. In a hub deployment, MDG is a
standalone system that distributes master data to other systems in the landscape. Co-deployment, on the
other hand, activates MDG directly within an existing SAP ERP/S/4HANA system.

Hub Deployment:
Dedicated System:
 MDG runs on a separate SAP S/4HANA instance, specifically for master data management.
Centralized Master Data:
This hub acts as a single source of truth for master data, and it distributes this data to all other connected
systems.

Example:
Imagine a scenario where a company has multiple ERP systems. MDG can be deployed as a hub to
manage all material master data, and then distribute this data to the various ERP systems, ensuring
consistency.

Co-Deployment:
 Integration within SAP: MDG is integrated directly into an existing SAP ERP or S/4HANA system.
 Local Master Data: While MDG manages the master data, the local systems can also maintain their own
instances of the master data.
 Example: A company might choose to co-deploy MDG on their main S/4HANA system to manage all
customer master data, allowing individual sales departments to access and manage their local customer
data, while ensuring MDG maintains the master record.

Key Differences:
Feature Hub Deployment Co-Deployment

MDG Separate Dedicated Integrated into SAP

Instance System ERP/S/4HANA

Master Data Centralized and Local Instances

Distributed Maintained in Each
System

Data MDG Hub distributes Data is replicated

Replication data to other systems between MDG and local
systems

System More complex, Less complex,

Landscape requires additional leverages existing SAP
infrastructure infrastructure

PIR:

In SAP Master Data Governance (MDG), a Purchasing Info Record (PIR) is a master data element that
stores information about a specific material and its supplier, including prices, conditions, delivery times, and
other relevant procurement data. It's used in the source determination process within SAP's Material
Management (MM) module to identify the best source of supply for a material.

Example:
Let's say you need to purchase "Screw M6" from a vendor. A PIR would store information like:
 Material: Screw M6 (material number)
 Vendor: "Supplier ABC" (vendor number)
 Price: $0.50 per screw
 Delivery Time: 5 business days
 Tolerance Limits: Overdelivery 10%, underdelivery 5%
 Last Purchase Order: PO-12345 (number of the last purchase order with this material and vendor)
 Validity Period: From 01/01/2025 to 12/31/2025
 This data allows the system to quickly determine that "Screw M6" should be purchased from "Supplier
ABC" when a new purchase order is created, taking into account the specified price, delivery time, and
other conditions.

A Floorplan Manager (FPM) application is a Web Dynpro application that is assigned one of the
following Web Dynpro components:
 FPM_OVP_COMPONENT. Web Dynpro component providing an overview page type of floorplan.
 FPM_OIF_COMPONENT. Web Dynpro component providing an object instance type of floorplan.
 FPM_GAF_COMPONENT.

SAP MDG Transaction Codes

SAP MDG Transaction Codes – Complete list of SAP Master Data Governance (SAP MDG) module
transaction Codes (T Codes) that are used for installation and deployment of SAP MDG, Data Modelling,
Process Modelling, Consolidation, Data Migration, Fiori Applications, etc.
Transaction Code Description
MDGIMG MDG Display IMG
NWBC SAP Business Client for HTML
SFW5 Activate Business Functions
SCPR20 Business Configuration Sets Activation
SWU3 Automatic Workflow Customizing
SICF Activate Application Services
SM59 Configuration of RFC Connections
PFCG Role Maintenance
SCDT_MAPPING Create Synchronization Object List
LPD_CUST Launchpads Configurations
DTIMPORT Import Master Data
DTEXPORT Export Master Data
SE80 Object Navigator
SFP Form Builder
MDB SPI Metadata Browser
GENIL_MODEL_BROWSER GenIL Objects for Business Partner
Data model
MDG_BS_MAT_CR_BCST06 Activate Business Configuration Sets
MDG_BS_BP_CR_BCSET4 MDG Change Request Types
(Business Partner)
MDG_BS_BP_CR_BCSET2 MDG Change Request Types
(Business Partner) MDG 7.0 FP
USMD_RULE Define Validation and Derivation Rules
DRFF Define Filter parameters
MDG_ADJUST_IDM Adjust Key Mapping after Client Copy
MDG_KM_MAINTAIN Maintain Key Mapping
MDG_ANALYSE_IDM Search Key Mapping
DRFIMG Define Replication Models
DRFOUT Execute Data Replication
DRFLOG Analyze Log for Outbound
Implementation
 FILE Logical File Path Definition
DRFSUB Subscribe to Business Objects for
Replication
DRFCC DRF Customizing Task
DRFLOGDEL Delete Replication Log for Outbound
Message
DRFRSD Display Replication Status
DRFRSDEL Delete Object Replication Status
MDGCPDEL Periodic Deletion
RSOR Data Warehousing Workbench
RSA5 Installation of Data Source from
Business Content
MDG_GEN_HBA_CR_EXT Generation of Hana Repository
Content for MDG Analytics
MDMGX SAP MDM Generic Extractor
CG3Z Upload Files to Application Server
STC01 Task Manager for Technical
Configuration
SEGW SAP Gateway Service Builder
MDG_DATA_MODEL List of Generated Model
SPERS_MAINT Edit User Personalization Objects
MDG_HDB_GEN_UI Hana View Generator
PFCG Role Maintenance
SLG1 Analyze Application Log
SWIA Process Work Item as Administrator
SWI5 Workload Analysis
SWI6 Display Workflows Select an Object
SWE2 Event Type Linkage
BD54 Change view logical systems overview
BD82 Generate Partner Profile
MDCIMG MDC Display IMG

SAP DQM Derivation in SAP MDG:

1. Step 1: Create the Change Request Actions. ...

2. Step 2: Define Change Request Step Types and Assign Actions. ...
3. Step 3: Configure Change Request Type. ...
4. Step 4: Define Change Request Steps for Rule-Based Workflow. ...
5. Step 5: Define the Service Name. ...
6. Step 6: Configure the Rule Based Workflow.

Mass Processing in SAP MDG

In SAP Master Data Governance (MDG), Mass Processing enables the updating of multiple master data
records simultaneously. This function is available for various master data objects like product master,
business partners, and custom object domains. Mass processing utilizes the same technical foundation as
consolidation capabilities in MDG, allowing for flexible process configuration.
Here's a more detailed explanation:
Key Features and Benefits:
Simultaneous Updates:
Mass Processing allows users to change multiple master data records at once, saving time and effort
compared to individual updates.
Flexibility:
It can be used in conjunction with consolidation and other MDG features, offering a versatile approach to
master data management.
Various Master Data Objects:
Applicable to material master, business partner data (customers and vendors), and custom objects.
Interactive Change Process:
Users interact with the system to select fields and records, enter changes, and validate data before
activation.
Staging and Activation:
Changes are first stored in a staging area, where they can be validated, and then activated to the active
system for use in business processes.
Parallel Processing:
Mass processing can leverage parallel processing to handle large data volumes efficiently.
How it Works:
Selection: Users select the fields and records they want to update.
Data Entry: They enter the changes in the selected fields.
Validation: The system validates the data entered to ensure accuracy and consistency.
Staging: The changes are stored in a staging area.
Activation: Users check the validated data and activate it to apply the changes to the active system.
Accessing Mass Processing:
The "Start Mass Processing" and "Manage Mass Processing" tiles in the SAP Fiori Launchpad provide
access to the functionality.

Validations and Derivations in SAP MDG:

In SAP MDG (Master Data Governance), validations and derivations are crucial for ensuring data quality
and consistency. Validations check the accuracy and completeness of master data, while derivations
automate the population of related fields or entities based on defined rules.
Validations:
Purpose:
Validation rules enforce data quality by checking if entered data meets predefined criteria. For example, a
rule might ensure a customer's postal code is valid or that a product's price is within a specified range.
Implementation:
Validations can be implemented using BRF+ (Business Rule Framework plus) or Business Add-Ins (BAdIs).
Trigger:
Validations typically trigger during change request processing or when data is entered or updated in MDG.
Example:
A validation rule could check if a customer's address is valid based on a geographical database.
Derivations:
Purpose:
Derivation rules automate the population of fields or related entities based on input data or existing
information. For example, a derivation might automatically fill in a customer's city and state based on their
postal code.
Implementation:
Derivations can also be implemented using BRF+ or BAdIs.
Trigger:
Derivations often run during the same process as validations, ensuring that fields are populated based on
the validated data.
Example:
A derivation rule might automatically create a storage location for a new plant when the plant is created.
Key Considerations:
Data Model:
Validation and derivation rules are typically defined for specific data models within MDG, such as the
Business Partner data model.
BRF+:
BRF+ provides a graphical interface for defining and managing validation and derivation rules without
coding, according to a LinkedIn post.
BAdIs:
BAdIs offer more flexibility and customization options for implementing validations and derivations, says a
SAP Help Portal.
Prioritization:
Derivations often take precedence over validations, meaning they may be executed before validations to
ensure fields are populated with default or derived values before validation checks are performed.

Rule Based Workflow:

In SAP Master Data Governance (MDG), a rule-based workflow defines the steps for processing change
requests using the Business Rule Framework plus (BRFplus). The workflow template (WS60800086) is
configured with BRFplus decision tables to determine the next step, assigned processors, and process
pattern based on the change request type, current step, and previous actions.
Here's a breakdown of the key steps involved in a rule-based workflow within MDG:
1. Start Workflow:
When a change request is submitted, the system initiates an instance of the rule-based workflow template
associated with that change request type.
2. Determine Change Request Type:
The system identifies the type of change request (e.g., Create Material, Change Material).
3. Check Processor Assignment:
The system checks if a processor is already assigned to the workflow. If not, BRFplus is launched to
determine the next step and assign a processor.
4. BRFplus Decision Table:
BRFplus evaluates the change request based on the current step, the last action taken, and other relevant
input parameters (e.g., priority, rejection reason). It determines the next step, process pattern, and the
required agents based on the rules defined in the decision tables.
5. Determine Processing Type (Single or Parallel):
The system checks if the workflow should be processed sequentially (single processing) or concurrently
(parallel processing) based on the number of configured agent groups for the current step.
6. Branch by Process Pattern:
The workflow branches into different processing paths based on the determined process pattern (e.g.,
approve, reject, send for revision).
7. Check Workflow Completion:
The system monitors the workflow's progress and determines if it has reached a complete status.
Key Considerations:
BRFplus:
The Business Rule Framework plus is a powerful tool for defining and managing business rules, making it
possible to create flexible and customizable workflows within SAP MDG.
Change Request Types:
Each change request type is associated with a specific workflow template, and the BRFplus rules define
the process flow for that type of change.
Flexibility and Customization:
Rule-based workflows offer flexibility in adapting the change request process to specific business needs, as
the rules and decision tables can be customized.
Four-Eyes Principle:
The four-eyes principle, where multiple users are involved in the approval process, can be implemented
within the rule-based workflow to ensure a higher level of accuracy and control.

Search and Duplicate Check:

To configure duplicate checks in SAP MDG, navigate to the "Data Quality and Search" settings within the
"Master Data Governance" area of the SAP GUI. Specifically, you'll want to configure "Search and
 Duplicate Check" by defining search applications and setting up match profiles for the desired entity types.
This involves setting thresholds for duplicate scores and defining which attributes are considered for
matching.
Detailed Steps:
1. Navigate to Customizing:
Run transaction MDGIMG.
Go to "Master Data Governance" -> "Central Governance" -> "General Settings" -> "Data Quality and
Search" -> "Search and Duplicate Check".
2. Define Search Applications:
Select "Define Search Application" to configure search modes like SAP HANA-based search (HA) or
Enterprise Search (ES).
For HANA-based search, you'll need to create a search view and potentially configure a match profile.
3. Configure Duplicate Check:
Go to "Configure Duplicate Check for Entity Types."
Select the relevant entity type (e.g., Business Partner, Material).
Enter the search mode (e.g., HA for HANA).
Specify threshold parameters (e.g., fuzziness threshold) for duplicate checks.
4. Match Profile Configuration (for HANA-based search):
Select "Match Profile" and enter the name of the search rule set if you created one.
Specify the relevant fields for duplicate check and their fuzziness threshold.
5. Test and Implement:
Test the configuration with NWBC (if applicable).
When a user creates a new master data record, the system will check for potential duplicates based on the
configured parameters.
Key Considerations:
Search Modes:
MDG offers various search modes, including SAP HANA-based search, Enterprise Search, and others.
Fuzziness:
Fuzziness allows the system to find records that are not exact matches but have similar values in certain
fields.
Thresholds:
Thresholds determine how closely two records must match to be considered potential duplicates.
Match Profile:
A match profile defines the rules for determining whether two records are similar.
Search View:
For HANA-based search, a search view is used to define the structure of the search results.
Freeform and Fuzzy Flags:
Enabling these flags allows for more flexible searching, including partial matches and misspelled terms.

File Upload and Download in SAP MDG:

In SAP Master Data Governance (MDG), file download involves copying master data from the MDG-
specific database tables to a local file, typically in CSV or Office Open XML format. This is useful for
exporting data for various purposes, including uploading to decentralized systems or for further
processing. File upload, on the other hand, involves loading master data from a file (usually a text file) into
the MDG database tables.

File Download Steps in SAP MDG:

1. Access the Web Dynpro application: Use the Web Dynpro application USMD_FILE_DOWNLOAD.
2. Specify Parameters: Enter the necessary parameters for the download, such as the entity type, file
structure, and upload settings.
3. Initiate Download: Start the download process using the application.
4. Save the File: Save the downloaded file to your local machine in the desired format (e.g., CSV, XLSX).
 File Upload Steps in SAP MDG:
1. Access the Web Dynpro application: Use the Web Dynpro application USMD_FILE_UPLOAD.
2. Define Entity Type and File Structure: Specify the entity type and the structure of the data in the file.
3. Choose Upload Settings: Determine the desired upload behavior (e.g., delete existing records and add
new ones, add new records only).
4. Upload the File: Upload the text file containing the master data.
5. Check and Execute: Review the data and ensure it's in the correct format.
6. Confirm the Upload: Confirm the upload process to finalize the data transfer.

Message Type and Idoc Types in SAP MDG:

In SAP Master Data Governance (MDG), message types and IDoc types are used to manage and distribute
master data between different SAP systems. Message types represent the business function or document
type, while IDoc types define the technical structure of the data exchanged. According to the SAP
Community, an IDoc type is linked to a specific message type, specifying the data structure for that
particular message type.

Here's a more detailed breakdown:

1. Message Types:
 Purpose: Represent the type of business document or function being exchanged (e.g., customer data,
product data, order).
 Function: Defines the purpose of the IDoc, indicating what kind of data is being transmitted.
 Example: DEBMAS (Customer Master), MATL (Material Master), ORDERS (Purchase Order).
 Transaction: WE82 is used to view, create, and maintain message types.

2. IDoc Types (Basic Types):

 Purpose: Define the technical structure of the data carried within an IDoc. They specify the segments,
fields, and data types.
 Function: Specify the exact data structure associated with a message type.
 Example: DEBMAS02, MATL01, ORDERS05.
 Transaction: WE30 is used to view, create, and maintain IDoc types.

3. Relationship between Message Types and IDoc Types:

 A message type is linked to one or more IDoc types.
 An IDoc type can be associated with one or more message types.
 This association defines how the data associated with a specific message type is structured and
transmitted in an IDoc.

4. MDG Integration:
 In MDG, message types and IDoc types are crucial for defining how master data is distributed and
replicated between different SAP systems or between SAP and non-SAP systems.
 By assigning specific message types to their corresponding IDoc types, you define the data structure and
how that data will be transferred during master data replication or synchronization.
 This ensures that data is consistently and accurately exchanged between different systems, contributing to
a unified master data view.
Custom Message Type:
In SAP Master Data Governance (MDG), custom message types are created to display specific messages
during master data transactions, such as validation errors or informational messages. These messages
help users understand the status of their actions and ensure data integrity. To create a custom message
type, you can use the SAP Help Portal documentation for configuring custom messages.

In SAP Master Data Governance (MDG), the main transaction code for IDoc processing is BD87. This
transaction is primarily used for monitoring and reprocessing IDocs that have encountered errors or failures
during the integration process. BD87 allows you to view the current status of IDocs, identify issues, and
initiate reprocessing to correct errors.

Here's a breakdown of how to create and manage custom messages in SAP MDG:
 1. Creating a Custom Message Type:
Define the Message:
Determine the purpose of the message (e.g., validation error, information message).
Choose a Message ID:
Assign a unique identifier for the message (e.g., using "Z" prefix for custom objects).
Write the Message Text:

Create a clear and concise text for the message that will be displayed to the user.

Maintain Language-Specific Descriptions:

If needed, create translations for the message text in different languages.

2. Utilizing Custom Message Types in MDG:

In Validation Rules:
You can use custom message types in validation rules to display specific error messages when certain
conditions are not met.
In Business Activities:
You can use custom message types to provide feedback to users during specific steps in a business
activity.
In UI Configurations:
You can integrate custom message types into the user interface to provide clear instructions and feedback
during master data management.

3. Key Considerations:
Message Severity:
Define the message severity (e.g., error, warning, information) to control how the message is displayed.
Message Display:
Determine where and how the message will be displayed (e.g., in a dialog box, on the status line, as part
of the UI).
Customizing Messages:

You can customize messages by adding additional information, such as the name of the affected field or
the reason for the error.

4. Example Scenario:
Imagine you're creating a custom message for a validation rule in MDG that checks if a business partner's
postal code is valid. You could create a custom message type with the following attributes:
 Message ID: ZVALIDATION_POSTAL_CODE
 Message Text: "Invalid postal code format. Please check the postal code field."
 Severity: Error
 Display: Error message displayed in a dialog box upon validation failure.
By utilizing custom message types in your MDG configurations, you can provide more specific and helpful
feedback to users, ensuring data quality and streamlining the master data management process.

Active Type Linkage:

In SAP Master Data Governance (MDG), an active type linkage defines which workflow template is
triggered when a specific event occurs for a given business object type. This linkage ensures that the
correct business process is initiated when a particular event happens within a master data object.

How Type Linkages Work:

Object Type: Specifies the type of master data object, such as a material or customer.

Event: Defines the action that triggers the workflow, such as "Created", "Activated", or "Reverted".

Receiver Type: Identifies the workflow template to be triggered when the event occurs.

Enabling Type Linkages:

Go to transaction SWE2: This transaction is used to display and maintain event type linkages.

Search for the relevant business object type: Locate the specific master data object you're interested in
(e.g., BUS2240 for material).

Check the "Linkage Activated" checkbox: Ensure this checkbox is selected for the specific event you want
to link to a workflow.

Set the receiver type: Specify the workflow template ID that should be triggered when the event occurs.

Save your changes: Ensure you save the changes within the transaction.

BRFplus Integration (for rule-based workflows):

When using rule-based workflows in MDG, BRFplus applications are generated for each change request
type.

This allows for dynamic selection of workflow templates based on rules defined in BRFplus.

Example:

For a material, the event "Created" might be linked to a workflow that requires approval before the material
is activated. This linkage ensures that the approval process is initiated automatically when a new material is
created.

Deep Copy and UI Enhancements:

In SAP MDG UI, deep copy involves creating a completely independent, replicated version of a UI
configuration, while enhancement refers to modifying or extending an existing UI configuration without
creating a new one. Deep copy ensures modifications to the copy won't affect the original, whereas
enhancement modifies the original.

Deep Copy:

Definition:

Creates a completely independent copy of a UI configuration, including all its technical elements and data.

Purpose:

To modify or extend a UI configuration without affecting the original standard configuration.

Process:

Involves selecting the UI configuration to copy, specifying the technical elements to be copied, and creating
a new configuration.

Benefits:

Allows for independent experimentation and customization of the UI without impacting the standard
configuration.

Example:

Creating a new UI configuration based on a standard one for a new business process or specific user
requirements.

Enhancement:

Definition:

Modifying or extending an existing UI configuration without creating a new one.

Purpose:
To add new functionality, customize fields, or change the appearance of an existing UI configuration.

Process:

Involves using various techniques like BAdIs, user exits, or customization options to modify the UI
configuration.

Benefits:

Allows for targeted and specific changes to the UI without requiring a full deep copy.

Example:

Adding a new field to an existing UI form or changing the visibility of a section within the form.

Key Differences:
Feature Deep Copy Enhancement

Replication Creates a new, Modifies the original

independent copy configuration

Modification Independent Modifications directly

modifications don't affect affect the original
the original

Purpose Customization, Targeted UI

experimentation, new changes,
functionality modifications

Impact on No impact on standard Impacts the standard

Standard configuration configuration

When to Use Extensive UI Specific UI changes,

customization, new use minor enhancements
cases

In summary: Choose deep copy for creating a completely new, independent UI based on a standard one,
and choose enhancement for making specific, targeted changes to an existing UI without creating a new
copy.

SMT Mapping Significance:

In SAP MDG, SMT (Service Mapping Tool) mapping is crucial for connecting custom master data fields
from various systems (like SAP ERP) to the standard MDG data model, facilitating consistent and accurate
master data management. It essentially defines how source data values are transformed and populated
into the MDG database, ensuring data integrity and streamlining the creation and maintenance of master
data across different systems.

Elaboration:

Connecting Systems:

SMT mapping allows you to integrate custom master data fields from external systems (like SAP ERP) into
the standard MDG data model.

Data Transformation:

It defines how source values from these external systems are converted and mapped to the corresponding
target fields within MDG.

Business Rules:
SMT mapping can also incorporate business rules to determine the mapping conditions, ensuring data
accuracy and consistency.

Simplified Maintenance:

By mapping fields and applying business rules, MDG can automatically populate master data values,
simplifying the process of creating and modifying data across different systems.

Data Consistency:

SMT mapping ensures that changes made in one system are reflected accurately in the MDG data model,
preventing data discrepancies and errors.

Example:

Imagine you have a custom field in SAP ERP (like "Customer Contact Person") that you want to use in
MDG. SMT mapping would define how the values in this custom field are converted and mapped to the
corresponding field in the MDG business partner data model.

In essence, SMT mapping in SAP MDG is a powerful tool for ensuring that master data is consistent,
accurate, and easily manageable across different systems.

Control Workflow Based on Material Type.

To control workflow based on material type in SAP Master Data Governance (MDG), you would use
BRFplus and decision tables to define the workflow steps based on the material type. This allows for
different approval paths and tasks for different material categories, ensuring the appropriate process is
followed.

Here's a more detailed breakdown:

1. Define Change Request Types:

Create different change request types for different material types or scenarios.

For example, one change request type for raw materials and another for finished goods.

2. Configure Rule-Based Workflow (BRFplus):

For each change request type, configure a BRFplus application with decision tables.

In the decision tables, define the next step in the workflow based on the material type.

You can use the material type as a column in the decision table and define different actions for each
material type.

For instance, you might have a step for a raw material to be reviewed by a procurement manager, while a
finished good might go to a production manager for review.

3. Assign Agents/Processors to Steps:

Assign users or organizational units to each workflow step, based on the material type.

This ensures that the correct individuals are responsible for processing the change request for each
material type.

4. Test and Activate:

Thoroughly test the workflows to ensure they function as expected for each material type.

Activate the changes and the workflows within MDG.

Example:
Imagine you have two change request types: CR_RAW for raw materials and CR_FIN for finished goods.
You could configure a BRFplus application for each, with decision tables that define the workflow steps
based on whether the material type is FT (for finished goods) or some other raw material type. The
workflow for CR_FIN might include a step for a production manager, while the workflow for CR_RAW might
include a step for a procurement manager.

Key Considerations:

BRFplus:

BRFplus is a powerful tool for creating and managing decision logic in MDG.

Decision Tables:

Decision tables within BRFplus are used to define the conditions and actions for each workflow step.

Workflow Templates:

You can choose to use standard or custom workflow templates, and with rule-based workflow, you can
configure the workflow without modifying the template.

Syniti RDG:

Syniti's Rapid Data Governance (RDG) provides a user-friendly interface for configuring MDG workflows,
including those based on material type.

Decision Table Settings in SAP MDG

In SAP MDG, decision tables utilize various settings to control their functionality and user interactions.
These settings are crucial for managing the complex logic within change requests and other MDG
processes. The main settings relate to column accessibility (Full Access, Display Only, Hidden), table
configuration (data objects, result attributes, settings dialog), and the structure of the decision table itself
(condition columns, result columns, and rows).

Column Accessibility:

Full Access (Changes Allowed): Users can modify cell values within the column.

Display Only (No Changes): Users can view cell values but cannot alter them.

Hidden: The column is completely hidden from view in the BRF+ workbench, both at design time and
runtime.

Table Configuration:

Data Objects:

The decision table can utilize various data objects, including those with reference attributes, to hold and
process data.

Result Attributes:

If using data objects with reference attributes, the target data object's attributes are also displayed as result
attributes.

Decision Table Settings Dialog:

A portion of the decision table's configuration can be exposed to the end user through this dialog box.

Structure of Decision Table:

Condition Columns: These columns define the input conditions against which the input data is compared.

Result Columns: These columns store the results returned when the conditions in a row are met.
Rows: Each row represents a unique combination of conditions.

Specific MDG Applications:

Change Requests:

Decision tables play a crucial role in determining workflow steps, handling agents, and background actions
within change requests.

Material Management:

Decision tables guide the creation and modification of material master data.

Rule-Based Workflow:

MDG leverages BRF+ and decision tables to dynamically control workflow processes and assign handling
agents.

Key Decision Tables in MDG:

Single Value Decision Table (DT\_SINGLE\_VAL\_MAT01): Master workflow table for material creation,
listing workflow steps and referencing other tables.

User Agent Decision Table (DT\_USER\_AGT\_GRP\_MAT01): Contains user assignments to workflow

tasks.

Non-User Agent Decision Table (DT\_NON\_USER\_AGT\_GRP\_MAT01): Lists system tasks for the
workflow.

Rule BADI vs Service BADI

In SAP MDG, both Rule BAdIs and Service BAdIs are used to enhance functionality, but they serve
different purposes and have distinct characteristics. Rule BAdIs, like USMD_RULE_SERVICE, are primarily
used for validations, derivations, and rule-based workflow contexts, often interacting with the BRF+ engine.
Service BAdIs, on the other hand, provide a way to extend the service layer of MDG, allowing for custom
logic and data access.

Key Differences:

Purpose:

Rule BAdIs focus on MDG process logic, while Service BAdIs enhance the service layer.

BRF+ Integration:

Rule BAdIs often interact with the BRF+ engine for rule execution, whereas Service BAdIs typically don't.

Context:

Rule BAdIs operate within the context of a change request or MDG process, while Service BAdIs can be
used in various service contexts.

Implementation:

Rule BAdIs often involve coding to define specific logic, while Service BAdIs can leverage existing service
APIs or business logic.

Examples:

USMD_RULE_SERVICE: Used for validations and derivations during change request processing.

USMD_SSW_DYNAMIC_AGENT_SELECT: Used to define custom logic for agent selection in the rule-
based workflow.
Service BAdIs related to specific MDG services, like MDG_IDM_GET_LCL_SYSTEM for system ID lookup.

When to Use Which:

Rule BAdIs:

When you need to perform validations, derivations, or extend the BRF+ rule engine for MDG change
requests or processes.

Service BAdIs:

When you need to extend the functionality of a specific MDG service, access data in a custom way, or
interact with external systems.

In essence: Rule BAdIs are for tailoring the internal MDG process flow and validation logic, while Service
BAdIs are for enhancing the external-facing service layer.

Workflow filters based on Material Type configuration steps for Material in SAP MDG

To implement workflow filters based on Material Type in SAP MDG, you need to configure rule-based
workflows. This involves defining rules within the workflow that utilize the Material Type to determine agent
assignments and task routing.

Here's a breakdown of the key steps:

1. Configure General Workflow Settings:

Ensure general settings for SAP Business Workflows are defined in Customizing for SAP NetWeaver under
Application Server Business Management > SAP Business Workflow.

Regenerate the authorization profile for SAP_ALL or include USMD* authorization objects in the
authorization for the WF-Batch user.

Activate workflow features using the semi-automated configuration in transaction SWU3 or through
Customizing under SAP NetWeaver Application Server Business Management > SAP Business Workflow >
Maintain Standard Settings.

2. Define Rule-Based Workflow:

Execute the "Create Steps" for rule-based workflow from MDGIMG (MDG Implementation Guide).

Specify the change request type (e.g., MAT02 for changing materials) and configure entries in the decision
tables.

If you want agents and steps to be determined dynamically based on Material Type, define a service name
to be used as a filter parameter for the BAdI implementation in the rule-based workflow.

3. Configure BAdI Implementation:

Inside the BAdI, read the Material Type data from the change request (e.g., from the library or labor object,
if standard SAP example is used).

Assign the retrieved Material Type value to an object ID for comparison in the decision table.

4. Configure Workflow Tasks and Agent Assignments:

Define workflow tasks such as "Approve Change Request" and assign agents (e.g., Master Data
Specialists) based on the configured rules.

These agents should have the authority to approve or reject the change request.

5. Activate the Workflow:

After making the necessary changes, activate the workflow to ensure it is operational.
By implementing these steps, you can ensure that workflows are tailored to specific Material Types,
allowing for efficient and controlled material master data management within your SAP system.

Single and Parallel Processing

In SAP MDG (Master Data Governance), both single and parallel processing of change requests and
master data updates are possible. Single processing involves processing a single change request or
master data update sequentially, while parallel processing allows for the simultaneous processing of
multiple change requests or master data updates, potentially speeding up the overall process.

Single Processing:

Sequential Execution:

In single processing, change requests or master data updates are processed one after another, in a
specific sequence determined by the MDG configuration.

Order Matters:

The order of processing can be important, as a change request may depend on the outcome of a previous
one.

Resource Constraints:

Single processing may be preferred when resources are limited or when the order of processing is critical.

Parallel Processing:

Simultaneous Execution:

Parallel processing allows multiple change requests or master data updates to be processed concurrently,
potentially reducing the overall time required for completion.

Resource Utilization:

This approach leverages available resources more effectively, allowing for faster processing of large
volumes of master data.

Independent Processes:

Change requests can be processed independently of each other, as long as they do not have
dependencies on each other.

MDG Configuration:

Parallel processing is enabled through specific configuration settings within MDG, including the definition of
parallel processing criteria, change request types, and workflow processes.

Example:

Enriching material master data for multiple plants can be done in parallel, with each plant-specific
enrichment being handled by a separate change request.

Background Jobs:

Parallel processing is often used in background jobs to process large volumes of data efficiently.

Key Considerations:

Resource Availability:

Ensure that there are sufficient resources available for parallel processing, including work processes and
server capacity.

Workflow Design:
Design workflows to support parallel processing, including the definition of roles, approvals, and
communication mechanisms.

Data Integrity:

Implement safeguards to ensure data consistency and prevent conflicts when multiple processes are
running concurrently.

Monitoring and Control:

Establish monitoring and control mechanisms to track the progress of parallel processes and identify
potential issues.

Single Entity Validation Vs Cross Entity Validation

In SAP MDG, single entity validation checks data integrity within a single entity type's attributes, while cross
entity validation involves checking data consistency across multiple entity types, often using relationships
between them. For instance, single entity validation might ensure a phone number is in a valid format, while
cross entity validation could verify that a customer's address matches the city's zip code.

Elaboration:

Single Entity Validation:

Focuses on the attributes of a single entity type, like a customer's general data or a material's master data.

Rules are typically defined using BRF+ for DQM (Data Quality Management), which allows for more
straightforward implementation and maintenance compared to traditional BAdIs.

Examples include checking if a field is mandatory, validating data format (e.g., phone number, email), or
ensuring values are within a specific range.

DQM allows for business-friendly rule creation, making it easier to define these validations.

Cross Entity Validation:

Involves verifying data consistency between different entity types that have a relationship defined in the
data model.

Examples:

Validating if a customer's address matches a customer's general data.

Ensuring a material's cost price is consistent with the price in a related purchase agreement.

Cross-entity validations are typically implemented using BAdIs (Business Add-Ins), as they require
accessing data from multiple tables.

BRF+ is generally not used for cross-entity validations, and the cross-entity BAdI
(USMD_RULE_SERVICE_CROSS_ET) is often used for this purpose, according to SAP Community.

For example, you can use BRF+ to validate the value of an airline's local currency or check if a material's
unit of measure is valid.

In essence:

Single entity validation: checks the data within a single record or object, while cross-entity validation checks
data relationships between different objects.

Single entity validations are typically easier to implement using DQM BRF+ rules, while cross-entity
validations often require coding through BAdIs.

Both types of validation are crucial for ensuring the quality and consistency of master data within MDG.
DIF vs File Upload:

In SAP MDG, both the Data Import Framework (DIF) and File Upload methods can be used to load master
data, but they differ in their approach and use cases. DIF is primarily used for transferring master data and
mapping information between systems, particularly for mass uploads of smaller volumes. File Upload, on
the other hand, is suitable for loading data from files directly into MDG, offering more control over the fields
selected for the load.

Here's a more detailed comparison:

Data Import Framework (DIF)

Purpose:

Primarily designed for transferring master data and mapping information between systems, including clients
or the main MDG system.

Process:

Involves exporting data from the source system to an XML file, transferring the file to the target system, and
then importing the data using the Data Import Framework.

Flexibility:

Supports both Flex and Reuse entities, allowing for data migration between different MDG environments.

Use Cases:

Suitable for scenarios where data needs to be moved between systems, especially when working with
smaller volumes of data.

File Upload

Purpose:

Allows for direct loading of data into MDG from files, offering more control over which fields are loaded.

Process:

Involves uploading a file (e.g., CSV) containing the data, with the option to select specific fields from the
entity type for the load.

Flexibility:

Supports both Flex and Reuse entities and can be used for initial loads or for mass updates.

Use Cases:

Ideal for situations where data needs to be loaded directly into MDG from a file format, especially when
working with larger volumes of data or when a more granular control over the fields is required.

Key Differences:

Data Source:

DIF relies on exporting data to an XML file, while File Upload loads data directly from files.

Control over Fields:

File Upload allows for selecting specific fields from the entity type for the load, while DIF imports all data
contained in the XML file.

Volume:

DIF is better suited for mass uploads of smaller volumes, while File Upload can handle larger volumes.
System Integration:

DIF is primarily used for transferring data between systems, while File Upload focuses on loading data
directly into MDG.

Mass Change in SAP MDG

In SAP Master Data Governance (MDG), mass change/update refers to the ability to modify multiple master
data records simultaneously, such as for materials, customers, or suppliers, by defining the fields and new
values to apply. This functionality allows for efficient and streamlined updates, enabling the modification of
attributes for a large number of objects at once.

Procedure for Mass Change in SAP MDG:

1. Open the Mass Change Screen:

Navigate to the appropriate work center (e.g., Supplier Governance, Material Governance) and select the
"Mass Change" option.

2. Select Objects:

Use the selections list to choose the master data objects (e.g., suppliers, materials) that you want to include
in the change request.

3. Refine Selection:

Review and refine your selection using the Scope of Selection table, removing any objects you don't want
to include.

4. Define Attributes and Values:

Specify the attributes you want to change and the new value you want to set for each attribute. Note that
only attributes available for mass change will be visible on this screen.

5. Check and Execute:

Review your changes and submit the change request by choosing "Execute Changes".

Key Considerations:

Change Requests:

Mass changes are typically initiated through change requests.

Staging Area:

If an object already exists in the staging area, the change request will overwrite it, so a warning will appear
before execution.

Object Types:

The available object types for mass change will depend on your system configuration.

File Upload:

In some cases, you can also use a file upload feature to upload changes from Excel or CSV files.

Validation:

The system may perform validation checks on the entered data before execution, ensuring compliance with
business rules.

Cloud-Ready Mode:

SAP MDG offers a cloud-ready mode for business partner data, which may have different functionalities
and limitations compared to the classic mode.
Integration:

Mass change functionality can be integrated with other SAP processes, such as those related to
consolidation and data quality management.

Customization:

The process steps and behavior of mass change can be adapted to specific business requirements.

Custom Workflow configuration steps for Material in SAP MDG

To configure a custom workflow for materials in SAP MDG, you'll need to create a workflow template,
define the change request steps, and configure the change request type. This involves creating a workflow
in SAP Business Workflow, defining the steps and logic for the process, and then connecting it to the MDG
change request process.

Here's a more detailed breakdown of the steps:

1. Define the Workflow:

Create the Workflow Template:

Use the SAP Business Workflow tools to design and define the steps of your custom workflow. This
includes defining the order of tasks, assigning users or roles to perform tasks, and setting up any
necessary conditions or checks.

Define Change Request Steps:

In the MDG Customizing, define the individual steps within your change request process. These steps
should align with the workflow steps you've created.

Create the Change Request Type:

Create a new change request type and assign your custom workflow template to it. This specifies the
workflow that will be used when a change request of this type is created.

2. Configure the Change Request Type:

Assign Processors to Change Request Steps:

In the MDG Customizing, assign specific users or roles to the change request steps. These users or roles
will be responsible for performing the actions associated with those steps.

Define Business Context:

Set up any necessary business context for the change request process, such as which organizational units
are involved or which data is relevant.

Configure Rule-Based Workflow:

If you're using rule-based workflows, configure the rules that determine the flow of the change request
based on specific criteria.

3. Activate and Test:

Activate the Workflow:

Once you've configured everything, activate the workflow to make it available for use in the MDG system.

Test the Workflow:

Thoroughly test the workflow by creating change requests and following the process to ensure it works as
expected.
Additional Considerations:

BRFplus:

For complex decision-making logic within your workflow, consider using the SAP Business Rule Framework
plus (BRFplus).

UI Configuration:

You may need to configure the User Interface (UI) elements associated with the change request process to
display relevant information and controls to the users.

Multiple Record Processing:

If you need to process multiple materials at once, configure the change request type to support multiple
record processing.

Flexible Workflows:

For more dynamic and adaptable workflows, consider using flexible workflows.

Sample Custom BADI configuration steps for Material in SAP MDG

To implement a custom BAdI for material in SAP MDG, you'll need to define a new BAdI, create an
implementation, and then configure the BAdI within the MDG process. First, identify the relevant BAdI
based on the specific need (e.g., before material creation, before saving, etc.). Then, create a BAdI
definition (e.g., using SE19) and implement the desired logic in an ABAP class. Finally, configure the BAdI
within the MDG change request process or data model to trigger the custom logic.

Here's a more detailed breakdown:

1. Identify the BAdI:

BAdI for Material Creation:

If you need to perform actions before a new material is created, you'll likely need to find the BAdI that's
triggered by the material creation process.

BAdI for Material Change:

If you need to validate or modify data before a change to the material master is saved, you'll need the BAdI
associated with the change process.

BAdI for Data Replication:

If you need to filter or modify data before it's replicated to another system, you'll need the DRF-related
BAdI.

2. Create the BAdI Definition:

Transaction SE19:

Use transaction SE19 to create the BAdI definition.

Enter BAdI Name and Description:

Give your BAdI a descriptive name (e.g., Z_MDG_MAT_CHECK) and a brief description.

Define Interface:

Define the interface (e.g., using ABAP interface) with the necessary methods for your logic.

Assign to Enhancement Spot:

Assign the BAdI to the appropriate enhancement spot where it's intended to be triggered.
3. Implement the BAdI Logic:

Create ABAP Class:

Create an ABAP class and implement the methods defined in the BAdI interface.

Write the Logic:

Write the code to perform the desired actions within the BAdI methods. This could include:

Validating data before saving.

Modifying data.

Logging information.

Triggering further actions, like triggering workflows or calling other functions.

4. Configure the BAdI within MDG:

Change Request Type:

If you're using a change request process, configure the BAdI to be triggered during the change request
lifecycle.

Data Model:

If you're modifying the data model, you'll need to configure the BAdI to be triggered during data loading or
replication.

Workflow:

If you're triggering workflows, configure the workflow to be started or updated based on the BAdI logic.

Example Scenario: Validating Material Data Before Saving

Let's say you want to ensure that a certain field (e.g., a custom segment field) is always filled in when
creating or modifying a material. Here's how you would approach it using a BAdI:

1. BAdI:

You'd identify a BAdI that's triggered before the material master is saved (e.g., a BAdI related to the
MDG_BS_MAT business object).

2. BAdI Definition:

Create a BAdI definition with a method like CHECK_MATERIAL_DATA.

3. BAdI Implementation:

In the CHECK_MATERIAL_DATA method, you'd add code to check the custom segment field. If it's empty,
you'd set an error message and prevent the material from being saved.

4. MDG Configuration:

You'd configure the BAdI within the MDG change request type or the data model to ensure it's called before
the material is saved.

DRF Steps:

In SAP MDG, the Data Replication Framework (DRF) steps involve defining replication models, assigning
outbound implementations, and configuring target systems. You start by defining a new replication model in
transaction DRFIMG, then assign an outbound implementation to it, and finally assign target systems.
Outbound parameters can also be configured.

Here's a more detailed breakdown:

1. Define Replication Model:

Use transaction DRFIMG and navigate to "Define Custom Settings for Data Replication > Define
Replication Models".

Select "Define Replication Model" and then "New Entries".

Enter a replication model name, description, and other relevant parameters.

Define the data model, for example, "MM" for Material Master, says SAP Help Portal.

2. Assign Outbound Implementation:

Select the newly defined replication model and choose "Assign Outbound Implementation".

Assign an outbound implementation like "I_MAT" (for material master) or "I_MAT_V2".

"I_MAT_V2" sends more data types than "I_MAT", according to SAP Help Portal.

3. Assign Target Systems:

Mark the line and choose "Assign Target Systems for Repl.".

Add the target business system to the replication model.

4. Assign Outbound Parameters (Optional):

Choose "Assign Outbound Parameter".

Assign parameters like "PACK_SIZE_BULK" with a value, notes SAP Help Portal.

5. Save and Activate:

Save the replication model.

You may need to further configure the outbound implementation and target systems, and then activate the
replication model.

Single Role vs Composite Role:

In SAP MDG (Master Data Governance), a single role defines specific actions or authorizations a user can
perform, while a composite role combines multiple single roles to grant a broader set of permissions.
Effectively, a composite role acts as a container for a collection of single roles, simplifying user
administration when a user needs access to multiple functions.

Here's a more detailed explanation:

Single Role:

A single role contains a set of transaction codes (Tcodes) and authorization objects, defining specific
functionalities a user can access or perform.

Composite Role:

A composite role is built by combining multiple single roles. When you assign a composite role to a user,
they automatically inherit the authorizations of all the included single roles.

Why use composite roles?

Simplifies User Administration:

Instead of assigning multiple individual roles, you can assign a single composite role, which streamlines the
process.
Scalability:

If a user's responsibilities change and they require access to additional functions, you can simply add the
relevant single role(s) to the composite role without needing to create new roles or reassign users.

Maintainability:

Managing a single composite role instead of multiple single roles can be easier, especially in large
organizations.

In MDG, composite roles are useful for:

Defining access to different master data areas:

A composite role can combine single roles granting access to customer, product, and vendor master data.

Granting different access levels within a master data area:

You can have composite roles for read-only access, update access, or full access to master data.

Implementing role-based access control (RBAC):

Composite roles allow you to group authorizations for similar business functions and then assign them to
users based on their roles within the organization.

In essence, composite roles are a powerful tool in SAP MDG for managing user access and streamlining
user administration, making it easier to grant specific permissions and maintain a secure system.

Significance of having Search Connector:

Having search functionality in SAP MDG is crucial for managing and ensuring the quality of master data. It
allows users to quickly locate and access data, identify potential duplicates, and facilitate efficient data
maintenance and governance processes. MDG's search capabilities enhance data quality by enabling
users to perform searches and duplicate checks on master data, which is essential for maintaining data
accuracy and integrity.

Here's a more detailed breakdown of the significance:

Data Discovery and Access:

Search enables users to easily find specific master data records, whether they are looking for a particular
customer, material, or other entity.

Duplicate Detection:

MDG's search functionality can identify potential duplicate records, helping to prevent data inconsistency
and ensure that each master data entry is unique.

Data Quality Improvement:

By facilitating accurate and efficient data retrieval and management, search helps improve overall data
quality and consistency across the organization.

Mass Change Operations:

Search can be used to locate and select multiple records for mass change operations, streamlining data
maintenance tasks.

Integration with SAP HANA:

SAP MDG can leverage the powerful search capabilities of SAP HANA for enhanced performance and
functionality, especially in terms of fuzzy and free-text search.

Flexibility and Configuration:

Search can be configured with different search modes (e.g., fuzzy search) and tailored to specific data
models, making it adaptable to various organizational needs.

Data Replication:

Search can be used as a filter provider for material master data replication, ensuring that only relevant data
is copied to the hub system.

Business Function Enhancement:

Certain business functions, like "Master Data Governance for Customer on Client (ERP)", leverage search
to enable users to search and compare data on the hub system before creating or changing customer
master data on a client system.

Search Methods in SAP MDG:

SAP MDG offers a few different search methods. You can utilize SAP HANA-based search for MDG
applications like Master Data Governance for Custom Objects, Financials, Supplier, Customer, Business
Partner, and Material. There are also SAP TREX-based search options and Enterprise Search available.
Additionally, you can use Business Address Services-based search and search providers for master data.

Here's a more detailed breakdown:

SAP HANA-based Search:

This search method is available for various MDG applications, including those for custom objects,
financials, suppliers, customers, business partners, and materials.

It leverages the SAP HANA database for searching and duplicate checking.

SAP HANA-based search can also be used as an alternative filter provider for Material master data
replication.

It supports free text and fuzzy search, allowing for more flexible searches.

SAP TREX-based Search:

Another option for searching data in change requests, including active and inactive data.

It has different capabilities and landscape requirements compared to HANA-based search.

Other Search Options:

Enterprise Search: This option is mentioned in the context of SAP MDG.

Business Address Services-based Search: This search method can be used with data models like MDG-
S/C/BP, utilizing best practice data quality management match capabilities.

Search Providers: MDG allows using various search providers to search for master data.

Standard Workflow Steps:

Standard workflows in SAP Master Data Governance (MDG) typically follow a process where a requestor
initiates a change, the change request goes through a review and approval process, and finally, the
approved changes are activated or implemented. This often involves multiple steps, including revision,
approval, and activation, with the possibility of rejection or withdrawal at various stages.
Here's a more detailed breakdown of common standard workflow steps in SAP MDG:
1. Initiation and Submission:
Requestor: The process begins with a requestor initiating a change by submitting a change request after
filling out the necessary data.
Change Request: The change request is created and assigned a unique ID.
2. Review and Approval:
Approver 1 (or multiple): A work item is sent to an approver (or multiple approvers) for review.
Review Options: The approver can take actions like:
Approve: If the approver approves, the change request moves to the next step (e.g., a subsequent
approver).
Reject: If the approver rejects, the change request is completed, and the process ends.
Send for Revision: If the approver requires changes or more information, the change request is sent back
to the requestor for revisions.
3. Activation or Implemented (if approved):
Approver 2 (if applicable):
If multiple approvals are required, a second (or subsequent) approver may receive the work item.
Activation/Implementation:
Once approved, the approved changes are activated or implemented in the master data.
4. Revisions and Rollback:
Revision:
If the approver sends the change request back for revision, the requestor receives the work item with
options to resubmit or withdraw.
Rollback:
If the change request is withdrawn, it is rolled back, and the workflow is completed.
5. Workflow Completion:
Finalization: The workflow concludes when the change request is either fully approved and activated,
rejected, or withdrawn.
Key Considerations:
BRF+ Integration:
MDG workflows often leverage BRF+ (Business Rule Framework plus) for dynamic rule-based decision-
making, allowing for flexible process configuration.
Customization:
While standard workflows are provided, they can be customized to meet specific business requirements by
modifying BRF+ decision tables or creating custom workflow templates.
Workflow Templates:
MDG uses SAP Business Workflow to process change requests, offering standard and custom workflow
templates.
Change Request Types:
Different change request types (e.g., material, supplier) may have specific workflow templates.

In SAP MDG, a standard rule-based workflow typically involves these core steps: initiating a change
request, determining the change request type, assigning a processor, and then using BRFplus to decide
the next step in the process based on rules and conditions. This decision-making process determines
whether single or parallel processing is needed, and it can branch the workflow into different operations like
approval, revision, or finalization.

Here's a more detailed breakdown:

1. Start Workflow: A workflow instance is initiated when a user submits a change request of a type
associated with the rule-based workflow.

2. Determine Change Request Type: The system identifies the type of change request, like "Create
Material" or "Change Material," and stores this information.

3. Check Processor Assignment: The system verifies if a processor is already assigned to the workflow. If
not, BRFplus is launched to determine the appropriate processor and the next step.

4. BRFplus Decision-Making: Based on the change request type, the current step, and any actions taken,
BRFplus uses decision tables to determine:
 The next step in the workflow.
 Whether single or parallel processing is required.
 The next processor or agent group involved.
5. Parallel Processing (if needed): If parallel processing is configured, the system can create sub-workflows
for different parts of the process to be handled simultaneously.

6. Workflow Branching: The workflow branches based on the process pattern identified by BRFplus,
potentially into steps like approval, revision, or finalization.

7. Check Workflow Completion: The system checks if the workflow has reached a complete state, such as
the change request being finalized.

Example Workflow Steps:

 Step Type 1: Check Change Request: Approver reviews the request, potentially agreeing or disagreeing.
 Step Type 2: Approve Change Request: The request is approved or rejected by an approver.
 Step Type 3: Process Change Request: The request is finalized or sent back for revision.
 Step Type 4: Revise Change Request: The request is revised, resubmitted, or withdrawn.

Rule BADI Steps:

In SAP MDG, Rule BADI steps involve leveraging Business Add-Ins (BAdIs) to enhance rule-based
workflows. These BAdIs are used to modify the behavior of the workflow, particularly in scenarios where
the standard SAP logic needs to be extended or customized. The process typically involves defining new
change request types, service names, creating BAdI implementations, and defining filters, all within the
MDG configuration.
Here's a more detailed breakdown of the process:
1. Identify the Need for a BAdI:
Determine if a standard BAdI or a custom one is required to achieve the desired workflow customization.
2. Locate the Relevant BAdI:
Using MDG IMG (t-code MDGIMG): Navigate to "General settings" -> "Data Quality and Search" -> "BADI"
-> "Define Validations and Derivations".
Using SE24: Explore the class CL_EXITHANDLER to find relevant BAdI names, especially using the
method GET_INSTANCE, as described by SAP.
3. Create a New BAdI (if needed):
If no existing BAdI meets the requirement, create a new one in the MDG IMG or using the SE19
transaction.
4. Implement the BAdI:
Create a new change request type: Define a new change request type to track modifications made through
the BAdI.
Define service names: Specify the names of the services that will be enhanced by the BAdI.
Create enhancement implementation: Develop the custom logic to be executed when the BAdI is triggered.
Create BAdI implementation: Define the filter criteria and the specific code to be executed for the BAdI.
Create filter: Determine the conditions under which the BAdI should be executed, using appropriate filter
values.
5. Configure the BAdI within the Workflow:
Rule Context Preparation: Use BAdIs like USMD_SSW_RULE_CONTEXT_PREPARE to add additional
parameters to the BRFplus user decision table, as mentioned on Scribd.
Dynamic Agent Selection: Use BAdIs like USMD_SSW_DYNAMIC_AGENT_SELECT to implement
dynamic agent determination within the workflow, as explained by SAP.
System Method Call: Use BAdIs like USMD_SSW_SYSTEM_METHOD_CALLER to call specific system
methods during the workflow, according to LinkedIn.
6. Test and Debug:
Thoroughly test the BAdI to ensure that it functions as expected and that any unexpected behavior is
addressed.
Key Considerations:
Filter Dependent vs. Multi-use BAdIs:
Understand the difference between BAdIs that are filter-dependent and those that can be used for multiple
purposes, as this affects how they can be implemented, according to SAP Community.
Multiple Implementations:
Be aware that some BAdIs may not support multiple implementations with the same filter, and ensure that
the filter settings are configured correctly, as noted in a SAP Community thread.

Service BADI Steps:

To implement a Service BAdI in SAP MDG, you'll typically follow these steps: identify the relevant BAdI and
its interface, create a new BAdI implementation, define filters if needed, and activate the implementation.
This involves using transactions like SE19 and SPRO.
Here's a more detailed breakdown:
1. Identify the BAdI and Interface:
Use the CL_EXITHANDLER class:
You can use the CL_EXITHANDLER class and its GET_CLASS_NAME_BY_INTERFACE method to find
BAdIs for a specific transaction or process, as described here.
Check MDG documentation and online resources:
Consult the SAP MDG documentation and community forums for known BAdIs relevant to your specific
MDG process or data quality rules, as discussed here.
Consider using BRFplus:
For data quality rules, you might use BRFplus and implement the rule logic there, as suggested by this
post.
2. Create the BAdI Implementation:
Open SE19:
Use transaction code SE19 to open the "Enhancement Definition" screen.
Enter BAdI Name and Implementation Class:
Enter the BAdI name and the name of the class where you'll be implementing the BAdI methods, as
explained in this guide.
Implement the Interface Methods:
Implement the methods defined by the BAdI interface in your implementation class.
Define Filters (If Applicable):
If the BAdI is filter-dependent, define the necessary filter values in the "Filter Definition" tab, as mentioned
here.
Check your code:
Ensure your code is syntactically correct and handles all the required logic.
3. Activate the BAdI:
Go to transaction SPRO: Use transaction code SPRO to navigate to the relevant configuration path for
MDG.
Find the BAdI Implementation: Find the BAdI implementation you created within the SPRO configuration.
Activate: Activate the BAdI implementation.
4. Testing and Debugging:
Use the debugger:
Utilize the SAP debugger to step through your BAdI implementation and verify that it's working as expected.
Test with different scenarios:
Test your BAdI with various inputs and scenarios to ensure it handles all possible cases.
Example Scenarios:
Dynamic Derivations:
You can use BAdIs to derive data based on user input, for example, automatically calculating a price based
on a quantity entered by the user, as explained here.
Master Data Enrichment:
You can use BAdIs to enrich master data with additional information, such as discussed here.

Add/Skip Workflow steps based on Material Group in SAP MDG

In SAP Master Data Governance (MDG), you can add or skip workflow steps based on Material Group by
utilizing the rule-based workflow capabilities and the Business Rule Framework plus (BRFplus) tool. This
allows you to define rules that determine which workflow steps are triggered or skipped based on specific
material group attributes.
Here's how you can achieve this:
1. Configure the Material Master Data Model:
Ensure that your material master data model includes the "Material Group" field as a relevant attribute.
You can optionally add additional attributes specific to your business needs, such as a flag indicating
whether a particular workflow step should be skipped for a certain material group.
2. Set up Rule-Based Workflows:
Utilize the BRFplus tool within the Customizing activity "Configure Rule-Based Workflows" to define the
rules.
Create decision tables and rules that evaluate the material group attribute.
For example, you can create a rule that specifies that if the material group is "XYZ", then step "A" should be
skipped, and step "B" should be added.
3. Define Workflow Templates:
Utilize the preconfigured or adapt the existing workflow templates for material master data governance.
Ensure that the workflow templates are correctly linked to the rule-based workflow and the corresponding
decision tables.
4. Activate and Test:
Activate the defined rules and workflow templates in your MDG configuration.
Test the workflows with different material groups to ensure that the expected behavior is achieved.
Example Scenario:
Let's say you have two material groups: "Raw Materials" and "Finished Goods". You want to skip the
"Inventory Check" workflow step for raw materials but not for finished goods. You would:
Create a rule in BRFplus that checks if the material group is "Raw Materials".
Configure the workflow to skip the "Inventory Check" step if the rule is met.
Test the workflow with materials belonging to both material groups to verify the expected behavior.
By using the rule-based workflow capabilities of MDG and BRFplus, you can create flexible and adaptable
workflows that are tailored to your specific business needs and material group hierarchies.

Single Value decision table configuration steps in SAP MDG

To configure a Single Value Decision Table in SAP MDG, navigate to the BRF+ workbench, select the
desired catalog, and navigate to the Decision Table section. Define the workflow steps and their
dependencies by filling in the relevant details, including next steps, agents, and actions within the decision
table. After defining the process flow, save and activate the decision table in BRF+.

Here's a more detailed breakdown:

1. Access BRF+ Workbench:

Open transaction BRF+.

Switch to the Catalog tab and select the relevant catalog for your MDG change request type.

2. Locate and Configure the Single Value Decision Table:

Navigate to the Decision Tables section within the BRF+ workbench.

Identify the Single Value Decision Table (e.g., DT\_SINGLE\_VAL\_ZVENDR02 for a custom change
request ZVENDR02).

Enter the details for each workflow step, including:

Next step (e.g., the number of the next step in the workflow).

Agent assignments (e.g., which user or system should handle the step).

Actions to be performed (e.g., approve, reject, activate).

Conditions that trigger the next step (e.g., based on previous step actions, approval status).

3. Define User Agent and Non-User Agent Decision Tables:

If your workflow requires user or system actions, you may need to configure the User Agent and Non-User
Agent Decision Tables as well.
These tables define which user or system should handle a specific step, or what actions the system should
take.

4. Save and Activate:

After defining the process flow in the decision tables, save your changes.

Activate the decision tables to make them effective in the MDG workflow.

5. Testing:

Once the decision tables are configured and activated, you can test your custom change request process
by navigating to the NWBC (SAP Business Client) transaction and initiating a change request.

User Agent decision table configuration steps in SAP MDG

To configure User Agent decision tables in SAP Master Data Governance (MDG), you need to define the
rules for assigning users or roles to specific change request steps within the workflow. This involves using
BRFplus to create and maintain decision tables, specifically the User Agent decision tables, which dictate
who is responsible for processing a particular step in the change request process.

Here's a step-by-step guide:

1. Open the BRF+ Workbench:

Access the BRF+ workbench through Customizing, specifically under Master Data Governance -> Central
Governance -> Master Data Governance for Supplier -> Workflow -> Configure Rule-Based Workflow.

2. Select the Catalog and Change Request Type:

Choose the relevant catalog and change request type for which you want to configure the User Agent
decision table.

3. Access the Decision Tables:

Navigate to the Decision Tables section within the BRF+ workbench.

4. Locate and Modify the User Agent Decision Table:

Identify the User Agent decision table, typically named DT_USER_AGT_GRP_<change_request_type> or

similar.

5. Define User Assignment Rules:

Condition Alias: Define the condition alias that triggers the assignment. This could be the change request
step number, a condition in the previous step, or other relevant criteria.

User Agent Type: Specify the type of agent, such as "SU" (Special User), "AG" (Role), or other relevant
types.

User Agent Value: Provide the specific user ID or role ID to be assigned.

User Agent Group No: If you need to assign a group of users, you can define a group number and assign
multiple rows for each user in the group.

6. Consider Parallel Processing: If multiple users can process a step concurrently, you can configure
parallel processing by creating multiple rows with the same Condition Alias and User Agent Group No.

7. Activate the Decision Table: After making changes, activate the decision table to apply the new rules.

8. Test the Workflow: Use the NWBC (e.g., transaction NWBC) to test the change request process and
verify that users are correctly assigned to the appropriate steps.

Key Considerations:
BRF+ Templates: SAP delivers preconfigured workflows and decision tables that you can adapt or use as a
starting point.

Predefined Agent Types:In preconfigured deliveries, the user agent type might be set to SU (Special User)
and the user agent value to INIT (Initiator).

Customization: You can create custom User Agent decision tables for specific requirements.

Error Handling: If the system cannot find a processor, check the workflow log for errors related to setting
the change request status.

Authorization: Ensure the user running the workflow has the necessary authorizations to perform the
required actions.

Non User Agent decision table configuration steps in SAP MDG

To configure a Non-User Agent decision table in SAP MDG for a rule-based workflow, you need to define
the automated actions and follow-up logic for non-user agent steps within a change request process. This
involves determining the appropriate Process Pattern and its corresponding action for each step that
doesn't require user intervention.

Steps for configuring a Non-User Agent Decision Table:

1. Define the Change Request Type and Process Diagram:

Create the change request type and determine the process flow, assigning the rule-based workflow
template (WS60800086).

2. Identify Non-User Agent Steps:

Within the process diagram, identify steps that will be executed automatically by the system, not by a user.

3. Choose the Process Pattern: For each non-user agent step, determine the appropriate process pattern,
referencing the "Process Pattern" column in the Non-User Agent Decision Table.

4. Determine the Condition Alias: Choose a 3-digit identifier (condition alias) for each arrow pointing to a
non-user agent step, using abbreviations for better readability (e.g., "ACT" for activation).

5. Create the Non-User Agent Decision Table:

In BRF+, create the decision table with the name DT\_NON\_USER\_AGT\_GRP\_<change request type>.

6. Maintain the Decision Table:

In the DT\_NON\_USER\_AGT\_GRP\_<change request type> decision table, maintain the following

information for each non-user agent step:

Change Request Type: Specify the change request type.

Change Request Step Number: Specify the step number within the change request.

Condition Alias: Enter the 3-digit condition alias defined in step 4.

Process Pattern: Specify the appropriate process pattern for the step.

7. Activate the Decision Table: After completing the maintenance, activate the decision table.

8. Test the Custom Process: Test the custom change request process using transaction NWBC to ensure
the rule-based workflow is working as expected.

Example:

If a change request step requires a background task to activate the change request, you would:
Identify the step: as a non-user agent step within your process diagram.

Choose the Process Pattern: 06/Activation.

Define a Condition Alias: like "ACT".

In the Non-User Agent Decision Table, specify the Change Request Type, Step Number, Condition Alias
"ACT", and Process Pattern 06/Activation.

By following these steps, you can configure the Non-User Agent decision table to automate specific actions
within your SAP MDG change request processes, streamlining the workflow and reducing manual
intervention.

Condition Alias configuration steps in SAP MDG

In SAP Master Data Governance (MDG), configuring condition aliases involves setting up identifiers for
specific actions or steps within a change request process, particularly for rule-based workflows. This allows
the system to determine the next steps based on the conditions met during a change request.

Here's a breakdown of the configuration steps:

1. Define the Condition Alias:

Identify the Change Request Step: Determine the specific step or action within your change request
process for which you want to define a condition alias.

Choose a 3-Digit Identifier: Select a unique 3-digit identifier for the condition alias.

Consider Parallel Processing (if applicable): If your process includes parallel processing, you might need to
define multiple condition aliases for different routes or steps.

2. Configure the Rule-Based Workflow:

Access Customizing:

Navigate to the relevant Customizing settings for your MDG module (e.g., Master Data Governance for
Material, Master Data Governance for Business Partner) in Customizing.

Define Step Types and Assign Actions:

Define the different step types (e.g., approval, data enrichment) and assign actions to them.

Configure the Rule-Based Workflow:

Configure the rule-based workflow, including defining the conditions that trigger the workflow, and the
actions to be taken.

Utilize the Condition Alias:

Within the rule-based workflow configuration, specify the condition alias for each arrow or transition that
leads to a change request step.

Define the Change Request Flow:

Use the condition alias to control the flow of the change request through the workflow.

3. Verify and Test:

Test the Workflow:Test the rule-based workflow to ensure that the condition aliases are correctly triggering
the expected actions.

Review and Adjust:Review the workflow and adjust the condition alias assignments as needed to optimize
the change request process.
Example:SAP MDG, BRF+ (Custom Workflow Design) | by Saroj Meher | Medium

Imagine a change request process for material updates where you need to route a request for approval
based on the material type. You might define a condition alias "101" for a material type requiring an
additional approval step, and another condition alias "102" for material types that bypass the approval step.

Duplicate search configuration steps in SAP MDG

To configure duplicate search in SAP MDG, navigate to the "Configure Duplicate Check for Entity Types"
activity under "General Settings" -> "Data Quality and Search" -> "Search and Duplicate Check" in the
MDG IMG (Implementation Guide). Select the desired entity type and configure search parameters like
search mode (e.g., HA), threshold values, and match profile settings.

Here's a more detailed breakdown of the steps:

1. Access the Configuration:

Open the MDG IMG (transaction code: MDGIMG).

Navigate to: Master Data Governance -> Central Governance -> General Settings -> Data Quality and
Search -> Search and Duplicate Check -> Configure Duplicate Check for Entity Types.

2. Configure Search for the Entity Type:

Select the data model and entity type for which you want to configure the duplicate check.

Choose the desired search mode (e.g., "HA" for HANA-based search).

Set threshold values for the duplicate check (e.g., how similar two records must be to be considered
duplicates).

Specify the name of the match profile and search view to be used for the duplicate check.

If applicable, select the "Match Profile Based UI" option.

3. Further Configuration Options:

Define Search Application:

If you're using the BAS-DES duplicate check, go to "Define Search Application" to enable freeform and
fuzzy search flags for the "AD" search application/line.

Create Search View and Match Profile:

You may need to create a new search view and/or match profile if they don't already exist for your specific
requirements.

HANA Search Rule Set:

If using HANA-based search, you may need to create, edit, and refine the HANA Search Rule Set (SRS) to
define the search rules, stop words, and term mappings, according to this blog post.

Testing and Troubleshooting:

After configuring the duplicate check, thoroughly test it to ensure it functions as expected and refine the
settings if necessary, as described in this blog post.

Include in Change Request:

Ensure the duplicate check is included in the MDG change request process.

4. Example: Duplicate Check for Business Partners (BP):

You might configure the duplicate check to consider fields like BUT000-NAME_ORG1, BUT000-
NAME_ORG2, and ADRC-COUNTRY for organization BPs, and fields like BUT000-NAME_FIRST,
BUT000-NAME_LAST, and ADRC-COUNTRY for person BPs, according to this help page.

You can create a new configuration, set a new configuration with rules that contain new attributes for a
duplicate check, and create a new master data record to test the duplicate check, as described in this help
page.

5. Checking for Duplicates in Master Data Records:

When creating or modifying a master data record, the system will automatically perform a duplicate check
based on the configured settings.

If potential duplicates are found, they will be displayed in the application.

Master Data Consolidation configuration steps in SAP MDG

To configure Master Data Consolidation in SAP MDG, you need to first activate the necessary business
functions and then configure the process model, adapters, and various steps like matching, validation, and
activation. This involves setting up the gateway for MDG, specifying the process model, adapters for your
specific master data objects (like Business Partner or Material), and defining rules for standardization,
matching, and best record calculation.

Here's a more detailed breakdown of the configuration steps:

1. Activate Business Functions:

If you're using SAP S/4HANA, you'll need to activate the relevant business function for MDG Consolidation
(e.g., MDG_CONSOLIDATION_MATERIAL_2 for material).

2. Configure Process Model:

Define the process model for your master data object (e.g., Business Partner, Material).

Specify the tables and fields that will be used in the consolidation process.

Set up the root table and specify process indicators for relevant tables.

3. Configure Gateway Services:

Configure Gateway services for SAP MDG, Consolidation and Mass Processing.

Set up the workflow for consolidation.

4. Configure Adapters:

Specify adapters for your master data object (e.g., Business Partner).

These adapters define how data is extracted, transformed, and loaded for consolidation.

5. Configure Standardization:

Set up rules for standardizing your master data, ensuring data consistency.

6. Configure Matching:

Define matching rules to identify and group duplicate records.

This includes setting up matching algorithms and thresholds.

7. Configure Best Record Calculation:

Determine how the best record is selected from a match group.

This can involve defining rules based on data quality, priority, or other criteria.

8. Configure Validation:

Set up validation rules to ensure data quality and accuracy.

This can include checks for mandatory fields, data types, and business rules.

9. Configure Activation:

Define how the consolidated records are activated and propagated to the back-end systems.

10. Configure Process Template:

Create and configure process templates for specific consolidation scenarios.

These templates define the sequence of steps and the adapters used for each process.

11. Data Load:

Load your master data into SAP MDG for consolidation.

12. Configure Custom Objects (if needed):

If you're consolidating custom master data objects, you'll need to configure the corresponding process
model, adapters, and other settings.

Master Data Consolidation DQM configuration steps in SAP MDG

In SAP MDG, Master Data Consolidation with Data Quality Management (DQM) configuration involves
several steps. First, you need to configure the gateway, specify the process model, adapters, and then
configure DQM components like standardization, matching, best record calculation, and validation. Finally,
you need to set up activation and process templates, and perform an initial data load.

Here's a more detailed breakdown of the configuration steps:

1. Accessing the Configuration:

You can access all SAP MDG consolidation specific Customizing activities using transaction MDCIMG.

2. Configuration Steps:

Configure Gateway for SAP MDG, Consolidation: This involves setting up the infrastructure for data flow
between systems.

Specify Process Model: Define the workflow and process flow for consolidating master data.

Specify Adapters: Configure how data is extracted and transformed from different sources.

Configure Standardization: Apply rules to standardize data formats and improve quality.

Configure Matching: Define how to identify and match duplicate or similar records.

Configure Best Record Calculation: Determine which record should be the final, unified master data record.

Configure Validation: Set up validation rules to ensure the quality and accuracy of the data.

Configure Activation: Define how the consolidated master data is activated and made available for use.

Specify Process Template: Use predefined or create custom process templates to define the consolidation
process for specific master data objects.

Initial Data Load: Load the initial set of master data into the consolidation system.
Services for SAP MDG, Consolidation Web Dynpro Applications: Configure the web applications for
managing the consolidation process.

File Upload configuration steps in SAP MDG

To upload files in SAP MDG, navigate to the "File Upload" service within the MDG work center. Select the
appropriate entity type, define the file structure, specify upload settings, and then check and execute the
upload. The process typically involves creating a change request, mapping the file to the relevant fields,
and then activating the change request to upload the data.

Here's a more detailed breakdown of the steps:

1. Access the File Upload Service: Locate the "File Upload" service within the MDG work center, often
found under the "Distribution Monitor" or "Data Transfer" workset.

2. Define Entity Type and Transfer Type: Specify the relevant entity type (e.g., material, customer, vendor)
and the type of transfer (e.g., attributes, language-dependent texts, or hierarchies).

3. Configure File Structure:Map the fields in your file to the corresponding fields in MDG. This may involve
creating a variant or customizing existing settings for the file upload.

4. Specify Upload Settings:

Define how the system should handle the uploaded data, including options for validation, scheduling, and
parallel processing.

5. Create and Manage Change Requests:

Create a change request to encapsulate the file upload and ensure proper governance processes.

6. Upload and Execute:Select the file and initiate the upload process. The system will validate the data and,
if successful, submit it to the change request for review and activation.

7. Confirm and Activate:Once the change request is approved and activated, the data is loaded into MDG.

Additional Considerations:

Change Requests:It's crucial to use change requests to manage the upload process, especially if you are
working with a governance model.

Staging Areas:Consider using staging areas to validate data before it's written to the active area.

File Format:Ensure your file is in a supported format (e.g., CSV, Excel) and that the file structure matches
the expected format.

Data Mapping: Pay close attention to data mapping to ensure fields are correctly linked between the file
and MDG.

Variant Management:Save your configuration as a variant to reuse it for future uploads.

Error Handling:The system logs upload errors, so review the logs to identify and resolve any issues.

Data Validation:Validate the data in the file to ensure it conforms to the MDG schema.

Background Processing:Consider using background processing for large files or to avoid interrupting
business operations.

File Download configuration steps in SAP MDG

To download files from SAP Master Data Governance (MDG), you can use the USMD_FILE_DOWNLOAD
Web Dynpro application to download master data from MDG database tables to a local CSV file.
Alternatively, you can use the USMD_DATA_TRANSFER program for both downloading and uploading
data.
Steps for downloading files in MDG:

1. Identify the desired data:

Determine which master data objects you want to download, such as GL Accounts, Materials, or Suppliers.

2. Use the USMD_FILE_DOWNLOAD application:

Enter the application name in the SAP transaction entry field and press Enter.

Configure the download settings, including the relevant parameters for the download.

Start the download process.

3. Utilize the USMD_DATA_TRANSFER program (alternative):

Enter the program name in the SAP transaction entry field and press Enter.

Configure the program with the necessary parameters for downloading data.

Execute the program to download the data.

4. File format and location:

The downloaded file will typically be in CSV format and saved to a local directory on your computer.

5. Review and further use:

Verify the downloaded data and use it as needed, such as for integration with external systems.

Mass Processing configuration steps in SAP MDG

To configure Mass Processing in SAP MDG, you start by accessing the Customizing settings via
transaction MDCIMG. You'll then configure areas like Gateway Services, Workflow, Process Model, and
Scope for Mass Processing, which also includes configuring matching, validation, and activation.

Here's a more detailed breakdown:

1. Accessing Customizing:

Use transaction MDCIMG to access the SAP MDG, Consolidation, and Mass Processing Customizing
settings.

2. Key Configuration Areas:

Services: Configure Gateway Services for MDG, Consolidation, and Mass Processing.

Workflow: Set up the workflow for the mass processing operations.

Process Model: Define the process model for the specific master data object (e.g., Business Partner,
Material).

Scope for Mass Processing: Define the scope of the mass processing by specifying the BO Type and the
fields to be included.

Choose the fields from the relevant tables (e.g., KNA1 for customer master, MARA for material master) to
be modified during the mass process.

Matching: Configure matching rules for identifying duplicate or related records, particularly relevant for
consolidation.

Validation: Define validation rules to ensure data quality and consistency during mass processing.
Activation: Configure how the updated master data records are activated and made available for use in
business processes.

Parallelization: Configure how parallelization is used during mass processing to enhance performance.

Process Template: Specify process templates for Business Partner and Material to define the steps
involved in the mass process.

3. Custom Objects: Configure custom objects if you need to extend MDG to manage master data that
doesn't fall under the standard Business Partner or Material.

This involves configuring the BO Type, process model, and matching rules for the custom object.

4. Data Load: Configure how data is loaded for mass processing, including options for importing data from
CSV files or other sources.

5. Fiori Apps: The Mass Processing functionality is accessible through Fiori apps like "Start Mass
Processing" and "Manage Mass Processing" on the Fiori Launchpad.

In essence, you configure MDG's mass processing capabilities by defining the scope of the process, the
rules for data validation and matching, the activation process, and any custom objects or data load
mechanisms needed for your specific business requirements.

Add tab UI configuration in SAP MDG

To add a tab in the UI configuration for SAP MDG, you'll typically utilize the UI Building Block (UIBB)
mechanism. This involves creating a new UIBB and then configuring it to display the desired information or
fields within a tabbed interface. You'll need to navigate to the relevant configuration area within MDG,
typically involving the UI Modeling or Component Configuration settings.

Here's a general outline of the process:

1. Access UI Configuration:

Navigate to the appropriate MDG configuration transaction or area where UI configurations are managed.
This could be under "Master Data Governance" -> "General Settings" -> "UI Modeling" or similar,
depending on the MDG version and configuration.

You'll likely need to access the "Component Configuration" section to make UI changes.

2. Create a New UI Building Block (UIBB):

From the UI configuration screen, select "Add" and then "UIBB" to create a new UIBB.

You'll need to define the details of this UIBB, such as the component, view, and configuration name.

3. Configure the UIBB:

Within the newly created UIBB, you'll configure its layout and content. This might involve selecting the
appropriate form component and view.

You'll likely need to specify which fields or attributes from your data model should be displayed within this
tab.

4. Assign the UIBB to a Tab:

Once the UIBB is configured, you'll need to assign it to a specific tab within the main UI of your MDG
application.

This might involve using a "Tabbed UIBB" component or a similar mechanism to create a tabbed interface.

5. Link the UIBB to Business Activities:

Finally, you'll need to link the newly created UI configuration with specific business activities or actions
within MDG.

This ensures that the tab and its content are displayed when users perform specific tasks within MDG.

Specific Steps (Illustrative):

Access Component Configuration: Navigate to MDG settings and select "Go to Component Configuration".

Add Entity Type: If you don't already have it, add the entity type (e.g., "ACCOUNT" for data model 0G).

Difference between Web dynpro and Fiori in SAP MDG

In SAP Master Data Governance (MDG), Web Dynpro and Fiori represent different UI technologies for
accessing and managing master data. Fiori, built on SAP UI5, offers a modern, mobile-first, and responsive
user experience, while Web Dynpro is a more traditional, server-side rendering technology. Fiori is
generally considered the preferred approach for new development and offers a more intuitive and user-
friendly interface, particularly for mobile devices, compared to Web Dynpro.

Here's a more detailed comparison:

Fiori (SAP UI5):

Modern UI:

Fiori applications are based on SAP UI5, a JavaScript-based framework, and offer a modern, clean, and
intuitive user interface, especially well-suited for mobile devices.

Responsive Design:

Fiori applications are responsive and adapt to different screen sizes and devices, providing a consistent
user experience across various platforms.

Mobile-first:

Fiori is designed with a mobile-first approach, offering a streamlined and efficient user experience on
smartphones and tablets.

Integration:

Fiori integrates seamlessly with other SAP systems, including MDG, and can be extended to integrate with
non-SAP systems.

Customization:

Fiori allows for extensive customization of the user interface and functionality, enabling developers to tailor
applications to specific business needs.

Web Dynpro:

Traditional UI:

Web Dynpro is a server-side rendering technology that is used for developing web applications within SAP.

Not Mobile-First:

Web Dynpro applications are not designed to be primarily used on mobile devices and may not be as
responsive as Fiori applications.

Server-Side Rendering:

Web Dynpro applications are rendered on the server-side, which can result in slower loading times and a
less responsive user experience compared to Fiori.

Legacy Technology:
While still supported, Web Dynpro is considered a legacy technology, and SAP is encouraging the
transition to Fiori for new development.

Limited Customization:

Web Dynpro offers less flexibility for customizing the user interface and functionality compared to Fiori.

In MDG, Fiori applications are generally preferred for new development and offer:

A more modern and intuitive user experience, Improved usability on mobile devices, Greater flexibility for
customization, and Better integration with other SAP systems.

While Web Dynpro applications may still be used in existing MDG systems, they are not recommended for
new development due to their limitations:

Less modern and intuitive user interface, Limited responsiveness on mobile devices, Less flexibility for
customization, and Potential for slower loading times.

In essence, Fiori offers a more modern and user-friendly experience in MDG, while Web Dynpro is a more
traditional technology that is being gradually replaced by Fiori.

Add UIBB: Choose "Add UIBB" and specify the details (component, view, etc.).

Add Form: Add a form to the UIBB to define the layout of the tab's content.

Link to Business Activities: In the "Business Activities" section, link the new UI configuration to relevant
business activities.

Example:

Let's say you want to add a tab for "Contact Information" to the "Customer" master data view in MDG.
You'd:

Create a new UIBB for "Contact Information."

Configure it to display fields like "Contact Person," "Phone Number," "Email," etc.

Create a "Tabbed UIBB" or similar component in your main MDG view.

Assign the "Contact Information" UIBB to a tab within this tabbed UI.

Ensure this tab is accessible when users are creating or editing customer master data.

Key Considerations:

Data Model:The fields displayed on the tab need to be defined within your MDG data model.

Business Requirements:

Carefully consider the business needs when designing the UI, ensuring that the relevant data and
information are readily accessible.

UI Modeling Tools:MDG provides tools like ABAP Web Dynpro and Floorplan Manager (FPM) for UI
modeling, allowing you to customize and create new UI applications.

Customization:You can customize UI configurations to adapt them to your specific business requirements
and user roles.

DRF configuration steps for Material in SAP MDG

To configure DRF for Material in SAP MDG, you need to define replication models, assign outbound
implementations, and configure target systems. This involves defining business systems, logical systems,
and assigning filter criteria. Key mapping and data validation are also crucial for accurate replication.

Here's a more detailed breakdown:

1. Define Business and Logical Systems:

Business System: This represents the source or hub system from which data is replicated.

Logical System: This is a technical representation of the business system and is used for IDoc
communication.

2. Define Replication Models:

Navigate to the appropriate configuration section within SAP MDG.

Create a new replication model and provide a name and description.

Assign an outbound implementation.

The outbound implementation number for material master data replication in SAP Master Data Governance
(MDG) is 194_1 SAP. This implementation is used to transfer material master data via the MATMAS IDoc.

Explanation:

Outbound Implementation:

In the context of SAP's Data Replication Framework (DRF), an outbound implementation defines how
specific business object data is replicated from a source system to a target system.

194_1:

This specific outbound implementation is designed for transferring material master data using the MATMAS
IDoc.

MATMAS IDoc:

The MATMAS (Material Master) IDoc is a standard SAP Intermediate Document used for exchanging
material master data between systems.

DRF (Data Replication Framework):

The DRF is a core component in SAP for replicating master data, and it uses outbound implementations to
define how data is transferred.

In summary, when replicating material master data from SAP MDG, you would use outbound
implementation number 194_1, which utilizes the MATMAS IDoc for the transfer.

Assign target systems (the systems where the data will be replicated).

Define outbound parameters, such as PACK_SIZE_BULK, which determines the number of records in a
single replication message.

Activate the replication model.

3. Key Mapping and Data Validation:

Key Mapping: Establish a mapping between the object IDs in the source and target systems to ensure
correct synchronization.

Data Validation: Define validation rules in MDG to check the data before it's replicated.

4. Other Important Configuration Steps:

Filter Criteria: Define filters to control which data is replicated.

Outbound Implementations: Configure the outbound implementation to handle the transmission of data.

Background Jobs: Set up background jobs to run the replication process.

Business Activities and Change Request Types: Ensure that the necessary business activities and change
request types are configured.

Data Quality Rules: Configure data quality rules to ensure data consistency and accuracy.

DRF configuration steps for BP in SAP MDG

To configure Business Partner (BP) replication in SAP MDG using the Data Replication Framework (DRF),
you need to define the technical settings for the business system, create and assign replication models,
and define outbound implementations and parameters. The configuration involves defining a replication
model for the BP, assigning it to an outbound implementation (e.g., 986_3 for BP/REL via Services), and
specifying the target system and outbound parameters, including the pack size for bulk replication.

Here's a step-by-step guide:

1. Define Technical Settings for Business System:

Transaction: DRFIMG -> Define Custom Settings for Data Replication -> Define Business System.

Define the technical details for your source and target business systems. This includes the RFC destination
and other communication settings.

2. Define Replication Model:

Transaction: DRFIMG -> Define Custom Settings for Data Replication -> Define Replication Models.

Create a new replication model, providing a name, description, and optionally, log expiry time.

Assign the replication model to the BP business object type (e.g., 986 for BP).

Assign Outbound Implementation:

Double-click on the created replication model and choose "Assign Outbound Implementation".

Select outbound implementation 986\_3 for BP/REL via Services and define the sequence and
communication channel.

Assign Target Systems:

Select the created implementation and choose "Assign Target Systems for Repl. Model / Outb. Impl.".

Add the target business system for replication.

Assign Outbound Parameters:

Select the created implementation and choose "Assign Outbound Parameter".

Define parameters like PACK_SIZE_BULK, which determines the number of records per replication
message.

Save and Activate:

Save the replication model and then activate it.

3. Define Filter Criteria (Optional):

Transaction: DRFIMG -> Enhance Default Settings for Outbound Implementation -> Define Filter Objects.

Define filter criteria to control which BP data is replicated based on specific attributes.

4. Configure Business Partner in SAP MDG (Classic Mode):

Transaction: MDGIMG -> Classic Mode in SAP MDG Central Governance -> General Settings -> Data
Modeling -> Edit Data Model.

Assign the Business Object Type 986 to the BP entity type within your MDG data model.
Generate the data model.

5. Configure Business Partner in SAP MDG (Business Activities):

Transaction: MDGIMG -> Classic Mode in SAP MDG Central Governance -> General Settings -> Process
Modeling -> Business Activities.

Ensure that the necessary business activities for BP management (e.g., create, change, display) are
assigned to the BP data model.

6. Configure Background Job (Optional):

Transaction: SM36 to define a background job for running the replication process.

Define a job name, job class, and schedule the job to run periodically (e.g., daily).

Add a step to the job, specifying the report USMD_EDITION_REPLICATE and a variant.

7. Create Outbound Services (SOAMANAGER):

Transaction: SOAMANAGER to create outbound services for data replication.

Define web service configuration for the replication process.