Professional Documents
Culture Documents
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help
Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
The selected structure has more than 150 subtopics. This download contains only the first 150 subtopics. You can manually download the missing
subtopics.
© 2016 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP
SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are
provided by SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP
Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set
forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional
warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in
Germany and other countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
Product Information
SAP Master Data Governance (SAP MDG), central governance provides central ownership of master data in line with a company’s business rules and
processes. MDG delivers domain-specific, out-of-the-box applications as well as a framework for custom-defined master data. MDG offers change request-
based processing of master data with integrated workflow, staging, approval, activation, and distribution. MDG can be deployed as a separate hub system, or
co-deployed with SAP ERP. In both cases, MDG can use SAP and company-specific business logic to create master data ready to be used in a company’s
business processes.
SAP MDG, consolidation provides an understanding of enterprise master data that is owned and maintained de-centrally. SAP MDG, consolidation delivers
capabilities to load master data from different sources, to standardize the master data, and to detect duplicates. For each of the resulting match groups, MDG
calculates a best record out of the duplicates in that group, using survivorship rules on the master data attributes. These best records can then be used in
dedicated analytical or business scenarios.
Within SAP MDG you can combine consolidation and central governance to support various master data management scenarios, like initial load of master
data as a starting point for central governance, consolidation of master data after mergers and acquisitions, or combinations where you keep de-central
ownership of master data in some parts of the company while centralizing master data ownership in other parts.
Features
SAP Master Data Governance offers the following features:
Centrally Governed Master Data
You can manage master data centrally in the Master Data Governance system. You can use a change requests to request changes to existing master
data or to create new master data. A flexible workflow concept enables you to create the exact master data control process you require, including quality
checks and authorizations.
Pre-Built Content for Master Data Domains
SAP Master Data Governance provides standard data models, user interfaces, and workflow definitions for financial master data, material master data,
business partners, customers, and suppliers. This standard content can be flexibly enhanced as needed.
Create Custom-Objects
You can use the SAP MDG Application Foundation to build central governance processes for your unique master data objects.
Replicate Central Master Data
You can use the data replication framework (DRF) to replicate your master data to target systems. Filters allow you to determine the data sent to each
target system. Key mapping allows for different IDs in different systems and value mapping supports translation of attribute values so that they can be
understood in the target systems. You can use enterprise services, IDocs, or the file download functions, as the underlying replication technology.
Load Master Data
You can use functions such as File Upload or Import Master Data to transfer data into your Master Data Governance system.
Ensure Master Data Quality
To increase your master data quality, you can check the data in your MDG governance processes against SAP business logic and rules you have
defined in the BRF+, or you can use data quality checks from external service calls.
Change Multiple Master Data Records
SAP Master Data Governance offers a range of methods to change multiple master data objects in a single change request.
Side Panel
Side Panels enable you to extend the SAP MDG user interface by enriching it with additional content for the end-user.
Process Quality Analytics
You can use SAP HANA for search and duplicate detection, for real-time aggregation of KPIs and trends in process analytics, as well as for increased
throughput in master data consolidation.
SAP Fiori Apps
A suite of dedicated SAP Fiori apps support use cases such as display and approval of master data requests.
Consolidate Master Data
You can standardize master data loaded from different sources and identify potential duplicates. You can calculate best records based on duplicate
groups and survivorship rules.
This documentation provides the information you require to set up SAP Master Data Governance (CA-MDG). This information supplements the information
provided in Customizing as well as the information about activities that you need to execute in addition to configuring Customizing settings.
SAP MDG, consolidation enables you to consolidate your master data using a sequence of process steps. The order of the process steps as well as the
behavior of each individual process step type can be adapted to your requirements.
This document provides the information you require to set up SAP MDG, consolidation . It contains information about Customizing as well as the information
Prerequisites
Services
You have activated the services for web dynpro applications. For a detailed list of the relevant services, see Services for SAP MDG, Consolidation (Web
Dynpro and Gateway).
Business Function
In the Customizing activity Activate Business Functions (transaction SFW5 ), you have activated at least one of the following business functions:
Master Data Governance for Customer, Consolidation 8.0 (Reversible)
Master Data Governance for Supplier, Consolidation 8.0 (Reversible)
Note
If you want to run SAP MDG, consolidation in parallel with SAP MDG, central governance you have to activate the corresponding business functions.
For more information, see Configuration of Master Data Governance
Authorization Objects
You have assigned the relevant authorization objects and roles. For more information about authorization objects and roles, see Authorization Objects and
Roles Used by SAP MDG, Consolidation.
Note
If you want to use the automated setup of bgRFC, see SAP Note 1043195 . This note includes the configuration of web service runtime.
General
In case you want to replicate data:
Either the MDG hub system and the source systems are connected to the System Landscape Directory (SLD) or the BAdI MDG_IDM_GET_LCL_SYSTEM is
implemented to determine the local system ID.
To verify the correctness of the SLD content run transaction SLDCHECK in the MDG hub and client systems. Ignore the browser dialog box. In the
systems check that the message reads: Summary: Connection to SLD works correctly.
If you decide to implement the BAdI and not to use SLD, see the documentation of the IMG activity under Master Data Governance General
Settings Data Replication Define Custom Settings for Data Replication Define Technical Settings BAdI: Determination of Local System Name
.
Process
You run the settings for this process in Customizing under Cross-Application Components Processes and Tools for Enterprise Applications Master
Data Governance, Consolidation .
Note
You can access all SAP MDG, consolidation specific Customizing activities using transaction MDCIMG.
Result
The system is configured for SAP MDG, consolidation .
More Information
Master Data Governance Security Guide
For security reasons the services delivered for Web Dynpro applications initially are available in an inactive state only. You have to activate the services you
want to use.
Activities
To activate the services, proceed as described below in the corresponding system:
1. On the Maintain Services screen (transaction SICF), make sure that the Hierarchy Type SERVICE is selected, enter the Service Name , and choose
Execute .
2. Choose Service/Host Activate , to activate the service.
Note
You have to perform the procedure for each single service you want to activate.
The table below provides a list of the services used in the respective components of MDG, consolidation .
You can run the gateway server either on a separate frontend system or on the backend system.
Prerequisites
On the frontend system, the launchpad UIMDC01 Master Data Consolidation Launchpad is listed in the transaction LPD_CUST. This launchpad is part
of the standard delivery of SAP MDG, consolidation .
The following role is available on the frontend system as part of the standard delivery of SAP MDG, consolidation : Master Data Specialist
(Consolidation) - Apps SAP_MDC_BCR_MASTERDATA_SPEC_T.
Activities
1. In the frontend system, create a trusted RFC connection to the backend system. To do so, run the Customizing activity under SAP Customizing
Implementation Guide SAP NetWeaver Gateway OData Channel Configuration Connection Settings SAP NetWeaver Gateway to SAP
System Manage RFC Destinations (transaction SM59)
Select the Connection Type 3 Connection to ABAP System .
On the Technical Settings tab, enter the Target System Settings for the backend system.
On the Logon & Security tab, mark the Current User indicator and mark the Yes radio button for Trust Relationship .
Note
If no entry exists proceed as follows:
1. Choose New Entries .
2. Use the entry help to select the Service Doc. Identifier .
The Service Doc. Identifier has the format <technical service name (see above)>_<service version (0001)>, for example
ZMDC_PROCESS_SRV_0001.
3. Assign the role mentioned above.
4. Use the entry help to select the system alias you created above.
9. Make sure the service has the status Active . To activate the service choose ICF Node Activate .
Prerequisites
The launchpad UIMDC01 Master Data Consolidation Launchpad is listed in the transaction LPD_CUST. This launchpad is part of the standard delivery
of SAP MDG, consolidation .
The following role is available as part of the standard delivery of SAP MDG, consolidation : Master Data Specialist (Consolidation) - Apps
SAP_MDC_BCR_MASTERDATA_SPEC_T.
Activities
To activate the service run the Customizing activity under SAP Customizing Implementation Guide SAP NetWeaver Gateway OData Channel
Administration General Settings Activate and Maintain Services
1. Choose Add Service .
2. Use the entry help to select the system alias LOCAL.
3. In the Technical Service Name field, enter MDC_PROCESS_SRV.
4. Choose Get Services .
5. Mark the corresponding entry in the list and choose Add Selected Services .
6. Adjust Technical Service Name if required and choose Continue .
7. Mark the service and choose Add System Alias .
8. Mark the entry, choose Copy As... , and assign the role mentioned above.
Note
If no entry exists proceed as follows:
1. Choose New Entries .
2. Use the entry help to select the Service Doc. Identifier .
The Service Doc. Identifier has the format <technical service name (see above)>_<service version (0001)>, for example
ZMDC_PROCESS_SRV_0001.
3. Assign the role mentioned above.
4. Use the entry help to select the system alias LOCAL.
9. Make sure the service has the status Active . To activate the service choose ICF Node Activate .
Result
You have configured the gateway service for SAP MDG, consolidation .
More Information
For further information of gateway services, see http://scn.sap.com/community/gateway .
Note
Do not enter this workflow template as Receiver Type in the type linkage.
Event STARTED
Receiver Type blank
Linkage Activated yes
Enable event queue no
The Linkage Activated indicator must not be active for other receiver types of the object type BUS2240 and the event STARTED . This receiver type is
defined by the Receiver Type Function Module MDC_RECEIVER_TYPE_GET. Make sure that Receiver Function Module
SWW_WI_CREATE_VIA_EVENT_IBF is entered.
Note
The Customizing for the object type BUS2240 is delivered in the client 000 in transaction SWE2.
In the standard delivery, process models for the following business object types are preconfigured:
Business Partner 147
The data model includes tables for business partner, customer, and supplier.
The validation uses ERP checks.
Records can be activated with SAP MDG, central governance using change requests and cleansing cases or can be activated directly.
The replication uses ALE or SOA..
Business Partner: Non-SAP-BS MDC_147
The data model includes tables for business partner, customer, and supplier.
SAP does not deliver a validation step, therefore no ERP checks are used.
Further configuration is required if you extend fields or nodes of the data model, or if you use your own business object type.
Note
For information about how to extend fields and nodes see SAP Note 1973686 .
Activities
Note
To perform the configuration steps described below, cross client customizing authorization is required.
To configure the process model for SAP MDG, consolidation , run the Customizing activity under Master Data Governance, Consolidation Configure
Process Model .
1. To see the tables that are assigned to the business object for the consolidation process, select the business object type and choose Tables .
2. To add further tables, select New Entries .
Only tables listed under a specific business object type are taken into account in the consolidation process. One table is marked as the Root table.
3. In the Tables view, select a specific table and choose Joins to see the joined tables.
4. To add further tables, select New Entries .
The Process indicator and the Active indicator show whether a table is used in the process data model or in the active data model.
5. In the Joins view, select a table and choose Join Fields to see the join conditions.
If required select New Entries to add further fields to join the tables. The Process indicator and the Active indicator show whether a field is used in
the process data model or in the active data model.
The standard delivery contains the adapters listed below for the different step types of the consolidation process. You can add adapters, you created to meet
your business requirements. Each adapter can be configured individually in the corresponding Customizing activity.
Standardization
CL_MDC_ADAPTER_BP_BAS_STD
Uses the third party interface of Business Address Services (BAS) to execute address validation against (external) address repositories.
CL_MDC_ADAPTER_BP_IM_STD
Matching
CL_MDC_ADAPTER_BP_BAS_MTC
Matching adapter that uses the third party interface of Business Address Services (BAS). Records are checked one by one with index, therefore the
adapter is not appropriate for mass data (more than 500.000).
CL_MDC_ADAPTER_BP_IM_MTC
Matching adapter that uses the SAP HANA information management and does the matching directly on the SAP HANA database. The adapter does not
support databases other than SAP HANA.
CL_MDC_ADAPTER_FUZZY_MTC
Matching adapter that uses the SAP HANA fuzzy algorithm. SAP HANA rulesets are generated for this adapter which can be configured and
implemented. The adapter does not support databases other than SAP HANA.
Validation
CL_MDC_ADAPTER_BP_VAL
Validation of business partner data using the business suite standard APIs. As a precondition to use this adapter for supplier and customer master data
the Customer Vendor Integration (CVI) has to be configured.
Activation
CL_MDC_ADAPTER_BP_ACT
Activation of business partner data using the business suite standard APIs. As a precondition to use this adapter for supplier and customer master data
the Customer Vendor Integration (CVI) has to be configured.
Replication
CL_MDC_ADAPTER_BP_REP
Executes the replication of business partners if you use SAP MDG, consolidation as a standalone application.
Note
In case MDG, consolidation is processed in parallel with SAP MDG, central governance we recommend to use the adapter
CL_MDC_ADAPTER_BP_ACT for replication.
Activities
Note
To perform the configuration steps described below, cross client customizing authorization is required.
To specify the adapters required for a specific step type of the consolidation process of a business object run the Customizing activity under Master Data
Governance, Consolidation Specify Adapters .
If you want to add own adapters or assign adapters to further business object types, proceed as described:
1. Choose New Entries .
2. In the BO Type field, select the business object type using the input help.
3. In the Step Type field, select a step type using the input help.
4. In the Adapter field, enter the adapter. The adapter has to be part of the customer namespace.
The adapter has to be assigned to a class that has implemented the interface IFMDC_ADAPTER.
5. Repeat the steps 2 to 4 to enter all required adapters.
Constraints
To ensure that within the application the Adapter Configuration is displayed correctly in the Manage Consolidation Processes process detail screen, the
amount of configurations per adapter should not exceed 100.
Within the process step standardization , address data is enriched and normalized by the system. In addition a check ensures that a specific address really
exist:
Example
Activities
To configure the standardization for MDG, consolidation, run the Customizing activity under Master Data Governance, Consolidation Configure
Standardization :
1. To configure the number of parallel processes run the Customizing activity Configure Parallelization for Standardization .
Adapting the number of parallel processes can improve the performance of the consolidation process.
Note
To use parallelization in SAP MDG, consolidation you have to set up an RFC destination:
To create the bgRFC inbound destination manually, the authorization object SBGRFC with activity 02 and type 07 has to be assigned to you.
1. Run transaction SBGRFCCONF.
2. On the Define Inbound Dest. tab choose Create .
3. Enter a name in the Destination field.
4. Enter MDC_QUEUE_ in the Prefixes field.
If you use a queue prefix other than MDC_QUEUE_ this has to be entered in the corresponding field as described below.
If you do not create the bgRFC inbound destination manually, you have to assign the authorization object SBGRFC with activity 02 and type 07
to a user. The very first consolidation process this user runs will trigger the automatic creation of the inbound destination.
For more information see http://help.sap.com/saphelp_nw70ehp2/helpdata/de/f0/225c3c60065627e10000000a114084/content.htm
Note
If you use queue prefixes other than MDC_QUEUE_ these have to be entered in the Prefix for Queue Name field.
2. To configure the Business Objects Data Services for BAS Adapter, see the documentation of the Customizing activity Configure Business Objects
Data Services for BAS Adapter .
Check the Customizing settings under SAP BusinessObjects Data Quality Management and adapt if required.
3. To import the predefined settings for SAP HANA information management run the Customizing activity Import Predefined Settings for SAP HANA
Information Management .
In this Customizing activity, you can activate the BC Set CA-MDG-EE-BP_IMHANA_C01 MDG-BP Consolidation: IM in Hana containing predefined
sets of table entries, that are required to run the process steps standardization and matching with the adapters for the SAP HANA information
management.
The BC Set contains settings for the tables listed below. You can use transaction SM30 to configure some of these tables to fulfill your requirements. Be
aware, that some settings are not to be changed. For details, see the description for each table.
Standardization and Matching
SIMDQ_INP_FILTER IM in HANA Filter for input
Settings to specify filters for standardization and matching. Records can be filtered out and do not take part in the corresponding process step.
Note
To ensure the correct processing of the consolidation process, the settings delivered by SAP are not to be changed.
Standardization
SIMDQ_ADDR_STG IM in HANA address related settings
Settings to specify the address standardization, for example address formats such as Woodstr. versus Wood Street.
SIMDQ_OTHR_STG IM in HANA non-address settings
Note
The settings delivered by SAP are required for technical reasons. Changing these settings does not have any impact.
Matching
SIMDQ_CMPRSRC IM in HANA compare source settings for Match Policy
Settings to specify the data sources to be considered for matching. The delivered settings compare process data with process and active data and
do not compare active data with each other.
Note
To ensure the correct processing of the consolidation process, the settings delivered by SAP are not to be changed.
Within the process step matching , the data records to be consolidated are checked for possible duplicates. According to a configured threshold records are
considered to be duplicates and are displayed as match groups in the attached match review .
Activities
To configure the matching for MDG, consolidation, run the Customizing activities under Master Data Governance, Consolidation Configure Matching :
1. To create the match configurations for the fuzzy matching run the Customizing activity Create Match Configurations for Fuzzy Matching .
In this Customizing activity, you define and generate a match configuration that SAP HANA uses to match master data records when using fuzzy
matching. This activity is only possible within a client allowing cross-client changes. Configurations created here are used during configuration of
process templates when assigning step type matching and adapter fuzzy matching.
Note
SAP provides the standard match configuration BPMATCH1 that can act as template to help you to define and generate your own match
configurations.
This Customizing activity calls the Web Dynpro application Match Configuration MDC_HDB_MATCH. You can use this screen to create, change, copy,
and delete a match configuration.
Create match configuration
1. To create a match configuration, choose New .
2. On the General Data screen, enter a name in the Match Configuration field.
3. Enter a description in the Description field.
4. Enter the business object type in the Business Object Type field.
5. Enter a name for the SAP HANA package in the HANA Package field.
The SAP HANA Package is generated with this name in the SAP HANA database when the match configuration is created. After the
generation of the package its name cannot be changed anymore.
6. Enter an ABAP package in the ABAP Package field.
Note
Do not use a package from standard delivery but create a package using transaction SE80.
On the Select Attributes screen, the attributes in the tables from the process model are presented in tree form. You can select the
attributes that are relevant for matching in your match configuration.
On the Review and Generate screen, you can review your choices from the previous screens, and if necessary, you can go back to the
previous screens to make changes.
The Generate button generates the match configuration. Before generation you must save the configuration.
Note
After generating the configuration you may maintain the rule set in the SAP HANA studio to meet your requirements.
The rule set can be found in the package used for creating the match configuration. The rule set naming convention is:
<MatchConfigurationName>RULESET.searchruleset.
By default one rule is generated with all the selected match attributes with minimum fuzziness of 0.8. All attributes are equally weighted.
To update the Rule Set, edit the rule set in the repositories view. Editing in the repositories view is possible since SAP HANA Studio
SPS09. Authorizations should be the same as for the project explorer view.
1. Create a repository work space.
2. Open the rule set in the package folder
3. Edit the rule set to change rule property or column property and conditions, such as the minimum fuzziness value or weight of an
attribute.
4. Save and Activate your changes.
For more information see the documentation on the SAP Help Portal:
Overview - SAP HANA Studio (http://scn.sap.com/docs/DOC-60363 )
SAP HANA Search Developer Guide (http://help.sap.com/hana/SAP_HANA_Search_Developer_Guide_en.pdf )
SAP HANA Fuzzy Search Reference (http://help.sap.com/hana/SAP_HANA_Fuzzy_Search_Reference.pdf )
Note
If you change the Select Attributes section by adding or removing attributes you have to set the Re-generate Rule Set indicator. Any manual
adjustment done on the ruleset has to be done on the regenerated rule set if intended.
Note
After copying the configuration you may maintain the rule set in the SAP HANA studio to meet your requirements. To do so, proceed as
described under Create match configuration.
2. To configure the number of parallel processes run the Customizing activity Configure Parallelization for Fuzzy Matching . Adapting the number of
parallel processes can improve the performance of the consolidation process.
Note
To use parallelization in SAP MDG, consolidation you have to set up an RFC destination:
To create the bgRFC inbound destination manually, the authorization object SBGRFC with activity 02 and type 07 has to be assigned to you.
1. Run transaction SBGRFCCONF.
2. On the Define Inbound Dest. tab choose Create .
3. Enter a name in the Destination field.
4. Enter MDC_QUEUE_ in the Prefixes field.
If you use a queue prefix other than MDC_QUEUE_ this has to be entered in the corresponding field as described below.
If you do not create the bgRFC inbound destination manually, you have to assign the authorization object SBGRFC with activity 02 and type 07
to a user. The very first consolidation process this user runs will trigger the automatic creation of the inbound destination.
For more information see http://help.sap.com/saphelp_nw70ehp2/helpdata/de/f0/225c3c60065627e10000000a114084/content.htm
Note
If you use queue prefixes other than MDC_QUEUE_ these have to be entered in the Prefix for Queue Name field.
3. To configure the Business Objects Data Services for BAS Adapter see the documentation of the Customizing activity Configure Business Objects Data
Services for BAS Adapter .
Check the Customizing settings under SAP BusinessObjects Data Quality Management and adapt if required.
4. To import the predefined settings for SAP HANA information management run the Customizing activity Import Predefined Settings for SAP HANA
Information Management .
In this Customizing activity, you can activate the BC Set CA-MDG-EE-BP_IMHANA_C01 MDG-BP Consolidation: IM in HANA containing predefined
sets of table entries, that are required to run the process steps standardization and matching with the adapters for the SAP HANA information
management.
The BC Set contains settings for the tables listed below. You can use transaction SM30 to configure some of these tables to fulfill your requirements. Be
aware, that some settings are not to be changed. For details, see the description for each table.
Standardization and Matching
SIMDQ_INP_FILTER IM in HANA Filter for input
Settings to specify filters for standardization and matching. Records can be filtered out and do not take part in the corresponding process step.
Note
To ensure the correct processing of the consolidation process, the settings delivered by SAP are not to be changed.
Standardization
SIMDQ_ADDR_STG IM in HANA address related settings
Settings to specify the address standardization, for example address formats such as Woodstr. versus Wood Street.
SIMDQ_OTHR_STG IM in HANA non-address settings
Note
The settings delivered by SAP are required for technical reasons. Changing these settings does not have any impact.
Matching
SIMDQ_CMPRSRC IM in HANA compare source settings for Match Policy
Settings to specify the data sources to be considered for matching. The delivered settings compare process data with process and active data and
do not compare active data with each other.
Note
To ensure the correct processing of the consolidation process, the settings delivered by SAP are not to be changed.
Within the process step Best Record Calculation , for each match group a best record is calculated. This calculation follows a well defined process based on
Activities
To configure the Best Record Calculation for MDG, consolidation, run the Customizing activities under Master Data Governance, Consolidation
Configure Best Record Calculation .
1. For an overview on the rules for the Best Record Calculation run the Customizing activity Specify Rules for Best Record Calculation .
The standard delivery contains the following rules to determine the best record:
COMPLETENESS: Determines that on field level completely maintained record win.
RECENCY: Determines that on table level the most recent record wins.
SOURCE_SYSTEM: Determines that on table level the record from a specified source system wins.
2. To specify the order of rules and the parallelization for the best record calculation run the Customizing activity Specify Order of Rules for Best Record
Calculation . Adapting the number of parallel processes can improve the performance of the consolidation process.
Note
To use parallelization in SAP MDG, consolidation you have to set up an RFC destination:
To create the bgRFC inbound destination manually, the authorization object SBGRFC with activity 02 and type 07 has to be assigned to you.
1. Run transaction SBGRFCCONF.
2. On the Define Inbound Dest. tab choose Create .
3. Enter a name in the Destination field.
4. Enter MDC_QUEUE_ in the Prefixes field.
If you use a queue prefix other than MDC_QUEUE_ this has to be entered in the corresponding field as described below.
If you do not create the bgRFC inbound destination manually, you have to assign the authorization object SBGRFC with activity 02 and type 07
to a user. The very first consolidation process this user runs will trigger the automatic creation of the inbound destination.
For more information see http://help.sap.com/saphelp_nw70ehp2/helpdata/de/f0/225c3c60065627e10000000a114084/content.htm
The process step matching has bundled records considered to be duplicates, the so called match groups.
In a first step, the records of a match group are compared on table level. For a specific table the source system or the recency can be considered to
have higher priority. Depending on this setting the corresponding data is taken into account for the best record. The information, what source system has
a certain priority for a specific table is maintained in the Order of Source Systems view.
In a second step the preliminary best record is processed on field level. If a field does not contain data but completeness is assigned to this field as
highest priority, then the data is completed with data derived from the record with the next highest order.
1. Choose New Entries
2. In the BO Type field, enter a business object type using the entry help.
3. In the Config. ID field, enter a configuration ID.
4. In the Adapter Config. Description field, enter the corresponding description.
5. In the Number of Processes field enter the number of processes you want to be processed in parallel.
6. If required enter the Prefix for Queue Name .
Note
If you use queue prefixes other than MDC_QUEUE_ these have to be entered in the Prefix for Queue Name field.
Note
You can reduce maintenance effort, in case you want to apply the same order of source systems to all tables: To do so, create an entry
with Space in the Table field and assign it to a source system. This order of source systems now is valid for all tables, except tables
that are explicitly assigned to another order of source systems.
Note
You can reduce maintenance effort, in case you want to apply the same order of rules to all tables: To do so, create an entry with Space
in the Table field and assign it to a rule. This order of rules now is valid for all tables, except tables that are explicitly assigned to another
order rules.
Example
Your source systems show the following entries in table BUT0BK (BP: Bank Details) for the fields BANKL (Bank Key), BANKN (Bank Account Number) and,
KOINH (Account Holder Name).
1 C33
2 B22
3 A11
As the table field does not contain any entry the order of source system is taken into account for all tables.
Order of Rules for Tables:
BUT0BK 1 SOURCE_SYSTEM
The rule SOURCE_SYSTEM is taken into account for the table BUT0BK .
Order of Rules for Fields:
The rule COMPLETENESS is taken into account for the field KOINH in table BUT0BK.
10010010 32168000
2. On field level the rule COMPLETENESS is applied. The field KOINH remained empty in the first step. Now the set of data is completed with data from
system B22 as this is the highest rated system that contains data in the KOINH field.
Note
Only if Order of Rules for Table contains an entry referring to the rule SOURCE_SYSTEM, either specific for table BUT0BK or generic for all tables,
the KOINH field is completed in the described way. If the Order for Rules for Table settings do not contain a corresponding entry, the source
system is not taken into account and it is not to be predicted what data is used to complete the KOINH field.
Within the process step validation the system checks whether the quality of a record is sufficient to meet the requirements defined in the backend system. If
the quality requirements are met the data can be saved directly, in other cases corrections and data enrichment might be required.
The process step validation runs without further configuration. Nevertheless you can configure the number of parallel processes to improve the performance of
the consolidation process.
Example
Data only can be saved if Street and House Number are maintained.
Activities
To configure the number of parallel processes for the validation run the Customizing activity under Master Data Governance, Consolidation Configure
Parallelization for Validation .
Note
To use parallelization in SAP MDG, consolidation you have to set up an RFC destination:
To create the bgRFC inbound destination manually, the authorization object SBGRFC with activity 02 and type 07 has to be assigned to you.
1. Run transaction SBGRFCCONF.
2. On the Define Inbound Dest. tab choose Create .
3. Enter a name in the Destination field.
4. Enter MDC_QUEUE_ in the Prefixes field.
If you use a queue prefix other than MDC_QUEUE_ this has to be entered in the corresponding field as described below.
If you do not create the bgRFC inbound destination manually, you have to assign the authorization object SBGRFC with activity 02 and type 07 to a
user. The very first consolidation process this user runs will trigger the automatic creation of the inbound destination.
Note
If you use queue prefixes other than MDC_QUEUE_ these have to be entered in the Prefix for Queue Name field.
Within the process step activation records are activated and thereby added to the systems active area. You can configure how the system proceeds with
different types of active data and you can set up a parallelization for the activation process.
Features
The activation can be adapted for all three possible types of records:
New record: Record does neither yet exist in the active area nor does it have any duplicates.
Updated record: Record already existed in the active area.
Match group: Record does not exist in the active area, but has duplicates in the process data.
Records that did not pass all validity requirements are considered as records with errors. You can specify an individual system reaction for each type of
record, depending whether a record contains errors or not. If you use SAP MDG, central governance in parallel with SAP MDG, consolidation you can use
change requests to have your records approved.
Activities
To configure the activation run the Customizing activity under Master Data Governance, Consolidation Configure Activation .
1. Select New Entries
2. Enter a Configuration ID and a Description .
3. Configure the parallelization for the activation adapter.
The activation is running without configuring the parallelization for the activation adapter. Nevertheless you can configure the number of parallel
processes to improve the performance of the consolidation process.
Note
To use parallelization in SAP MDG, consolidation you have to set up an RFC destination:
To create the bgRFC inbound destination manually, the authorization object SBGRFC with activity 02 and type 07 has to be assigned to you.
1. Run transaction SBGRFCCONF.
2. On the Define Inbound Dest. tab choose Create .
3. Enter a name in the Destination field.
4. Enter MDC_QUEUE_ in the Prefixes field.
If you use a queue prefix other than MDC_QUEUE_ this has to be entered in the corresponding field as described below.
If you do not create the bgRFC inbound destination manually, you have to assign the authorization object SBGRFC with activity 02 and type 07
to a user. The very first consolidation process this user runs will trigger the automatic creation of the inbound destination.
For more information see http://help.sap.com/saphelp_nw70ehp2/helpdata/de/f0/225c3c60065627e10000000a114084/content.htm
1. In the field Number of Parallel Processes , enter the number of processes you want to be processed in parallel.
2. If required enter the Prefix for Queue Name .
Note
If you use queue prefixes other than MDC_QUEUE_ these have to be entered in the Prefix for Queue Name field.
4. Specify the types of activation dependent on different record types and whether these records are considerd as correct or incorrect by the process step
validation:
Note
Records that did not pass all validity requirements are considered as records with errors. You can specify an individual system reaction for each type
of record, depending whether a record contains errors or not. If you use SAP MDG, central goverance in parallel with SAP MDG, consolidation you
can use change requests to have your records approved.
Note
If you want to activate using change requests make sure the selected change request type does not run checks that prevent the creation of the
record:
Run the Customizing activity Configure Properties of Change Request Step and for Change Request Step 00 check the setting under
Enhancements and Checks per Change Request Step and Entity Types per Change Request Step .
1. Configure the system behavior for New Records . In the field Activation Target for New Records , select an entry using the input help and assign
a corresponding change request type. In the field Target for New Incorrect Records , select an entry using the input help assign a corresponding
change request type.
2. Configure the system behavior for Updated Records . In the field Activation Target for Updated Records , select an entry using the input help and
assign a corresponding change request type. In the field Target for Updated Incorrect Records , select an entry using the input help and assign a
corresponding change request type.
3. Configure the system behavior for Match Groups . In the field Activation Target for Match Groups , select an entry using the input help and
Note
The Replication as part of Activation Step indicator is only valid for the process goal Central Maintenance . For the process goal Consolidation no
replication is executed.
If you activate all types of records using change requests or cleansing cases flag does not have any impact.
If you activate all types of records with the Direct Activation you can choose the setting to meet your requirements.
If you activate using change requests and Direct Activation, we recommend to set the flag.
Constraints
If you use SAP MDG, consolidation without activating SAP MDG, central governance the possibilities for this configuration step are reduced, as less
activation targets are offered and no selection fields for Change Request Type are displayed.
The process template you use to create a consolidation process specifies whether and in what configuration certain consolidation steps are processed and in
which order the steps apply. The setup of process templates is tied to certain rules concerning the order and recurrence of the individual process steps.
Standardization No limitation
Matching Once
Validation No limitation
Activities
To specify the Process Template run the Customizing activity under Master Data Governance, Consolidation Specify Process Template .
Create Process Template
1. Choose New Entries .
2. Enter a Process Template ID , a corresponding Description, select the Business Object Type (147 Business Partner or MDC_147 Business
Partner for Consolidation ), and the Workflow Template WS54500001.
3. In the Process Goal field, use the input help to select either Consolidation or Central Maintenance.
Note
If you select the Process Goal Consolidation records can be loaded repeatedly to be consolidated. The records are not replicated
to the source systems.
If you select the Process Goal Central Maintenance, records are loaded only once in the hub system. After being consolidated
the records are replicated to the source systems. You can use SAP MDG, central governance to perform the central maintenance.
The data to be consolidated can be loaded from SAP and non-SAP-systems using ETL tools (extract, transform, load) .
Solutions offered by SAP are the following:
SLT System Landscape Transformation
Note
Recommended for existing SAP business suite models, as identical data models are used.
Note
SAP recommends to import the data in the SAP HANA Studio into an interim table. In a second step the content of the interim tables can be loaded
to the source tables using SQL or a custom ABAP report.
Prerequisites
The data has to be transformed into the SAP data structure before the data load can be performed.
Features
Load the data into the source tables for the BP data model listed below:
Table Data
Note
The table is required in all cases.
Note
The table is required in case you use the customer data model
Note
The table is required in case you use the vendor data model
Note
For a complete list of the tables run the Customizing activity under Master Data Governance, Consolidation Configure Process Models , select the
Business Object Type 147 and double click on Tables in the dialog structure.
Note
For the upload of data related to organizations, you can also use the vendor or the customer data model. In this case you have to run the report
MDC_BP_TRANSFORM_SOURCE_DATA to transform the data to the BP data model after the source tables are filled. The report only supports the
transformation of data related to organizations. It does not supports the transformation of person-related data.
Note
For the upload of data related to organizations, you can also use the vendor or the customer data model. In this case you have to run the report
MDC_BP_TRANSFORM_SOURCE_DATA to transform the data to the BP data model after the source tables are filled. The report only supports the
transformation of data related to organizations. It does not supports the transformation of person-related data.
Note
The source system is XYZ_333. All data is uploaded to the client 401.
Data Value
Name SAP SE
Country Germany
Telephone +49/6227/7-47474
Fax +49/6227/7-57575
E-Mail info@sap.com
BP Data Model
Using the BP data model for the upload, the following tables are filled:
Note
It is required to run the report MDC_BP_TRANSFORM_SOURCE_DATA after the source tables are filled.
Tables in detail
The tables listed below show in detail the data to be loaded.
BUT000_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 1234567890
TYPE 2
Note
2 = Organization
NAME_ORG1 SAP SE
SOURCE_RECENCY 20150706000000
SOURCE_FILTER TEST1
Caution
NULL is not supported.
We recommend to use a proper value for the field SOURCE_FILTER.
BUT020_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 1234567890
SOURCE_ADDRNUMBER 1234567891
SOURCE_RECENCY 20150706000000
BUT_ADRC_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 1234567890
SOURCE_ADDRNUMBER 1234567891
DATE_FROM 00010101
ADDRNUMBER 1234567891
Note
Used with the supplier model
CITY1 Walldorf
POST_CODE1 69190
STREET Dietmar-Hopp-Allee
HOUSE_NUM1 16
COUNTRY DE
LANGU D
SOURCE_RECENCY 20150706000000
BUT_ADR2_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 1234567890
SOURCE_ADDRNUMBER 1234567891
DATE_FROM 00010101
COUNTRY DE
FLGDEFAULT X
TEL_NUMBER 06227/7-47474
TELNR_LONG +496227747474
Note
Used as an alternative to TEL_NUMBER
SOURCE_RECENCY 20150706000000
BUT_ADR3_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 1234567890
SOURCE_ADDRNUMBER 1234567891
DATE_FROM 00010101
CONSNUMBER 001
COUNTRY DE
FLGDEFAULT X
FAX_NUMBER 06227/7-57575
FAXNR_LONG +496227757575
Note
Used as an alternative to FAX_NUMBER
SOURCE_RECENCY 20150706000000
BUT_ADR6_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 1234567890
SOURCE_ADDRNUMBER 1234567891
DATE_FROM 00010101
CONSNUMBER 001
FLGDEFAULT X
SMTP_ADDR info@sap.com
SOURCE_RECENCY 20150706000000
BUT0BK_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 1234567890
BKVID 0001
BANKS DE
BANKL 987654321
BANKN 1234567890
SOURCE_RECENCY 20150706000000
DFKKBPTAXNUM_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 1234567890
TAXNUM DE143454214
SOURCE_RECENCY 20150706000000
BUT0ID_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 1234567890
TYPE BUP001
IDNUMBER 316268655
SOURCE_RECENCY 20150706000000
BUT100_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 1234567890
RLTYP FLVN01
Note
Role for suppliers
SOURCE_RECENCY 20150706000000
LFA1_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 1234567890
LIFNR 1234567890
Note
Only required if you use the supplier model.
NAME1 SAP SE
Note
Only required if you use the supplier model.
ADRNR 1234567891
Note
Only required if you use the supplier model.
KTOKK KRED
SPRAS D
Note
Only required if you use the supplier model.
SOURCE_RECENCY 20150706000000
LFBK_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 1234567890
BANKS DE
BANKL 987654321
BANKN 1234567890
BVTYP 0001
SOURCE_RECENCY 20150706000000
Data Value
Country Germany
E-Mail erika.mustermann@email-adresse.com
BP Data
Note
As the report MDC_BP_TRANSFORM_SOURCE_DATA does not support the transformation of person-related data, in this example the customer data model
can not be used.
Customer data related to organizations can be uploaded using the customer model. This can be done in analogy to the supplier model.
Using the BP data model for the upload, the following tables are filled:
Table Description
Tables in detail
The tables listed below show in detail the data to be loaded.
BUT000_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 2345678901
TYPE 1
Note
1 = Person
NAME_LAST Mustermann
NAME_FIRST Erika
XSEXF X
BIRTHDT 19640812
SOURCE_RECENCY 20150706000000
SOURCE_FILTER TEST2
Caution
NULL is not supported.
We recommend to use a proper value for the field SOURCE_FILTER.
BUT020_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 2345678901
SOURCE_ADDRNUMBER 2345678902
SOURCE_RECENCY 20150706000000
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 2345678901
SOURCE_ADDRNUMBER 2345678902
DATE_FROM 00010101
CITY1 Koeln
POST_CODE1 51147
STREET Heidestrasse
HOUSE_NUM1 17
COUNTRY DE
LANGU D
SOURCE_RECENCY 20150706000000
BUT_ADR6_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 2345678901
SOURCE_ADDRNUMBER 2345678902
DATE_FROM 00010101
CONSNUMBER 001
FLGDEFAULT X
SMTP_ADDR erika.mustermann@email-adresse.com
SOURCE_RECENCY 20150706000000
BUT100_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 2345678901
RLTYP FLCU01
Note
role for customers
SOURCE_RECENCY 20150706000000
KNA1_SRC
Field Content
CLIENT 401
SOURCE_SYSTEM XYZ_333
SOURCE_ID 2345678901
KTOKD DEBI
SOURCE_RECENCY 20150706000000
More Information
Note
The source ID has to be a unique identifier for a specific source system. If you upload data using the vendor or customer data model, you have to make
sure that the ID remains unique. If there are vendor- and customer IDs within the same number range the IDs might be made unique by adding a suffix. For
example a customer and a vender, both with the ID 1234567890 might be renamed to K123456789 and L123456789.
This documentation provides the information you require to set up Master Data Governance, Central Governance (CA-MDG). This information supplements the
information provided in Customizing as well as the information about activities that you need to execute in addition to configuring Customizing settings.
Note
The relevant Customizing settings are under Cross-Application Components Processes and Tools for Enterprise Applications Master Data
Governance, Central Governance .
This documentation provides the information you require to set up Master Data Governance for Custom Objects. This information supplements the information
provided in Customizing.
For security reasons the services delivered for Web Dynpro applications initially are available in an inactive state only. You have to activate the services you
want to use.
Activities
To activate the services, proceed as described below:
1. On the Maintain Services screen (transaction SICF), make sure that the Hierarchy Type SERVICE is selected, enter the Service Name , and choose
Execute .
2. Choose Service/Host Activate , to activate the service.
Note
You have to perform the procedure for each single service you want to activate.
Once you have activated a service it cannot be reset to inactive.
The table below provides a list of the services used in the respective components of SAP MDG, central governance .
APB_LAUNCHPAD Launchpad x x x x
MDG_BS_DATALOAD_M Reprocessing x x x x
ONITOR
MDG_EXTR_FPM_CMP Extractor x
USMD_CREQUEST_PRO USMD_CREQUEST_PRO x x x x
CESS CESS
USMD_EDITION Edition x
USMD_WF_NAVIGATION Workflow-Based x x x x
Navigation
WDA_BS_ANLY_LIST_OV List x x x x
P
WDR_CHIP_PAGE wdr_chip_page x x x x
The purpose of data modeling is to define the structure of the data storage. During the master data processing, a change request is used that stores the
master data changes in a staging area. The data model can define a reuse area that is used for data storage after the change request processing has been
completed and the related data has been activated. In this case, the system moves data from the staging area to a storage location that is connected by the
access class of the reuse area. This storage location is called active area.
If there is no reuse area defined, the same database tables that are used for the staging area, are also used to store active data. Then, no access class is
involved, the system does not move data from one location to another, and MDG is used as the active area.
A data model in Master Data Governance is comprised of various elements (entity types, attributes, and relationships) to enable you to model master data
structures of any complexity in the system. These elements are described below.
The system uses the data model to generate database tables for storing the data you enter when managing the master data. Which key fields and non-key
fields these database tables contain depends on the structure of your data model.
Note
This documentation supplements the information that is available in Customizing for Master Data Governance under General Settings Data
Modeling Edit Data Model . Therefore, this documentation only covers the areas of the data model that require more background information for better
comprehension.
Entity Types
You define entity types to model different types of master data in your data model. The system generates for each entity type the database tables that are
needed for processing the master data in Master Data Governance . You can define the following properties for an entity type:
You use the validity of entity field to specify for an entity type whether the validity of master data changes is restricted to editions:
Edition
When you create a change request to process entities for entity types with this validity concept, you need to assign the new change request to an
edition.
The corresponding change request type must reference an edition type.
With this validity concept, the edition field is included in the database tables.
No Edition
When you create a change request (to process entities) for entity types with this validity concept, you do not assign the new change request to an
edition unless you want to create edition-dependent hierarchies in the change request. The corresponding change request type does not have to
reference an edition type in this case.
With this validity concept, the edition field is not included in the database tables.
You use storage/use type to specify whether and how master data can be changed in Master Data Governance . The storage and use type also
indicates which database tables are generated by the system:
1 - Changeable via Change Request; Generated Database Tables
The master data of this storage and use type can be changed in Master Data Governance with a change request. The system generates all
necessary database tables: check and text tables as well as additional tables, for example, for attachments and sets.
The common key fields of these tables are:
The entity type itself
The edition – if you previously specified in the data model that the validity of master data changes is restricted to editions
The entity types that are assigned to the entity type through leading relationships
Furthermore, all tables contain a checkbox that indicates whether the master data record is active. If the entity is stored in the MDG active area,
this checkbox separates data in the staging from active data. If the entity is stored in a re-use area, this checkbox is used to mark a copy of the
data from the active area as a snapshot at the time when the change request was created. This snapshot is used during activation of the data to
detect conflicting changes that were done directly to the active area.
The settings you make for the entity type (such as language dependency) result in additional key fields in the text table and the tables for
attachments and sets.
The non-key fields contained in the text table are the entity texts. The non-key fields contained in the check table are the attributes of the entity
type. The attachment and set tables contain predefined non-key fields. Furthermore, all database tables contain a checkbox that indicates the
deletion of the master data record. For entities that are edition-based, this checkbox indicates the end of validity in time. For entities that are
stored in a re-use active area, this checkbox is considered during activation to check if data needs to be deleted. The check table also contains
attributes that record which user created or changed the data records and when this was done.
2 - Changeable w/o Change Request; Generated Check/Text Tables
The master data of this storage and use type can be changed in Master Data Governance without a change request. The system generates only
the check and text tables with the entity type as well as with the entity types assigned to the entity type through leading relationships as fixed key
fields.
The non-key fields contained in the text table are the entity texts. The check table does not contain non-key fields.
Note
Entities of the entity type that you define as the root node cannot be used as lower-level entities in the hierarchy. No relationships with relationship
type Leading can be defined for the entity type itself.
You can also specify in the data model whether the system is to restrict the validity of the hierarchy for an entity type to editions.
The system automatically generates the database tables needed to store the hierarchies. They contain the following key fields:
The edition – if you previously specified in the data model that the validity of the hierarchy for this entity type is restricted to editions
A checkbox that indicates whether the master data record is active
The higher-level entity type
The higher-level entity
The lower-level entity type
The lower-level entity
The hierarchy version (if the hierarchy is version-dependent)
The hierarchy name (that is, the entity of the entity type you defined for the root node) if the hierarchy is not cross-name
The table also contains a checkbox (as a non-key field) that indicates whether the respective master data record has been deleted, as well as a
sequence number. This number specifies the sequence of the respective lower-level entities.
To define the technical properties of an entity type or the texts for field labels and input help on the user interface for Master Data Governance , you can
assign an existing data element to the entity types with storage and use type 1 . You must assign a data element to entity types with storage and use
types 2 and 3 . This assignment is not permitted for entity types with storage and use type 4 .
Note
If no data element is assigned to an entity type, you must use this entity type as a To-entity type in at least one relationship with the type Leading
or Qualifying .
By assigning the type of key assignment, you specify for new entities created for an entity type whether the processors are to specify the key or
whether this is to be assigned internally by the system. You can also define whether processors are permitted to later change these keys.
Note
If you select a setting other than Key Cannot Be Changed; No Internal Key Assignment as the type of key assignment, the generated database
tables change as follows:
Check table
The table key contains a technical field instead of the entity type and its higher-level entity types. The entity type and its higher-level entity
types are included in the attribute area of the database table.
Hierarchy table
The hierarchy table does not change.
Other tables
The key for the tables contains a technical field instead of the entity type and its higher-level entity types.
The system generates a mapping table. The database table key contains a technical field for the mapping table. The attribute area contains
the entity type and its higher-level entity types. If you select the Key Can Be Changed; Internal Key Assignment Possible setting as the type
of key assignment, an additional attribute field to store the temporary key is added to the mapping table.
If the entity type is used as a From-entity type in relationships (see the “Relationships” section), the technical field replaces the entity type
and its higher-level entity types in the corresponding tables.
You also need to assign a number range object in this data model that the system can use to derive the required temporary keys when keys are
assigned internally (before the entity is activated).
If you want to define texts for an entity type, you can specify the length of the short, medium, and long texts and you can specify whether these texts
are to be stored as language-dependent in the database tables.
You can enter a more detailed description of the objects in the data model (entity type, attribute, or relationship). For entity types without data
elements, the system also uses this description for display in master data maintenance.
For entity types with storage and use type 3 whose data elements reference a check table that, in turn, does not reference a text table, you can specify
texts for the source field (short text, medium text, and long text). The system uses the text that can be stored in this check table field as the
descriptive text of the entity type’s attributes (for example, when formatting the input help).
You can specify whether deletion of entity types by means of change requests is permitted.
Note
Whether you use a relationship with the relationship type Referencing to define attributes or whether you define these directly (where possible)
depends on the settings configured in the data model and on the use type of the attributes. For example, if an attribute is a value to which a unit or
currency is to be assigned, you must define this directly. In contrast, if an entity type with storage and use type 3 that you can use for attribute
definition already exists, you should define a referencing relationship.
Which relationship types are permitted depends on the storage and use types of the entity types:
Example
For an example of the database tables the system generates for entity types with different properties defined in the data model, see Example: Generated
Database Tables.
MANDT S_MANDT
ID S_CUSTOMER
NAME S_CUSTNAME
FORM S_FORM
STREET S_STREET
POSTBOX S_POSTBOX
POSTCODE POSTCODE
CITY CITY
COUNTRY S_COUNTRY
REGION S_REGION
TELEPHONE S_PHONENO
CUSTTYPE S_CUSTTYPE
DISCOUNT S_DISCOUNT
LANGU SPRAS
EMAIL S_EMAIL
WEBUSER S_WEBNAME
MANDANT S_MANDT
BUSPARTNUM S_BUSPANUM
CONTACT S_CONTACT
CONTPHONO S_CPHONENO
BUSPATYP S_BUSPATYP
MANDT S_MANDT
AGENCYNUM S_AGNCYNUM
NAME S_AGNCYNAM
STREET S_STREET
POSTBOX S_POSTBOX
POSTCODE POSTCODE
CITY CITY
COUNTRY S_COUNTRY
REGION S_REGION
TELEPHONE S_PHONENO
URL S_URL
LANGU SPRAS
CURRENCY S_CURR_AG
Data Modeling
In this process, you create entity types for SBUSPART, SCUSTOM, and STRAVELAG, their attributes, and the relationships between the entity types.
1. Create Data Model
Define the data model in Customizing for Master Data Governance under General Settings Data Modeling Edit Data Model .
Select the Data Models view, choose New Entries , and enter a new data model called YZ with the description Airline Business Partner .
2. Create Entity Types
Select the Entity Types view, choose New Entries , and make the following entries for the entity type ZSBUSPART :
Storage/Use Type Changeable via Change Request; Generated Type-1 Entity Type
Database Tables
Data Element S_BUSPANUM Defines the key of the entity type and the field labels
Key Assignment Key Cannot Be Changed; No Internal Key User needs to provide the key when creating new
Assignment entities
Leave all other fields of the entity type blank, which is the default.
Create a new entry for the type-4 entity type ZSCUSTOM
Storage/Use Type Changeable via Other Entity Type; Generated Type-4 Entity Type
Database Tables
Data Element <BLANK> Left blank for ZSCUSTOM as the key will be derived
from the relationship to the leading entity type
ZSBUSPART (see below)
Key Assignment Key Cannot Be Changed; No Internal Key User needs to provide the key when creating new
Assignment entities
Storage/Use Type Changeable via Other Entity Type; Generated Type-4 entity type
Database Tables
Data Element <BLANK> Left blank for ZSTRAVLAG as the key will be derived
from the relationship to the leading entity type
ZSBUSPART (see below).
Key Assignment Key Cannot Be Changed; No Internal Key User needs to provide the key when creating new
Assignment entities
Note
If you save your data at this point, the check log shows various errors, which you can ignore at this time.
Enter the attributes of the entity types ZSBUSPART , ZSTRAVLAG , and ZSCUSTOM . Select the entity type you want to process and navigate to
the Attributes view.
Choose New Entries and enter the following attributes and data elements for entity type ZSBUSPART :
BUSPATYP S_BUSPATYP
CONTACT S_CONTACT
CONTPHONO S_CPHONENO
Leave all other fields of the attributes blank, which is the default.
Note
Data in MDG is always client dependent. Therefore, the MANDT field is not modeled as an attribute.
Choose New Entries and enter the following attributes and data elements for the entity type ZSTRAVLAG :
CITY CITY
COUNTRY S_COUNTRY
CURRENCY S_CURR_AG
NAME S_AGNCYNAM
POSTBOX S_POSTBOX
POSTCODE POSTCODE
REGION S_REGION
STREET S_STREET
TELEPHONE S_PHONENO
URL S_URL
ZLANGU SPRAST
MDG uses the value table of the domain as defined in the data element of the attribute. This lets you perform checks and call up input help in the
user interface.
In transaction SE11, you can see that the attribute LANGU with the data element SPRAS is used in the data dictionary (DDIC) table
STRAVELAG. This cannot be reflected in the MDG data model. The attribute name LANGU cannot be used. Therefore, the name ZLANGU is
used. The data element SPRAS cannot be used as well, but it can be replaced by SPRAST. The attribute names MANDT, SID, TXTLG, TXTMI,
and TXTSH cannot be used as well.
Choose New Entries and enter the following attributes and data elements for the entity type ZSCUSTOM :
SCITY CITY
SCOUNTRY S_COUNTRY
SCUSTTYPE S_CUSTTYPE
SDISCOUNT S_DISCOUNT
SEMAIL S_EMAIL
SFORM S_FORM
SLANGU SPRAST
SPOSTBOX S_POSTBOX
SREGION S_REGION
SSTREET S_STREET
STELEPHON S_PHONENO
SWEBUSER S_WEBNAME
Attributes such as CITY can only be assigned once to a type-1 entity type. Therefore, you have to rename the attributes of entity type
ZSCUSTOM. This is also true for indirect assignments that involve leading type-4 entity types. When renaming, insert an S as the prefix.
3. Create Relationships
Select the Relationships view, choose New Entries , and enter the following relationship details:
Leave all other fields of the relationships blank, which is the default.
4. Save and Activate the Data Model
First, you need to save the data model. This will automatically perform a check. For the data in this example data the warning messages, which are
related to change documents. Now activate the data model.
You can transfer data models for Master Data Governance from your test system to your target system by means of transport requests.
Process
To transport an active version of a data model to the target system, proceed as follows:
1. In Customizing for Master Data Governance , choose General Settings Data Modeling and then the Edit Data Model activity.
2. To activate the data model again, select it and choose ( Activate ).
A dialog box appears.
3. Specify the transport request that you want to use to transport the active data model and save your entries.
The active data model is transported to the target system. Once in the target system, the data model is activated automatically. This can have the
following effects on the generated database tables in which the entities are saved:
The generated database tables are generated again.
The generated database tables are adjusted.
If the entity type was removed from the current data model, the generated database tables are deleted.
Note
If a deletion of the active data model is transported, the generated database tables are not deleted – with the exception of the hierarchy tables.
To transport an inactive version of a data model to the target system, proceed as follows:
1. In Customizing for Master Data Governance , choose General Settings Data Modeling and then the Edit Data Model activity.
2. Choose Table View Transport and specify the transport request with which you want to transport the inactive data model.
3. Select the data model and choose Process Transport Include in Request .
In the dialog box that appears, specify that all lower-level entries are to be transported and save your entries.
Note
You can activate the transported inactive data model in the target system.
To do this, in Customizing for Master Data Governance in the target system, choose General Settings Data Modeling and then the Edit Data
Model activity.
Select the data model and choose ( Activate ).
You can use this Web Dynpro application to define and activate a data model to map master data in the system, along with its properties and relationships.
The system uses this data model to generate database tables in which the master data can be stored.
You can assign a reuse active area to a data model or to individual entity types of a data model. Then the inactive portion of master data for this data model is
stored in the generated tables and the active portion is stored in the database tables specified in the reuse active area.
Note
You can also assign a reuse active area on the level of an entity type.
Prerequisites
You have created any customer-specific data elements you want to use for the entity types in the data model or for their attributes.
If you use entity types with internal key assignments, you can define prefixes for internal key assignment. You do this in Customizing for Master Data
Governance under General Settings Define Prefixes for Internal Key Assignment .
Features
Attributes Tab
Here you define the attributes of each entity type in the data model. Attributes are mapped as non-key fields in the generated database tables of the entity
type. You also need to assign an existing data element to each attribute. The data element determines the technical properties of the attribute as well as the
field labels and the input help texts on the user interface. Attributes can be defined as required entry fields or as optional fields. You use a currency-supplying
attribute or a unit-supplying attribute to assign a currency or unit of measure to the attribute.
Example
In the PFLI entity type of the SF data model, you model flight scheduling data. For example, you can specify the cities CITYFROM and CITYTO. The
GEOCITY entity type has a storage and use type of 3. It acts as a check table for valid cities. If you want to ensure only valid cities are selectable, you
create a foreign key relationships between CITYFROM and GEOCITY, and between CITYTO and GEOCITY.
To maintain the foreign key attributes for PFLI, you can open the Incoming Relationships tab, select the relationships CITYFROM and CITYTO, and
choose the foreign keys button. You want to define foreign key relationships so that the fields PARTNER_1 and PARTNER_2 at entity type BPREL
contain only the values of the field BP_HEADER at entity type BP_HEADER.
Hierarchies Tab
If you want it to be possible to set up a hierarchy for the entity type, you must specify at least the root node (hierarchy name) for the hierarchy here. To do
this, choose one of the available entity types and assign Hierarchy Name as the usage type. You also can specify all entity types that are to be allowed in
1.1.2.2.6.2 UI Modeling
The purpose of UI modeling is to define and customize user interfaces with which users process master data.
You use the Manage UI Configurations (USMD_UI_CONFIGURATION) Web Dynpro application to manage user interfaces in SAP Master Data Governance.
Each table row represents a separate user interface and consists of the user interface application and its configuration. You can create a new user interface
configuration by copying an existing one. You can also edit the configurations for existing user interfaces. Each link you click opens the relevant screen in the
Floorplan Manager (FPM).
Note
You can only use this function if Business Function Master Data Governance, Generic Functions 7.0 Feature Pack (MDG_FOUNDATION_5) is active.
The previous version of this application only allows management of UI configurations for specific types of single-object processing UIs.
If the relevant business function is not active, you can edit the relevant technical elements using transaction SE80. For more information, see the links in
this document under Activities Working with a UI Configuration . The documents listed cover editing using transaction SE80 as well as editing
using this Web Dynpro application.
The most common types of user interface that you can manage are as follows:
Single-Object Processing
Multiple-Record Processing
Search
There are many options to change a user interface including customizing, enhancement, context-based adaptation (CBA), and personalization. Some options
affect all clients of a system. Other options are client specific. It is even possible to restrict changes to only one user. For more information, see Floorplan
Manager for Web Dynpro ABAP.
Prerequisites
An active data model exists.
You have basic knowledge of how to use the FPM and of the configuration of applications and components with Web Dynpro ABAP.
To create a new user interface by copying an existing one, the following criteria must be met:
You can use an active MDG data model with at least one entity type with storage and use type 1.
You have assigned a business object type code (OTC) to this entity type.
Before starting the configuration you need to carry out the following steps to ensure the default data model as the data model for which the UI is
configured in the following way:
1. Run transaction SPERS_MAINT.
2. Select Edit Objects
3. From the displayed list, choose SAP Master Data Governance - R_FMDM_MODEL .
4. In the pop-up, set the value of the field Standard Data Model to the model that you want to use for UI processing.
5. Confirm and save.
Activities
Search
Concept: Configuration of the Generic Search
Instructions: Configuring the Generic Search for a Particular Business Object Type
In a complete UI configuration for single object processing, several components work together and need to be configured accordingly as shown in the figure
MDG UI Configuration for Single-Object Processing below.
Two of these components are the MDG Web Dynpro application USMD_OVP_GEN and MDGF_OVP_GEN with their application configurations. Each
application configuration is specific for an object type and this object type is defined with the parameter USMD_OTC.
This Web Dynpro application implements an adaptable overview page (OVP) component of the Floorplan Manager (FPM): FPM_ADAPTABLE_OVP. This OVP
component is a wrapper that contains an FPM overview page component (FPM_OVP_COMPONENT). The configuration of the adaptable OVP references the
adaptation scheme for creating context based adaptations (CBA) of the included OVP component and of its sub-components.
For more information, see Generic Context-Based Adaptation Scheme.
The configuration of the OVP contains at least one page. At least one section of the page contains user interface building blocks (UIBBs). Most UIBBs enable
the processing of business object data on the UI. The UIBBs are configured for all entity types that belong to the business object. Usually, there’s more than
one entity type.
The MDG framework provides the following UIBBs:
The change request UIBB (CRUIBB) displaying the change request properties, such as description, due date, notes, and attachments
The validity UIBB displaying the time validity for edition-based entities
These UIBBs are no explicit parts of the configuration of the Web Dynpro application, but are added at runtime by the MDG communicator, which has overall
responsibility for the change request process. The MDG communicator controls the availability of change request actions, which are represented as buttons in
the global toolbar. The settings that the MDG communicator uses are stored in its component configuration.
Note
You can also include the CRUIBB explicitly in the OVP configuration.
If you want to have an object-specific search, the OVP can include an initial screen with an FPM search UIBB to enter search criteria and a list UIBB to
display search results.
genIL Components
When you activate an MDG data model that is in the customer namespace, the system creates the following genIL components as local objects. The names
of the components are as follows:
ZSP_<ID of MDG data model>
This component is responsible for all user interfaces related to the single object processing of the entity types from your custom data model. If your data
model ID, for example, is ZT, the genIL component is named ZSP_ZT.
ZMP<ID of MDG data model>
This component is responsible for all user interfaces related to the multi-record processing of the entity types from your custom data model. If your data
model ID, for example, is ZT, the genIL component is named ZMP_ZT.
ZHP<ID of MDG data model>
This component is responsible for all user interfaces related to the hierarchy processing of the entity types from your custom data model. If your data
model ID, for example, is ZT, the genIL component is named ZHP_ZT.
You can check the successful creation of the genIL components by calling transaction GENIL_MODEL_BROWSER.
Note
If you work with a data model that is in the SAP namespace, you have to create the related genIL components and a transaction handler class manually.
For more information, see Creating genIL Components and Transaction Handler Manually.
This document describes how to configure the generic MDG single-object processing user interface that is provided by the MDG Web Dynpro application
USMD_OVP_GEN.
Prerequisites
You have completed the following:
1. You can use an active MDG data model with at least one entity type with storage and use type 1. You have assigned a business object type code (OTC)
Process
Note
Instead of using transaction SE80 for the processes described below, you can also use the Customizing activity Manage UI Configurations under
General Settings UI Modeling for the deep-copy of application configurations and the creation of MDG communicator settings. For more information,
see Managing of UI Configurations.
Recommendation
Replace <GEN> in the configuration IDs with the combination of an MDG data model and the main entity type using meaningful names. For example,
Z_USMD_OVP_SF_CARR for the application configuration and Z_USMD_SF_CARR_OVP for the OVP configuration.
5. Open the new application configuration and change the parameter USMD_OTC to the object type code of the business object that you want to process
with this configuration as mentioned in step 1 of the Prerequisites section of this document.
Create MDG Communicator Settings
For the integration of the new application configuration with the MDG framework the system requires the configuration of the MDG communicator.
Note
In this configuration activity you will create MDG communicator settings from a template that contains dummy entries for the UIBB of the main entity and
the page ID of the OVP. After you have added this UIBB to the OVP component, remember to replace these dummy entries with the actual IDs that you
have chosen.
Note
The two configuration IDs need to match exactly. Otherwise, the application is unable to determine the settings for the MDG communicator.
5. The settings of the MDG communicator must be completed in a later step, after you have configured the UIBB that displays the main entity on the OVP.
Only then you know which values need to be entered here. To complete this step, open the copied configuration of the MDG communicator. In the table
Configuration Context , navigate to Context Settings crWires (MAIN) and enter the following values: :
Page Id
ID of the page in the OVP that contains the UIBB with the main entity
Source Component
The UIBB that contains the main entity
Source Config Name
The UIBB that contains the main entity
Note
If you make a mistake in the configuration of the MDG communicator, the integration with the MDG framework will not work.
Possible symptoms at runtime are:
There is no change request UIBB displayed after choosing Edit in one of the UIBBs
No change request ID is generated
There are no change request action buttons displayed in the main toolbar
This document describes how to configure a Floorplan Manager (FPM) form for a user interface building block (UIBB) to process data with the MDG Web
Dynpro application USMD_OVP_GEN. You can use this configuration description for implementations of the following form UIBBs:
FPM form GUIBB GL2: FPM_FORM_UIBB_GL2
FPM form GUIBB: FPM_FORM_UIBB
The FPM form GUIBB has been replaced by the new FPM form GUIBB GL2.
MDG delivers the feeder class CL_MDG_BS_GUIBB_FORM which you can use in such a configuration. The feeder class retrieves the attributes of the entity
type for which the form is configured. With this you can configure the layout of the form. During runtime the feeder class reads, writes, and checks the data of
the entity that is currently being processed.
Note
An FPM form GUIBB GL2 is included in the example configuration USMD_SF_OVP_CARR. This example configuration is located in the generic MDG Web
Dynpro application USMD_OVP_GEN in package MDG_FND_SAMPLE_IMPLEMENTATIONS.
For information on assigning UI fields for each entity type, see the Generic Interaction Layer (genIL) section in Building Blocks for the UI Framework.
Prerequisites
You have completed the following:
1. You can use an active MDG data model with at least one entity type with storage and use type 1. You have assigned a business object type code (OTC)
to this entity type.
2. You have generated the required structures in the Customizing activity Generate Data Model-Specific Structures under General Settings Data
Modeling .
3. You have set the standard data model in your user profile.
4. The data model is in the customer namespace. If the data model is not in the customer namespace follow the description in Creating genIL Components
and Transaction Handler Manually.
5. You can use a configuration of the generic MDG Web Dynpro application USMD_OVP_GEN that includes an FPM overview page (OVP)
FPM_OVP_COMPONENT to which you can add the UIBB. You can open and edit the configuration of this page in the FPM editor. Alternatively, you can
create Customizing for this configuration.
For more information, see Creating User Interfaces for Single Object Processing.
Process
Configuration of a FPM Form GUIBB
Follow these steps to create a new configuration of a FPM form GUIBB:
1. Create a new configuration for the form component FPM_FORM_UIBB_GL2 by copying the template FPM_FORM_UIBB_GL2_TEMPLATE from
package APB_FPM_GUIBB.
Recommendation
For the configuration ID, follow a naming convention that includes the MDG data model, the entity type and FORM. For example,
Z_MDG_SF_CARR_FORM.
2. In the configuration of the component, enter the following values for the parameters of the feeder class CL_MDG_BS_GUIBB_FORM:
Component
Enter ZSP<data_model>. This is the genIL component for single-object processing that was created for your MDG data model, with
<data_model> being the ID of your MDG data model.
Object Name
Enter an entity type for which you want the form to be configured.
Editable
Select the Edit checkbox.
3. Add the fields you want to process with the form and adapt the layout as required.
Caution
The highlight changes function uses the tooltip to inform the user about the previous value. This is not possible if a fixed value for the tooltip is either
entered in the UI configuration or the UI customizing. In this case this fixed value is displayed.
Note
If this is the first form and it displays the main entity, do not forget to update the MDG Communicator settings. For more information, see Creating
User Interfaces for Single Object Processing.
If this is a form in a master/detail layout that should display the details of a selected entity in a list UIBB, use the following parameters for the wire:
Component and Config ID: Enter the form that you have added.
Source Component and Source Config Name: Enter the list component in which you select the entity to be displayed in the form.
Port Type: Lead Selection
Connector Class: Enter the class CL_FPM_CONNECTOR_BOL_IDENTITY.
3. In the toolbar schema of the FPM OVP, add the following button for the form UIBB:
This document describes how to configure a Floorplan Manager (FPM) list for a generic user interface building block (GUIBB) using ABAP table services
(ATS) for processing data with the MDG Web Dynpro application USMD_OVP_GEN.
You can also use this document when configuring the FPM list GUIBB. However, this FPM list GUIBB has been replaced by the FPM list ATS GUIBB.
In these lists you can display entities of storage and use type 4 that have a 1:many-relationship with a leading entity, which is displayed in a form UIBB. For
example, there is a form UIBB on a page that displays a PFLI entity and all related FLIGHT entities are displayed in a list UIBB. MDG delivers the feeder
class CL_MDG_BS_GUIBB_LIST to be used in such a configuration. The feeder class retrieves the attributes of the entity type for which the list is configured.
Now you can configure the layout of the table. During runtime the feeder class reads, writes, and checks the data of the entities that are being processed.
Note
An FPM list ATS GUIBB is included in the example configuration USMD_SF_OVP_PFLI. The example configuration can be found in the generic MDG
Web Dynpro application USMD_OVP_GEN in package MDG_FND_SAMPLE_IMPLEMENTATIONS.
Prerequisites
You have completed the following:
1. You can use an active MDG data model with at least one entity type with storage and use type 1. You have assigned a business object type code (OTC)
to this entity type.
2. You have generated the required structures in the Customizing activity Generate Data Model-Specific Structures under General Settings Data
Modeling .
3. You have set the standard data model in your user profile.
4. The data model is in the customer namespace. If the data model is not in the customer namespace follow the description in Creating genIL Components
and Transaction Handler Manually.
5. You can use a configuration of the generic MDG Web Dynpro application USMD_OVP_GEN that includes an FPM overview page (OVP)
FPM_OVP_COMPONENT to which you can add the UIBB. You can open and edit the configuration of this page in the FPM editor. Alternatively, you can
create Customizing for this configuration.
For more information, see Creating User Interfaces for Single Object Processing.
Process
Configuration of a FPM List ATS GUIBB
To create a new configuration of a FPM List ATS GUIBB perform the following steps:
1. Create a new configuration for the list component FPM_LIST_UIBB_ATS by copying the template FPM_LIST_UIBB_ATS_TEMPLATE from package
APB_FPM_GUIBB.
Recommendation
For the configuration ID, follow a naming convention that includes the MDG data model, the entity type and LIST. For example,
Z_MDG_SF_FLIGHT_LIST.
2. In the configuration of the component, enter the following values for the parameters of the feeder class CL_MDG_BS_GUIBB_LIST:
Component
Enter ZSP<data_model>. This is the genIL component for single-object processing that was created for your MDG data model, with
<data_model> being the ID of your MDG data model.
Object Name
Enter an entity type for which you want the list to be configured.
Editable
Select the Edit checkbox.
3. Add the fields you want to process with the list and adapt the layout as required.
4. If you want to use features of the Highlight Changes function you need to adjust the UIBB configuration. You can add a column for the element
USMD_CHANGE_INDICATOR to indicate whether a row was changed, created or deleted. You can also select the element
Caution
The highlight changes function uses the tooltip to inform the user about the previous value. This is not possible if a fixed value for the tooltip is either
entered in the UI configuration or the UI customizing. In this case this fixed value is displayed.
This document describes how to create a configuration for an FPM List ATS GUIBB for processing language-dependent texts with the MDG Web Dynpro
application USMD_OVP_GEN.
You can create a list with one row for each language including columns for descriptions with short text, medium text, and long text to enter a description in the
respective language.
MDG delivers the feeder class CL_MDG_BS_GUIBB_LIST to be used in such a configuration. The feeder class gets the attributes of the entity type for which
the list is configured. This enables you to configure the layout of the table. During runtime it reads, writes, and checks the data of the entities that are currently
being processed.
Prerequisites
You have completed the following:
1. You can use an active MDG data model with at least one entity type with storage and use type 1. You have assigned a business object type code (OTC)
to this entity type.
2. There is an entity type with indicator Language-Dependent Texts selected and the length of at least one description type (short, medium, long) is set to
a value greater than 0.
3. You have generated the required structures in the Customizing activity Generate Data Model-Specific Structures under General Settings Data
Modeling .
4. You have set the standard data model in your user profile.
5. The data model is in the customer namespace. If the data model is not in the customer namespace follow the description in Creating genIL Components
and Transaction Handler Manually.
6. You can use a configuration of the generic MDG Web Dynpro application USMD_OVP_GEN that includes an FPM overview page (OVP)
FPM_OVP_COMPONENT to which you can add the UIBB. You can open and edit the configuration of this page in the FPM editor. Alternatively, you can
create Customizing for this configuration.
For more information, see Creating User Interfaces for Single Object Processing.
Process
Configuration of a FPM List ATS GUIBB
To create a new configuration of an FPM List ATS GUIBB perform the following steps:
1. Create a new configuration for the list component FPM_LIST_UIBB_ATS by copying the template FPM_LIST_UIBB_ATS_TEMPLATE from package
APB_FPM_GUIBB.
Recommendation
For the configuration ID, follow a naming convention that includes the MDG data model, the entity type and TEXT. For example,
Z_MDG_SF_PFLI_TEXT.
2. In the configuration of the component, enter the following values for the parameters of the feeder class CL_MDG_BS_GUIBB_LIST:
Component
Enter ZSP<data_model>. This is the genIL component for single-object processing that was created for your MDG data model, with
<data_model> being the ID of your MDG data model.
Object Name:
Select the entry DTxT<entity type>, for example DTxTPFLI if you want to configure the list for the texts of entity type PFLI.
Editable
Caution
The highlight changes function uses the tooltip to inform the user about the previous value. This is not possible if a fixed value for the tooltip is either
entered in the UI configuration or the UI customizing. In this case this fixed value is displayed.
This document describes how to provide a UI for handling attachments of entities with the MDG Web Dynpro application USMD_OVP_GEN.
Entity types with storage and use type 1 can be configured in the MDG data model to store attachments. If the indicator Attachments is selected, you can
store attachments (for example, Microsoft Word or Adobe PDF files) to entities that belong to this entity type. The system automatically provides a data store
for this. The existing attachments can be displayed on the UI in a list and new attachments can be created with a dialog box.
Attachments are included in the example configuration USMD_SF_OVP_CARR of the generic MDG Web Dynpro application USMD_OVP_GEN in package
MDG_FND_SAMPLE_IMPLEMENTATIONS.
Prerequisites
You have completed the following:
1. You can use an active MDG data model with at least one entity type with storage and use type 1. You have assigned a business object type code (OTC)
to this entity type.
2. There is an entity type with the indicator Attachments selected.
3. You have generated the required structures in the Customizing activity Generate Data Model-Specific Structures under General Settings Data
Modeling .
4. You have set the standard data model in your user profile.
5. The data model is in the customer namespace. If the data model is not in the customer namespace follow the description in Creating genIL Components
and Transaction Handler Manually.
6. You can use a configuration of the generic MDG Web Dynpro application USMD_OVP_GEN that includes an FPM overview page (OVP)
FPM_OVP_COMPONENT to which you can add the UIBB. You can open and edit the configuration of this page in the FPM editor. Alternatively, you can
create Customizing for this configuration.
For more information, see Creating User Interfaces for Single Object Processing.
Process
Attachment List
The following numbered list describes how to add the attachment list to the UI.
1. Create a new configuration for the list component FPM_LIST_UIBB_ATS by copying the template USMD_SF_CARR_ATTACHMENT_LIST from package
MDG_FND_SAMPLE_IMPLEMENTATIONS.
2. In the configuration of the list component enter the following values for the parameters of the feeder class CL_USMD_ATTACHMENT_LIST:
Component
Enter ZSP<data_model>. This is the genIL component for single-object processing that was created for your MDG data model, with
<data_model> being the ID of your MDG data model.
Object Name:
Enter Atth Entity Type in this field. Replace Entity Type with the name of the entity type for which you want to configure attachments. Atth
stands for attachment header.
Editable
Select the Edit checkbox.
Context-Based Adaptations
A context-based adaptation (CBA) is a Floorplan Manager (FPM) concept that allows you to change the UI in a flexible way based upon values such as
application parameters and user input. A CBA consists of an adaptation scheme made up of one or more adaptation dimensions.
The generic MDG Web Dynpro application USMD_OVP_GEN implements an FPM-adaptable overview page (OVP) component (FPM_ADAPTABLE_OVP) so
that the provided adaptation scheme, USMD_GEN, can be used to create context-based adaptations of the included OVP component and of its sub-
components.
The adaptation scheme includes the following adaptation dimensions:
USMD_OTC: Usable for adaptations based on the current business object type code
More Information
For more information about adapting your FPM applications, see Floorplan Manager for Web Dynpro ABAP.
User Interface
The UIs for MDG are based on ABAP Web Dynpro. They are built with Floor Plan Manager (FPM) using the Business Object Layer (BOL)/generic interaction
layer (genIL) technology. This technology offers the following characteristics:
Loose coupling of the UIs to the MDG-specific processes
Flexible UI creation where the fields to be displayed are divided into small user interface building blocks (UIBBs). UIBBs support lists and forms as well
as pop-ups, search input, and search results.
The ability to create object-specific UIs to create a consistent layout and a similar look and feel between the MDG UIs and the SAP GUI transactions
Reuse of the tables, structures, and fields (including their names) generated by MDG during UI creation
Generic Interaction Layer (genIL)
GenIL components are required for the MDG UIs. A genIL component consists of a genIL data model and one or more genIL implementation classes. SAP
provides the genIL components for standard MDG data models. For custom MDG data models that are in the customer namespace, the system creates genIL
components with the implementation class CL_USMD_GENERIC_GENIL_ADAPTER automatically.
When you activate an MDG data model that is in the customer namespace, the system creates two genIL components as local objects. The names of the
components are as follows:
ZSP_<ID of MDG data model>
This component is responsible for all user interfaces related to the single object processing of the entity types from your custom data model. If your data
model ID, for example, is ZT, the genIL component is named ZSP_ZT.
ZMP<ID of MDG data model>
This component is responsible for all user interfaces related to the multi-record processing of the entity types from your custom data model. If your data
model ID, for example, is ZT, the genIL component is named ZMP_ZT.
You can check the successful creation of the genIL components by calling transaction GENIL_MODEL_BROWSER.
Note
If you work with a data model that is in the SAP namespace, you have to create the related genIL components and a transaction handler class manually.
For more information, see Creating genIL Components and Transaction Handler Manually.
To view the genIL component, call transaction GENIL_MODEL_BROWSER in the SAP backend.
A genIL data model consists of objects and relations with the following characteristics:
Objects consist of attributes. Each attribute reflects a usable field on the UI.
Relations connect one object to another. They also define the cardinality of objects in a relationship. Relationships are reflected on the UI by the wires
(connections) from one UIBB to another. The UIBB hierarchy in the OVP must be consistent with the genIL object hierarchy as defined by the
relationships.
The genIL data models in MDG are dynamic. Any manual change to a genIL data model is strictly forbidden. The genIL data model is generated by its
implementation class according to the runtime information of the MDG data model with the following characteristics:
Each entity type of storage and use type 1 of the data model is transferred to a genIL root object.
Each entity type of storage and use type 4 of the data model is transferred to a genIL dependent object.
Relations are determined and transferred into genIL relations.
For example, between entity types of storage and use type 1 and entity type of storage and use type 1 or between entity type of storage and use type 1
and entity type of storage and use type 4.
Each entity type of storage and use type 1 retrieves additional genIL queries and query result objects to support the search.
If an entity type of storage and use type 1 supports multi-lingual texts, a dependent object is created in genIL to enable the text processing within a
table.
If an entity type of storage and use type 1 supports attachments, two dependent objects are created in genIL to enable attachment processing within a
table and processing of related pop-ups.
The generated structures belonging to an entity are used for the genIL key and attribute structures. This ensures that all fields of the MDG data model
are available for the creation of the related user interfaces. Attribute structures are used by FPM to build the field catalog that is available during UI
creation.
Enhancements of the MDG data model are reflected immediately after activation of the data model in the genIL component. Manual changes or enhancements
of the MDG genIL components are strictly forbidden. If enhancements in genIL are required, all changes have to be implemented in a related genIL
implementation class. It is mandatory that this class inherits data from the SAP class CL_USMD_GENERIC_GENIL_ADAPTER.
This document describes how to extend a UI for single-object processing using the MDG Web Dynpro application USMD_OVP_GEN with UI components to
display and process hierarchy assignments.
Prerequisites
You have completed the following:
1. You can use an active MDG data model with at least one entity type with storage and use type 1. You have assigned a business object type code (OTC)
to this entity type.
2. This MDG data model contains a hierarchy type that defines entities of this type as possible nodes.
For more information, see the Data Modeling section in Configuring Hierarchy Types
3. The data model is in the customer namespace. If the data model is not in the customer namespace follow the description in Creating genIL Components
and Transaction Handler Manually.
4. You can use a configuration of the generic MDG Web Dynpro application USMD_OVP_GEN that includes an FPM overview page (OVP)
FPM_OVP_COMPONENT to which you can add the UIBB. You can open and edit the configuration of this page in the FPM editor. Alternatively, you can
create Customizing for this configuration.
For more information, see Creating User Interfaces for Single Object Processing.
Process
Hierarchy Assignment List
The following describes how to add the hierarchy assignment list to the UI.
1. Create a new configuration for the list component FPM_LIST_UIBB_ATS using the feeder class CL_USMD_HRY_ASSIGNMENTS.
2. In the configuration of the list component, enter the following values for the parameters of the feeder class:
Component
Enter ZHP<data_model>. This is the genIL component for hierarchy processing that was created for your MDG data model, with
<data_model> being the ID of your MDG data model.
Object Name
Enter Hras<Hierarchy Type>_<Entity Type> in this field. Replace <Hierarchy Type> with the hierarchy type for which you want the
assignments of the entities specified with <Entity Type> to be processed. Hras stands for hierarchy assignments.
Editable
Select the Edit checkbox.
Columns
For a default configuration, add the following fields as columns:
PARENT_ENTITY Parent Type Dropdown List Entity type of the parent node
USMD_HRYVERS Hierarchy Version Dropdown List Include this field for hierarchy types
that are version-dependent.
Furthermore, you can configure all hierarchy attributes, defined in the hierarchy type for this node type, as columns. Alternatively to adding the
hierarchy attributes as columns, you can also create an edit page for the hierarchy attributes. For more information, see the Using an Edit Page for
the Hierarchy Attributes section in this document
Caution
The highlight changes function uses the tooltip to inform the user about the previous value. This is not possible if a fixed value for the tooltip is
either entered in the UI configuration or in the UI Customizing. In this case, the fixed value is displayed.
Row Actions
Add the following row actions to the list:
If you want to use an edit page for the hierarchy attributes, add row actions to display the edit page.
FPM_CALL_DEFAULT_EDIT_PAGE ~Icon/Edit not available Opens the edit page in edit mode.
SHOW not available Details Opens the edit page in display mode.
Toolbar
Add the following buttons to the toolbar:
Next Hierarchy Changes not available Next Hierarchy Changes HRY_NEXT_CHANGE Only for edition-dependent
hierarchies: Opens a dialog
box displaying a list of
editions with hierarchy
changes later in the validity
period of the object.
3. Add the list component to the FPM OVP on which you want the hierarchy assignments to be displayed.
4. In the wiring of the page, create a wire for the hierarchy assignment list using the connector class CL_MDG_BS_CONNECTOR_BOL_REL and the following
parameters:
Source Component : FPM_FORM_UIBB_GL2 (example) and Source Config Name : USMD_SF_CARR_FORM (example)
Enter the component that displays the entity for which you want the assignments to be shown. This could be a form component on the page, for
example.
Port Type : Lead Selection and Port Identifier: Standard
Relation Name:
Hras<Entity Type>2<Hierarchy Type>Rel. Replace <Hierarchy Type> with the hierarchy type for which you want the assignments of
the entities specified with <Entity Type> to be processed. Hras stands for hierarchy assignments. For example, HrasCARR2CARRRel: Here,
the entity type has the same ID as the hierarchy type.
5. In the toolbar schema of the FPM OVP, add the following button for the hierarchy assignment list UIBB:
Now, you have configured a user interface that can be used to process hierarchy assignments.
In the following you find information on advanced configuration topics.
Using an Edit Page for the Hierarchy Attributes
If you want to use an edit page to process the hierarchy attributes of the assignment, proceed as follows:
1. Create a new configuration for the form component FPM_FORM_UIBB_GL2 using the feeder class CL_MDG_BS_GUIBB_FORM.
2. In the configuration of the form component, enter the following values for the parameters of the feeder class:
Component
Enter ZHP_<data_model>. This is the genIL component for hierarchy processing that was created for your MDG data model, with
<data_model> being the ID of your MDG data model.
Object Name
Enter Hrat<Hierarchy Type>_<Entity Type> in this field. Replace <Hierarchy Type> with the hierarchy type for which you want the
hierarchy attributes of the assigned entities specified with <Entity Type> to be processed. Hrat stands for hierarchy attributes.
Editable
Select the Edit checkbox.
Fields
Add the required hierarchy attributes to the layout of the form.
3. Add an edit page to the FPM OVP with which you want the hierarchy assignment to be processed.
4. Add the form component that you have created in step 1 to the edit page.
5. In the wiring of the page, create a wire for the form in the edit page using the connector class CL_MDG_BS_CONNECTOR_BOL_REL and the following
parameters:
Source Component : FPM_LIST_UIBB_ATS and Source Config Name : enter the configuration ID of the hierarchy assignment list.
Port Type : Lead Selection and Port Identifier: Standard
Relation Name:
Hras<Hierarchy Type>_<Entity Type>2HratRel.Replace<Hierarchy Type> with the hierarchy type and <Entity Type> with the
entity type for which you want to process hierarchy attributes. For example: HrasFSCHEDGRP_PFLIX2HratRel for hierarchy type FSCHEDGRP
and entity type PFLIX.
Restricting Entity Types for Usage as Parent Node or Previous Node
If you want to ensure that specific entity types cannot be used for the parent node or the previous node of a hierarchy assignment, proceed as follows:
1. Create a custom feeder class for the hierarchy assignment list by inheriting from the SAP defined class.
2. Redefine method DEFINE_INVALID_NODE_TYPES.
1. The method shall be used to fill class attributes MT_INVALID_PARENT_TYPES and/or MT_INVALID_PREVIOUS_TYPES with entity types that
must not be used as parent respectively previous nodes.
SAP and partners of SAP who develop data models in the SAP namespace have to create related genIL components manually using, for example, transaction
GENIL_MODEL_BROWSER. The genIL component name has to use the SAP namespace, too. Separate genIL components have to be created for single-object
processing, and multi-record processing, and hierarchy-processing. You also need a custom transaction handler that uses cl_mdg_bs_bol_transaction
as super class.
Process
Create Implementation Classes for genIL Components
You need to create specific implementation classes for your MDG data model that inherit from:
CL_USMD_GENERIC_GENIL_ADAPTER for single-object processing
CL_USMD_GEN_MC_GENIL_ADAPTER for multi-record processing
CL_USMD_HRY_GENIL for processing hierarchies in single-object processing UIs
The classes have to implement a custom constructor. The constructor has to define the MDG data model to be used before performing a call to the parent's
constructor.
1. Create a new class for the single-object processing genIL component using transaction SE24 or SE80.
Proposed name: ZCL_USMD_GENIL_ADAPTER<ID of MDG data model>
Proposed description: MDG genIL Adapter SOP for <data model>
Super Class: CL_USMD_GENERIC_GENIL_ADAPTER
2. Create a constructor.
Add the method CONSTRUCTOR with the parameters IV_MODE and IV_COMPONENT:
importing
!IV_MODE type CHAR1
!IV_COMPONENT_NAME type CRMT_COMPONENT_NAME optional .
Use the following code snippet for the method implementation:
"define the desired model
IF mv_defined_model IS INITIAL.
mv_defined_model = <YOUR MDG MODEL NAME>
ENDIF.
"call parent
super->constructor(
iv_mode = iv_mode
The data quality functions of MDG allow you to enrich and validate master data, as well as to prevent the creation of duplicates. The various search
capabilities are not only used to find master data that can be processed, but are also used for matching data to prevent the creation of duplicate information.
Correct and complete data can be achieved with automatic derivation of attributes and enrichment from external data sources.
In SAP Master Data Governance you can use the following search providers to search for master data:
Enterprise Search
Database Search
Business Address Services (BAS)-Based Search
Searching with Customer-Specific Search Providers
SAP HANA Search
Note
To configure SAP HANA Search see Configuring SAP HANA-Based Search for MDG and Configuring Drill-Down Search (Optional).
In SAP Master Data Governance you can use Enterprise Search to search for master data in the staging area and the active area.
Features
The standard system contains the following default search application and access class in Customizing for Master Data Governance, Central Governance
under SAP Customizing Implementation Guide Cross-Application Components Processes and Tools for Enterprise Applications Master Data
Governance, Central Governance General Settings Data Quality and Search Define Search Applications :
ES CL_SDQ_USMD_SEARCH_DATA_IMPL
The following additional search options are available for Enterprise Search:
Free text search
Fuzzy search
When you select the respective checkboxes, two additional fields appear on the Enterprise Search user interface. In the standard system these two
checkboxes are selected for search application ES.
Activities
Note
To use Enterprise Search for SAP Master Data Governance, step one and step two of the procedure must be executed only if you use customer-defined
objects. Step three and step four must always be executed.
Recommendation
On the detailed screen for the search object connector template, go to the Schedules tab page and enable real-time indexing.
4. Search index:
In the Connector Administration Cockpit you have to execute the following:
Initial data load for indexing the data for your search object connector(s).
Schedule the delta update of the search index so that the Enterprise Search is regularly updated with the master data that has been changed in
the meantime.
The concept of Enterprise Search for SAP Master Data Governance described above is shown in the following figure:
In SAP Master Data Governance you can use the database search to find master data for changing or verification. It is an exact search method that is based
on exact values or value ranges like identification numbers or names that are stored in databases.
In SAP Master Data Governance you can also implement your own search providers. If you want to do this, you have to do the following:
Procedure
Note
Your access class must use the standard search interface IF_USMD_SEARCH_DATA ( Search for Entities ).
2. User interface: Use the generic WebDynpro application USMD_ENTITY_SEARCH and launch it with the parameter SEARCH_MODE = your new search
SAP HANA -based search for SAP Master Data Governance enables you to perform searches and duplicate checks on master data residing in the SAP
HANA database. An SAP HANA search provider is delivered to enable these features.
The following data models are supported out-of-the-box for MDG on HANA :
Flex data models
The business partner reuse model (BP)
The material reuse model (MM)
The access class implementation is not provided for other reuse models. You must implement the access class for SAP HANA search to use it with the
other reuse models.
SAP HANA-based search for SAP Master Data Governance can be used for the following MDG applications:
Master Data Governance for Custom Objects
Master Data Governance for Financials
Master Data Governance for Supplier
Master Data Governance for Customer
Master Data Governance for Material
Prerequisites
You have activated the business functions Master Data Governance, Generic Functions 7.0 or higher (MDG_FOUNDATION_4 or higher) and Master Data
Governance, Generic Functions 7.0 Feature Pack or higher (MDG_FOUNDATION_5 or higher).
You have installed the SAP HANA database, support package 06 or higher. We recommend that you install the highest available version of the SAP HANA
database.
You must have the following permissions to work with search views in SAP HANA :
Permission to create a package and to write objects into packages
Permission to create, change and drop attribute views
Permission to create, change and drop SQL views
Permission to create, execute and drop rule sets
For more details please refer to the SAP HANA security guide.
Process
To configure SAP HANA -based search for MDG, carry out the steps described below.
1. Create Database Connection
Run transaction DBCO and create a database connection to the SAP HANA database.
Field Value
Database Connection Name Unique name for the SAP HANA database connection used for search and
duplicate check
Permanent Yes
Connection Limit 0
Note
Deployment Options for MDG
MDG can be deployed on an SAP HANA database or on any database.
If you deploy MDG on SAP HANA , then SAP HANA acts as the primary database and the creation of the database connection is optional. If
the database connection is not maintained then a default connection is derived automatically.
If you deploy MDG on any other database, then you must maintain the database connection to the schema in the SAP HANA database.
Field Value
Database Connection Name for MDG The SAP HANA database used for the search and duplicate check
processes created in the previous step. This field is optional if MDG is
deployed on a SAP HANA database.
RFC Connecting MDG to SLT System Optional, only enter data if you use SLT for data replication
SLT Configuration Name Optional, only enter data if you use SLT for data replication
In the SAP HANA system, where the search on MDG data is performed, you must generate the search view. If you deploy MDG on a traditional
database, and use SLT for replication then, when generating the view, before it is created, the system replicates the required table metadata to
the SAP HANA database using the SLT settings.
If SAP HANA is the primary database, it is not mandatory to maintain the database connection name in MDG Landscape Profile customizing. If
the name is not maintained the system uses the default database connection. You still have the option of maintaining a different connection name
in the MDG Landscape Profile if you do not wish to use the default database connection.
4. In the SLT system the SLT user requires the authorization object S_DMIS, with the following field values defined for their role:
MBT PCL: Processing Role Level (MBT_PR_LEV) PACKAGE (Transfer package level)
5. For Material Search, in transaction SA38 execute the report MDG_HDB_MAT_MIGRATE_LONGTEXT as a background job. Select the Overwrite
target table records checkbox, to perform the initial load of material long texts to the database table MDGHDB_LONGTEXT. This loads the following
long text types: Basic Data Text, Sales Text, Purchase Order Text, Inspection Text, Internal Note, and Material Note MRP.
3. Define Authorization Relevance for Each Entity Type
The authorizations maintained in customizing are considered during search. You can maintain the authorization in Customizing under Master Data
Governance, Central Governance General Settings Data Modeling Define Authorization Relevance per Entity Type .
4. Create Search View
Create a search view in the development system and transport it to the test and production systems. The search view must be generated or regenerated
in the target (test and production) systems.
If you are using the business partner, customer, or supplier domains and have activated the business functions MDG_ERP_CUSTOMER_3 or higher,
MDG_ERP_SUPPLIER_4 or higher, or MDG_BUPA_1 or higher, or if you are using material domain and have activated the business function
MDG_MATERIAL_5 or higher, then you must assign the template views from these business functions to a customer package in the Create Search
View configuration activity before you can generate and use them.
You must also have authorization to create a workbench request.
To create a search view, run transaction MDG_HDB_GEN_UI or navigate to Master Data Governance, Central Governance General Settings Data
Quality and Search Search and Duplicate Check Create Search View .
The package where you generate the search view must be in the customer namespace. Enter the name of the package during search view creation.
When you create the search view and the system generates the SAP HANA view, the following search configuration data is automatically updated:
Master Data Governance, Central Governance General Settings Data Quality and Search Search and Duplicate Check Define Search
Applications Allocation of Search Help to Search Applications
Master Data Governance, Central Governance General Settings Data Quality and Search Search and Duplicate Check Define Search
Applications Allocation of Entities to Search Help
In SAP HANA attribute views are created on the active and inactive areas. After you create the search view it can be manually edited within SAP HANA
Studio to update the search properties of an attribute. In this case, if the search view is regenerated, the new search view will overwrite the manually
updated search view.
You can create a search rule set during the search view generation if you want the search to be performed based on search rule sets. If you choose the
create ruleset option for a reuse model, a union SQL view is created on the attribute view in SAP HANA. This search rule set can also be manually
updated according to the business requirements of the users after it is generated. If the search view is edited at a later date and is regenerated, the
search rule set will not be regenerated/overwritten; it has to be manually adjusted.
You must manually check out the generated search rule set to the Project Explorer view of the SAP HANA Studio Administration Console before it
can be edited to change any parameter, such as the fuzzy value or weight of an attribute, and activate it to enable search based on this modified search
rule set.
You can also copy an existing search view and edit it before generating the search view.
If there is a mismatch between the generated search view and the underlying objects, the system recognizes this and updates the status of the
generated search view to Outdated. You can edit this outdated search view and regenerate the view.
To delete a search view, you must first remove the customizing settings for the search view, and then delete the search view. The status of the view is
then set to Marked for Deletion. In transaction SE38 execute the report program MDG_HDB_DELETE_SEARCH_VIEWS to delete the specific view or all
views that are marked for deletion, and drop the corresponding objects in SAP HANA.
You must set filters in the SAP HANA staging views to exclude records that have the obsolete indicator set. Identify all the Obsolete Indicator flags.
The fields corresponding to the obsolete indicator flags in each table of a staging view have the technical naming convention USMD*_OBS_* or
USMD*_O_*. Select the obsolete indicator in the Details section of the staging view, right click and select Apply Filter . In the Operator field select
Not Equal and in the Value field enter X .
For material search you must set filters in the SAP HANA views for the material-related long texts stored in the database table MDGHDB_LONGTEXT.
This means that only the appropriate long texts are taken from MDGHDB_LONGTEXT. To do this, in the SAP HANA studio, open the Content folder and
navigate to the package where the search views are created. For reuse entity types, creating a search view generates two views in the SAP HANA
system (one each for the active and staging areas), or three if you are using classification data. The views generated for the active area have names
similar to searchviewname_Reuse and searchviewname_RINOB.
Open the reuse SAP HANA views below. Go to Detail window, and select the long text table with the alias you want to update and right-click on the
attribute. From the menu choose Apply Filter . From the drop-down menu choose the operator Equal and maintain the values as specified in the tables
below.
Basic Text
Sales Text
Purchase Text
Plant Text
Result
You have now configured your system to use SAP HANA for MDG search. For drill down search configuration, see Configuring Drill-Down Search (Optional).
The Drill-Down Search UI is used to search master data records, starting with a general category, and moving down through the hierarchy of fields to the
required information. This document contains the information required to configure this UI.
Prerequisites
Before you can begin configuring the drill-down search you must consider the following:
SAP HANA Configuration
You have completed configuration of SAP HANA search for MDG and configuration of data replication for your SAP HANA database. See Configuring
SAP HANA-Based Search for MDG for more details.
Deployment Scenario and Component Installation
You have decided on a deployment scenario and installed the required components. There are two deployment options for installing SAP NetWeaver
Gateway :
Single system deployment or embedded deployment where the back end system and Gateway hub are installed on the same system.
Dual system deployment or central hub deployment where the back end system and the Gateway hub are deployed on two different systems.
SAP recommends the dual system deployment scenario, where the back end system and Gateway hub are deployed on different systems. Depending
on the deployment scenario and SAP NetWeaver release, the following Gateway components need to be installed:
NW740 Single system or dual system No need to install as all the above Gateway
components come as part of bundle under the
component SAP_GWFND .
For SAP NetWeaver release NW731, UI5 SP04 has to be installed regardless of the deployment scenario. For SAP NetWeaver release NW740 and
above, UI5 is part of the bundle. For a full range of features it is recommended that you install SAP UI5 1.15.0 or higher.
Browser Support
You have chosen a browser and version that is supported. See SAP Note 1716423 for details on supported browsers.
Attributes with Technical Keys
If a database view contains attributes with technical keys (such as Country Keys or Region Codes) then your query results will display these technical
keys. To avoid this, manually modify your generated SAP HANA views in SAP HANA Studio by adding text joins to the corresponding text tables.
This causes the text description to display correctly in the browser panes and result set.
Update Annotation Namespaces for SAP NetWeaver Gateway Server
Update the SAP namespace in table /IWFND/I_MED_ANS by implementing SAP Note 1885373 .
Process
Follow the steps below to configure the drill-down search for SAP Master Data Governance :
1. Create an External Alias
1. Run transaction SICF.
2. Create an external alias called /sap/mdg for the URL http://gatewayserver:port/sap/opu/OData/ .
3. In the URL, insert your own port and Gateway server names where it says gatewayserver and port. This enables the system to interpret
your URL correctly.
2. Activate the Gateway System
Open the SAP Gateway hub system. In the SAP Customizing Implementation Guide navigate to SAP NetWeaver Gateway OData Channel
Configuration Activate or Deactivate SAP NetWeaver Gateway . Activate the SAP NetWeaver Gateway .
In the dual-system deployment scenario, the web dispatcher has to be configured. For more details, see Configure Web Dispatcher below.
Note
Make sure that the configuration to create search views is complete before creating a search view. To configure search view creation see
Configuring SAP HANA-Based Search for MDG.
Example
Using the example service name from the Maintain OData Service section above, ZMDG_CUSTOMER_SERVICE, the URL
http://sapexampleurl/ZMDG_CUSTOMER_SERVICE with an external alias becomes /sap/mdg/sap/ZMDG_CUSTOMER_SERVICE/.
The web dispatcher must be configured so that if it is given the alias /sap/mdg, it routes to the Gateway system, and in all other cases routes to the
SAP backend system. When setting up the UI, change the port number in the application URL to the port number of the Web Dispatcher.
For more details on Web Dispatcher configuration go to http://help.sap.com and navigate to SAP NetWeaver SAP NetWeaver Platform SAP
NetWeaver 7.3 (or higher) Application Help Function-Oriented View Application Server Application Server Infrastructure SAP Web
Dispatcher .
12. Prepare Drill Down Search for Launch
You have two choices for launching the Drill Down Search UI: you can either choose to link it to a PFCG role or set it up to launch from the Favorites
menu. To set up the Drill Down Search UI to launch from the Favorites menu follow this procedure:
1. Go to Favorites Add Other Objects BSP Application .
2. In the BSP Applicat. field enter MDG_DRILL_DOWN.
3. In the Description field enter a description of your choice.
4. In the Start Page field choose WebContent/index.html from the context menu.
5. In the Name field enter service_name.
6. In the Value field enter the external OData service name that you created above.
Note
If your Gateway system runs separately to your back-end system, and if you choose to run the drill-down search from the classic UI then you will
need to manually adjust the port number in the URL to the Web Dispatcher port number each time you execute the application.
More Information
More information about the SAP HANA Appliance Software can be found here: http://help.sap.com/hana_appliance/#section3 .
Search views are used by the SAP HANA database to optimize performance when searching. Each search view consists of entities and attributes from the
Master Data Governance data model. You can use the Create Search View application to create search views for your more common searches and reports.
If an existing search view is outdated you can also use this application to update and regenerate it. Regenerating a view overwrites manual modifications to
the attribute views made in SAP HANA but does not overwrite rule set changes.
Process
To create a search view follow this process:
1. Open the Create Search View application.
2. In the Enter General Data step, enter a technical name, description, and choose a business object type.
3. Choose an SAP HANA package which specifies the folder in the SAP HANA system where the view is created. You can leave this field blank and fill
it in later, before view generation. If you want to search based on rule sets, select the Rule Set checkbox.
4. Choose Next .
5. In the Select Entities and Attributes step, select the entities and attributes you want to add to the search view. The entities and attributes displayed are
based on the business object you selected in the previous step.
6. Choose Next .
7. In the Review and Generate step, confirm the data you entered in the previous steps. Save and transport the data to the target system. In the target
system enter the package name if you have not already done so. Choose Generate to create a search view in the SAP HANA system under the
package you have entered.
Result
You have generated a new or updated search view in the SAP HANA system.
More Information
Configuring SAP HANA-Based Search for MDG
The Generic Search (USMD_SEARCH) service enables you to search for and display instances of business objects based on specified criteria. For more
information, see Search Business Object.
You can configure the user interface of the Generic Search (USMD_SEARCH) Web Dynpro application so that only business objects for a particular entity type
and data model can be searched. With this configuration, users do not have to select data models or entity types from dropdown lists in the search control
area. You can also configure which fields display in which order in the search results.
You can create this example configuration using the Manage UI Configurations Web Dynpro application in Customizing. For more information, see Managing
of UI Configurations
If the searched-for business object can belong to a hierarchy, you can configure a search that is capable of showing results in the context of the hierarchy.
Prerequisites
You have set the standard data model to the data model for the entity type for which you are configuring the generic search by completing the following steps:
1. In transaction SPERS_MAINT, you have chosen the Edit objects button.
2. You have double-clicked the SAP Master Data Governance row.
3. In the popup, you have entered the standard data model and you have saved your changes.
The data model for the entity type for which you are configuring the generic search is in the customer namespace. If this is not the case, see Creating genIL
Components and Transaction Handler Manually.
Procedure
Copy UI Configuration
1. In Customizing for Master Data Governance, Central Governance , go to General Settings UI Modeling Manage UI Configurations
2. In the table, select the row with the following attributes and choose the Copy button:
Application :USMD_SEARCH
Application Configuration :USMD_SEARCH_TEMPLATE
3. In the Floorplan Manager: Application Hierarchy screen, enter target configuration IDs for the application configuration, the UI configuration (also known
as the OVP configuration), and the UIBB configurations. Then choose the Start Deep Copy button.
Note
3. (Optional Step) To make the most commonly used search application appear as the default search application in the dropdown list, enter the search
application in the USMD_SEARCH_MODE parameter. If appropriate, enter the search help in the USMD_SEARCH_HELP parameter.
4. Save the application configuration.
Search Mode Yes The search application. You can find the definition of
search applications in use in Customizing for Master
Data Governance, Central Governance under
General Settings Data Quality and Search
Search and Duplicate Check Define Search
Applications
Incl SearchHelp No (Optional) The search help for the search application.
You can find the definition of search helps allocated
to the search application in Customizing for Master
Data Governance, Central Governance under
General Settings Data Quality and Search
Search and Duplicate Check Define Search
Applications .
5. In the Search UIBB Schema , add search attributes by using the Search Criteria button. Use the Up and Down buttons to change the order of the
search attributes. You can change the number of search attributes that display in General Settings , by selecting a value for Number of Search Rows
on Open . It might be necessary to restart the application before the search attributes of the entity type specified by the Dyn Query Name are made
available.
6. (Conditional Step) If the entity type is edition-based, add a search attribute so that the user can select the validity timeframe for the returned instances
of the business objects. If you add search attribute Valid On (USMD_VALID_AT), the user can select the validity timeframe directly. If you add search
attribute Edition (USMD_EDITION), the user can select an edition that determines the validity timeframe. In the latter case, set parameter
USMD_SEARCH_EDITION_MODE to X in the copied application configuration.
Save the Search UIBB Schema configuration and return to the UI configuration.
7. (Optional Step) If you want to allow the end users to personalize the Search Criteria block of the search application, go to the General Settings
section and, from the Personalization dropdown list, select Enabled . Save the component configuration and return to the UI configuration.
Parameter Value
3. In the List UIBB Schema , add search result attributes by using the Column button. Use the Up and Down buttons to change the order of the result
attributes.
Note
To enable navigation from the search results to the inactive data of a business object, add column CREQUEST_PENDING and set its display type to
Image . To enable navigation from the search results to the active data of a business object, set the display type of the column representing the
object key to Link To Action .
4. (Conditional step) If the entity type is edition-based, add the required result attributes that describe the validity of the displayed instances of business
objects. You can display result attributes for time-related validity and for edition-related validity.
Time-related validity
For a date-specific edition type, add attributes Valid From (USMD_VDATE_FROM) and Valid To (USMD_VDATE_TO).
For a period-specific edition type, add attributes Period/Fiscal Year From (USMD_VPER_FROM) and Period/Fiscal Year To
(USMD_VPER_TO).
Edition-related validity
To display validity in terms of editions, add attributes From Edition (USMD_EDITION) and To Edition (USMD_EDITION_TO).
5. In the Toolbar Schema , add required toolbar elements (or buttons) and save the configuration.
Note
This is only valid if you are configuring a search that allows the user to specify a hierarchy type and a hierarchy,
If the user specifies a hierarchy type in the search, a different user interface building block (UIBB) is required for the Search Criteria section of the Search
screen. This UIBB is configured to include a Hierarchy dropdown list.
1. Return to the Manage UI Configurations screen and refresh the screen.
2. Open the UI Configuration you just created, by clicking the relevant link under the UI configuration column. Choose the Copy icon.
3. Enter a new Configuration and Description .
4. Choose the Continue in Change Mode button. In the General Settings section, choose the Feeder Class Parameters button. Enter the following
Feeder Class Parameters :
Parameter Value
Business Object Type (requires scrolling to end of popup) Business Object Type
For example, MDG_CARR.
5. In the Search UIBB Schema section, add search attributes by using the Search Criteria button.
By default, the configuration includes no search criteria. The following attributes are mandatory if selectable:
Parameter Label
USMD_EDITION Edition
Only selectable if the hierarchy type is edition-dependent
USMD_HIERARCHY_VERSION Version
Only selectable if the hierarchy type is version-dependent
6. Use the Up and Down buttons to change the order of the search attributes. You can change the number of search attributes that display in General
Settings , by selecting a value for Number of Search Rows on Open .
It might be necessary to restart the application before the search attributes of the entity type specified by the Dyn Query Name are made available.
7. In the General Settings panel, you can specify settings applicable to the result list. To enable selection of multiple rows in the result list, apply the
following settings:
Selection Mode: Multiple Selection
Multiple Selection: Enable Event on All Selections
Under Selection Raises an FPM Event: select the Display Mode checkbox.
Note
This is only valid if you are configuring a search that allows the user to specify a hierarchy type and a hierarchy,
1. If the user specifies a hierarchy type in the search, a different user interface building block (UIBB) is required for the Search Criteria section of the
Search screen. This UIBB is configured to include a Hierarchy dropdown list.
2. Return to the Manage UI Configurations screen and refresh the screen.
3. Open the UI Configuration you just created, by clicking the relevant link under the UI configuration column. Choose the Copy icon.
4. Enter a new Configuration and Description .
5. Choose the Continue in Change Mode button. In the General Settings section, choose the Feeder Class Parameters button. Enter the following
Feeder Class Parameters .
Parameter Value
Business Object Type (requires scrolling to end of popup) Enter the technical name of the business object type being searched.
Example: MDG_CARR.
6. In the Search UIBB Schema, add search attributes by using the Search Criteria button. By default, the list is empty. The following attributes are
mandatory if selectable:
USMD_HIERARCHY_NAME: Hierarchy Name
USMD_EDITION: Edition (only selectable if the hierarchy type is edition-dependent)
(Optional) UI Configuration for Hierarchy Search: Set Rules for Selecting Which Search Criteria UIBB to Display
Note
This is only valid if you are configuring a search that allows the user to specify a hierarchy type and a hierarchy,
Depending on your configuration, you can switch between a search criteria building block on the user interface that specifies a hierarchy type (UIBB for
Hierarchy Search Criteria) and a search criteria building block that does not specify a hierarchy type.
1. Open the Manage UI Configurations user interface and click the link for the UI configuration.
2. Choose the Continue in Change Mode button and under General Settings choose the Feeder Class Parameters button.
3. Enter the following values in the Morph Entry with UIBB Terminus table
Spot Name Spot Value Entry Key Parent Key Configuration ID Meaning
MDG USMD Search ENTITY_TYPE MAIN <Hierarchy ID for A standard search UIBB
Entity Type Standard Search for a hierarchy search
UIBB>
MDG USMD Search HIER_NO MAIN <Hierarchy ID for Standard search criteria
Hierarchy Type Standard Search shown if hierarchy type is
UIBB> not entered.
MDG USMD Search ENTITY_TYPE HIER_YES MAIN <Hierarchy ID for Hierarchy search
Hierarchy Type Hierarchy Search parameter added to
UIBB> search criteria if a
hierarchy type is
specified. This requires a
different user interface
building block.
Result
To test the application you created, open the copied application configuration and choose the Test button.
You use this Web Dynpro application (USMD_RULE) to define validation and derivation rules for a specific data model of Master Data Governance. Derivation
rules are designed to simplify the entry of master data, whereas validation rules ensure consistency of the master data entered.
Integration
After you specify a data model, the Web Dynpro application launches the Business Rule Framework plus (BRFplus) application. For more information, see
Business Rule Framework plus (available in English only).
Prerequisites
You have created the data model for which you want to define derivations and validations.
Features
Trigger Functions
You can assign trigger functions to the following events to validate master data changes:
CHECK_ENTITY (Check entity): The system executes the function assigned to this event when entity values are validated during single or collective
processing, when mass changes are made, or during the upload process.
CHECK_CHANGE_REQUEST (Check change request): The system executes the function assigned to this event when the change request is checked. It
also executes the function prior to the final check of the change request.
Note
If entity type 1 and entity type 4 have the cardinality 1:1, instead of calling the derivation function of entity type 4, the system calls the derivation function
of entity type 1.
Naming Conventions
The following naming conventions apply to the relevant nodes, objects, applications, and catalogs:
Trigger function nodes in the catalog structure
The naming convention for validation-based trigger function nodes of a catalog structure is: CHECK_<name of entity type>, for example,
CHECK_ACCOUNT.
The naming convention for derivation-based trigger function nodes of a catalog structure is DERIVE_<name of entity type>, for example,
DERIVE_ACCOUNT.
Note
These naming conventions apply only to the naming of the trigger function nodes of a catalog structure. They do not apply to the naming of the
trigger functions linked to the nodes. Each entity type should have a maximum of one trigger function per event. The nodes of the respective
function branch of the trigger function represent the corresponding application options.
Data objects
Data objects are automatically generated from the data model definition. The structure-type data objects have the same names as their respective entity
types.
Note
The naming conventions valid for SAP enhancement package 4 are still supported. However, we recommend that you discontinue their use.
The standard system features the following predefined data objects, which you can use within rules and functions, as additional input parameters:
SAPFMDM_CREQUEST_TYPE: Change of change request type ID
SAPFMDM_CREQUEST: Change of change request ID
SAPFMDM_EDITION_TYPE: Edition type ID
SAPFMDM_EDITION: Edition ID
SAPFMDM_PROCESS: Business activity
SAPFMDM_CREQUEST_STEP: Change request step
SAPFMDM_CREQUEST_INDEX: Change request index
SAPFMDM_WORKITEM_ID: Work item
SAPFMDM_HRY_DELTA: Deep structure consisting of a hierarchy relationship (or an associated pair of objects) for validation
This must be used in the hierarchy-based validation events CHECK_ENTITY_HRY, CHECK_CREQUEST_HRY, and CHECK_EDITION_HRY.
Note
If a trigger function contains the predefined data objects only, it is executed once during the validation.
Note
Use the namespace for the system-generated BRFplus application and catalog structure to create your own applications and catalogs. The
system uses the syntax FMDM_MODEL_<name of data model>, for example, FMDM_MODEL_0G for data model 0G.
Activities
To start this Web Dynpro application, in Customizing for Master Data Governance, Central Governance choose General Settings Data Quality and
Search and choose the Customizing activity Define Validation and Derivation Rules .
Example
Creating BRFplus functions for derivations of entities with storage and use type 4
The following table shows an example of the different cardinalities, which are described in the BRFplus Structure Generation section.
CARR 1
CURRCODE
URL
COUNTNUM
AIRPORT
C_URL
This example contains the entity CARR with storage and use type 1 along with the dependent entities CARR_DELTA and COUNTER, which have storage and
use type 4. CARR_DELTA has the cardinality 1:1 and COUNTER has the cardinality 1:N. The third column shows the attributes of the entities.
Generated BRFplus Structures
CARR
CARR
CURRCODE
URL
CARR_DELTA
URL
COUNTER
CARR
COUNT_NUM
AIRPORT
C_URL
In the data model, the entities with storage and use type 4 have their own attributes. In contrast, in generated BRFplus structures, the system adds the
attributes of the entities with storage and use type 4 with cardinality 1:1 to the attributes of entity type 1. For this reason, the CARR structure has the
additional URL attribute.
Derivations for entities with cardinality 1:1
UIs based on Web Dynpro application USMD_ENTITY_VALUE2
If you want to create a derivation for CARR_DELTA in BRFplus, you can execute this only with the function DERIVE_CARR, but not with the
DERIVE_CARR_DELTA function. When entities have the cardinality 1:1, in BRFplus you access derivations using the entity type 1.
UIs based on the Convenience API CL_USMD_CONV_SOM_GOV_API
If you want to create a derivation for CARR_DELTA in BRFplus, you can execute this only with the function DERIVE_CARR_DELTA, but not with
the DERIVE_CARR function.
The generated BRFplus structure of the entity type 1 contains the attributes of the entity type 4 with cardinality 1:1. If you specify the signature for the
BRFplus function, you must use the structure of the type-1 entity CARR.
In contrast, to access an entity type 4 with cardinality 1:N (for example, COUNTER), you call the DERIVE_COUNTER function.
The signature of the BRFplus function DERIVE_COUNTER is the COUNTER structure.
This document describes the necessary configuration steps you have to process to use the data quality remediation in Master Data Governance.
Process
Configuration Process
1. You need to execute the Customizing activity Define Data Quality Service . For more information, see the documentation of this customizing activity
under General Settings Data Quality and Search Data Quality Remediation .
2. Copy the Floor Plan Manager (FPM) Configuration Templates
1. In the package MDG_DQR_GENERAL select Web Dynpro Application configuration MDG_DQR_OVP and choose Start Configurator .
2. In the Editor for the Web Dynpro ABAP Application Configuration select Continue in Display Mode .
3. In the Application Configuration MDG_DQR_OVP select the configuration name MDG_DQR_OVP of the component FPM_OVP_COMPONENT.
4. In the Component Configuration of component MDG_DQR_OVP select Additional Functions Deep Copy .
5. Choose Configurable Components to expand the list of configurations. To create a copy of the Application Configuration MDG_DQR_OVP, the
Overview Page Floorplan MDG_DQR_OVP and at least of the component configuration MDG_DQR_FAILED_REC_LIST_UIBB, set the according
flags in the column Copy and enter appropriate names in the column Target Configuration . Then choose Deep-Copy .
Note
The technical names of target configurations should reflect the business object type and the data quality service.
The configuration of governance scope, change requests, and workflow offers you flexible ways to model the desired governance process.
You can determine a governance scope based on your business needs. Ungoverned fields are read-only in change requests, unless you remove them from the
user interface.
Example
In the material application, you can for example, remove sales grouping data from the governance scope.
Prerequisites
You have identified the data models whose governance scope you want to change, as well as the content within each data model that you want to govern.
You are aware of the consequences of changing the governance scope. See the help document in Customizing for Master Data Governance under
General Settings Process Modeling Define Governance Scope
Procedure
1. In Customizing for Master Data Governance under General Settings Process Modeling , choose Define Governance Scope .
Result
You have defined a governance scope for the data model. You can keep ungoverned data model elements on the user interface for information purposes. If the
elements are not informative to your users, we recommend that you remove them. For more information, see Managing of UI Configurations.
You need to carry out the following steps if you want to enable users to create a single entity without having to create a change request beforehand in a
separate step. As a result, the user also no longer needs to select the data model, the entity type, or the change request type. These are predefined
automatically as part of the configuration settings described in this documentation.
Procedure
1. Create a new business activity in the customer namespace.
In Customizing for Master Data Governance, Central Governance , choose General Settings Process Modeling Change Requests Create
Business Activity .
2. Assign the new business activity to a change request type for single objects.
In Customizing for Master Data Governance, Central Governance , choose General Settings Process Modeling Change Requests Create
Change Request Type .
When configuring the change request process you need to define the following:
Processing steps and their processors
Possible actions of processors
Process flow between steps
Change request status in each step
Additionally, you can use editions to schedule changes and you can define when the data replication should happen. For more information, see Using Editions
to Schedule Changes.
You must configure the following elements:
Change Request Type
The change request type defines which data can be processed. The change request type is assigned to one MDG data model and lists the possible
entity types that the change request can contain.
SAP Business Workflow is used to process change requests in SAP Master Data Governance. To define the process flow of the change request you
can use standard workflow templates or custom workflow templates when defining a change request type. For more information on SAP Business
Workflow, see the Customizing activities under SAP NetWeaver Application Server Business Management SAP Business Workflow .
Alternatively, you can use the MDG rule-based workflow template when defining a change request type. In this case, the content of Business Rule
Framework plus (BRFplus) decision tables defines the process flow of the change request.
For more information, see the Customizing activity Create Change Request Type under General Settings Process Modeling Change Requests
.
Change Request Step
Each change request process consists of a number of change request steps that can be either dialog steps or background steps. For each dialog
change request step, you can do the following:
Assign processors
Configure validations and data enrichments
Assign UIs
The processing sequence of the steps is based on the processors' decision and other criteria that are evaluated by the workflow assigned to the change
request type.
If you are not using the rule-based workflow, the workflow template defines the available change request steps. Every change request type using this
workflow template can only have the available steps. For more information, see Customizing activity Define Change Request Step Types and Assign
Actions under General Settings Process Modeling Workflow .
If you are using the rule-based workflow, the Customizing settings and the content of the BRFplus decision tables define the available steps. Every
change request type using the rule-based workflow can have different change request steps although all change request types are using the same rule-
based workflow template. For more information, see Customizing activity Define Change Request Steps for Rule-Based Workflow under General
Settings Process Modeling Workflow Rule-Based Workflow .
Change Request Step Type and Change Request Action
The change request step type defines the possible actions that a processor of a change request step can use. We deliver a number of change request
step types, for example Approve Change Request with the possible actions Approve and Reject .
The change request step type of each change request step is determined at runtime. You can configure a change request step that allows the actions
Approve and Reject in one case, while allowing Finalize Processing and Send for Revision in another case.
For the design of the change request process and its configuration, it is useful to create a diagram that comprises all change request steps and their
connections. The recommended process is as follows:
Process
1. Start with step 00 and an appropriate description, for example Request. Provide a name for the group of users that are allowed to create change
requests of this type, for example Requester.
Note
You control which users can create change requests of a certain type with the authorization object USMD_CREQ. For further information on
authorizations, see Authorization Objects and Roles Used by Master Data Governance.
2. Add a step for each task that a user needs to perform. Assign a step number that is unique for the process and choose an appropriate description. Name
the group of users that shall perform the task. Select a step type in Customizing activity Define Change Request Step Types and Assign Actions under
General Settings Process Modeling Workflow that fits to the task and includes the actions the processor should be able to choose. Add the
step type and the possible actions as outcomes to the diagram like shown below.
Dialog Step 90/Approve: With Expert as Processor, Approve Change Request as Step Type, and Approve and Reject as Possible Actions
3. Add a step for each background task. Assign a step number and a description. Add this information together with the description of the background task
to the diagram. Also, include all possible outcomes of the task on which you want to react in the process. Some important standard tasks of MDG to
work with the change request are the following:
ACTIVATE CHANGE REQUEST (TS60808002)
DISCARD CHANGE REQUEST (TS75707936)
CHANGE REQUEST REPLICATION (TS60807976)
4. Connect each step with an arrow that originates from the respective outcome of the previous step and ends at the step that should follow. For each
arrow, add the new status that the change request shall have, when the process proceeds from one step to the next.
If the expert chooses to approve the change request, the status shall be set to 02/Changes to be Executed, and the system shall activate the change
request.
More Information
For more information, see Creating a Basic Change Request Process and Add User-Agent Steps for examples to configure the rule-based workflow.
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
1. Choose an appropriate template by examining its documentation.
2. Create the change request type and enter the chosen workflow template.
3. Perform further configuration according to the requirements of the template, for example, assign processors to the change request steps.
Custom Workflow Template
1. Create the workflow template.
2. Define the change request steps in the MDG Customizing.
3. Create the change request type and enter your custom workflow template.
4. Perform further configuration, according to the requirements of the template, for example assign processors to the change request steps.
Rule-based workflow
1. Create the change request type.
2. Define change request steps in MDG Customizing.
3. Create decision tables.
You use this process to define the mandatory Customizing settings that are needed to enable SAP Business Workflow for the change request process in
Master Data Governance.
Prerequisites
You have defined the necessary settings for SAP Business Workflow and defined the organizational plan in Customizing under SAP NetWeaver
Application Server Business Management SAP Business Workflow .
Process
1. The workflow system user (typically WF-BATCH) processes background tasks of MDG. Therefore, this user needs to have the required MDG
authorizations. Assign the PFCG role SAP_MDG_WF_ADM to the workflow system user in transaction SU01. For more information, see SAP Note
1650993 .
2. Create event type linkages for the business object BUS2250 (MDG Change Request) as described in Customizing activity Activate Type Linkage under
General Settings Process Modeling Workflow .
3. To assign processors to change request types and change request steps, decide on the possible agents of the MDG workflow tasks in general. In
Customizing activity Configure Workflow Tasks under General Settings Process Modeling Workflow assign specific agents from your
organizational plan to each dialog task. In the attributes pop-up of each dialog task, select to whom processors may forward a respective work item.
Instead of assigning specific possible agents to a dialog task, you can also classify a dialog task as general task, so that a work item can be executed
by any user. All users in the list of possible agents that are also assigned as processors of a change request step, are selected as the agents at runtime
and will receive the work item. Make the settings for all dialog tasks of the application component CA-MDG-AF and the respective components of the
MDG application that you use.
Note
If you assign a processor to a change request step that is not assigned as possible agent, the workflow will end in an error at runtime unless you
have classified the task as general task.
Instead of building your own workflow template, you can use the MDG rule-based workflow. Using the rule-based workflow, you can configure any kind of
change request process without the need to create and adapt a workflow template. You can define different change request processes in decision tables of the
Business Rules Framework plus (BRFplus), which are maintained in Customizing for each change request type. At runtime, the current step, the user
interactions, and other parameters in the decision tables determine the process flow of the change request. When you adapt the decision tables in BRFplus,
you can add or remove a change request step or change the order of the steps without changes in the workflow template.
The rule-based workflow uses BRFplus to determine the change request status, the next change request step, and expected agent(s). To make this
information available, the system uses the current step, the last action, the priority of the change request, and, where appropriate, the reason of rejection as
input parameters. You access the BRFplus application to determine how change requests are processed for a particular change request type in Customizing
activity Configure Rule-Based Workflow under General Settings Process Modeling Change Requests Workflow Rule-Based Workflow . If you
process this Customizing activity for a change request type for the first time the system generates a BRFplus application for each change request type. Each
application contains functions, rule-sets, and decision tables. The content of the decision tables defines the change request process.
Three decision tables are available for each change request type:
Single Value Decision Table
The Single Value Decision Table DT_SINGLE_VAL_<change request type> defines the process flow between the change request steps. Based
on the previous step, the action, and other parameters, this table returns the next step and other result parameters. The most important result parameter
is the condition alias that links to the other decision tables. This decision table has the following condition columns:
CR Previous Step
This parameter contains the previously processed change request step.
Previous Action
This parameter contains the result of the previous system or previous user action.
Chng. Req. Priority
This parameter contains the current priority of the change request.
Chng. Req. Reason
This parameter contains the reason for this change request.
CR Rejection Reason
This parameter contains the reason for rejection of this change request.
CR Parent Step and Parallel Agt Grp No.
These columns are used for parallel processing and are considered by the rule-based workflow to find the next step in the relevant subprocess.
The system identifies the relevant subprocess by referring to the values in CR Parent Step and Parallel Agt Grp No. . For more information, see
Parallel Processing.
Based on the data from these condition columns, the system takes the actions and sets the statuses outlined in the result columns. This decision table
has the following result columns:
Condition Alias
The condition alias references the other decision tables. Each condition alias must be handled using at least one row in either the User Agent
Decision Table or the Non-User Agent Decision Table .
New Chng. Req. Step
This parameter contains the next step in the process.
New CR Status
More Information
For information on how to create and enhance your rule-based workflow, see Creating a Basic Change Request Process and Add User-Agent Steps.
Application specific information on rule-based workflow is available in Rule-Based Workflows for Material.
This document explains how to configure the rule-based workflow for a change request process that you have described using a process diagram as explained
in Designing the Change Request Process.
Prerequisites
You have completed the Customizing settings as described in Workflow Set-Up.
Process
Enhance Process Diagram
Enhance the process diagram with further information required by the rule-based workflow. For each non-user agent change request step, determine the
appropriate Process Pattern and add the information to the diagram.
To activate the change request, you need to use the process pattern 06/Activation.
For each arrow pointing to a change request step, choose a 3 digit identifier for the condition alias. It is common to use abbreviations of the step’s
meaning for better readability, for example APP for an approval step.
The arrow pointing to the change request step Activate is labeled with the condition alias ACT.
For information about an example of a process diagram that is enhanced for the rule-based workflow, see Add User-Agent Steps.
Create Change Request Type
In Customizing activity Create Change Request Type under General Settings Process Modeling Change Requests , create the change
request type for which you want to define the process flow. Assign the rule-based workflow template WS60800086 to the change request type.
Define Change Request Steps
In Customizing activity Define Change Request Steps for Rule-Based Workflow under General Settings Process Modeling Workflow Rule-
Based Workflow , define the process steps that are used in the process diagram of your change request type.
Service Names
In the case of a complex workflow scenario, for example, when using a handler to merge the results of parallel processing, you need to define service
names for the BAdI implementations that you need to use. For more information, see the documentation of Customizing activity Define Service Names
for Rule-Based Workflow under General Settings Process Modeling Workflow Rule-Based Workflow .
Build Decision Tables
Start Customizing activity Configure Rule-Based Workflow under General Settings Process Modeling Workflow Rule-Based Workflow and
enter your change request type to open the BRFplus workbench and to enter the values for the decision tables.
Note
If you perform this activity the first time for this change request type, the BRFplus application is generated. Depending on the settings of the client,
you are asked to assign a transport request and a software component.
1. For each arrow in your process diagram, enter a row in the Single Value Decision Table DT_SINGLE_VAL_<change request type>. Use the
step numbers on each end of the arrow as the values for CR Previous Step and New Chng. Req. Step . The action code of the previous step
that triggers this connection is the value for Previous Action . The labels on the arrow provide the values for Condition Alias and New CR
Status .
Note
You can use the condition columns Chng. Req. Priority , Chng. Req. Reason , CR Rejection Reason , CR Parent Step , and Parallel Agt
Grp No. as additional parameters to make the process flow more specific.
You can enter a time limit for the processors of the next change request step in Hours to Completion . This uses the feature of the requested
end deadline monitoring of the SAP Business Workflow. The rule-based workflow will send a notification to all processors of this change request
step as a reminder to complete this task.
The result columns Merge Type and Merge Parameter are used for parallel processing. For further information, see Parallel Processing.
Instead of providing values for the result columns in the decision table, you can provide a service name in Dyn Agt Sel Service to link to an
implementation of BAdI: Dynamic Selection of Agent in Rule-Based Workflow . For more information, see the documentation of BAdI: Dynamic
Selection of Agent in Rule-Based Workflow in MDG Customizing under General Settings Process Modeling Workflow Rule-Based
Workflow Business Add-Ins .
2. For each user agent step in your process diagram, enter a row in the User Agent Decision Table DT_USER_AGT_GRP_<change request
type>. If you followed the recommendation in Designing the Change Request Process to use the same condition alias for all arrows that point to a
change request step, use this value for the column Condition Alias . If you use different aliases, you need to create multiple rows, one for each
alias.
Transfer the values for Step Type , User Agent Type , and User Agent Value from the diagram into the table. The valid values for User Agent
Type and User Agent Value are defined by your organizational structure (for example, see Customizing activity Edit Organizational Plan ) and
identify an organizational object, for example, the purchasing department. If you use SU for User Agent Type you can use INIT (Initiator) as
User Agent Value to select the requester of the change request as processor. Furthermore, the value LAST for User Agent Value selects the
processor of the previous step as the processor.
If the overall group of processors for the change request step consists of multiple organizational objects, create a row for each object. In this case
and unless you want to configure parallel processing of the change request step, use the same value for User Agt Grp No . for this condition alias.
You configure parallel processing of the change request step by using different values for User Agt Grp No. for the same condition alias. For
further information, see Parallel Processing.
The information from this diagram leads to the following values in the decision table: Condition Alias = APP. User Agt Grp No. = 001 (arbitrary value).
Step Type = 02. User Agent Type = AG. User Agent Value = MD Experts (assuming there is a PFCG role named MD Experts and all users assigned to
this role should be processors).
3. For each background step in your process diagram, enter a row in the Non-User Agent Decision Table DT_NON_USER_AGT_GRP_<change
request type>.
If you followed the recommendation in Designing the Change Request Process to use the same condition alias for all arrows that point to a change
request step, use this value for the column Condition Alias . If you use different aliases, you need to create multiple rows, one for each alias.
Transfer the value for Process Pattern from the diagram into the table. If required by the chosen process pattern, specify the Service Name .
Unless you want to configure parallel processing in this change request step, choose any value for Agent Group , for example 001. For more
information, see Parallel Processing.
Caution
The decision tables are processed in sequence Therefore, the table entries should be arranged starting with the most specific ones, followed by more
general ones.
More Information
For information about examples of process diagrams related to the rule-based workflow, see Creating a Basic Change Request Process and Add User-Agent
Steps.
The rule-based workflow groups several workflow steps together to form basic operations that are called Process Patterns . These patterns are used to control
the flow of the change request process or to define which background task the system will perform in a change request step.
Technically, the rule-based workflow runs in a loop. In each repetition of the loop, one out of several process patterns is executed. The workflow continues to
run in this loop until the change request process is ended with the process pattern 99 Complete (Sub-)Workflow .
If the current change request step is a user-agent step, the used process pattern is 01 UI Dialog . For non-user agent steps, the column Process Pattern in
the Non-User Agent Decision Table DT_NON_USER_AGT_GRP_<change request type> is used to determine the pattern.
The possible process patterns are:
01 UI Dialog
This process pattern is used by the system for user-agent change request steps and should not be entered by you in the Non-User Agent Decision
Table . It is a special process pattern that is always automatically selected if a user agent has been found in the user agent decision table. This process
pattern uses the dialog task Dialog Processing TS60807954.
02 Call Synchronous Method
You can use this process pattern to include operations that are not provided from SAP. This process pattern uses the background task Synch. System
Method TS60807949. For more information, see BAdI: Calling of System Method for Rule-Based Workflow in MDG Customizing under General
Settings Process Modeling Workflow Rule-Based Workflow Business Add-Ins .
03 Call Sub-Workflow
You can use this process pattern to start a sub-workflow. The background task Subworkflow for Single Step Workflow TS60807994 starts a sub-
workflow with the workflow template ID that is read from the column Service Name of the non-user agent decision table.
04 Call Data Replication
You can use this process pattern to start the replication of the master data after the change request has been activated. This process pattern uses the
background task Change Request Replication TS60807976 and the method DISTRIBUTE of the object type MDG Change Request BUS2250 to
replicate the object using the data replication framework (DRF).
05 Activation (do not bypass snapshot)
You can use this process pattern to activate the data in the change request. This process pattern uses the background task Activate Change Request
TS60808002 with the indicator IGNORE_SNAPSHOT_DIFF not set. The value of Previous Action is updated with the result of the operation enabling
you to handle error situations. If there have been conflicting changes to the data in the standard master data tables while the change request was in
process the activation fails. In this case, Previous Action is set to 33 Activation failed for Snapshot . If the activation was successful Previous
Action is set to 31 Activation Successful . In all other cases, Previous Action is set to 32 Activation failed .
06 Activation (bypass snapshot)
You can use this process pattern to activate the data in the change request, even if the data has been changed in the backend since the change request
was created. The system ignores these potential changes and overwrites them. This process pattern uses the background task Activate Change
Request TS60808002 with the indicator IGNORE_SNAPSHOT_DIFF set.
07 Validate Change Request
You can use this process pattern to validate the change request data. The results are written to the application log. The process pattern uses the
background task Check Change Request TS75707952.
08 Roll Back Change Request
You can use this process pattern to remove the inactive data of the change request from the staging area if the change request should not be activated.
This process pattern also provides the information when and by whom the change request was released and sets the change request status to 06 Final
Check Rejected . The process pattern uses the background task Discard Change Request TS75707936.
98 Error
You can use this process pattern to handle errors and exceptions. The process pattern uses the background task Error Handler TS60807951.
99 Complete (Sub-)Workflow
You can use this process pattern to end the rule-based workflow instead of looping back.
This document describes how to enable a basic change request process using the MDG rule-based workflow. This basic change request process only
activates the change request after it was submitted. The process does not include any dialog step. To provide data governance capabilities, you need to
enhance the process adding further change request steps such as approving the change request.
The figure in this document shows a complete process.
The process starts with step 00 when the requester submits the change request. The next step 91 is the activation of the change request. If the change
request is successfully activated, its status is set to Final Check Approved and the process ends with step 99. If the activation fails, the change request is
rolled back in step 92, the change request status is set to Final Check Rejected , and the process ends.
Prerequisites
You have created a change request type and you have entered the template for rule-based workflow WS60800086 in Customizing activity Create Change
Request Type under General Settings Process Modeling Change Requests . In the following example configuration, the change request type
CR_TYPE is used.
Process
You need to perform the following steps in order to configure the rule-based workflow for the basic change request process:
1. Create necessary change request steps.
Define the change request steps 00, 91, 92, and 99 as shown in the figure in Customizing activity Define Change Request Steps for Rule-Based
Workflow under General Settings Process Modeling Workflow Rule-Based Workflow .
Change Request Type Change Request Step Description of Change Request Step
CR_TYPE 00 Request
CR_TYPE 91 Activation
CR_TYPE 99 Complete
CR Previous Step CR Previous Action Condition Alias New CR Step New CR Status
00 n.a. ACT 91 02
91 31 END 99 05
91 31 RB 92 02
92 n.a. END 99 06
The basic process contains only steps with background steps. Therefore, you only have to configure the Non User Agent table and the User Agent
table is left empty. In the figure all arrows pointing to the same change request step have identical condition aliases. These condition aliases have been
chosen to match the process pattern of this step.
You have to add a row in the Non User Agent table for each change request step and use the following information from the figure:
Condition Alias
Process Pattern
Note
The column Agent Group is only relevant for parallel processing. Use the value 001 to create one work item for a change request step.
If you look at the arrow with condition alias ACT from step 00 to step 91 with process pattern 05, the first row in the Non User Agent table contains the
condition alias ACT, agent group 001 and process pattern 05.
The following rows are needed in the Non User Agent table for the configuration of the complete basic process:
ACT 001 05
RB 001 08
END 001 99
After you have saved and activated the new entries for the Single Value table and the Non User Agent table, you can use the new change request
type.
This document describes how to enhance the basic change request process with a user agent step. In the basic process, a change request is immediately
activated after the requester submits the change request without further involvement of another user. In this enhanced process, a second user checks the
change request in an additional user-agent step. If this user decides to approve the change request, the activation is started with change request step 91.
Otherwise, the roll back of the change request is started with change request step 92. The other change request steps are not changed.
Note
The terms dialog step and user agent step are used as synonyms in MDG.
To enhance the basic process from the document Creating a Basic Change Request Process to the enhanced process described in this document, the new
step 90 Final Check with step type 2 Approve Change Request is added. The user symbol next to the step type indicates that this is a user-agent step. The
arrow from change request step 00 now points to the new change request step 90. The condition alias of this arrow was chosen as FC to abbreviate Final
Check. The arrow, depicting that the user has accepted the change request with action 03, points to the change request step 91. The condition alias ACT for
the change request step 91 is added to the arrow. The arrow, depicting that the user has rejected the change request with action 04, points to the change
request step 92. The condition alias RB for the change request step 92 is added to the arrow.
Prerequisites
You have configured the rule-based workflow for the basic change request process, as described in Creating a Basic Change Request Process. In the
following example process, the change request type CR_TYPE and the user FINAL_CHECK_USER are used.
Process
You need to process the following steps in order to extend the basic workflow with a user step:
1. Create the new change request step.
The new change request step for the user dialog is defined in Customizing activity Define Change Request Steps for Ruled-Based Workflow under
General Settings Process Modeling Workflow Ruled-Based Workflow .
Workflow Step Numbers
CR Previous Step CR Previous Action Condition Alias New CR Step New CR Status
00 n.a. FC 90 02
After this change, you have to add a new row to the Singe Value table for every arrow that is depicted in the figure Change Request Process Including
Dialog Tasks and not depicted in the figure Basic MDG Change Request Process. You have to add the following rows to configure the new sequence of
steps:
CR Previous Step CR Previous Action Condition Alias New CR Step New CR Status
90 03 ACT 91 02
90 04 RB 92 02
In the basic rule-based workflow, only background tasks are used. In the enhanced workflow described in this document, a dialog task is used. In the
User Agent table, you have to configure the user agent group, the change request step type, the user agent and the user agent value for the new
change request step 90. The following line with the condition alias FC for the new change request step is required:
Condition Alias User Agt Group Step Type User Agent Type User Agent Value
More Information
Rule-Based Workflow: Technical Details
1. Start Workflow
An instance of the rule-based workflow template is started when a user submits a change request of a type that has the rule-based workflow template
assigned. The same workflow template is also used to create sub-workflow instances for parallel processing.
2. Determine Change Request Type
The system determines the change request type; for example, Create Material or Change Material and stores the change request type in the workflow
container.
3. Check Assignment of Processor to Workflow
The system checks whether a processor is already assigned to the workflow, for example, the current workflow instance is a sub-workflow that was
started for parallel processing.
If a processor is not yet assigned, the system launches BRFplus. The BRFplus decision tables for the change request type are used to find the next
step, the process pattern, and the agents, based on the previous step and action. If the current workflow instance is the main workflow, the system also
refreshes the status of the change request.
4. Determine Whether Single Processing or Parallel Processing is Configured
The system determines the number of configured agent groups of the current change request step. An agent group can consist of a single user or
multiple users. For example, it might be necessary that users in the purchasing department and users in the accounting department should able to
approve the change request in parallel.
If more than one agent group is found, parallel processing is configured and the system proceeds as follows:
1. The system creates multiple workflow instances of the WS60800086 template: one for each agent group. These sub-workflows run in parallel.
2. As soon as all subworkflows are completed, the BAdI: Handling of Parallel Results in Rule-Based Workflow in MDG Customizing under
General Settings Process Modeling Workflow Rule-Based Workflow Business Add-Ins is called in order to merge the results of the
parallel subworkflows into one result and, based on those results, determines the next step of the change request process.
5. Branch by Process Pattern
Based on the determined process pattern, the workflow branches into one out of several basic operations of the rule-based workflow.
For more information, see Process Pattern
6. Check Workflow Completion
The system checks whether the process pattern was 99 Complete (Sub-)Workflow .
If this is the case the system completes the workflow.
If this is not the case the system returns to step 3 and starts again.
You can determine the extent to which users can make parallel changes to a hierarchy that belongs to a particular hierarchy type. A change to a hierarchy can
comprise adding a node, moving a node, removing a node, changing the attributes of a node, or creating a hierarchy. After a change to a hierarchy is saved to
a change request, changes to interlocked nodes must be saved to the same change request. The system determines which nodes are interlocked by referring
to the Interlocking setting in Customizing for the relevant hierarchy type.
Hierarchy nodes that represent business objects are technically distinct from the business objects themselves. Interlocking affects the parallel processing of
hierarchy nodes only.
The Interlocking setting applies to a Hierarchy Type and specifies which nodes besides the node being changed are interlocked while a hierarchy-specific
change is in process. The setting is described in the table below:
Loose Nodes assigned to the parent node of the node being changed.
Strict Interlocking propagates upwards and downwards from the parent node of the node
being changed:
Upwards interlocking interlocks the parent node and its assigned nodes, the
parent node of the parent node and its assigned nodes, and so on up to the
root node.
Downwards interlocking interlocks child nodes of the parent node, their
child nodes, and so on down to the end nodes. This comprises a
subhierarchy of interlocked nodes with the parent node at its root.
Prerequisites
To minimize business disruption, we recommend that you define the scope for changes to a hierarchy type when you define the hierarchy type within a data
model. You can only change the scope for changes to a hierarchy type when no pending change requests exist for any hierarchy of this type. If you must
change the scope after you have defined the hierarchy type and you must then transport your changes, ensure that no pending changes exist for the affected
hierarchies in the target system.
Interlocking – Loose
The figure below shows how the Interlocking setting of Loose affects a hierarchy in the scenario where Rome is added to Italy.
Interlocking – Loose
Loose interlocking affects all nodes that are assigned to the parent node of the node being changed. The node being changed is Rome and its parent
node is Italy. Only the direct child nodes of Italy - Rome and Milan - are interlocked with the pending change request.
Interlocking – Strict
The figure below shows how the Interlocking setting of Strict affects a hierarchy in the scenario where Rome is assigned to Italy in a pending change
request.
Upwards Interlocking
All nodes in the path from Italy to Global are interlocked. The child nodes of these nodes are also interlocked. Affected nodes include the following:
Italy (parent node), Rome and Milan (child nodes)
Europe (parent node of parent node), France and Italy (child nodes)
Global (root node), Asia and Europe (child nodes)
Downwards Interlocking
All nodes in the subhierarchy below Italy are interlocked. Affected nodes include the following:
Cities Rome and Milan, which are below country Italy (Also covered by upwards interlocking)
Teams I and J, which are below city Rome
Teams K and L, which are below city Milan
Any other nodes that might be added in the future to any nodes descending from Italy
In SAP Master Data Governance, you can navigate to user interfaces in the following ways:
Roles and Navigation
You use menu nodes provided in SAP NetWeaver Business Client to directly navigate to an application. The menu is defined using a PFCG role.
Object-and-Action Based Navigation
You navigate in this way to display or start the processing of master data objects.
Change-Request Based Navigation
You navigate in this way to display a change request that contains one or more master data objects that are being processed.
The starting point of a user to work with MDG is the menu provided by the PFCG role assigned to the user. The role SAP_MDGX_MENU_04 provides you with a
generic example that you can use to create a specific role for your needs.
For the authorizations that are required to use MDG, see SAP Master Data Governance Security Guide
Typically, there are several menu entries available:
Change Request Work List
The change request steps that require user interaction create work items that are displayed in the user’s change request work list. Technically, a POWL with
the configuration USMD_CREQUEST_POWL provides this function. To include the work list in the menu, create a menu entry with the following settings:
Configuration USMD_CREQUEST_POWL
Parameters
SYUNAME Use value X to show the change requests that the user created. Leave the value
empty to allow the user to select the displayed change requests.
Search
This entry provides access to the application specific or generic search of MDG. To include the generic search, create a menu node with the following
settings:
Configuration USMD_SEARCH_02
Parameters
USMD_OTC Enter the Object Type Code of the entity and data model for which the search
should be used.
See Configuring the Generic Search for a Particular Business Objectfor a list of supported parameters.
Create Change Request
The Create Change Request application allows users to create a change request. The user has the options to only provide a description without referencing
any object, to include a single object, or to include multiple objects to processing. For more information, see Creation of a Change Request.
The corresponding menu node is created with the following settings:
Parameters
PROCESS Use the ID of a business activity as the value to restrict the use of the application to
the corresponding data model and objects.
DISPLAY_TYPE Leave the parameters empty to allow the use to switch between collective
processing and hierarchy processing, if available for the selected object. Use the
value HIERARCHY to start the application in hierarchy processing mode and to
restrict the usage of the application to this mode. Use the value LIST to achieve the
same for collective processing mode.
Configuration USMD_WF_NAVIGATION
I_UI_CONFIGURATION {WDCONFIGURATIONID}
I_UI_APPLICATION {WDAPPLICATIONID}
I_CREQUEST {CREQUEST}
portal_bo_alias SAP_ERP_Common
2. Workflow Log
Configuration USMD_WF_NAVIGATION
CREQUEST {CREQUEST}
portal_bo_alias SAP_ERP_Common
3. Log
Description Log
USMD_RFCDEST {USMD_RFCDEST}
USMD_SHM_INSTANCE {USMD_SHM_INSTANCE}
portal_bo_alias SAP_ERP_Common
CREQUEST {CREQUEST}
CREQUEST_WORKITEM {CREQUEST_WORKITEM}
portal_bo_alias SAP_ERP_Common
5. Where-Used List
PROCESS {PROCESS}
USMD_RFCDEST {USMD_RFCDEST}
USMD_SHM_INSTANCE {USMD_SHM_INSTANCE}
portal_bo_alias SAP_ERP_Common
SYUNAME {SYUNAME}
USMD_RFCDEST {USMD_RFCDEST}
USMD_SHM_INSTANCE {USMD_SHM_INSTANCE}
portal_bo_alias SAP_ERP_Common
7. Change Documents
PROCESS {PROCESS}
USMD_RFCDEST {USMD_RFCDEST}
USMD_SHM_INSTANCE {USMD_SHM_INSTANCE}
portal_bo_alias SAP_ERP_Common
PROCESS {PROCESS}
DISPLAY_TYPE {DISPLAY_TYPE}
USMD_RFCDEST {USMD_RFCDEST}
USMD_SHM_INSTANCE {USMD_SHM_INSTANCE}
portal_bo_alias SAP_ERP_Common
PROCESS {PROCESS}
CREQUEST {CREQUEST}
portal_bo_alias SAP_ERP_Common
PROCESS {PROCESS}
USMD_RFCDEST {USMD_RFCDEST}
USMD_SHM_INSTANCE {USMD_SHM_INSTANCE}
portal_bo_alias SAP_ERP_Common
PROCESS {PROCESS}
USMD_RFCDEST {USMD_RFCDEST}
USMD_SHM_INSTANCE {USMD_SHM_INSTANCE}
portal_bo_alias SAP_ERP_Common
CREQUEST {CREQUEST}
WDCONFIGURATIONID {WDCONFIGURATIONID}
USMD_MODEL {USMD_MODEL}
You use object-and-action based navigation to display or to start the processing of master data objects.
The typical navigation sequence for the user is as follows:
1. Launch the search application from the SAP NetWeaver Business Client (transaction NWBC).
To do this, you can choose an entry from the role menu, click a link from the service map, or click a link from the home page.
2. Search for an object.
You search for a business object of interest and display the object in a new window. By clicking the link to display the business object, you initiate a
logical action. Another possibility is choosing the New button. In all cases, the system opens a new window with the target UI.
3. Process the object in the target user interface.
Sometimes you can directly edit the object in the target user interface and sometimes you must choose the Edit button first. Choosing the Edit button
triggers another logical action.
Features
The user can still override the defaults you set by selecting different options on the user interface.
If you specify a Business Object Type with the parameter USMD_OTC, users can no longer change the data model and the entity type. For more information
on the required parameters, see Configuration of the Generic Search.
Note
In the following description, the Generic Search is used as an example of the Current UI .
If you do not specify the USMD_OTC parameter for the USMD_SEARCH Web Dynpro application, the system derives an Business Object Type for the data
model and entity type based on Customizing.
The relevant settings are as follows:
Activity: Customizing for Master Data Governance, Central Governance (transaction MDGIMG) under General Settings Data Modeling Edit Data
Model
View: Business Object Type
When a user clicks a link to a business object, the system triggers logical action DISPLAY. Further logical actions are possible, for example CREATE. The
availability of logical actions (defined in Customizing for Master Data Governance under Process Modeling Business Activities Define Logical
Actions ) depends on the UI, the UI configuration, and the state of the chosen business object type.
Note
If the current UI application is the generic single-object processing UI USMD_OVP_GEN and the same UI is also the target UI application, the system
ignores the value of Configuration ID from the view User Interface per Change Request Step . Instead, USMD_OVP_GEN uses its current configuration for
the initial change request step.
Change-request based navigation occurs when you start processing a change request. Navigation possibilities include the following:
Opening the relevant work item from the inbox.
Searching for and selecting a change request in My Change Requests .
Searching for a business object and clicking the Pending Change Requests icon.
Features
Note
If the system cannot determine a target UI based on the logic described above, the target UI is the obsolete single-object processing UI
USMD_ENTITY_VALUE2. In this case, the system determines the application configuration ID for USMD_ENTITY_VALUE2 in the Entity Types view of
the following activity in Customizing for Master Data Governance, Central Governance : General Settings Process Modeling Change Requests
Create Change Request Type .
You can apply system settings that allow you to monitor in detail how effectively your organization processes change requests. You can analyze the statuses
of change requests in your organization, the processing times of change requests in your organization, and the nature of change requests involving you. For
more information, see Analysis of Change Requests.
Procedure
Enabling the detailed analysis of change requests involves completing the following tasks:
1. Configuring Operational Data Provisioning
2. Activating Business Information (BI) Content in Master Data Governance
3. Setting up the business context viewer
4. Assigning roles to your user
5. Changing authorization objects
6. Integrating SAP BusinessObjects Dashboards
7. (Optional) Defining a service-level agreement
Note
After you activate the business context viewer, you can configure a side panel for any Web Dynpro application.
MDG_MONITOR_CR_PROCESTIME Used for the analysis of the status of change requests or the processing time of
change requests.
MDG_ANLY_CR_REJ_REASON Used to display the reasons why change requests were rejected.
Note
You can view and edit roles using transaction PFCG . The Menu tabbed page shows Web Dynpro applications. Often, existing roles that use the required
Web Dynpro applications have technical names with suffixes of *_MENU.
If you do not have the required roles, consider the following options:
Assign the Master Data Governance: Analytics (SAP_MDGA_MENU) role to your user.
SAP Master Data Governance Specify the types of change requests Change Request Type Specify the level of the access allowed
Type of Change Request users are allowed to analyze and the to each the change request types
(USMD_CREQ) level of access allowed. specified under Activities . As a
minimum, choose Display . Choose
other options, if required.
Caution
Be careful when using wildcards;
you do not want to accidentally
provide access to incorrect change
request types.
Business Context Viewer Specify the Web Dynpro applications Context Key Enter the following context keys:
Execute Side Panel (BCV_SPANEL) requiring a side panel. MDGAF_MYCR
The application is the
Application Framework (MDGAF)
and the object is My Change
Requests (MYCR). Specifying
this context key enables a side
panel for the My Change
Request screen.
MDGAF_ANLY
The application is the
Application Framework (MDGAF)
and the object is (ANLY).
Specifying this context key
enables a side panel for the
Status (Graphic View) screen,
which is used to analyze the
status of change requests.
Front End Integration Xcelsius Authorization for working with SAP RSXCLSID Specify the technical name of the
Dashboard (S_RS_XCLS) BusinessObjects Dashboards. dashboard: 0XC_MDG_MONITOR_CR.
5. Save the authorization profile and choose the ( Generate Authorization Profile ) icon.
Integrating Dashboards
For an overview of how to integrate dashboards, see Xcelsius Enterprise Integration
SAP Business Objects dashboards only work if a BI Java server is enabled. For more information, see SAP Note 1450981
Result
After completing this procedure, it is possible to access meaningful analytical information about change requests.
You use this function to make the necessary settings for data replication within the Data Replication Framework (DRF). Data is replicated to business systems
that are assigned to outbound implementations of replication models (see graphic below).
Features
SAP supplies most of the objects and assignments as standard, such as the following:
Business objects
Filter objects
Outbound implementations
Service operations
Note
You can view the objects and assignments that SAP supplies as standard in Customizing. More information is available in Customizing for Master Data
Governance, Central Governance under General Settings Data Replication .
However, you must configure your replication model. This involves the following:
Definition of replication model
Define your replication model and enter a description.
Definition of the receiving systems of your replication model
Enter one or more systems in which you want to replicate the data.
Caution
When you transfer your Customizing settings to the production system, you must subsequently check and adjust the assignment of the replication
model to the receiving systems.
Note
The following communication channels are available for data replication purposes:
RFC
IDoc
Enterprise Services
File download
Ensure that you use only those communication channels that are supported by your replication model.
One or more outbound implementations can be used for each replication model. This means that different data can be transferred in different ways for a
certain replication model. This depends on the attributes of the outbound implementations that are assigned to the replication model.
Definition of additional parameters per outbound implementation
Activities
You configure your replication model in Customizing for Master Data Governance, Central Governance under General Settings Data Replication
Define Custom Settings for Data Replication Configure Replication Models .
For further prerequisites for data replication, see Customizing for Master Data Governance, Central Governance under General Settings Data
Replication Overall Information .
You can replicate master data stored within MDG as well as reference data, stored in configuration tables. The replication process is slightly different in each
case.
MDG offers the following options to store active master data (data that has been approved):
The reuse option used by MDG-M and MDG-S stores data in the SAP ERP tables such as MARA or LFA1.
The flex option used by MDG-F and MDG for Custom Objects stores data in generated tables.
In both options, inactive master data (data that has not yet been approved) is stored in the generated tables.
Data that the MDG system replicates to target systems is always active data. The MDG system takes the active data from the SAP ERP tables or from the
generated tables depending on the option in use (reuse option or flex option).
MDG applications such as MDG-M, MDG-S, and MDG-F include standard implementations of the Data Replication Framework (DRF) that read the data and
send the messages to the target system. The standard implementations support key mapping and value mapping.
Prerequisites
At least one data model, with entity types, attributes, and relationships is defined using the flex model. The user interface, workflow, and processors are
defined.
Prerequisites for the replication of Reference data are as follows:
1. The target system of replication is a development system.
2. The user who replicates the data has the same ID in the source system and in the target system.
3. The RFC destination for the target system has the following settings:
1. Under Logon & Security , you have selected Trust Relationship .
2. Under Logon & Security Logon Procedure , you have selected Current User .
4. In the target system, the user who replicates the data is added to the list of RFC Users authorized to execute RFC calls in trusted systems.
Procedure
Note
You can adjust the generated function module according to your needs, for example, in the case of reference data, you can omit the release of
the transport request in order to enable data enrichment. The user can then release the transports manually.
Example
Select the CARR entity type and all of its attributes. Choose the Name ABAP Dictionary Objects button. Enter the following details for the new
structure:
Interface Model ID = ZZ_SFLIGHT
Interface Model Description = SFlight Outbound Model (ZZ)
Object Type Code = ZZSF
Package Name = Z_ZZ_FUNC_GROUP
Name = ZZ_SFLIGHT
Description = Generated RFC for SFlight Outbound Model (ZZ)
Note
A complex filter such as the one in the example does not require a table name. The system only requires table names for simple filters. Such
filters are only available for standard applications that are built using the reuse option.
2. Define the filters for the filter object in the Assign Filters subview.
If required, you can define your own structure to include all relevant fields from the generated table. In the Assign Filters view, apply the following
settings.
1. For the Filter field, use codes between 80 and 99. This range is assigned to the customer namespace.
2. Specify a filter class. Example: Use the generic Filter Class CL_MDG_OIF_DRF_FILTER .
8. Assign a filter object to a business object type (specific filtering) or to an outbound implementation.
Assignment of a filter object to a business object type (specific filtering).
Path: Customizing for Data Replication (transaction MDGIMG ) under Enhance Default Settings for Outbound Implementations Define
Business Objects and Object Identifiers Assign Filter Objects to Business Objects
Assignment of a filter object to an outbound implementation:
Path: Customizing for Data Replication (transaction MDGIMG ) under Enhance Default Settings for Outbound Implementations Define
Outbound Implementations
Example: Business Object Type = ZZSF ; Filter Object = ZZSF_FR00T ; Outbound Interface Model ID = ZZ_SFLIGHT
9. Create a filter to indicate precisely what data you want to replicate.
1. Run transaction DRFF .
2. Select the Business Object for which you want to define filter criteria.
Example: SFLIGHT (Flex Option) .
3. Define a filter.
Example: Under Filter Criteria to Include Business Objects , choose Airline local currency is EUR .
10. Create a replication model, assign the outbound implementation to the replication model, and assign the business systems that act as target systems
for replication to the combination of the outbound implementation and the replication model. Each replication model specifies one or more outbound
implementations.
1. Create a replication model.
Client-Specific Path: Customizing for Data Replication (transaction MDGIMG ) under Define Custom Settings for Outbound Implementations
Define Replication Models
Example:
In the Define Replication Model view, create a new entry with the following settings:
Replication Model = ZZSF ; Description = Replication Model for SFLIGHT ; Log -Days : 15 .
Select the new entry.
2. Assign an outbound implementation to the replication model.
Example: In the Assign Outbound Implementation view, apply the following settings: Outbound Implementation = ZZSF_01 ; Communication
Channel = 4 Replication via RFC ; Replication via RFC ; Filter Time = 2 Filter After Change Analysis .
Select the assigned Outbound Implementation.
3. Assign the business system or business systems to which you want to replicate data using the combination of the replication model and the
outbound implementation.
Example: Open the Assign Receiver Systems view, and enter the following value: Business System = QV5_410
4. Activate the replication model.
Choose the Activate Replication Model pushbutton.
Note
You can adjust the generated function module according to your needs, for example you can omit the release of the transport request in order
to enable data enrichment. The user can then release the transports manually.
Example
Select the CARR entity type and all of its attributes. Choose the Name ABAP Dictionary Objects button. Enter the following details for the new
structure:
Interface Model ID = ZZ_SFLIGHT
Interface Model Description = SFlight Outbound Model (ZZ)
Object Type Code = ZZSF
Package Name = Z_ZZ_FUNC_GROUP
Name = ZZ_SFLIGHT
Description = Generated RFC for SFlight Outbound Model (ZZ)
2. Wizard step: Select Entity Types and Attributes . Select entity types and attributes you want to include in the interface model. Then enter names
for the resulting dictionary objects, by choosing the Name ABAP Dictionary Objects button.
Example: Select the CARR entity type and all of its attributes. Choose the Name ABAP Dictionary Objects pushbutton. Enter the following
details for the new structure:
Structure Name = ZZSF_S_CARR
Structure Description = Structure for CARR
Table Type Name = ZZSF_T_CARR
Table Type Description = ZZSF_T_CARR
3. Wizard Step: Review and Submit . Review and submit your work. Create a transport request or assign an existing transport request. You can use
the same transport to transfer the function module to the target system later on.
4. Wizard Step: Check Application Log . Check the application log that displays after you review your submitted work.
5. Review the code of the function module. Run transaction SE80 . Open the Repository Browser and browse by the Function Group you created
earlier. Open the Function Modules folder, and review the system-generated function module for the outbound interface model.
The outbound implementation you define in the data replication framework calls this function module to replicate the data.
2. Create a mapping using the service mapping tool to map data from the staging area in the source system to the reuse table in the target system.
Ensure the following:
The source structure is the data model-specific structure for the outbound interface model.
The source structure uses the flex option and the target structure uses the reuse option.
Path: Customizing for Master Data Governance, Central Governance (transaction MDGIMG ) under Data Modeling Generate Data Model-Specific
Structures
3. Maintain a mapping table to map the tables to the objects.
Run transaction SM30.
Example:
Table Name : ZFX_S_ZT024E .
Specified when you created an outbound interface model.
Object : V_T024E
The target business object stored in Customizing.
Type : view.
SMT_Mapping : ZF_PO_MAP .
Created previously in the Service Mapping Tool (SMT).
You can use this Web Dynpro application (WDA_OIF_MANAGE) to define outbound interface models.
More Information
You execute this function in Customizing for Master Data Governance. For more information, see SAP Customizing Implementation Guide Cross-
Application Components Processes and Tools for Enterprise Applications Master Data Governance General Settings Data Replication Enhance
Default Settings for Outbound Implementations Define Outbound Interface Models .
You can use value mapping to map the code values for customizing elements that are represented in the system to the code values of a named external list.
The external list can be a global code list or a system-specific code list.
Prerequisites
Features
When implementing value mapping, you have the following options:
Use of a Global Code List (see Prerequisites section)
For more information, see Value Mapping: Use of Global Code Lists.
Use of a System-Specific Code List (see Prerequisites section)
For more information, see Value Mapping: Use of System-Specific Code Lists.
You use this process to implement value mapping using global code lists. We recommend you use a global code list for inbound and outbound mapping to
target systems if you are using enterprise service-oriented architecture (eSOA) communications or if target systems support value mapping.
Process
The following steps describe value mapping for a selected value when you use a global code list. The selected value is the Company form of address.
1. Outbound Processing on the MDG Hub
When the MDG hub sends a message that contains the Company form of address, the system converts the internal code defined for the MDG hub
(0004) to the code defined for the message (0003). See graphic below.
The value mapping configuration information shown in the graphic is summarized in the table below.
Values come from one of the global code lists for the Global Data Type Values come from the AD_TITLE data element. This data element is
(GDT) FormOfAddressCode. This code list has a list agency ID of associated with the AD_TITLE domain.
MDG_GLOBAL and a list version ID of 1. Codes are 0001 = Ms., 0002 = Mr., and 0004 = Company.
Codes are 0001 = Ms. ., 0002 = Mr., and 0003 = Company. Values are mapped to the values described in the Values in the Message
Values are mapped to the values described in the Internal Values (MDG column.
Hub) column.
The value mapping configuration information shown in the graphic is summarized in the table below.
Values come from one of the global code lists for the Global Data Type Values come from the AD_TITLE data element. This data element is
(GDT) FormOfAddressCode. This code list has a list agency ID of associated with the AD_TITLE domain.
MDG_GLOBAL and a list version ID of 1. Codes are 0002 = Ms., 0001 = Mr., and 0003 = Company.
Codes are 0001 = Ms., 0002 = Mr., and 0003 = Company. Values are mapped to the values described in the Values in the Message
Values are mapped to the values described in the Internal Values column.
(Target System) column.
You use this process to implement value mapping using system-specific code lists. You must use a system-specific code list if you are using Application Link
Enabling (ALE) communications or if target systems do not support value mapping.
Process
The following steps describe value mapping for a selected value when you use a system-specific code list. The selected value is the Company form of
address.
1. Outbound Processing on the MDG Hub
When the MDG hub sends a message that contains the Company form of address, the system converts the internal code defined for the MDG hub
(0004) to the code defined for the message (0003). See graphic below.
The value mapping configuration information shown in the graphic is summarized in the table below.
Customizing for key mapping under General Settings Key Mapping is recommended but not mandatory. You can use key mapping instantly, without
doing any Customizing.
The use cases for Customizing key mapping are as follows:
Changing Default Key Mapping Settings
Extending Key Mapping Settings for Existing Business Objects
Typically, you extend existing key mapping settings by adding new object IDs.
Extending Key Mapping Settings for New Business Objects
The Customizing activities you use to extend key mapping do not enable key mapping. After you define elements such as object IDs, you must implement
them in code. You can refer to the code for existing key mapping entries to implement new key mapping entries.
1.1.2.1.9 Analytics
You can configure content in the SAP Master Data Governance system so that it can be analyzed in a range of analytical tools. Analysis can involve asking
business-specific questions either about the process or about the data.
Configuration instructions are available for each of the following tasks:
Enabling Detailed Analysis of Change Requests
Analysis of the process. For example, provide the data that can answer the question: how many change requests are in process between two dates?
Extracting Business Object Data Using Generated Data Sources
Analysis of the data. For example, provide the data that can answer the question: how much revenue do you generate from customers in a particular
region?
Extracting Key Mapping Data.
You can use key mapping data to consolidate InfoObjects that are incorrectly represented more than once because of differing keys. This improves the
accuracy of your reporting.
You can apply system settings that allow you to monitor in detail how effectively your organization processes change requests. You can analyze the statuses
of change requests in your organization, the processing times of change requests in your organization, and the nature of change requests involving you. For
more information, see Analysis of Change Requests.
Procedure
Enabling the detailed analysis of change requests involves completing the following tasks:
1. Configuring Operational Data Provisioning
2. Activating Business Information (BI) Content in Master Data Governance
3. Setting up the business context viewer
4. Assigning roles to your user
5. Changing authorization objects
6. Integrating SAP BusinessObjects Dashboards
7. (Optional) Defining a service-level agreement
Note
After you activate the business context viewer, you can configure a side panel for any Web Dynpro application.
MDG_MONITOR_CR_PROCESTIME Used for the analysis of the status of change requests or the processing time of
change requests.
MDG_ANLY_CR_REJ_REASON Used to display the reasons why change requests were rejected.
Note
You can view and edit roles using transaction PFCG . The Menu tabbed page shows Web Dynpro applications. Often, existing roles that use the required
Web Dynpro applications have technical names with suffixes of *_MENU.
If you do not have the required roles, consider the following options:
Assign the Master Data Governance: Analytics (SAP_MDGA_MENU) role to your user.
This role only contains the relevant Web Dynpro applications.
Create your own role and add the Web Dynpro applications to that role.
If you do this, you can control the placement of Web Dynpro applications on the menu in the user interface.
SAP Master Data Governance Specify the types of change requests Change Request Type Specify the level of the access allowed
Type of Change Request users are allowed to analyze and the to each the change request types
(USMD_CREQ) level of access allowed. specified under Activities . As a
minimum, choose Display . Choose
other options, if required.
Caution
Be careful when using wildcards;
you do not want to accidentally
provide access to incorrect change
request types.
Business Context Viewer Specify the Web Dynpro applications Context Key Enter the following context keys:
Execute Side Panel (BCV_SPANEL) requiring a side panel. MDGAF_MYCR
The application is the
Front End Integration Xcelsius Authorization for working with SAP RSXCLSID Specify the technical name of the
Dashboard (S_RS_XCLS) BusinessObjects Dashboards. dashboard: 0XC_MDG_MONITOR_CR.
5. Save the authorization profile and choose the ( Generate Authorization Profile ) icon.
Integrating Dashboards
For an overview of how to integrate dashboards, see Xcelsius Enterprise Integration
SAP Business Objects dashboards only work if a BI Java server is enabled. For more information, see SAP Note 1450981
Result
After completing this procedure, it is possible to access meaningful analytical information about change requests.
To enable external analysis of master data, you can generate datasources for entity types that have corresponding business object types.
Procedure
Example
Here is an example of the code to fill the IOBJNM attribute of the C_T_HIENODE table with the name of each information object representing
the hierarchy node.
IF i_datasource = '0MDG_T1_BP_HEADER_HIER'.
LOOP AT c_t_hienode ASSIGNING ls_hienode.
<ls_hienode>-iobjnm = 'ZMDGBPHRY'.
ENDLOOP.
Maintain Datasources
After creating datasources, you can choose to maintain them as you see fit.
1. Run transaction SM30. The Maintain Table Views program opens.
2. Open table view MDGV_ANLY_DSOURC and maintain the data sources.
The names of generated structures use the following syntax:<Prefix / Namespace>_S_<Data Model>_EX_<Name of Entity Type>
The letter S represents structure and the letters EX represent extraction.
Example
ZMY_S_ZG_EX_ALLIANCE.
Transaction RSA1: SAP NetWeaver Business Intelligence System: Replicate the DataSources of the Source System and
Their Metadata
Replicate all SAP Master Data Governance datasources from the source system to the target system.
1. In the BI system, run transaction RSA1.
In the Modeling column, Source Systems is selected.
2. Navigate to the source system. Right-click the source system and choose Replicate Datasources and then choose Replicate Metadata.
Key mapping in SAP Master Data Governance identifies when two or more representations of the same business object exist with different keys. You can
extract key mapping information available to BW. This makes it possible for you to create consolidated InfoObjects for such scenarios, and so improve the
accuracy of your data analysis.
Procedure
Transaction RSA1: SAP BI System: Replicate the DataSources of the Source System
Replicate all SAP Master Data Governance data sources from the source system to the target system.
1. In the BI system, run transaction RSA1.
In the Modeling column, Source Systems is selected.
2. Navigate to the source system. Right-click the source system and choose Replicate Datasources .
The delivery of SAP Master Data Governance contains example configurations for several capabilities that allow you to explore the supported processes and
functions for the user as well as how to configure the supported processes and functions.
The examples are based on the Flight Data Model demonstration and education content.
Prerequisites
You have activated the Master Data Governance, Generic Functions 8.0 (MDG_FOUNDATION_6) business function.
To enable the example, see Enabling the Configuration Examples.
Examples
Process Airlines
Based on a simplistic data model of a single entity type, you can explore the following functions:
Search
Display
Single-Object Processing and Multi-Object Processing
Copy
Mass Change
Multiple-Record Processing
File Upload and File Download
Hierarchy Processing
Data Quality Remediation
Process Flight Connections
This example shows you how to combine multiple entity types to a larger business object with selected functions as already included in the Process
Airlines example.
Analyze Change Request Process
This example demonstrates the reporting capabilities on change requests.
Example Content
Role SAP_MDGX_FND_SAMPLE_SF_05
Provides you with authorizations and a menu for SAP NetWeaver Business Client to work with the example.
Data Modeling
The data model SF that uses the Flight Data Model data base tables for airlines (SCARR) and for flight connections (SPFLI and SFLIGHT) as active
area. It also contains entity types that use MDG as the active area.
UI Modelling
Configurations of the generic search USMD_SEARCH and the generic single-object processing application USMD_OVP_GEN allow you to search and
process airlines and flight connections.
Data Quality and Search
A minimal configuration shows how to use a simple data base comparison for the duplicate check integration into the change request process. It also
contains examples that show how to integrate a data quality service so that the result of a data quality check can be used to start a data quality
remediation process in MDG.
Process Modeling
Change request types and related Customizing offer a simple change request process with request, process and approval steps.
The example content is either provided as Customizing that is contained in BC Sets or provided as workbench objects that are part of the ABAP package
MDG_FOUNDATION_SAMPLE. For more information, see Enabling the Configuration Examples.
This description provides the information to setup the examples of Master Data Governance for Custom Objects.
Prerequisites
You have activated the business function Master Data Governance, Generic Functions 8.0 (MDG_FOUNDATION_6).
Process
1. Setup of the Organizational Structure
The assignment of processors to the workflow steps of the change request is done by using organizational structures. This structure needs to be
available before the activation of the BC Set in one of the next steps. Create 2 positions, and 1 organizational unit for this assignment. The identification
numbers are generated by the system and are different in each client. You can use transaction PPOC to create these structures and also to assign
users to these structures. This configuration description assumes an organizational structure as depicted below.
Note
You can display the codes and IDs of the objects by using the Column Configuration. You need the IDs when activating the BC-Set containing the
change request types. You can use the same user and assign it to each position. This will allow you to go through the change request process with
one single logon and is therefore easier to use. However, to demonstrate the segregation of tasks, it is recommended to use a dedicated user for
each of the positions.
Note
The BC Sets assume a configuration of priorities for change requests. Use the Customizing activity Define Priorities for Change Requests under
General Settings Process Modeling to check whether there are defined the priorities 1 (High) , 2 (Medium) , and 3 (Low) . If this is not the
case, these priorities have to be created before activating the BC Set. You can activate the BC Set CA-MDG-AF-FS_SFLIGHT_CR_PRIOS to
define the priorities.
During the activation the system prompts you to enter the IDs of the organizational structures you want to use for agent determination. The values that
you need to enter depend on how you have set up the organizational structure in step 1. Using the example values from step 1, you would have to enter
the following values:
Agents: Flight Operations Manager — 50001128
Agents: Flight Application Process Expert — 50001127
Note
You can activate this BC Set in multiple clients to be able to execute the scenarios independent in each client.
If the system raises errors during the activation of BC Sets that come from other configuration data for example, from change request types that are
not contained in the BC Set, the activation fails. You first need to repair the error in the respective Customizing activity.
Result
The users that you have assigned to the organizational structure in step 1 are able to execute the Master Data Governance for Custom Objects Example.
Note
You can execute the report SAPBC_DATA_GENERATOR to populate the Flight Data Model with example data like airlines, airports, or cities. This example
data will give you a better impression of the example.
For greater flexibility you want to be able to develop new UIs that enhance your Master Data Governance applications and are consistent with the existing
software. A number of developments in the Master Data Governance Application Framework (MDGAF) allow you greater freedom to build UIs for applications.
Governance API
Convenience API
Application Context API
Communicator
Change Request UI Building Block (CRUIBB)
The configuration of components is shown below:
Features
Governance API
The Governance API covers the entire governance process, handling processes that are not UI-related, and background services such as master data load
and data replication.
The Governance API is designed to handle multiple change requests simultaneously. At any time, one instance of the Governance API can exist in the
system per data model.
The Governance API also provides services to the convenience API. There is less grouping of functions than in the Convenience API so that you can
combine a greater range of individual methods to meet the needs of the application. The Governance API also provides services for UI issues, but the
applications access these services through the Convenience API, which then calls the Governance API.
The Governance API Class ID is CL_USMD_GOV_API (IF_USMD_GOV_API).
Convenience API
The Convenience API provides the functionality needed for an application to work with a change request. It can handle one change request for a single data
model at a given time. The Convenience API takes over all governance-relevant logic such as managing change request data, handling change requests, and
routing change requests to the Governance API. The Convenience API groups together some of the methods of the Governance API ensuring tighter control of
the change request-handling capability available to the applications, and simplifying the use of UI services for applications. The application manages only the
application data.
The Convenience API Class ID is CL_USMD_CONV_SOM_GOV_API (IF_USMD_CONV_SOM_GOV_API).
Communicator
The Communicator allows the user to work with the change request and ensures consistency of change request handling prerequisites, such as change
request type, change request ID, and work item ID. When a user begins working with a change request, the Communicator recognizes missing parameters and
initiates user interaction accordingly, for example, requesting the user to specify a change request type if none has yet been specified.
Change Request UI Building Block (CRUIBB)
This UI component is included in application-specific UIs and handles the presentation of change request data in Web Dynpro applications, ensuring a
consistent UI layout for change request data across all applications. The CRUIBB contains data such as CR description, priority, reason for CR, notes, and
attachments. Applications need to manage the application data only.
A hierarchy is tree-like structure consisting of hierarchy nodes that is identified by its hierarchy name. The hierarchy type defines which objects can be used
as nodes. The configuration of hierarchies is centered around the hierarchy type. You use entity types in the MDG Data Model to create a hierarchy type.
Example
An airline hierarchy has a hierarchy type based on entity type Airline (CARR) and a hierarchy name based on entity type Names of Hierarchies of Airlines
(CARR_HIER)
Integration
You can start processing hierarchies from the results list of the Generic Search application, if it is configured for use with hierarchies. For more
information, see Search Business Object.
Collective Processing (USMD_ENTITY) allows users to structure and restructure a hierarchy. For more information, see Collective Processing.
You can open single-object processing for individual business objects displayed in the List View and in the Hierarchy view of the Collective
Processing application. For more information, see Single-Object Processing
(Applicable to selected business object types in SAP Master Data for Custom Objects and SAP Master Data Governance for Financials only) You
can assign individual business objects to hierarchies in the Hierarchy Assignment block of Single-Object Processing, if the appropriate change request
type is configured. For more information about the end user process, see Hierarchy Assignments in Single-Object Processing
Note
After working with a hierarchy assignment, users must finalize the change request before the system allows them to add, delete, remove, or change
the hierarchy properties of other hierarchy nodes that have the same parent node.
You can upload and download hierarchies in the relevant applications. For more information, see the following:
File Upload (USMD_FILE_UPLOAD)
File Download (USMD_FILE_DOWNLOAD)
You can change multiple master data objects at the same time through integration with the Mass Change process.
When you change data in Collective Processing , the process of either creating a new change request or assigning an existing change request to your
changes is supported.
Procedure
Note
All paths to Customizing mentioned in this document are in Customizing for Master Data Governance, Central Governance under General Settings .
When configuring hierarchy types, you need to answer the following questions, which are grouped based on their corresponding settings:
Data Modeling: Which entity type is a used as a hierarchy type? Is the hierarchy type synchronized? Is the hierarchy type version-dependent?
Data Modeling: Is the hierarchy type edition dependent?
You can use editions to schedule changes to business objects and hierarchies. For more information, see Using Editions to Schedule Changes.
Data Modeling: Which other entity types can be represented as nodes in hierarchies of this hierarchy type? Which entity type defines the root node
(Hierarchy Name)? For which entity types in the hierarchy are ranges permitted on end nodes?
Data Modeling: How do you define the relationships between nodes in a hierarchy of this hierarchy type?
For example, you can set credit / debit balances indicators on the account assignment in a financial reporting structure.
Data Modeling: What authorizations on the various levels of the hierarchy should the nodes have?
UI Modeling: Do you want to create a user interface for single-object processing that allows assignment of single objects to hierarchies?
Process Modeling: If the hierarchy type is version-dependent, which versions are defined?
Process Modeling: Which change request types are defined for the creation and processing of hierarchy types?
Process Modeling: When a user creates a change request for a hierarchy assignment, which nodes does the system interlock with the pending change
request?
Data Quality and Search: Which validations apply to the relationships between hierarchy nodes?
When a hierarchy node is expanded in the Collective Processing user interface, how many nodes should display?
Values: If the entity type is used as a hierarchy type, the field starts with Yes .
Requirement:
Assign the storage and use type 1 (Changeable via Change Request) to this
entity type.
Example:
A profit center group is the hierarchy type of a profit center hierarchy.
If versions of hierarchies can exist, the field starts with Yes and states that
the hierarchy type is Version Dependent .
Example:
The hierarchy can have a planning version and a current version.
If subhierarchies must be synchronized in all hierarchies they belong to, the
field starts with Yes and states that the hierarchy type is Synchronized
Example:
The structure of the synchronized subhierarchy Oyster Airline Alliance is
mirrored in hierarchy Airline Alliances - Regional and hierarchy Airline
Alliances - Tiered .
Version-Dependent Hierarchies
If the Oyster Airline Alliance hierarchy is version dependent, it can have a planning version and a current version. If it is not version dependent it can only have
one version (see figure below).
Values: Edition .
Hierarchies can use Editions. For more information, see Using Editions to
Schedule Changes.
Note
If you create an edition-dependent hierarchy, all business objects that
belong to that hierarchy and for which you have created user interface
building blocks (UIBBs) in single-object processing, must also be edition-
dependent.
No Edition
Hierarchies cannot use editions.
Data Modeling: Which other entity types can be represented as nodes in hierarchies of this hierarchy type? Which entity
type defines the root node (Hierarchy Name)? For which entity types in the hierarchy are ranges permitted on end nodes?
You specify the entity types that can be represented as nodes in a hierarchy. Each Entity Type has a designated use.
View: Inactive Data Models Entity Types Entity Types for Hierarchies
Setting: Use
Data Modeling: How do you define the relationships between nodes in a hierarchy of this hierarchy type?
Views: Inactive Data Models Entity Types Entity Types for Hierarchies
Hierarchy Attributes
For example, you can set credit/debit balances indicators on the account
assignment in a financial reporting structure. You can specify a hierarchy
attribute for a relationship using a data element. You can specify an
alternative data element if it is technically identical. .
Inactive Data Models Entity Types Entity Types for Hierarchies
Hierarchy Attributes from References
For example, you can set credit/debit balances indicators on the account
assignment in a financial reporting structure. You can specify a hierarchy
attribute for a relationship using a reference to an entity type. If you want to
add hierarchy attributes to the relation of the entity type for which the
hierarchy has been defined you have to specify it in the Entity Types for
Hierarchies view
Data Modeling: What authorizations at the various levels of the hierarchy should hierarchy nodes have?
In the Customizing activity Define Authorization Relevance per Entity Type , you can determine whether authorization is relevant for objects on every level of
the hierarchy (see table below).
Customizing Activity: Data Modeling Define Authorization Relevance per Entity Type
This activity indicates which parts of the hierarchy are authorization relevant, but
does not define the authorizations themselves.
More Information The authorization object for master data is USMD_MDAT and the authorization object
for hierarchies is USMD_MDATH. The standard role for a Master Data Governance
Administrator is SAP_MDG-ADMIN
For more information, see Authorization Objects and Roles Used by SAP MDG,
Central Governance
UI Modeling: Do you want to create a user interface for single-object processing that allows assignment of single objects
to hierarchies?
You can adapt the single-object processing user interface so that it includes a Hierarchy Assignment block (see link in table below.)
More Information For general information about creating a single-object processing user interface,
see Creating User Interfaces for Single Object Processing.
For hierarchy-specific information, see Creating a UI for Hierarchies.
Process Modeling: If the hierarchy type is version-dependent, where are the versions defined?
You can define hierarchy versions in Customizing.
Process Modeling: Which change request types are defined for the creation and processing of hierarchies?
You can create change requests that are relevant both to single-object processing and collective processing of hierarchies. The initial settings are described in
the table below.
Before You Start Identify which entity type is used as the hierarchy type, by referring to the following
section of this document:
Data Modeling: Which entity type is a used as a hierarchy type? Is the hierarchy
type synchronized? Is the hierarchy type version-dependent?
Example
This example is for change request type CCT2P2 that can be used to create a
cost center and that allows hierarchy assignments in the creation of the cost
center.
Type of Change Request
Type of Change Request: CCT2P2
Description: Create Cost Center with Hry. Assignments
Main Entity Type: CCTR. This is the entity type for a cost center, on
which the change request type is based.
Edition Type: OG_ALL.
Single-Object: Checkbox selected as this is a change request
type to create individual cost centers.
Type of Change Request Entity Type
CCTR
CCTRG. This entity type represents the cost center group,
which is the hierarchy type.
CCTRH
Process Modeling: When a user creates a change request for a hierarchy assignment, which nodes does the system
interlock with the pending change request?
Setting: Interlocking
Values: Loose interlocking interlocks nodes assigned to the parent node of the node being
changed.
Strict interlocking propagates upwards and downwards from the parent node of
the node being changed.
Upwards interlocking interlocks the parent node and its assigned nodes, the
parent node of the parent node and its assigned nodes, and so on, up to the
root node.
Downwards interlocking interlocks child nodes of the parent node, their child
nodes, and so on, down to the end nodes. This comprises a subhierarchy of
interlocked nodes with the parent node at its root.
Data Quality and Search: Which validations apply to the relationships between hierarchy nodes?
You can add validations for relationships between hierarchy nodes using the BRFplus or using BAdI: Define Validations/Derivations in Customizing. For
example, you can define specific cardinalities such as single higher-level nodes.
Examples of validations that you can create include the following:
Do not allow the same business objects in the same hierarchy twice.
Generate an error message if a business object is not assigned to a hierarchy.
Do not repeat a business object in the same subhierarchy.
Tool BRFplus
Complimentary Coding Data Quality and Search Business Add-Ins BAdI: Define
Validations/Derivations
User Parameter: When a hierarchy node is expanded in the Collective Processing user interface, how many subnodes
should display?
For faster screen load and a reduction in user scrolling, you can control the number of subnodes that display when a node is expanded. The user can click
<Number> More to expand the collapsed nodes.
Example
The following example shows how to display the configuration settings of a profit center group hierarchy and its profit center group.
1. Process the Customizing activity Edit Data Model under General Settings Data Modeling . Mark the data model SF on the Inactive Data
Models view. Then double-click the Entity Types view.
In the column Entity Type , double-click the entity type CARR (Airline). In the group frame Entity Types you can see the following configuration
settings:
Is Hierarchy Type : Yes - Not Version-dependent / Not Synchronized
Note
Assigning the Names for Hierarchies of Airlines hierarchy CARR_HIER to the storage and use type 1 ( Changeable via Change Request ) defines
that this hierarchy can be processed using change requests. This assignment enables the entity type CARR_HIER to become a root node for the
hierarchy.
3. Double-click the Entity Types view and mark the row of the entity type CARR. Then double-click the Entity Types for Hierarchies view. In the group
frame Entity Types for Hierarchies you can see the following configuration settings:
The Entity Type of Node CARR_HIER (Names for Hierarchies of Airlines) has the Use : Hierarchy Name .
The Entity Type of Node CARR (Airline) has the Use : No Special Use .
Master Data Governance for Financials enables you to monitor and control the creation, change, and deletion of financial master data. This documentation
provides the information you need to set up Master Data Governance for Financials. It gives more information about the activities you need to execute in
addition to configuring Customizing settings.
For security reasons the services delivered for Web Dynpro applications initially are available in an inactive state only. You have to activate the services you
want to use.
Activities
To activate the services, proceed as described below:
1. On the Maintain Services screen (transaction SICF), make sure that the Hierarchy Type SERVICE is selected, enter the Service Name , and choose
Execute .
2. Choose Service/Host Activate , to activate the service.
Note
You have to perform the procedure for each single service you want to activate.
Once you have activated a service it cannot be reset to inactive.
The table below provides a list of the services used in the respective components of SAP MDG, central governance .
APB_LAUNCHPAD Launchpad x x x x
MDG_BS_DATALOAD_M Reprocessing x x x x
ONITOR
MDG_EXTR_FPM_CMP Extractor x
USMD_CREQUEST_PRO USMD_CREQUEST_PRO x x x x
CESS CESS
USMD_EDITION Edition x
USMD_WF_NAVIGATION Workflow-Based x x x x
Navigation
WDA_BS_ANLY_LIST_OV List x x x x
P
WDR_CHIP_PAGE wdr_chip_page x x x x
SAP Master Data Governance for Financials enables you to govern financial master data on a hub system and to replicate the data to a number of client
systems. The system centralizes and manages the master data by an approval process. You can use this guide to help you to configure Master Data
Governance for Financials (MDG-F) 8.0.
Note
MDG-specific Customizing is located under SAP Customizing Implementation Guide Cross-Application Components Processes and Tools for
Enterprise Applications Master Data Governance, Central Governance .
You can also directly access all MDG-specific Customizing using transaction MDGIMG .
The Customizing settings are located under Master Data Governance, Central Governance Master Data Governance for Financials as well as
Master Data Governance, Central Governance General Settings . For more information, see General Settings for Financials .
Prerequisites
After installing MDG-F 8.0, run the report RGZZGLUX before opening the UIs delivered with MDG-F 8.0. The report performs several checks regarding the
general ledger configuration of your MDG system.
Data Model
If data model 0F is available in your system and you want to activate the new data model 0G, delete data model 0F. Data model 0F is the predecessor of 0G
and must not be used. To delete data model 0F, follow the steps described in Deleting Data Model 0F.
Business Function
Before you activate the business functions, ensure that you have the administration authorization for MDG. The required authorization objects are delivered
with the authorization role SAP_MDG_ADMIN. In transaction PFCG, we recommend creating a copy of this role and assigning the relevant authorization values.
For the authorization object USMD_DM, you need to assign the values for the authorization field USMD_MODEL (for example MM, BP, or 0G) and the values for
the authorization activity ACTVT (for example, 01: Create or generate or 02: Change ).
Process
1. Activate Data Model 0G
2. Activate the Business Configuration Set
3. Check or Create an Edition Type
4. Check Business Activities
5. Check or Define a Change Request Type
6. Assign and Personalize the Role
7. Define the Validation Rules and Derivation Rules
Result
You have configured the system for Master Data Governance for Financials.
Check whether you can use the data model 0G delivered by SAP for managing your Financials master data. For more information about modifying the data
model, see Enhancement of Master Data Governance Content.
You can activate the data model you want to use in Customizing under Master Data Governance, Central Governance General Settings Data
Modeling Edit Data Model .
Note that you should maintain usage type 3 entity types, such as the standard hierarchy name for each controlling area, before using MDG-F.
The Business Configuration Set CA-MDG-APP-FIN_EDITION_05 provides the default 0G_ALL edition type. We strictly recommend using a single edition
type containing all MDG-F entity types due to the cross-references between entity types in data model 0G.
Activate the BC Set CA-MDG-APP-FIN_EDITION_05 in Customizing under Master Data Governance for Financials Import Predefined Edition Types
.
You can also activate the BC Set CA-MDG-APP-FIN_EDITION_05 using the following procedure:
1. On the SAP Easy Access screen, choose Tools Customizing Business Configuration Sets Activation of BC Sets (transaction SCPR20).
2. Enter the BC Set CA-MDG-APP-FIN_EDITION_05, and choose ( Activate BC Set ).
Leave the default settings as they are.
The Business Configuration Set CA-MDG-APP-FIN_CR_TYPES_06 contains predefined change request types you can use for your master data governance
process. You can also define your own change request types.
To activate the BC Set CA-MDG-APP-FIN_CR_TYPES_06, open the activity documentation in Customizing under Master Data Governance for Financials
Import Predefined Change Request Types , and click on the link Change Request Types MDG-F 8.0 (CA-MDG-APP-FIN_CR_TYPES_06) in the
Activities section.
You can also activate the BC Set CA-MDG-APP-FIN_CR_TYPES_06 using the following procedure:
1. On the SAP Easy Access screen, choose Tools Customizing Business Configuration Sets Activation of BC Sets (transaction SCPR20).
2. Enter the BC Set CA-MDG-APP-FIN_CR_TYPES_06, and choose ( Activate BC Set ).
Leave the default settings as they are.
If you want to access the MDG-F homepage or the Business Context Viewer (BCV), activate the BC sets MDGAF_BCV and CA-MDG-APP-
FIN_BCV_PANEL_04.
If you want to use the SAP-Fiori-based request UIs, activate the BC set MDGF Change Request Types for SAP Fiori (Financials) 7.0 FP (CA-MDG-APP-
FIN_CR_ODATA_05).
This BC Set provides the predefined change request types for use in OData services and the SAP Fiori applications Request Profit Center and Request Cost
Center .
Check if the edition type 0G_ALL has been created for data model 0G after you have activated the business functions. It should contain all 25 entity types that
are defined in the data model 0G. You can create your own edition type in Customizing under Master Data Governance, Central Governance General
Settings Process Modeling Create Edition Type . We strictly recommend using a single edition type containing all MDG-F entity types due to the cross-
references between entity types in data model 0G.
Check if the table displayed in the "Business Activity: Definition" Overview view contains entries related to data model 0G, for example:
You can display the table in Customizing under Master Data Governance, Central Governance General Settings Process Modeling Business
Activities Create Business Activity .
If you have activated the BC set CA-MDG-APP-FIN_CR_TYPES_06, check the change request types. You can create your own change request types in
Customizing under Master Data Governance, Central Governance General Settings Process Modeling Change Requests Create Change Request
Type . You can enter change request type keys and a short description to tag or classify your change requests. These keys can be used later for change
request analytics (process quality analysis). They can also be used to influence the workflow-driven processes. For example, depending on the priority of a
change request, you can mark it for special processing. You can define priorities, reasons, or rejection reasons for change requests. For more information, see
Customizing for Master Data Governance, Central Governance under General Settings Process Modeling Change Requests and work through the
following activities:
Edit Statuses of Change Requests
Define Priorities for Change Requests
Define Reasons for Change Requests
Define Rejection Reasons for Change Requests
Check the predelivered print forms that are assigned to data model 0G in Customizing under UI Modeling Assign Print Forms for Single Processing .
You also have the option of defining print forms for change requests. By default, the form USMD_EDITION_CREQUEST is used. This form is only relevant if
your own print forms or multiple print forms are required. For more information, see Customizing for Master Data Governance, Central Governance under
General Settings Process Modeling Change Requests Define Print Form for Change Requests .
We continue using 3 work centers in financials – accounting, controlling, and consolidation. The following authorization and menu roles are used:
On the SAP Easy Access screen, choose Tools Administration User Maintenance Role Administration Roles (PFCG).
For example, using the role SAP_MDGF_ACC_MENU_04 on the Personalization tab page, edit the personalization key SAP Master Data
Governance (R_FMDM_MODEL). Specify 0G as the standard data model. If applicable, assign the default values for the edition, the change request
type, and the entity type.
On the SAP Easy Access screen, choose Tools Administration User Maintenance Users (SU01).
Assign the required roles to your users, for example, SAP_MDGF_ACC_MENU_04, and at least 1 authorization role, for example,
SAP_MDGF_ACC_SPEC_04.
Work through the Customizing activity under Master Data Governance, Central Governance General Settings Data Quality and Search Validations
and Enrichments Define Validation and Derivation Rules . For more information, see Definition of Validations and Derivations.
Several workflow templates are available for MDG-F. For more information, see Workflow Templates for Financials. If the Business Configuration Set has been
activated, the default SAP business workflow template WS75700027 is assigned to change request type 0G_ALL and the workflow template WS75700040 is
assigned to all other change request types.
1. Activate type linkage
To activate the type linkage, run the following activity in Customizing for Master Data Governance, Central Governance under General Settings
Process Modeling Workflow Activate Type Linkage .
Ensure that object type BUS2250 has the following settings:
The type linkage indicator must not be active for all other receiver types of object type BUS2250 and events CREATED, ACTIVATED, and
ROLLED_BACK. This receiver type is defined using the receiver type function module USMD_WF_RECEIVER_TYPE.
Note
To enter the receiver type function module or if you want to change the settings, mark the according line in the table and choose Goto Details
.
You can determine the level of freedom with which users can make parallel changes to a hierarchy that belongs to a particular hierarchy type. A change to a
hierarchy can comprise adding a node, moving a node, removing a node, changing the attributes of a node, or creating a hierarchy.
After a change to a hierarchy is saved to a change request, changes to interlocked nodes must be saved to the same change request. The system determines
which nodes are interlocked by referring to the Interlocking setting for the relevant hierarchy type.
You make these settings in Customizing under Master Data Governance, Central Governance General Settings Process Modelling Hierarchies
Define Scope for Changes .
Note that an Interlocking setting of Strict has a considerably greater impact on the system performance than a setting of Loose , as the amount of data
records the system locks and checks is higher with a setting of Strict .
Note
You can only change the scope for changes to a hierarchy when no pending change requests exist for that hierarchy. If you change the scope and then
transport your changes, ensure no pending changes exist for the affected hierarchy in the target system.
Work through the Customizing activity Master Data Governance, Central Governance General Settings Process Modeling Hierarchies Create
Hierarchy Versions .
Data replication in MDG can be defined, triggered, and controlled using the Data Replication Framework (DRF). You can replicate the master data of Financials
with SAP enterprise services, IDoc, or file downloads. For more information, see File Download and Configuring Data Replication. Work through the
Customizing activities for Master Data Governance, Central Governance under General Settings Data Replication .
Replicate master data using SOA
Value mapping links field values in different systems, usually based on global data types. If the Customizing values are not harmonized in your system
landscape, you must define the value mapping under Master Data Governance, Central Governance General Settings Value Mapping . For more
information, see Value Mapping.
If you are working with multiple connected systems and did not consolidate the financial object keys during the initial load phase, key mapping may be
required.
You can define the system-specific mappings for the key value for financials in Customizing for Master Data Governance under Master Data Governance,
Central Governance General Settings Key Mapping .
The mapping definitions of the key mappings can be conducted by any authorized user on the productive MDG system using the business transaction from
the portal or the corresponding back-end transaction.
You can manage the master data for financials in one of the following environments:
SAP NetWeaver Business Client
If you want to use SAP NetWeaver Business Client for managing your master data in Financials, you can create, define, or configure the role for the
Business Client in the SAP ERP system. Perform the steps described under Assign and personalize the role. You can now start the necessary steps
without using the SAP NetWeaver Portal. You can use the role for testing or when the portal is inactive.
Check the settings of the authorization objects within the roles and restrict them, if applicable.
SAP NetWeaver Portal
The SAP NetWeaver portal content for MDG-F is derived directly from the menu roles. To create SAP NetWeaver menu roles, you must log on to the
portal and upload the content information from your backend system menu roles.
Note
You must install the Business Package for Common Parts in the SAP NetWeaver Portal before you can upload the MDG roles.
MDG-F supports the option to initially upload accounts, companies, cost centers, cost elements and profit centers from your MDG target systems into your
MDG hub system.
The extraction of the master data in the MDG target system is performed by the generic MDM extractor (MDMGX). The upload of the master data in the MDG
hub system is performed by the MDG data import framework (DIF). MDG-F provides content for both.
Process
Setting up MDMGX in client systems
MDG-F uses transaction MDMGX for the extraction of master data from SAP MDG target systems. To set up MDMGX, perform the following:
1. Apply the SAP Notes 1783851 , 1880169 and 2134044 in the target systems.
2. Download the required MDMGX configuration text file from SAP Note 2151430 . The note includes a detailed how-to document about MDMGX
setup and execution.
3. Run transaction MDMGX in the client systems.
4. Choose Define Object Types . Check that the object types in the following table exist in your system. The object types are predefined by SAP. If
they do not exist, create the missing entries. Afterwards, navigate back to the main menu of the transaction.
Company Company
5. Choose Define Repositories and FTP Servers . Check if there is an entry with the attribute Log. Repository Name defined as
SAP_MDG_TEMPLATE. If it is available, you can use this entry as a template for defining your own repositories. You can use the Copy button to
create a new repository from the template. Each master data object that you want to extract requires a specific repository.
6. If the template does not exist, you can create a new repository. Define the attributes of the new repository according to the master data object that
you want to extract. The table below shows the entries for the MDG-F objects. Define attributes Clnt Code and Remote System Type according
to your specific systems. Other attributes may use the values as shown in the table. It is absolutely mandatory that the repository name starts
with MDG_.
7. Choose Upload Ports and Check-Tables . Upload the configuration text file and perform the following:
1. Define the object type as Account .
2. Browse the configuration text file.
3. Select the Remove Header Line checkbox.
4. Execute the upload and go back to the main menu
8. Define the function modules for the cost elements as follows:
1. Choose Define Function Module Parameters for Exceptional Cases and search without attributes.
2. Choose the Create button, and enter CostElement as the object type and MDM_ERP_CELEM_EXTR as the function module. Do not
provide an input parameter.
3. Save your entries.
4. Repeat the procedure for the function module MDM_ERP_CELEM_DESCR_EXTR.
9. The predefined content of the configuration text file has to be adapted according to the master data that shall be extracted. Refer to the how-to
You can use this BAdI to display a list of entities changed by MDG-F in a remote system. You can display the where-used list in remote systems for entities
in MDG. You can access this BAdI under Master Data Governance, Central Governance General Settings Data Quality and Search Business Add-
Ins BAdI: Remote Where-Used List .
For each message, you can define the respective message type for the different check levels (for example, change request, edition, or single maintenance). If
you do not redefine the message types for a message, the set standard message type applies for all 3 check levels. For more information, see Customizing
for Master Data Governance, Central Governance under Master Data Governance for Financials Control of Validation Messages Change Message
Type for Validations .
You can apply system settings that allow you to monitor how effectively your organization processes change requests. You can analyze the statuses and
processing times of change requests in your organization, and the types of change requests involving you. For more information, see Enabling Detailed
Analysis of Change Requests.
To enable this feature, set the application parameter MDGF_ENABLE_KEY_SWITCH to X in the Web Dynpro application configuration. SAP delivers these for
each entity with SU type 1 that has its own user interface. It is possible to enable the feature for a single entity only.
1. Create a custom Web Dynpro application configuration as a copy of a predefined SAP configuration.
1. Start the Web Dynpro application CONFIGURE_APPLICATION.
2. Define an existing Web Dynpro application configuration with component name MDGF_OVP_GEN and its configuration ID (for example,
MDGF_0G_OVP_CCTR).
3. Choose Copy . Follow the instructions of the copy window to create your custom Web Dynpro application configuration.
4. Once the copy is finished, choose the Continue in Change Mode button to apply the application parameter value.
5. Locate parameter MDGF_ENABLE_KEY_SWITCH in the list of application parameters and set its value to X .
6. Save your entries.
2. Create a custom MDG Communicator configuration.
1. Start the Web Dynpro application CONFIGURE_COMPONENT.
2. Define an existing MDG Communicator configuration with component name MDG_BS_GOV_COMMUNICATOR and its configuration ID (for example,
MDGF_0G_OVP_CCTR).
3. Choose the Copy button. Follow the instructions of the copy window to create your custom Web Dynpro component configuration for the MDG
Communicator.
3. Adjust MDG Customizing.
MDG consists of several customizing tables that are used for the navigation to user interfaces. You need to add the newly created Web Dynpro
application to the tables to ensure that the new user interface that supports changeable IDs is used instead of the SAP pre-defined user interface. Carry
out the steps described below. The steps take the Cost Center as an example.
1. Start transaction MDGIMG.
2. Open General Settings Process Modeling Business Activities .
3. Open the Customizing activity Link Log. Actions with UI Application and Bus. Activity: Custom Definition .
1. Take a look at the SAP default configuration for cost centers in the Customizing activity Link Log. Actions with UI Application and Bus.
Act.: Standard Definition , which should contain records similar to the ones shown in the table below:
BO Type Log. Action Current UI App. Current UI Config. Target UI App. Target UI Config. Business Activity
2. Copy or note the lines that relate to the creation and display of cost centers using the SAP UI configuration MDGF_0G_OVP_CCTR.
3. Navigate to the custom definition and add new entries using the previously copied or noted values as a template. Define your new target UI
configuration.
BO Type Log. Action Current UI App. Current UI Config. Target UI App. Target UI Config. Business Activity
2. Copy or note the lines that relate to the creation and display of cost centers using the SAP UI configuration MDGF_0G_OVP_CCTR.
3. Navigate to the custom definition and add new entries using the previously copied values as a template:
You want to enable SAP HANA search for financial objects because of high volume data or advanced features provided by the SAP HANA database such as
freestyle and fuzzy search. This document explains the configuration steps that must be applied to the MDG system to enable this feature. It describes how to
connect the search application with the SAP HANA search UIBB and generate the HANA search view.
Prerequisites
Before starting the implementation, check that SAP HANA is connected to the MDG system. If not, refer to Configuring SAP HANA-Based Search for MDG.
Process
1. Generate SAP HANA search view in the SAP HANA database
1. Open transaction MDGIMG under Master Data Governance, Central Governance General Settings Data Quality and Search Search and
Duplicate Check Create Search View . Find the relevant search views from the table SAP HANA Search Supported MDG-F Objects below.
For the MDG-F predelivered view for data model 0G, the name starts with MDGF_0G_*. Choose the Edit button to open each search view.
2. Enter the name of the SAP HANA package you received from your system administrator. Save your entries.
3. Choose Next until the last step and choose Generate . You should get a message saying the view generation is successful.
2. Enable SAP HANA Search UIBB
This is done by adding an SAP-delivered search UIBB to the communicator configuration as follows:
1. Start the customizing configurator for the communicator configuration.
1. Start the Web Dynpro application CUSTOMIZE_COMPONENT.
2. Enter the component name MDG_BS_GOV_COMMUNICATOR. You can find the configuration ID in the table below.
SAP HANA Search Supported MDG-F Objects
Object Name Communicator Configuration ID HANA Search UIBB HANA Search View
3. Choose New , enter a description, and choose OK . Select a transport request if your customizing needs to be transported to other
systems.
2. Mark the Settings node, and choose New Search UIBBs . Enter all parameters for the object in the table, for example, the following are
the cost center parameters:
Search Mode: HA
Incl. Search Help: MDGF_0G_CCTR
Component: FPM_SEARCH_UIBB
Config ID: MDGF_0G_CCTR_DQUERY_HA
Result
You have completed all the necessary steps to enable HANA search.
You can use this function to view context-related information for your financials master data in a side panel. You must activate the Business Context Viewer
(BCV) to access the side panels for all MDG-F Web Dynpro applications.
Prerequisites
1. To enable BCV, you must activate the following business functions:
FND, Business Context Viewer Main Application (/BCV/MAIN)
FND, Business Context Viewer Main Application 2 (/BCV/MAIN_1)
FND, Business Context Viewer NWBC Side Panel (/BCV/NWBC_SIDEPANEL)
2. Activate the BC Set BCV Content for MDG Framework (MDGAF_BCV) in transaction SCPR20.
3. Activate the BC Set BCV Content for MDG-F (CA-MDG-APP-FIN_BCV_PANEL_04), which contains the business content for MDG-F.
Process
To view this content, open the BCV side panel by choosing the Side Panel link in the upper right corner of your MDG Financials user interface. From the side
panel, select the following overview from the dropdown list:
Changes Overview
This BCV content provides you with a list of changes raised by the current MDG change request.
More Information
For more information about BCV, see Business Context Viewer (BCV)
This document describes the configuration steps required to enable the exchange of financial data. The configuration uses point-to-point enterprise services
communication without a process integration (PI) system. The MDG hub is installed on NetWeaver 7.40 (or higher). For more information about how to use the
SOA Manager to configure a Web service-based communication, see Configuring a Consumer Proxy.
Prerequisites
The following prerequisites must be performed in both the MDG hub and target systems.
Configuration of the Web Service Runtime
Set up the technical configuration of the web service runtime using SAP Note 1043195 .
Authorizations
Assign the administrative role SAP_BC_WEBSERVICE_ADMIN_TEC for the SOA Manager.
Business Functions
Check if the business function FND_SOA_REUSE_1 is active.
Note
Activate the business function from transaction SFW5. By activating the business function, you can use the following cross-application tool improvements
that facilitate the use of services:
SOA mapping tool
Error handling
Point-to-point enablement for asynchronous enterprise services
For replication to an ERP system, activate the business function FIN_MDM_SOA_ORG in the MDG target system. For replication to an ERP system with SEM-
BCS installed, activate the business function FIN_MDM_SOA_CU in the MDG target system.
In an ERP system with SEM-BCS installed, perform the same steps, but use the application SEM_BW_INBOUND and the groups SEM_BW_INBOUND_ITEM
and SEM_BW_INBOUND_REPUNIT_EHP6.
Support for Point-to-Point Communication
To activate the support for point-to-point communication, run the Customizing activity under Cross-Application Components Processes and Tools for
Enterprise Applications Enterprise Services Point-to-Point Enablement for Asynchronous Enterprise Services Activate Support for Point2Point
Communication .
Connection to System Landscape Directory
Check whether the hub and target systems are connected to the system landscape directory (SLD) or the BAdI MDG_IDM_GET_LCL_SYSTEM is implemented
to determine the local system ID. For more information, see Customizing for Master Data Governance, Central Governance under General Settings
Data Replication Define Custom Settings for Data Replication Define Technical Settings BAdI: Determination of Local System Name .
Error and Conflict Handler
To activate the error and conflict handler, run the Customizing activity under Cross-Application Components General Application Functions Error and
Conflict Handler Activate Error and Conflict Handler .
Procedure
The following steps are required to configure the SOA Manager for MDG-F (transaction SOAMANAGER) and must be performed in both the MDG hub and MDG
target systems.
Configure a Profile For Point-To-Point Communication
1. On the Technical Administration tab, choose Profiles .
2. Choose Create Profiles , enter the name MDG and description and choose Next .
Note
The profile names should be identical in the SOA manager settings for both MDG hub and target systems.
3. Mark User ID/Password and verify that in section Identifiable Business Context , the field IBC Determination has the value No IBC
Determination. Choose Next .
4. If necessary, enter the proxy settings and choose Finish to save the settings and activate the profile.
Retrieve Business Application ID
1. On the Technical Administration tab, choose SAP Client Settings and then choose Edit .
2. Enter a business system and a business system ID in the form: XYZ_001 , where XYZ is the system ID and 001 is the client.
3. To receive the business application ID from the system landscape directory (SLD), choose Get from SLD .
4. Save your entries.
The business application ID should now be displayed in the corresponding field.
Configure a Provider System for the Business Scenario Configuration
1. On the Technical Administration tab, choose Provider Systems , then choose Create . Enter the system ID of the client system as the name, for
example XYZ_001 , select the profile name defined in step 1, and choose Next .
2. Enter the SLD identifier in the following form:
<Client>.SystemName.<ABC>.SystemNumber.<InstallationNumber>.SystemHome.<Host>, for example,
Note
The system number can be found under System Status SAP System Data Installation Number .
Similarly, the system home can be found under System Status Database Data Host .
3. Enter the access URL for WSIL and logon information under WSIL Services .
Note
To identify the host name and port for the access URL, call transaction SMICM and choose Goto Services . Use the HTTPS host name and
port displayed in the list. We recommend that you use the message server host.
4. Enter the user for WSDL and a password for the WSDL documents.
5. Enter the service user that you have created in the backend system.
6. Maintain the business application ID. The business application ID can be found in the counterpart system in the transaction SOAMANAGER under
Technical Administration SAP Client Settings
1. Choose Create to maintain a business application ID in the MDG hub system.
2. Enter an application name and description, for example sap.com/BusinessApplicationABAP.
3. Enter the business application ID.
4. Choose Finish to save and activate the system connection.
As a result, the Identifiable Business Context (IBC) reference for the counterpart system is automatically generated. To verify this, perform the following:
1. From the Service Administration tab, choose the link Identifiable Business Context Reference .
2. Choose the Search button. The IBC reference for the counterpart system should display in the list in the form of XYZ_001, where XYZ_001 is the
system ID and client of the counterpart system.
Edit Logon Data for Business Scenario
Note
The backend user should exist in both systems.
GENERALLEDGERACCOUNTMASTERREP1 Replication bulk request for general ledger account master data
3. To assign a profile to the service definitions in the MDG target system, carry out the previous steps for the MDG hub.
4. Select Service Groups and assign the provider IBC reference as follows:
UC0_FINCNSELMNTRPLCTNBCO UC0_FINCNSELMNTRPLCTNBCO
UC0_FINCNSSTRUCTRPLCTNCO UC0_FINCNSSTRUCTRPLCTNCO
5. To assign a provider IBC reference in the MDG target system, carry out the previous steps for the MDG hub.
6. Activate the integration scenario in the target system:
1. Choose Yes to activate the integration scenario immediately.
2. Click on the link Click here to open shown at the top to display all pending tasks.
3. Choose the pushbutton Rebuild List to refresh the list of all pending tasks.
4. Choose the pushbutton Process List to execute all pending tasks.
To activate the logical ports in the MDG target system, you must first process any pending tasks in the MDG hub. This activates the integration scenario in
the MDG hub. You must then process all pending tasks in the target system that failed the activation again.
Define Business Systems
In the MDG hub client, create a business system for each target system:
1. Enter transaction MDGIMG.
2. Navigate to General Settings Data Replication Define Custom Settings for Data Replication Define Technical Settings Define Technical
Settings for Business Systems .
3. Choose the pushbutton New Entries .
4. Set the values for business system, logical system, and RFC destination for each client of the target system, for example, QM8_410; QM8CLNT410;
QM8CLNT410.
5. Mark the line of the newly defined business system and select the folder Define Bus. Systems, Bos . Enter all required business object types:
154 Company
The following are the business object types for replication to an SEM-BCS system:
Repeat this step for all business systems defined for SOA replication in step 4.
6. For each business system with a defined business object, choose the folder Define Bus. Systems, BOs, Communication Channel . Choose the
1 Replication via Services
4. For each defined replication model, mark the line of the replication model and select folder Assign Outbound Implementation . Choose the pushbutton
New Entries . Assign one outbound implementation to each replication model as described in the following table:
5. For each outbound implementation you have described in step 4 ,mark the line of the implementation and select the folder Assign Target Systems for
Repl. Model /Outb.Impl . Choose the pushbutton New Entries . Assign all business systems with the ERP clients of the target systems.
Caution
In case the replication is triggered for PI service instead of P2P communication in the hub or the client, and the SOA message is displayed in
SXMB_MONI instead of SRT_MONI, you have to set the logical port for the consumer proxy to default in SOAMANAGER.
In the client of the MDG hub, you have to set the logical port to default for the consumer proxies:
1. On the Service Administration tab, choose Web Service Configuration .
2. Search for object name CO_USMD_COMPANYRPLCTNBRQ, and click on the internal name to display the consumer proxy details.
3. On the Configurations tab, mark the entry with the desired target system, and choose Set Log. Port Default .
4. Repeat the steps above for all entries mentioned in the table below.
CO_USMD_COMPANYRPLCTNBRQ CompanyReplicationBulkRequest_Out
CO_USMD_CHARTOFACCRPLCTNRQ_V1 ChartOfAccountsReplicationRequest_Out_V1
CO_USMD_GENLEDACCMRPLCTNRQ GeneralLedgerAccountMasterReplicationBulkRequest_Out
CO_USMD_FINREPSTRUCTRPLCTNRQ FinancialReportingStructureReplicationRequest_Out
CO_USMD_COSTCTRRPLCTNBRQ CostCentreReplicationBulkRequest_Out
CO_USMD_COSTCTRGRPHIRPLCTNRQ CostCentreGroupHierarchyReplicationRequest_Out
CO_USMD_PROFITCTRRPLCTNBRQ ProfitCentreReplicationBulkRequest_Out
CO_USMD_PRFTCTRGRPHIRPLCTNRQ ProfitCentreGroupHierarchyReplicationRequest_Out
CO_USMD_COSTELMNTRPLCTNBRQ CostElementReplicationBulkRequest_Out
CO_USMD_COSTELMNTGRPHIRPLCTNRQ CostElementGroupHierarchyReplicationRequest_Out
CO_USMD_CHARTOFACCRPLCTNRQ_V1 ChartOfAccountsReplicationRequest_Out_V1
CO_USMD_FINREPSTRUCTRPLCTNRQ FinancialReportingStructureReplicationRequest_Out
CO_USMD_FINCNSELMNTRPLCTNBRQ FinancialConsolidationElementReplicationBulkRequest_Out
CO_USMD_FINCNSSTRUCTRPLCTNRQ FinancialConsolidationStructureReplicationRequest_Out
In the client of the MDG client system, you have to set the logical port to default for the consumer proxies:
1. On the Service Administration tab, choose Web Service Configuration .
2. Search for object name CO_USMD_COMPANYRPLCTNBCO, and click on the internal name to display the consumer proxy details.
3. On the Configurations tab, mark the entry with the desired target system, and choose Set Log. Port Default .
4. Repeat the steps above for all entries mentioned in the table below.
CO_FBS_COMPANYRPLCTNBCO CompanyReplicationBulkConfirmation_Out
CO_FBS_CHTACCTSRPLCTNCO ChartOfAccountsReplicationConfirmation_Out
CO_FBS_FINRPTGSTRUCCO FinancialReportingStructureReplicationConfirmation_Out
CO_FBS_GLACCTMSTRRPLCTNRCO GeneralLedgerAccountMasterReplicationBulkConfirmation_Out
CO_KBAS_COSTCTRGRPHRYRPLCO CostCentreGroupHierarchyReplicationConfirmation_Out
CO_KBAS_COSTCTRRPLCTNCO CostCentreReplicationBulkConfirmation_Out
CO_KBAS_COSTELMNTGRPHRYRPLCO CostElementGroupHierarchyReplicationConfirmation_Out
CO_KBAS_COST_ELEMENT_REPLICATI CostElementReplicationBulkConfirmation_Out
CO_KE1_PRCTRGRPRPLCTNCO ProfitCentreGroupHierarchyReplicationConfirmation_Out
CO_KE1_PRCTRRPLCTNBULKCO ProfitCentreReplicationBulkConfirmation_Out
CO_UC0_CHARTOFACCRPLCTNCO ChartOfAccountsReplicationConfirmation_Out
CO_UC0_FINCNSELMNTRPLCTNBCO FinancialConsolidationElementReplicationBulkConfirmation_Out
CO_UC0_FINCNSSTRUCTRPLCTNCO FinancialConsolidationStructureReplicationConfirmation_Out
CO_UC0_FINREPSTRUCTRPLCTNCO FinancialReportingStructureReplicationConfirmation_Out
Result
You have configured the financial data for SOA manager using enterprise services on NetWeaver 7.40 (or higher).
More Information
Configuring Master Data Governance for Financials
This document describes the configuration steps that are required to enable the exchange of financial data using Application Link Enabling (ALE) for MDG-F.
Prerequisites
Set Up RFC Connections
Set up RFC connections in the MDG hub and MDG target systems:
1. Run transaction SM59 (configuration of RFC connections) and provide the required RFC destination details.
2. Define the logical systems in Customizing for SAP NetWeaver . Run transaction SALE and then choose Basic Settings Logical Systems Define
Logical System . Enter all target systems as logical systems.
3. Run transaction SALE and assign the logical system to a client under Basic Settings Logical Systems Assign Logical System to Client .
Procedure
The following steps are required to configure ALE for MDG-F (transaction SALE) in the MDG hub and MDG target system.
4. After you have saved your settings, you need to generate a partner profile. Choose Environment Generate Partner Profiles . Select the model
view you just have saved and enter the target system. Select immediate processing for the output mode and inbound parameter. Choose the pushbutton
Execute .
5. After you have generated the necessary partner profile, choose Edit Model view Distribute to distribute this model view to your target system.
6. Enter the target system and repeat step 4 to generate partner profiles on the MDG client.
In the client of the target system, the distribution model also needs to be enhanced, as follows:
1. Enter the client of the target system and call transaction SALE.
2. Goto Communication Maintain Distribution Model and Distribute Views . Mark the distribution model you have generated previously.
3. Select Environment: Change Partner Profile from the dropdown list.
4. Open Partner Type LS and select the profile of the source system.
5. Choose the pushbutton Create outbound parameter .
6. Chose the message type ALEAUD, select the receiver port from the selection list, and enter the value ALEAUD01 as the basic type.
7. Select Transfer Idoc Immed. as the output mode and save your entries.
Define Business Systems
In the client of the MDG hub, a business system for the target client needs to be created as follows:
1. Call transaction MDGIMG.
2. Goto General Settings Data Replication Define Custom Settings for Data Replication Define Technical Settings Define Technical Settings
for Business Systems .
3. Choose the pushbutton New Entries .
4. Enter the business system, logical system, and RFC destination for the target client.
5. Mark the line of the newly defined business system and select the folder Define Bus. Systems, Bos . Enter all desired business object types:
6. Mark each business object type and choose the folder Define Bus. Systems, BOs, Communication Channel . Choose the pushbutton New Entries and
select the communication channel 2 Replication via IDoc . Repeat this for all defined business object types.
7. Save your entries.
Create Replication Models
After the distribution model and the business system have been defined in the client of MDG hub, it is now possible to create a replication model for each IDoc
type:
1. Call transaction MDGIMG.
2. Goto General Settings Data Replication Define Custom Settings for Data Replication Define Replication Models .
3. Choose the pushbutton New Entries and define a replication model with name, description, and data model 0G for each IDoc type listed.
4. For each defined replication model, mark the line of the replication model and select the folder Assign Outbound Implementation . Choose the
pushbutton New Entries . Assign the corresponding outbound implementation to each replication model you have defined:
5. For each outbound implementation you have described in step 4, mark the line of the implementation and select the folder Assign Target Systems for
Repl. Model /Outb.Impl . Choose the pushbutton New Entries . Assign the business system with the ERP client of the target system.
6. Save your entries
Activate Replication Models
Activate the previously defined replication models as follows:
1. Call transaction MDGIMG.
2. Goto General Settings Data Replication Define Custom Settings for Data Replication Define Replication Models .
3. In the table of replication models, mark all replication models you have previously defined.
4. Choose the pushbutton Activate and check the log for error messages. Successful activation is indicated with a checkmark in the Active column.
5. Check the log and make sure that all replication models marked have been activated successfully.
More Information
Configuring Master Data Governance for Financials
Configuring the SOA Manager for Master Data Governance for Financials
1.1.2.2.5 Appendix
1.1.2.2.5.1 Interlocking
Interlocking specifies which nodes are interlocked with a pending change request while a change to a hierarchy is made. A change to a hierarchy can comprise
adding a node, moving a node, removing a node, changing the attributes of a node, or creating a hierarchy. After a change to a hierarchy is saved to a change
request, changes to interlocked nodes must be saved to the same change request. If a node is not interlocked, you can use any change request to make a
hierarchy-specific change.
With a setting of Loose , nodes assigned to the parent node of the node being changed are interlocked.
With a setting of Strict , interlocking propagates upwards and downwards from the parent node of the node being changed as follows:
Upwards interlocking interlocks the parent node and its assigned nodes, the parent node of the parent node and its assigned nodes, and so on up to
the root node.
Downwards interlocking interlocks child nodes of the parent node, their child nodes, and so on down to the end nodes. This comprises a subhierarchy
of interlocked nodes with the parent node at its root.
For a full description of what interlocking means that includes a graphical representation of the Loose and Strict settings, see Scope for Hierarchy-Specific
Changes.
Prerequisites
Make sure that data model 0F is not activated in your productive system.
Activities
1. If the data model 0F has an active version, run transaction MDG_DELETE_MODEL (Delete Active Version of Data Model) first.
Caution
Running transaction MDG_DELETE_MODEL will irrevocably delete the active version of the data model, including all dependent data.
2. Open the Customizing activity Master Data Governance, Central Governance General Settings Data Modeling Edit Data Model , and
confirm the dialog box.
3. In the data model list, select the row that contains data model 0F.
4. Choose ( Delete ).
5. In the Specify objects to be deleted dialog box, select all entries .
6. Confirm all information and warning messages by pressing Enter .
7. Choose ( Save ) to confirm the deletion of the data model. If required, create a workbench request.
This documentation provides the information you require to change and enhance settings for Master Data Governance for Financials. It supplements the
information provided in the section Configuring Master Data Governance for Financials .
The purpose of data modeling is to define the structure of the data storage. During the master data processing, a change request is used that stores the
master data changes in a staging area. The data model can define a reuse area that is used for data storage after the change request processing has been
completed and the related data has been activated. In this case, the system moves data from the staging area to a storage location that is connected by the
access class of the reuse area. This storage location is called active area.
If there is no reuse area defined, the same database tables that are used for the staging area, are also used to store active data. Then, no access class is
involved, the system does not move data from one location to another, and MDG is used as the active area.
You can transfer data models for Master Data Governance from your test system to your target system by means of transport requests.
Process
To transport an active version of a data model to the target system, proceed as follows:
1. In Customizing for Master Data Governance , choose General Settings Data Modeling and then the Edit Data Model activity.
2. To activate the data model again, select it and choose ( Activate ).
A dialog box appears.
3. Specify the transport request that you want to use to transport the active data model and save your entries.
The active data model is transported to the target system. Once in the target system, the data model is activated automatically. This can have the
following effects on the generated database tables in which the entities are saved:
The generated database tables are generated again.
The generated database tables are adjusted.
If the entity type was removed from the current data model, the generated database tables are deleted.
Note
If a deletion of the active data model is transported, the generated database tables are not deleted – with the exception of the hierarchy tables.
To transport an inactive version of a data model to the target system, proceed as follows:
1. In Customizing for Master Data Governance , choose General Settings Data Modeling and then the Edit Data Model activity.
2. Choose Table View Transport and specify the transport request with which you want to transport the inactive data model.
3. Select the data model and choose Process Transport Include in Request .
In the dialog box that appears, specify that all lower-level entries are to be transported and save your entries.
Note
You can activate the transported inactive data model in the target system.
To do this, in Customizing for Master Data Governance in the target system, choose General Settings Data Modeling and then the Edit Data
Model activity.
You can use this Web Dynpro application to define and activate a data model to map master data in the system, along with its properties and relationships.
The system uses this data model to generate database tables in which the master data can be stored.
You can assign a reuse active area to a data model or to individual entity types of a data model. Then the inactive portion of master data for this data model is
stored in the generated tables and the active portion is stored in the database tables specified in the reuse active area.
Note
You can also assign a reuse active area on the level of an entity type.
Prerequisites
You have created any customer-specific data elements you want to use for the entity types in the data model or for their attributes.
If you use entity types with internal key assignments, you can define prefixes for internal key assignment. You do this in Customizing for Master Data
Governance under General Settings Define Prefixes for Internal Key Assignment .
Features
Attributes Tab
Here you define the attributes of each entity type in the data model. Attributes are mapped as non-key fields in the generated database tables of the entity
type. You also need to assign an existing data element to each attribute. The data element determines the technical properties of the attribute as well as the
field labels and the input help texts on the user interface. Attributes can be defined as required entry fields or as optional fields. You use a currency-supplying
attribute or a unit-supplying attribute to assign a currency or unit of measure to the attribute.
Example
In the PFLI entity type of the SF data model, you model flight scheduling data. For example, you can specify the cities CITYFROM and CITYTO. The
GEOCITY entity type has a storage and use type of 3. It acts as a check table for valid cities. If you want to ensure only valid cities are selectable, you
create a foreign key relationships between CITYFROM and GEOCITY, and between CITYTO and GEOCITY.
To maintain the foreign key attributes for PFLI, you can open the Incoming Relationships tab, select the relationships CITYFROM and CITYTO, and
choose the foreign keys button. You want to define foreign key relationships so that the fields PARTNER_1 and PARTNER_2 at entity type BPREL
contain only the values of the field BP_HEADER at entity type BP_HEADER.
1.1.2.2.6.2 UI Modeling
The purpose of UI modeling is to define and customize user interfaces with which users process master data.
You use the Manage UI Configurations (USMD_UI_CONFIGURATION) Web Dynpro application to manage user interfaces in SAP Master Data Governance.
Each table row represents a separate user interface and consists of the user interface application and its configuration. You can create a new user interface
configuration by copying an existing one. You can also edit the configurations for existing user interfaces. Each link you click opens the relevant screen in the
Floorplan Manager (FPM).
Note
You can only use this function if Business Function Master Data Governance, Generic Functions 7.0 Feature Pack (MDG_FOUNDATION_5) is active.
The previous version of this application only allows management of UI configurations for specific types of single-object processing UIs.
If the relevant business function is not active, you can edit the relevant technical elements using transaction SE80. For more information, see the links in
this document under Activities Working with a UI Configuration . The documents listed cover editing using transaction SE80 as well as editing
using this Web Dynpro application.
The most common types of user interface that you can manage are as follows:
Single-Object Processing
Multiple-Record Processing
Search
There are many options to change a user interface including customizing, enhancement, context-based adaptation (CBA), and personalization. Some options
affect all clients of a system. Other options are client specific. It is even possible to restrict changes to only one user. For more information, see Floorplan
Manager for Web Dynpro ABAP.
Prerequisites
An active data model exists.
You have basic knowledge of how to use the FPM and of the configuration of applications and components with Web Dynpro ABAP.
To create a new user interface by copying an existing one, the following criteria must be met:
You can use an active MDG data model with at least one entity type with storage and use type 1.
You have assigned a business object type code (OTC) to this entity type.
Before starting the configuration you need to carry out the following steps to ensure the default data model as the data model for which the UI is
configured in the following way:
1. Run transaction SPERS_MAINT.
2. Select Edit Objects
3. From the displayed list, choose SAP Master Data Governance - R_FMDM_MODEL .
4. In the pop-up, set the value of the field Standard Data Model to the model that you want to use for UI processing.
5. Confirm and save.
Activities
Single-Object Processing
Concept: Creating User Interfaces for Single Object Processing
Instructions: Creating a Basic Configuration for the Single-Object Processing UI
Search
Concept: Configuration of the Generic Search
Instructions: Configuring the Generic Search for a Particular Business Object Type
In a complete UI configuration for single object processing, several components work together and need to be configured accordingly as shown in the figure
MDG UI Configuration for Single-Object Processing below.
Two of these components are the MDG Web Dynpro application USMD_OVP_GEN and MDGF_OVP_GEN with their application configurations. Each
application configuration is specific for an object type and this object type is defined with the parameter USMD_OTC.
This Web Dynpro application implements an adaptable overview page (OVP) component of the Floorplan Manager (FPM): FPM_ADAPTABLE_OVP. This OVP
component is a wrapper that contains an FPM overview page component (FPM_OVP_COMPONENT). The configuration of the adaptable OVP references the
adaptation scheme for creating context based adaptations (CBA) of the included OVP component and of its sub-components.
For more information, see Generic Context-Based Adaptation Scheme.
The configuration of the OVP contains at least one page. At least one section of the page contains user interface building blocks (UIBBs). Most UIBBs enable
the processing of business object data on the UI. The UIBBs are configured for all entity types that belong to the business object. Usually, there’s more than
one entity type.
The MDG framework provides the following UIBBs:
The change request UIBB (CRUIBB) displaying the change request properties, such as description, due date, notes, and attachments
The validity UIBB displaying the time validity for edition-based entities
These UIBBs are no explicit parts of the configuration of the Web Dynpro application, but are added at runtime by the MDG communicator, which has overall
responsibility for the change request process. The MDG communicator controls the availability of change request actions, which are represented as buttons in
the global toolbar. The settings that the MDG communicator uses are stored in its component configuration.
Note
You can also include the CRUIBB explicitly in the OVP configuration.
If you want to have an object-specific search, the OVP can include an initial screen with an FPM search UIBB to enter search criteria and a list UIBB to
display search results.
genIL Components
When you activate an MDG data model that is in the customer namespace, the system creates the following genIL components as local objects. The names
of the components are as follows:
ZSP_<ID of MDG data model>
This component is responsible for all user interfaces related to the single object processing of the entity types from your custom data model. If your data
model ID, for example, is ZT, the genIL component is named ZSP_ZT.
ZMP<ID of MDG data model>
This component is responsible for all user interfaces related to the multi-record processing of the entity types from your custom data model. If your data
model ID, for example, is ZT, the genIL component is named ZMP_ZT.
ZHP<ID of MDG data model>
This component is responsible for all user interfaces related to the hierarchy processing of the entity types from your custom data model. If your data
model ID, for example, is ZT, the genIL component is named ZHP_ZT.
You can check the successful creation of the genIL components by calling transaction GENIL_MODEL_BROWSER.
Note
If you work with a data model that is in the SAP namespace, you have to create the related genIL components and a transaction handler class manually.
For more information, see Creating genIL Components and Transaction Handler Manually.
The data quality functions of MDG allow you to enrich and validate master data, as well as to prevent the creation of duplicates. The various search
capabilities are not only used to find master data that can be processed, but are also used for matching data to prevent the creation of duplicate information.
Correct and complete data can be achieved with automatic derivation of attributes and enrichment from external data sources.
Note
To configure SAP HANA Search see Configuring SAP HANA-Based Search for MDG and Configuring Drill-Down Search (Optional).
In SAP Master Data Governance you can use the database search to find master data for changing or verification. It is an exact search method that is based
on exact values or value ranges like identification numbers or names that are stored in databases.
In SAP Master Data Governance you can also implement your own search providers. If you want to do this, you have to do the following:
Procedure
Note
Your access class must use the standard search interface IF_USMD_SEARCH_DATA ( Search for Entities ).
2. User interface: Use the generic WebDynpro application USMD_ENTITY_SEARCH and launch it with the parameter SEARCH_MODE = your new search
application (as defined in step 1).
The configuration of governance scope, change requests, and workflow offers you flexible ways to model the desired governance process.
You can determine a governance scope based on your business needs. Ungoverned fields are read-only in change requests, unless you remove them from the
user interface.
Example
In the material application, you can for example, remove sales grouping data from the governance scope.
Prerequisites
You have identified the data models whose governance scope you want to change, as well as the content within each data model that you want to govern.
You are aware of the consequences of changing the governance scope. See the help document in Customizing for Master Data Governance under
General Settings Process Modeling Define Governance Scope
Procedure
1. In Customizing for Master Data Governance under General Settings Process Modeling , choose Define Governance Scope .
Result
You have defined a governance scope for the data model. You can keep ungoverned data model elements on the user interface for information purposes. If the
elements are not informative to your users, we recommend that you remove them. For more information, see Managing of UI Configurations.
You need to carry out the following steps if you want to enable users to create a single entity without having to create a change request beforehand in a
separate step. As a result, the user also no longer needs to select the data model, the entity type, or the change request type. These are predefined
automatically as part of the configuration settings described in this documentation.
Procedure
1. Create a new business activity in the customer namespace.
In Customizing for Master Data Governance, Central Governance , choose General Settings Process Modeling Change Requests Create
Business Activity .
2. Assign the new business activity to a change request type for single objects.
In Customizing for Master Data Governance, Central Governance , choose General Settings Process Modeling Change Requests Create
Change Request Type .
When configuring the change request process you need to define the following:
Processing steps and their processors
Possible actions of processors
Process flow between steps
Change request status in each step
Additionally, you can use editions to schedule changes and you can define when the data replication should happen. For more information, see Using Editions
to Schedule Changes.
You must configure the following elements:
Change Request Type
The change request type defines which data can be processed. The change request type is assigned to one MDG data model and lists the possible
entity types that the change request can contain.
SAP Business Workflow is used to process change requests in SAP Master Data Governance. To define the process flow of the change request you
can use standard workflow templates or custom workflow templates when defining a change request type. For more information on SAP Business
Workflow, see the Customizing activities under SAP NetWeaver Application Server Business Management SAP Business Workflow .
Alternatively, you can use the MDG rule-based workflow template when defining a change request type. In this case, the content of Business Rule
Framework plus (BRFplus) decision tables defines the process flow of the change request.
For more information, see the Customizing activity Create Change Request Type under General Settings Process Modeling Change Requests
.
Change Request Step
Each change request process consists of a number of change request steps that can be either dialog steps or background steps. For each dialog
change request step, you can do the following:
Assign processors
Configure validations and data enrichments
Assign UIs
The processing sequence of the steps is based on the processors' decision and other criteria that are evaluated by the workflow assigned to the change
request type.
If you are not using the rule-based workflow, the workflow template defines the available change request steps. Every change request type using this
workflow template can only have the available steps. For more information, see Customizing activity Define Change Request Step Types and Assign
Actions under General Settings Process Modeling Workflow .
If you are using the rule-based workflow, the Customizing settings and the content of the BRFplus decision tables define the available steps. Every
change request type using the rule-based workflow can have different change request steps although all change request types are using the same rule-
based workflow template. For more information, see Customizing activity Define Change Request Steps for Rule-Based Workflow under General
Settings Process Modeling Workflow Rule-Based Workflow .
Change Request Step Type and Change Request Action
The change request step type defines the possible actions that a processor of a change request step can use. We deliver a number of change request
step types, for example Approve Change Request with the possible actions Approve and Reject .
The change request step type of each change request step is determined at runtime. You can configure a change request step that allows the actions
For the design of the change request process and its configuration, it is useful to create a diagram that comprises all change request steps and their
connections. The recommended process is as follows:
Process
1. Start with step 00 and an appropriate description, for example Request. Provide a name for the group of users that are allowed to create change
requests of this type, for example Requester.
Note
You control which users can create change requests of a certain type with the authorization object USMD_CREQ. For further information on
authorizations, see Authorization Objects and Roles Used by Master Data Governance.
2. Add a step for each task that a user needs to perform. Assign a step number that is unique for the process and choose an appropriate description. Name
the group of users that shall perform the task. Select a step type in Customizing activity Define Change Request Step Types and Assign Actions under
General Settings Process Modeling Workflow that fits to the task and includes the actions the processor should be able to choose. Add the
step type and the possible actions as outcomes to the diagram like shown below.
Dialog Step 90/Approve: With Expert as Processor, Approve Change Request as Step Type, and Approve and Reject as Possible Actions
3. Add a step for each background task. Assign a step number and a description. Add this information together with the description of the background task
to the diagram. Also, include all possible outcomes of the task on which you want to react in the process. Some important standard tasks of MDG to
work with the change request are the following:
ACTIVATE CHANGE REQUEST (TS60808002)
DISCARD CHANGE REQUEST (TS75707936)
CHANGE REQUEST REPLICATION (TS60807976)
4. Connect each step with an arrow that originates from the respective outcome of the previous step and ends at the step that should follow. For each
arrow, add the new status that the change request shall have, when the process proceeds from one step to the next.
If the expert chooses to approve the change request, the status shall be set to 02/Changes to be Executed, and the system shall activate the change
request.
More Information
For more information, see Creating a Basic Change Request Process and Add User-Agent Steps for examples to configure the rule-based workflow.
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
1. Choose an appropriate template by examining its documentation.
2. Create the change request type and enter the chosen workflow template.
3. Perform further configuration according to the requirements of the template, for example, assign processors to the change request steps.
Custom Workflow Template
1. Create the workflow template.
2. Define the change request steps in the MDG Customizing.
3. Create the change request type and enter your custom workflow template.
4. Perform further configuration, according to the requirements of the template, for example assign processors to the change request steps.
Rule-based workflow
1. Create the change request type.
2. Define change request steps in MDG Customizing.
3. Create decision tables.
You use this process to define the mandatory Customizing settings that are needed to enable SAP Business Workflow for the change request process in
Master Data Governance.
Prerequisites
You have defined the necessary settings for SAP Business Workflow and defined the organizational plan in Customizing under SAP NetWeaver
Application Server Business Management SAP Business Workflow .
Process
1. The workflow system user (typically WF-BATCH) processes background tasks of MDG. Therefore, this user needs to have the required MDG
authorizations. Assign the PFCG role SAP_MDG_WF_ADM to the workflow system user in transaction SU01. For more information, see SAP Note
1650993 .
2. Create event type linkages for the business object BUS2250 (MDG Change Request) as described in Customizing activity Activate Type Linkage under
General Settings Process Modeling Workflow .
3. To assign processors to change request types and change request steps, decide on the possible agents of the MDG workflow tasks in general. In
Customizing activity Configure Workflow Tasks under General Settings Process Modeling Workflow assign specific agents from your
organizational plan to each dialog task. In the attributes pop-up of each dialog task, select to whom processors may forward a respective work item.
Instead of assigning specific possible agents to a dialog task, you can also classify a dialog task as general task, so that a work item can be executed
by any user. All users in the list of possible agents that are also assigned as processors of a change request step, are selected as the agents at runtime
and will receive the work item. Make the settings for all dialog tasks of the application component CA-MDG-AF and the respective components of the
MDG application that you use.
Note
If you assign a processor to a change request step that is not assigned as possible agent, the workflow will end in an error at runtime unless you
have classified the task as general task.
Instead of building your own workflow template, you can use the MDG rule-based workflow. Using the rule-based workflow, you can configure any kind of
change request process without the need to create and adapt a workflow template. You can define different change request processes in decision tables of the
Business Rules Framework plus (BRFplus), which are maintained in Customizing for each change request type. At runtime, the current step, the user
interactions, and other parameters in the decision tables determine the process flow of the change request. When you adapt the decision tables in BRFplus,
you can add or remove a change request step or change the order of the steps without changes in the workflow template.
The rule-based workflow uses BRFplus to determine the change request status, the next change request step, and expected agent(s). To make this
information available, the system uses the current step, the last action, the priority of the change request, and, where appropriate, the reason of rejection as
input parameters. You access the BRFplus application to determine how change requests are processed for a particular change request type in Customizing
activity Configure Rule-Based Workflow under General Settings Process Modeling Change Requests Workflow Rule-Based Workflow . If you
process this Customizing activity for a change request type for the first time the system generates a BRFplus application for each change request type. Each
application contains functions, rule-sets, and decision tables. The content of the decision tables defines the change request process.
Three decision tables are available for each change request type:
Single Value Decision Table
The Single Value Decision Table DT_SINGLE_VAL_<change request type> defines the process flow between the change request steps. Based
on the previous step, the action, and other parameters, this table returns the next step and other result parameters. The most important result parameter
is the condition alias that links to the other decision tables. This decision table has the following condition columns:
CR Previous Step
This parameter contains the previously processed change request step.
Previous Action
This parameter contains the result of the previous system or previous user action.
Chng. Req. Priority
This parameter contains the current priority of the change request.
Chng. Req. Reason
This parameter contains the reason for this change request.
CR Rejection Reason
This parameter contains the reason for rejection of this change request.
CR Parent Step and Parallel Agt Grp No.
These columns are used for parallel processing and are considered by the rule-based workflow to find the next step in the relevant subprocess.
The system identifies the relevant subprocess by referring to the values in CR Parent Step and Parallel Agt Grp No. . For more information, see
Parallel Processing.
Based on the data from these condition columns, the system takes the actions and sets the statuses outlined in the result columns. This decision table
has the following result columns:
Condition Alias
The condition alias references the other decision tables. Each condition alias must be handled using at least one row in either the User Agent
Decision Table or the Non-User Agent Decision Table .
New Chng. Req. Step
This parameter contains the next step in the process.
New CR Status
More Information
For information on how to create and enhance your rule-based workflow, see Creating a Basic Change Request Process and Add User-Agent Steps.
Application specific information on rule-based workflow is available in Rule-Based Workflows for Material.
This document explains how to configure the rule-based workflow for a change request process that you have described using a process diagram as explained
in Designing the Change Request Process.
Prerequisites
You have completed the Customizing settings as described in Workflow Set-Up.
Process
Enhance Process Diagram
Enhance the process diagram with further information required by the rule-based workflow. For each non-user agent change request step, determine the
appropriate Process Pattern and add the information to the diagram.
To activate the change request, you need to use the process pattern 06/Activation.
For each arrow pointing to a change request step, choose a 3 digit identifier for the condition alias. It is common to use abbreviations of the step’s
meaning for better readability, for example APP for an approval step.
The arrow pointing to the change request step Activate is labeled with the condition alias ACT.
For information about an example of a process diagram that is enhanced for the rule-based workflow, see Add User-Agent Steps.
Create Change Request Type
In Customizing activity Create Change Request Type under General Settings Process Modeling Change Requests , create the change
request type for which you want to define the process flow. Assign the rule-based workflow template WS60800086 to the change request type.
Define Change Request Steps
In Customizing activity Define Change Request Steps for Rule-Based Workflow under General Settings Process Modeling Workflow Rule-
Based Workflow , define the process steps that are used in the process diagram of your change request type.
Service Names
In the case of a complex workflow scenario, for example, when using a handler to merge the results of parallel processing, you need to define service
names for the BAdI implementations that you need to use. For more information, see the documentation of Customizing activity Define Service Names
for Rule-Based Workflow under General Settings Process Modeling Workflow Rule-Based Workflow .
Build Decision Tables
Start Customizing activity Configure Rule-Based Workflow under General Settings Process Modeling Workflow Rule-Based Workflow and
enter your change request type to open the BRFplus workbench and to enter the values for the decision tables.
Note
If you perform this activity the first time for this change request type, the BRFplus application is generated. Depending on the settings of the client,
you are asked to assign a transport request and a software component.
1. For each arrow in your process diagram, enter a row in the Single Value Decision Table DT_SINGLE_VAL_<change request type>. Use the
step numbers on each end of the arrow as the values for CR Previous Step and New Chng. Req. Step . The action code of the previous step
that triggers this connection is the value for Previous Action . The labels on the arrow provide the values for Condition Alias and New CR
Status .
Note
You can use the condition columns Chng. Req. Priority , Chng. Req. Reason , CR Rejection Reason , CR Parent Step , and Parallel Agt
Grp No. as additional parameters to make the process flow more specific.
You can enter a time limit for the processors of the next change request step in Hours to Completion . This uses the feature of the requested
end deadline monitoring of the SAP Business Workflow. The rule-based workflow will send a notification to all processors of this change request
step as a reminder to complete this task.
The result columns Merge Type and Merge Parameter are used for parallel processing. For further information, see Parallel Processing.
Instead of providing values for the result columns in the decision table, you can provide a service name in Dyn Agt Sel Service to link to an
implementation of BAdI: Dynamic Selection of Agent in Rule-Based Workflow . For more information, see the documentation of BAdI: Dynamic
Selection of Agent in Rule-Based Workflow in MDG Customizing under General Settings Process Modeling Workflow Rule-Based
Workflow Business Add-Ins .
2. For each user agent step in your process diagram, enter a row in the User Agent Decision Table DT_USER_AGT_GRP_<change request
type>. If you followed the recommendation in Designing the Change Request Process to use the same condition alias for all arrows that point to a
change request step, use this value for the column Condition Alias . If you use different aliases, you need to create multiple rows, one for each
alias.
Transfer the values for Step Type , User Agent Type , and User Agent Value from the diagram into the table. The valid values for User Agent
Type and User Agent Value are defined by your organizational structure (for example, see Customizing activity Edit Organizational Plan ) and
identify an organizational object, for example, the purchasing department. If you use SU for User Agent Type you can use INIT (Initiator) as
User Agent Value to select the requester of the change request as processor. Furthermore, the value LAST for User Agent Value selects the
processor of the previous step as the processor.
If the overall group of processors for the change request step consists of multiple organizational objects, create a row for each object. In this case
and unless you want to configure parallel processing of the change request step, use the same value for User Agt Grp No . for this condition alias.
You configure parallel processing of the change request step by using different values for User Agt Grp No. for the same condition alias. For
further information, see Parallel Processing.
The information from this diagram leads to the following values in the decision table: Condition Alias = APP. User Agt Grp No. = 001 (arbitrary value).
Step Type = 02. User Agent Type = AG. User Agent Value = MD Experts (assuming there is a PFCG role named MD Experts and all users assigned to
this role should be processors).
3. For each background step in your process diagram, enter a row in the Non-User Agent Decision Table DT_NON_USER_AGT_GRP_<change
request type>.
If you followed the recommendation in Designing the Change Request Process to use the same condition alias for all arrows that point to a change
request step, use this value for the column Condition Alias . If you use different aliases, you need to create multiple rows, one for each alias.
Transfer the value for Process Pattern from the diagram into the table. If required by the chosen process pattern, specify the Service Name .
Unless you want to configure parallel processing in this change request step, choose any value for Agent Group , for example 001. For more
information, see Parallel Processing.
Caution
The decision tables are processed in sequence Therefore, the table entries should be arranged starting with the most specific ones, followed by more
general ones.
More Information
For information about examples of process diagrams related to the rule-based workflow, see Creating a Basic Change Request Process and Add User-Agent
Steps.
The rule-based workflow groups several workflow steps together to form basic operations that are called Process Patterns . These patterns are used to control
the flow of the change request process or to define which background task the system will perform in a change request step.
Technically, the rule-based workflow runs in a loop. In each repetition of the loop, one out of several process patterns is executed. The workflow continues to
run in this loop until the change request process is ended with the process pattern 99 Complete (Sub-)Workflow .
If the current change request step is a user-agent step, the used process pattern is 01 UI Dialog . For non-user agent steps, the column Process Pattern in
the Non-User Agent Decision Table DT_NON_USER_AGT_GRP_<change request type> is used to determine the pattern.
The possible process patterns are:
01 UI Dialog
This process pattern is used by the system for user-agent change request steps and should not be entered by you in the Non-User Agent Decision
Table . It is a special process pattern that is always automatically selected if a user agent has been found in the user agent decision table. This process
pattern uses the dialog task Dialog Processing TS60807954.
02 Call Synchronous Method
You can use this process pattern to include operations that are not provided from SAP. This process pattern uses the background task Synch. System
Method TS60807949. For more information, see BAdI: Calling of System Method for Rule-Based Workflow in MDG Customizing under General
Settings Process Modeling Workflow Rule-Based Workflow Business Add-Ins .
03 Call Sub-Workflow
You can use this process pattern to start a sub-workflow. The background task Subworkflow for Single Step Workflow TS60807994 starts a sub-
workflow with the workflow template ID that is read from the column Service Name of the non-user agent decision table.
04 Call Data Replication
You can use this process pattern to start the replication of the master data after the change request has been activated. This process pattern uses the
background task Change Request Replication TS60807976 and the method DISTRIBUTE of the object type MDG Change Request BUS2250 to
replicate the object using the data replication framework (DRF).
05 Activation (do not bypass snapshot)
You can use this process pattern to activate the data in the change request. This process pattern uses the background task Activate Change Request
TS60808002 with the indicator IGNORE_SNAPSHOT_DIFF not set. The value of Previous Action is updated with the result of the operation enabling
you to handle error situations. If there have been conflicting changes to the data in the standard master data tables while the change request was in
process the activation fails. In this case, Previous Action is set to 33 Activation failed for Snapshot . If the activation was successful Previous
Action is set to 31 Activation Successful . In all other cases, Previous Action is set to 32 Activation failed .
06 Activation (bypass snapshot)
You can use this process pattern to activate the data in the change request, even if the data has been changed in the backend since the change request
was created. The system ignores these potential changes and overwrites them. This process pattern uses the background task Activate Change
Request TS60808002 with the indicator IGNORE_SNAPSHOT_DIFF set.
07 Validate Change Request
You can use this process pattern to validate the change request data. The results are written to the application log. The process pattern uses the
background task Check Change Request TS75707952.
08 Roll Back Change Request
You can use this process pattern to remove the inactive data of the change request from the staging area if the change request should not be activated.
This process pattern also provides the information when and by whom the change request was released and sets the change request status to 06 Final
Check Rejected . The process pattern uses the background task Discard Change Request TS75707936.
98 Error
You can use this process pattern to handle errors and exceptions. The process pattern uses the background task Error Handler TS60807951.
99 Complete (Sub-)Workflow
You can use this process pattern to end the rule-based workflow instead of looping back.
This document describes how to enable a basic change request process using the MDG rule-based workflow. This basic change request process only
activates the change request after it was submitted. The process does not include any dialog step. To provide data governance capabilities, you need to
enhance the process adding further change request steps such as approving the change request.
The figure in this document shows a complete process.
The process starts with step 00 when the requester submits the change request. The next step 91 is the activation of the change request. If the change
request is successfully activated, its status is set to Final Check Approved and the process ends with step 99. If the activation fails, the change request is
rolled back in step 92, the change request status is set to Final Check Rejected , and the process ends.
Prerequisites
You have created a change request type and you have entered the template for rule-based workflow WS60800086 in Customizing activity Create Change
Request Type under General Settings Process Modeling Change Requests . In the following example configuration, the change request type
CR_TYPE is used.
Process
You need to perform the following steps in order to configure the rule-based workflow for the basic change request process:
1. Create necessary change request steps.
Define the change request steps 00, 91, 92, and 99 as shown in the figure in Customizing activity Define Change Request Steps for Rule-Based
Workflow under General Settings Process Modeling Workflow Rule-Based Workflow .
Change Request Type Change Request Step Description of Change Request Step
CR_TYPE 00 Request
CR_TYPE 91 Activation
CR_TYPE 99 Complete
CR Previous Step CR Previous Action Condition Alias New CR Step New CR Status
00 n.a. ACT 91 02
91 31 END 99 05
91 31 RB 92 02
92 n.a. END 99 06
The basic process contains only steps with background steps. Therefore, you only have to configure the Non User Agent table and the User Agent
table is left empty. In the figure all arrows pointing to the same change request step have identical condition aliases. These condition aliases have been
chosen to match the process pattern of this step.
You have to add a row in the Non User Agent table for each change request step and use the following information from the figure:
Condition Alias
Process Pattern
Note
The column Agent Group is only relevant for parallel processing. Use the value 001 to create one work item for a change request step.
If you look at the arrow with condition alias ACT from step 00 to step 91 with process pattern 05, the first row in the Non User Agent table contains the
condition alias ACT, agent group 001 and process pattern 05.
The following rows are needed in the Non User Agent table for the configuration of the complete basic process:
ACT 001 05
RB 001 08
END 001 99
After you have saved and activated the new entries for the Single Value table and the Non User Agent table, you can use the new change request
type.
This document describes how to enhance the basic change request process with a user agent step. In the basic process, a change request is immediately
activated after the requester submits the change request without further involvement of another user. In this enhanced process, a second user checks the
change request in an additional user-agent step. If this user decides to approve the change request, the activation is started with change request step 91.
Otherwise, the roll back of the change request is started with change request step 92. The other change request steps are not changed.
Note
The terms dialog step and user agent step are used as synonyms in MDG.
To enhance the basic process from the document Creating a Basic Change Request Process to the enhanced process described in this document, the new
step 90 Final Check with step type 2 Approve Change Request is added. The user symbol next to the step type indicates that this is a user-agent step. The
arrow from change request step 00 now points to the new change request step 90. The condition alias of this arrow was chosen as FC to abbreviate Final
Check. The arrow, depicting that the user has accepted the change request with action 03, points to the change request step 91. The condition alias ACT for
the change request step 91 is added to the arrow. The arrow, depicting that the user has rejected the change request with action 04, points to the change
request step 92. The condition alias RB for the change request step 92 is added to the arrow.
Prerequisites
You have configured the rule-based workflow for the basic change request process, as described in Creating a Basic Change Request Process. In the
following example process, the change request type CR_TYPE and the user FINAL_CHECK_USER are used.
Process
You need to process the following steps in order to extend the basic workflow with a user step:
1. Create the new change request step.
The new change request step for the user dialog is defined in Customizing activity Define Change Request Steps for Ruled-Based Workflow under
General Settings Process Modeling Workflow Ruled-Based Workflow .
Workflow Step Numbers
CR Previous Step CR Previous Action Condition Alias New CR Step New CR Status
00 n.a. FC 90 02
After this change, you have to add a new row to the Singe Value table for every arrow that is depicted in the figure Change Request Process Including
Dialog Tasks and not depicted in the figure Basic MDG Change Request Process. You have to add the following rows to configure the new sequence of
steps:
CR Previous Step CR Previous Action Condition Alias New CR Step New CR Status
90 03 ACT 91 02
90 04 RB 92 02
In the basic rule-based workflow, only background tasks are used. In the enhanced workflow described in this document, a dialog task is used. In the
User Agent table, you have to configure the user agent group, the change request step type, the user agent and the user agent value for the new
change request step 90. The following line with the condition alias FC for the new change request step is required:
Condition Alias User Agt Group Step Type User Agent Type User Agent Value
More Information
Rule-Based Workflow: Technical Details
1. Start Workflow
An instance of the rule-based workflow template is started when a user submits a change request of a type that has the rule-based workflow template
assigned. The same workflow template is also used to create sub-workflow instances for parallel processing.
2. Determine Change Request Type
The system determines the change request type; for example, Create Material or Change Material and stores the change request type in the workflow
container.
3. Check Assignment of Processor to Workflow
The system checks whether a processor is already assigned to the workflow, for example, the current workflow instance is a sub-workflow that was
started for parallel processing.
If a processor is not yet assigned, the system launches BRFplus. The BRFplus decision tables for the change request type are used to find the next
step, the process pattern, and the agents, based on the previous step and action. If the current workflow instance is the main workflow, the system also
refreshes the status of the change request.
4. Determine Whether Single Processing or Parallel Processing is Configured
The system determines the number of configured agent groups of the current change request step. An agent group can consist of a single user or
multiple users. For example, it might be necessary that users in the purchasing department and users in the accounting department should able to
approve the change request in parallel.
If more than one agent group is found, parallel processing is configured and the system proceeds as follows:
1. The system creates multiple workflow instances of the WS60800086 template: one for each agent group. These sub-workflows run in parallel.
2. As soon as all subworkflows are completed, the BAdI: Handling of Parallel Results in Rule-Based Workflow in MDG Customizing under
General Settings Process Modeling Workflow Rule-Based Workflow Business Add-Ins is called in order to merge the results of the
parallel subworkflows into one result and, based on those results, determines the next step of the change request process.
5. Branch by Process Pattern
Based on the determined process pattern, the workflow branches into one out of several basic operations of the rule-based workflow.
For more information, see Process Pattern
6. Check Workflow Completion
The system checks whether the process pattern was 99 Complete (Sub-)Workflow .
If this is the case the system completes the workflow.
If this is not the case the system returns to step 3 and starts again.
The following workflow templates are available for Master Data Governance for Financials:
Workflow Template WS72100012
Workflow Template WS75700027
Workflow Template WS75700040
Workflow Template WS75700043
For more information, see Configuration of the Workflow.
SAP delivers the standard workflow template WS72100012 for the approval process. This enables you to forward the change request as a work item to the
appropriate processors. The status of the change request is automatically updated in the background. The template is mandatory for cost center hierarchy or
profit center hierarchy maintenance if the objects are distributed using IDocs to the MDG client systems.
This workflow template consists of the following steps:
1. Start workflow
The workflow is started when a change request is created, for example, by a corporate accountant.
2. Get number of parallel steps
The system determines the number of users or user groups to which the change request needs to be sent.
3. Evaluate change request
A work item is sent to all responsible master data specialists. Each specialist independently evaluates the change request and either agrees or
disagrees with it:
If one or more specialists disagree with the change request, the work item with the change request is sent back for revision to the corporate
accountant ( → Step 4).
If all master data specialists agree with the change request, a work item with the change request is sent to the master data manager for
consideration and approval ( → Step 5).
4. Revision after rejection
The person responsible for processing the change request when it is rejected, such as the corporate accountant, decides whether to revise the change
request:
If he or she revises the change request, a work item with the change request is again sent to the master data specialists for evaluation ( → Step
3).
If he or she withdraws the change request, the status of the change request is set to Final Check Rejected . If changes have already been made
to the master data, these are reset and the workflow is ended ( → Step 10).
5. Consider and approve
The master data manager gets a work item to approve or reject the change request:
If he or she rejects the change request, a work item with the change request is sent back for revision to the corporate accountant ( → Step 4).
If he or she approves the change request, a work item with the change request is sent to the master data processor to execute the changes ( →
Step 6).
6. Execute changes
Note
The changes are then activated in the central system. When the workflow has been completed, the changes still need to be distributed to the local
systems. If a cost center hierarchy or profit center hierarchy has been changed, the system creates MDG change pointers for the affected cost
centers or profit centers. After activation, the system triggers the distribution based upon the previously created MDG change pointers. This ensures
that both the hierarchies and master data is synchronized in the MDG client system.
SAP delivers the standard workflow template WS75700027 for the approval process. This enables you to forward the change request as a work item to the
appropriate processors. The status of the change request is automatically updated in the background.
This workflow template consists of the following steps:
1. Start workflow
The workflow is started when a change request is created, for example, by a corporate accountant.
2. Get number of parallel steps
The system determines the number of users or user groups to which the change request needs to be sent.
3. Evaluate change request
A work item is sent to all responsible master data specialists. Each specialist independently evaluates the change request and either agrees or
disagrees with it:
If one or more specialists disagree with the change request, the work item with the change request is sent back for revision to the corporate
accountant ( → Step 4).
If all master data specialists agree with the change request, a work item with the change request is sent to the master data manager for
consideration and approval ( → Step 5).
4. Revision after rejection
The person responsible for processing the change request when it is rejected, such as the corporate accountant, decides whether to revise the change
request:
If he or she revises the change request, a work item with the change request is again sent to the master data specialists for evaluation ( → Step
3).
If he or she withdraws the change request, the status of the change request is set to Final Check Rejected . If changes have already been made
to the master data, these are reset and the workflow is ended ( → Step 10).
5. Consider and approve
The master data manager gets a work item to approve or reject the change request:
If he or she rejects the change request, a work item with the change request is sent back for revision to the corporate accountant ( → Step 4).
If he or she approves the change request, a work item with the change request is sent to the master data processor to execute the changes ( →
Step 6).
6. Execute changes
The master data processor receives a work item to execute the changes:
If he or she is unable to execute the changes, he or she can send the change request back to the corporate accountant. In this case, a work item
with the change request is sent to the corporate accountant for revision ( → Step 4).
If he or she is able to successfully execute the changes, the changes made to the master data are then checked ( → Step 7).
7. Validate
The system checks the change request using validation rules for consistency, and saves the check results in a log. Afterwards, the log is available in
the change request.
8. Perform final check
The master data manager gets a work item to do a final check of the change request. He or she checks the validation results in the log and then either
approves or rejects the final check:
If he or she rejects the change request, a work item with the change request is sent back for revision to the corporate accountant ( → Step 4).
If he or she approves the change request, the system activates the changes. ( → Step 9).
9. Activate changes
The system activates the master data in the database tables of the modified objects according to the changes entered in step 6.
Note
The changes are then activate in the central system. When the workflow has been completed, the changes still need to be distributed to the local
systems.
SAP delivers the standard workflow template WS75700040 for the approval process. This enables you to forward the change request as a work item to the
appropriate processors. The status of the change request is automatically updated in the background.
This workflow template consists of the following steps:
1. Start workflow
The workflow is started when a change request is created by the user, for example, a corporate accountant.
2. Execute changes
The master data specialist receives a work item to execute the changes:
If they do not want to execute the changes, they can send the change request back to the corporate accountant. In this case, a work item with the
change request is sent to the corporate accountant for revision ( → Step 3).
If they want to execute the changes, the changes made to the master data are then checked ( → Step 4).
3. Revision after rejection
The person responsible for processing the change request when it is rejected, such as the corporate accountant, decides whether to revise the change
request:
If he they revise the change request, a work item with the change request is again sent to the master data specialist for processing ( → Step 2).
If they withdraw the change request, the status of the change request is set to Final Check Rejected. If changes have already been made to the
master data, these are reset and the workflow ends ( → Step 6).
4. Perform final check
The system checks the change request, using validation rules for consistency, and saves the check results in a log. The master data steward receives
a work item to do a final check of the change request. They check the validation results in the log and either approve or reject the final check:
If they reject the change request, a work item with the change request is sent back for revision to the corporate accountant ( → Step 3).
If they approve the change request, the system activates the changes ( → Step 5).
5. Activate changes
The system activates the master data in the database tables of the modified objects according to the changes entered in step 4.
Note
The changes are then activated in the central system. When the workflow has been completed, the changes still need to be distributed to the local
systems.
6. End workflow
The system ends the workflow.
SAP delivers the standard workflow template WS75700043 for the approval process.
This enables you to forward the change request as a work item to the appropriate processors. The status of the change request is automatically updated in the
background.
Note
You define in the Customizing for Financial Master Data Management, under Workflow/Process Modeling Assign Processor to Workflow Step
(Advanced Workflow) , whether one or more responsible processors receive a work item in their worklists for the workflow steps, dependent on the entity
type (for example, entity type Account ).
Note
The responsible processors cannot add any new objects to the object list.
10. Validate
The system checks the change request using validation rules for consistency, and saves the check results.
The relevant employees from the responsible organizational units also receive a work item in their universal worklists to perform the final check of the
change request.
11. Perform final check
The relevant employees from the responsible organizational units have received a work item in their universal worklists to perform the final check of the
change request.
They check the validation results and make the following decision:
If a processor decides that the change request should be deleted, he or she rejects the change request. The responsible organizational unit then
receives the work item in their universal worklist to cancel the change request (→ step 8). The requester also receives an SAP express mail for
information.
If a processor decides that the change request needs to be revised, he or she rejects the change request. The responsible organizational unit then
receives a work item and revises the change request (→ step 8).
If a processor approves the change request, he or she approves the change request. The system then activates the changes (→ step 12).
12. Activate changes
The system activates the master data in the database tables of the modified objects according to the changes entered in step 9.
Note
The changes are then activated in the central system. When the workflow is over, the changes still need to be distributed to the local systems.
You can determine the extent to which users can make parallel changes to a hierarchy that belongs to a particular hierarchy type. A change to a hierarchy can
comprise adding a node, moving a node, removing a node, changing the attributes of a node, or creating a hierarchy. After a change to a hierarchy is saved to
a change request, changes to interlocked nodes must be saved to the same change request. The system determines which nodes are interlocked by referring
to the Interlocking setting in Customizing for the relevant hierarchy type.
Hierarchy nodes that represent business objects are technically distinct from the business objects themselves. Interlocking affects the parallel processing of
hierarchy nodes only.
The Interlocking setting applies to a Hierarchy Type and specifies which nodes besides the node being changed are interlocked while a hierarchy-specific
change is in process. The setting is described in the table below:
Loose Nodes assigned to the parent node of the node being changed.
Strict Interlocking propagates upwards and downwards from the parent node of the node
being changed:
Upwards interlocking interlocks the parent node and its assigned nodes, the
parent node of the parent node and its assigned nodes, and so on up to the
root node.
Downwards interlocking interlocks child nodes of the parent node, their
child nodes, and so on down to the end nodes. This comprises a
subhierarchy of interlocked nodes with the parent node at its root.
Prerequisites
To minimize business disruption, we recommend that you define the scope for changes to a hierarchy type when you define the hierarchy type within a data
model. You can only change the scope for changes to a hierarchy type when no pending change requests exist for any hierarchy of this type. If you must
change the scope after you have defined the hierarchy type and you must then transport your changes, ensure that no pending changes exist for the affected
hierarchies in the target system.
Example
The hierarchy called Global consists of continents, countries, cities, and teams. A change request to add Rome as a child node to Italy as the parent node is
pending. No other hierarchy-relevant change requests are pending. If you want to change nodes that are specified as Interlocked in the figures and
descriptions below, you must use the pending change request that assigns Rome to Italy. For changes to other nodes, you can use separate change requests.
Interlocking – Loose
The figure below shows how the Interlocking setting of Loose affects a hierarchy in the scenario where Rome is added to Italy.
Interlocking – Loose
Loose interlocking affects all nodes that are assigned to the parent node of the node being changed. The node being changed is Rome and its parent
node is Italy. Only the direct child nodes of Italy - Rome and Milan - are interlocked with the pending change request.
Interlocking – Strict
The figure below shows how the Interlocking setting of Strict affects a hierarchy in the scenario where Rome is assigned to Italy in a pending change
request.
Upwards Interlocking
All nodes in the path from Italy to Global are interlocked. The child nodes of these nodes are also interlocked. Affected nodes include the following:
Italy (parent node), Rome and Milan (child nodes)
Europe (parent node of parent node), France and Italy (child nodes)
Global (root node), Asia and Europe (child nodes)
Downwards Interlocking
All nodes in the subhierarchy below Italy are interlocked. Affected nodes include the following:
Cities Rome and Milan, which are below country Italy (Also covered by upwards interlocking)
Teams I and J, which are below city Rome
Teams K and L, which are below city Milan
Any other nodes that might be added in the future to any nodes descending from Italy
You can apply system settings that allow you to monitor in detail how effectively your organization processes change requests. You can analyze the statuses
of change requests in your organization, the processing times of change requests in your organization, and the nature of change requests involving you. For
more information, see Analysis of Change Requests.
Procedure
Enabling the detailed analysis of change requests involves completing the following tasks:
1. Configuring Operational Data Provisioning
2. Activating Business Information (BI) Content in Master Data Governance
3. Setting up the business context viewer
4. Assigning roles to your user
5. Changing authorization objects
6. Integrating SAP BusinessObjects Dashboards
7. (Optional) Defining a service-level agreement
Note
After you activate the business context viewer, you can configure a side panel for any Web Dynpro application.
MDG_MONITOR_CR_PROCESTIME Used for the analysis of the status of change requests or the processing time of
change requests.
MDG_ANLY_CR_REJ_REASON Used to display the reasons why change requests were rejected.
Note
You can view and edit roles using transaction PFCG . The Menu tabbed page shows Web Dynpro applications. Often, existing roles that use the required
Web Dynpro applications have technical names with suffixes of *_MENU.
If you do not have the required roles, consider the following options:
Assign the Master Data Governance: Analytics (SAP_MDGA_MENU) role to your user.
This role only contains the relevant Web Dynpro applications.
Create your own role and add the Web Dynpro applications to that role.
If you do this, you can control the placement of Web Dynpro applications on the menu in the user interface.
SAP Master Data Governance Specify the types of change requests Change Request Type Specify the level of the access allowed
Type of Change Request users are allowed to analyze and the to each the change request types
(USMD_CREQ) level of access allowed. specified under Activities . As a
minimum, choose Display . Choose
other options, if required.
Caution
Be careful when using wildcards;
you do not want to accidentally
Business Context Viewer Specify the Web Dynpro applications Context Key Enter the following context keys:
Execute Side Panel (BCV_SPANEL) requiring a side panel. MDGAF_MYCR
The application is the
Application Framework (MDGAF)
and the object is My Change
Requests (MYCR). Specifying
this context key enables a side
panel for the My Change
Request screen.
MDGAF_ANLY
The application is the
Application Framework (MDGAF)
and the object is (ANLY).
Specifying this context key
enables a side panel for the
Status (Graphic View) screen,
which is used to analyze the
status of change requests.
Front End Integration Xcelsius Authorization for working with SAP RSXCLSID Specify the technical name of the
Dashboard (S_RS_XCLS) BusinessObjects Dashboards. dashboard: 0XC_MDG_MONITOR_CR.
5. Save the authorization profile and choose the ( Generate Authorization Profile ) icon.
Integrating Dashboards
For an overview of how to integrate dashboards, see Xcelsius Enterprise Integration
SAP Business Objects dashboards only work if a BI Java server is enabled. For more information, see SAP Note 1450981
Result
After completing this procedure, it is possible to access meaningful analytical information about change requests.
For greater flexibility you want to be able to develop new UIs that enhance your Master Data Governance applications and are consistent with the existing
software. A number of developments in the Master Data Governance Application Framework (MDGAF) allow you greater freedom to build UIs for applications.
Governance API
Convenience API
Application Context API
Communicator
Change Request UI Building Block (CRUIBB)
The configuration of components is shown below:
Features
Governance API
The Governance API covers the entire governance process, handling processes that are not UI-related, and background services such as master data load
and data replication.
The Governance API is designed to handle multiple change requests simultaneously. At any time, one instance of the Governance API can exist in the
system per data model.
The Governance API also provides services to the convenience API. There is less grouping of functions than in the Convenience API so that you can
combine a greater range of individual methods to meet the needs of the application. The Governance API also provides services for UI issues, but the
applications access these services through the Convenience API, which then calls the Governance API.
The Governance API Class ID is CL_USMD_GOV_API (IF_USMD_GOV_API).
Convenience API
The Convenience API provides the functionality needed for an application to work with a change request. It can handle one change request for a single data
model at a given time. The Convenience API takes over all governance-relevant logic such as managing change request data, handling change requests, and
routing change requests to the Governance API. The Convenience API groups together some of the methods of the Governance API ensuring tighter control of
the change request-handling capability available to the applications, and simplifying the use of UI services for applications. The application manages only the
application data.
The Convenience API Class ID is CL_USMD_CONV_SOM_GOV_API (IF_USMD_CONV_SOM_GOV_API).
Application Context API
The Application Context API stores context-specific runtime information at a central point so that this information is accessible for other parts of the
application and can be used to control the program-flow. Previously the system did not provide application context information such as what change request is
being processed and whether the master data object is to be created or updated. The Application Context API provides a consistent, reliable solution to this
problem.
The following context information is available:
Data model
Business activity
Workflow information
Change request
Change request type
Change request step
Change request index (relevant for parallel processing)
Workflow item
Application parameter data (stored in the Workflow Container, not accessed by MDG)
The Application Context API offers the following advantages:
Allows existing UIs to access the application context without using the complete Governance API
Keeps existing interfaces stable
Increases flexibility.
While, for example, the Governance API or Convenience API can only be instantiated for a data model, the Context API is directly available to MDGAF
A hierarchy is tree-like structure consisting of hierarchy nodes that is identified by its hierarchy name. The hierarchy type defines which objects can be used
as nodes. The configuration of hierarchies is centered around the hierarchy type. You use entity types in the MDG Data Model to create a hierarchy type.
Example
An airline hierarchy has a hierarchy type based on entity type Airline (CARR) and a hierarchy name based on entity type Names of Hierarchies of Airlines
(CARR_HIER)
Integration
You can start processing hierarchies from the results list of the Generic Search application, if it is configured for use with hierarchies. For more
information, see Search Business Object.
Collective Processing (USMD_ENTITY) allows users to structure and restructure a hierarchy. For more information, see Collective Processing.
You can open single-object processing for individual business objects displayed in the List View and in the Hierarchy view of the Collective
Processing application. For more information, see Single-Object Processing
(Applicable to selected business object types in SAP Master Data for Custom Objects and SAP Master Data Governance for Financials only) You
can assign individual business objects to hierarchies in the Hierarchy Assignment block of Single-Object Processing, if the appropriate change request
type is configured. For more information about the end user process, see Hierarchy Assignments in Single-Object Processing
Note
After working with a hierarchy assignment, users must finalize the change request before the system allows them to add, delete, remove, or change
the hierarchy properties of other hierarchy nodes that have the same parent node.
You can upload and download hierarchies in the relevant applications. For more information, see the following:
File Upload (USMD_FILE_UPLOAD)
File Download (USMD_FILE_DOWNLOAD)
You can change multiple master data objects at the same time through integration with the Mass Change process.
When you change data in Collective Processing , the process of either creating a new change request or assigning an existing change request to your
changes is supported.
Procedure
Note
All paths to Customizing mentioned in this document are in Customizing for Master Data Governance, Central Governance under General Settings .
When configuring hierarchy types, you need to answer the following questions, which are grouped based on their corresponding settings:
Data Modeling: Which entity type is a used as a hierarchy type? Is the hierarchy type synchronized? Is the hierarchy type version-dependent?
Data Modeling: Is the hierarchy type edition dependent?
You can use editions to schedule changes to business objects and hierarchies. For more information, see Using Editions to Schedule Changes.
Data Modeling: Which other entity types can be represented as nodes in hierarchies of this hierarchy type? Which entity type defines the root node
(Hierarchy Name)? For which entity types in the hierarchy are ranges permitted on end nodes?
Data Modeling: How do you define the relationships between nodes in a hierarchy of this hierarchy type?
For example, you can set credit / debit balances indicators on the account assignment in a financial reporting structure.
Data Modeling: What authorizations on the various levels of the hierarchy should the nodes have?
UI Modeling: Do you want to create a user interface for single-object processing that allows assignment of single objects to hierarchies?
Process Modeling: If the hierarchy type is version-dependent, which versions are defined?
Process Modeling: Which change request types are defined for the creation and processing of hierarchy types?
Process Modeling: When a user creates a change request for a hierarchy assignment, which nodes does the system interlock with the pending change
request?
Data Quality and Search: Which validations apply to the relationships between hierarchy nodes?
When a hierarchy node is expanded in the Collective Processing user interface, how many nodes should display?
Values: If the entity type is used as a hierarchy type, the field starts with Yes .
Requirement:
Assign the storage and use type 1 (Changeable via Change Request) to this
entity type.
Example:
A profit center group is the hierarchy type of a profit center hierarchy.
If versions of hierarchies can exist, the field starts with Yes and states that
the hierarchy type is Version Dependent .
Example:
The hierarchy can have a planning version and a current version.
If subhierarchies must be synchronized in all hierarchies they belong to, the
field starts with Yes and states that the hierarchy type is Synchronized
Example:
The structure of the synchronized subhierarchy Oyster Airline Alliance is
mirrored in hierarchy Airline Alliances - Regional and hierarchy Airline
Alliances - Tiered .
Version-Dependent Hierarchies
If the Oyster Airline Alliance hierarchy is version dependent, it can have a planning version and a current version. If it is not version dependent it can only have
one version (see figure below).
Values: Edition .
Hierarchies can use Editions. For more information, see Using Editions to
Schedule Changes.
Note
If you create an edition-dependent hierarchy, all business objects that
belong to that hierarchy and for which you have created user interface
building blocks (UIBBs) in single-object processing, must also be edition-
dependent.
No Edition
Hierarchies cannot use editions.
Data Modeling: Which other entity types can be represented as nodes in hierarchies of this hierarchy type? Which entity
type defines the root node (Hierarchy Name)? For which entity types in the hierarchy are ranges permitted on end nodes?
You specify the entity types that can be represented as nodes in a hierarchy. Each Entity Type has a designated use.
View: Inactive Data Models Entity Types Entity Types for Hierarchies
Setting: Use
Data Modeling: How do you define the relationships between nodes in a hierarchy of this hierarchy type?
Views: Inactive Data Models Entity Types Entity Types for Hierarchies
Hierarchy Attributes
For example, you can set credit/debit balances indicators on the account
assignment in a financial reporting structure. You can specify a hierarchy
attribute for a relationship using a data element. You can specify an
alternative data element if it is technically identical. .
Inactive Data Models Entity Types Entity Types for Hierarchies
Hierarchy Attributes from References
For example, you can set credit/debit balances indicators on the account
assignment in a financial reporting structure. You can specify a hierarchy
attribute for a relationship using a reference to an entity type. If you want to
add hierarchy attributes to the relation of the entity type for which the
hierarchy has been defined you have to specify it in the Entity Types for
Hierarchies view
Data Modeling: What authorizations at the various levels of the hierarchy should hierarchy nodes have?
In the Customizing activity Define Authorization Relevance per Entity Type , you can determine whether authorization is relevant for objects on every level of
the hierarchy (see table below).
Customizing Activity: Data Modeling Define Authorization Relevance per Entity Type
This activity indicates which parts of the hierarchy are authorization relevant, but
does not define the authorizations themselves.
More Information The authorization object for master data is USMD_MDAT and the authorization object
for hierarchies is USMD_MDATH. The standard role for a Master Data Governance
Administrator is SAP_MDG-ADMIN
For more information, see Authorization Objects and Roles Used by SAP MDG,
Central Governance
UI Modeling: Do you want to create a user interface for single-object processing that allows assignment of single objects
to hierarchies?
You can adapt the single-object processing user interface so that it includes a Hierarchy Assignment block (see link in table below.)
More Information For general information about creating a single-object processing user interface,
see Creating User Interfaces for Single Object Processing.
For hierarchy-specific information, see Creating a UI for Hierarchies.
Process Modeling: If the hierarchy type is version-dependent, where are the versions defined?
You can define hierarchy versions in Customizing.
Process Modeling: Which change request types are defined for the creation and processing of hierarchies?
You can create change requests that are relevant both to single-object processing and collective processing of hierarchies. The initial settings are described in
the table below.
Before You Start Identify which entity type is used as the hierarchy type, by referring to the following
section of this document:
Data Modeling: Which entity type is a used as a hierarchy type? Is the hierarchy
type synchronized? Is the hierarchy type version-dependent?
Example
This example is for change request type CCT2P2 that can be used to create a
cost center and that allows hierarchy assignments in the creation of the cost
center.
Type of Change Request
Type of Change Request: CCT2P2
Description: Create Cost Center with Hry. Assignments
Main Entity Type: CCTR. This is the entity type for a cost center, on
which the change request type is based.
Edition Type: OG_ALL.
Single-Object: Checkbox selected as this is a change request
type to create individual cost centers.
Type of Change Request Entity Type
CCTR
CCTRG. This entity type represents the cost center group,
which is the hierarchy type.
CCTRH
Process Modeling: When a user creates a change request for a hierarchy assignment, which nodes does the system
interlock with the pending change request?
Setting: Interlocking
Values: Loose interlocking interlocks nodes assigned to the parent node of the node being
changed.
Strict interlocking propagates upwards and downwards from the parent node of
the node being changed.
Upwards interlocking interlocks the parent node and its assigned nodes, the
parent node of the parent node and its assigned nodes, and so on, up to the
root node.
Downwards interlocking interlocks child nodes of the parent node, their child
nodes, and so on, down to the end nodes. This comprises a subhierarchy of
interlocked nodes with the parent node at its root.
Data Quality and Search: Which validations apply to the relationships between hierarchy nodes?
You can add validations for relationships between hierarchy nodes using the BRFplus or using BAdI: Define Validations/Derivations in Customizing. For
example, you can define specific cardinalities such as single higher-level nodes.
Examples of validations that you can create include the following:
Do not allow the same business objects in the same hierarchy twice.
Generate an error message if a business object is not assigned to a hierarchy.
Do not repeat a business object in the same subhierarchy.
Tool BRFplus
Complimentary Coding Data Quality and Search Business Add-Ins BAdI: Define
Validations/Derivations
User Parameter: When a hierarchy node is expanded in the Collective Processing user interface, how many subnodes
should display?
For faster screen load and a reduction in user scrolling, you can control the number of subnodes that display when a node is expanded. The user can click
<Number> More to expand the collapsed nodes.
Example
The following example shows how to display the configuration settings of a profit center group hierarchy and its profit center group.
1. Process the Customizing activity Edit Data Model under General Settings Data Modeling . Mark the data model SF on the Inactive Data
Models view. Then double-click the Entity Types view.
In the column Entity Type , double-click the entity type CARR (Airline). In the group frame Entity Types you can see the following configuration
settings:
Is Hierarchy Type : Yes - Not Version-dependent / Not Synchronized
Note
Assigning the Names for Hierarchies of Airlines hierarchy CARR_HIER to the storage and use type 1 ( Changeable via Change Request ) defines
that this hierarchy can be processed using change requests. This assignment enables the entity type CARR_HIER to become a root node for the
hierarchy.
3. Double-click the Entity Types view and mark the row of the entity type CARR. Then double-click the Entity Types for Hierarchies view. In the group
frame Entity Types for Hierarchies you can see the following configuration settings:
The Entity Type of Node CARR_HIER (Names for Hierarchies of Airlines) has the Use : Hierarchy Name .
The Entity Type of Node CARR (Airline) has the Use : No Special Use .
Master Data Governance for Material enables you to monitor and control the creation, editing, and deletion of material master data.
This documentation provides the information you require to set up Master Data Governance for Material. It supplements the information provided in
Customizing as well as the information about activities that you need to execute in addition to configuring Customizing settings.
For security reasons the services delivered for Web Dynpro applications initially are available in an inactive state only. You have to activate the services you
want to use.
Activities
To activate the services, proceed as described below:
1. On the Maintain Services screen (transaction SICF), make sure that the Hierarchy Type SERVICE is selected, enter the Service Name , and choose
Execute .
2. Choose Service/Host Activate , to activate the service.
Note
You have to perform the procedure for each single service you want to activate.
Once you have activated a service it cannot be reset to inactive.
The table below provides a list of the services used in the respective components of SAP MDG, central governance .
APB_LAUNCHPAD Launchpad x x x x
MDG_BS_DATALOAD_M Reprocessing x x x x
ONITOR
MDG_EXTR_FPM_CMP Extractor x
USMD_CREQUEST_PRO USMD_CREQUEST_PRO x x x x
CESS CESS
USMD_EDITION Edition x
USMD_WF_NAVIGATION Workflow-Based x x x x
Navigation
WDA_BS_ANLY_LIST_OV List x x x x
P
WDR_CHIP_PAGE wdr_chip_page x x x x