Finance MDG Config PDF
Finance MDG Config PDF
Finance MDG Config PDF
2019-06-27
4 Configuring the SOA Manager for MDG-F (NW 7.53 or higher). . . . . . . . . . . . . . . . . . . . . . . . . .33
6 Configuring the SOA Manager for MDG-F in MDG Client Systems (NW 7.32 or lower). . . . . . . . 63
8 Appendix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.1 Interlocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.2 Deleting Data Model 0F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
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.
Use
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
1. On the Maintain Services screen (transaction SICF), make sure that the Hierarchy Type SERVICE is
selected, enter theService 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 SAP MDG, Central
Governance.
APB_LAUNCHPAD Launchpad x x x x
MDG_BS_DATA Reprocessing x x x x
LOAD_MONITOR
MDG_EXTR_FPM_ Extractor x
CMP
USMD_CRE USMD_CRE x x x x
QUEST_PROCESS QUEST_PROCESS
USMD_EDITION Edition x
USMD_WF_NAVI Workflow-Based x x x x
GATION Navigation
WDA_BS_ANLY_LI List x x x x
ST_OVP
WDA_MDG_DT_C Configuration x x x x
ONF_WORK Workbench
BENCH
WDR_CHIP_PAGE wdr_chip_page x x x x
WD_GLOBAL_SET Cross-Application x x x x
TING Settings for Web
Dynpro ABAP
Use
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) 9.1.
Note
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, run the report RGZZGLUX before opening the UIs delivered with MDG-F. 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 [page 74].
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).
You have made your general settings for SAP Business Workflow in Customizing for SAP NetWeaver under
Application Server Business Management SAP Business Workflow . For more information, see SAP
Business Workflow.
You have activated the services for Web Dynpro Applications. For a detailed list of the relevant services, see
Services to be Activated for Web Dynpro Applications [page 5].
Process
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_08 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_08 in Customizing under Master Data Governance for
Financials Import Predefined Edition Types .
You can also activate the BC Set CA-MDG-APP-FIN_EDITION_08 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_08, and choose the Activate BC Set button.
Leave the default settings as they are.
The Business Configuration Set CA-MDG-APP-FIN_CR_TYPES_08 contains predefined change request types
you can use for your master data governance process. You can also define your own change request types.
You can also activate the BC Set CA-MDG-APP-FIN_CR_TYPES_08 using the following procedure:
1. On the SAP Easy Access screen, choose Tools Customizing Business Configuration Sets Activation
of BC Sets (transaction SCPR20).
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_05.
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 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:
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_07.
Work through the Customizing activity under Data Quality and Search Validations and Enrichments
Define Validation and Derivation Rules .
Several workflow templates are available for MDG-F. For more information, see Workflow Templates for
Financials [page 113]. 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.
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
[page 74] 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.
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 .
Some additional settings are required for enterprise services. To configure the service interfaces and service
groups, see Customizing for Cross-Application Components under Processes and Tools for Enterprise
Applications Enterprise Services General Settings for Enterprise Services Manage and Test Enterprise
Services (transaction SOAMANAGER). For information on configuring the SOA Manager for NetWeaver 7.40 or
higher, see Configuring the SOA Manager for Master Data Governance for Financials (NW 7.40) [page 48].
Alternatively, you can use Application Link Enabling (ALE) with IDoc messages. For detailed information about
how to configure the ALE for MDG-F, see Configuring ALE for Master Data Governance for Financials [page
69].
You use the report USMD_EDITION_REPLICATE to replicate financial objects that do not support time-
dependency. The report is run once a day for all new or changed time-independent financial objects. The valid
financial objects are determined by the start date of the selected edition. You must define a variant for the
report in the MDG hub as follows:
The next step is to configure and release the background job, as follows:
You specify whether Internal Order master data can be changed locally in the financial controlling system after
it has been replicated from the MDG system.
You do this in Customizing under Master Data Governance, Central Governance Master Data Governance
for Financials Replication Inbound Processing for Financial Master Data Adapt the Master System Field for
Internal Order API .
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:
Note
You must install the Business Package for Common Parts in the SAP NetWeaver Portal before you can
upload the MDG roles.
Use
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 generic MDM extractor (MDMGX) extracts the master data in the MDG target system. The MDG data
import framework (DIF) uploads the master data in the MDG hub system. MDG-F provides content for both the
MDMGX and the DIF.
Process
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. It is mandatory that the repository
name starts with MDG_. Define the attributes of the new repository based on 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.
7. Choose Upload Ports and Check-Tables. To upload the configuration text file, do the following:
1. Define the object type as Account.
2. Select 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. Define the function modules for internal orders as follows:
1. Choose Define Function Module Parameters for Exceptional Cases and search without attributes.
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 [page 123].
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:
4. Open the Customizing activity Link Logical Actions with Business Activity: Custom Definition.
1. Take a look at the SAP default configuration for cost centers in the Customizing activity Link
Logical Actions with Business Activity: Standard Definition, which should contain records similar to
the ones shown in the table below:
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
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
Object Name Communicator Configu HANA Search UIBB HANA Search View
ration ID
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.
Use
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.
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 single object maintenance user interface from your current change request. From the side
panel, select one of the following overviews:
Changes Overview
Select this BCV content in the dropdown list under Overview to display a list of changes raised by the current
MDG change request.
In addition to displaying changes per change request, you can also display just the hierarchy changes for the
change request. To do so, select the display option Hierarchy Changes for Request in the section under Query
Views Query View List .
Note
You can export the hierarchy changes for a change request to Microsoft Excel by choosing the Export
button in the BCV Main Analytics View.
More Information
For more information about BCV, see Business Context Viewer (BCV)
Use
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.
Note
If your MDG Client system has an SAP NetWeaver version 7.40, please refer to the configuration steps
described in Configuring the SOA Manager for MDG-F (NW 7.40 or higher) [page 48].
If your MDG Client system has an SAP NetWeaver version below 7.40, please refer to the configuration
steps described in Configuring the SOA Manager for MDG-F in MDG Client Systems (NW 7.32 or lower)
[page 63]
Prerequisites
The following prerequisites must be performed in both the MDG hub and client systems.
Set up the technical configuration of the web service runtime using SAP Note 1043195 .
Authorizations
● SU01
● SUIM
● PFCG
Business Functions
Activate the business function using transaction SFW5. By activating the business function, you can use the
following cross-application tool improvements that facilitate the use of services:
For replication to an ERP system, activate the business function FIN_MDM_SOA_ORG in the MDG client system.
For replication to an ERP system with SEM-BCS installed, activate the business function FIN_MDM_SOA_CU in
the MDG client system.
1. Assign a transport request for an inbound service by running the Customizing activity in the MDG client
system under Cross-Application Components Processes and Tools for Enterprise Applications Master
Data Governance, Central Governance Master Data Governance for Financials Replication Enterprise
Services Inbound Services for Financials Master Data Manage Transport Requests . If the Customizing
activity is not available in the client, open transaction SM34 and enter the view cluster VC_TRN_REG_RQST.
Choose Maintain.
2. Enter the application FINMDM_DATA_REPLICATION and choose Continue.
3. Enter the groups FINMDM_DATA_COMPANY_RPLCTN and FINMDM_DATA_REPLICATION_GRP and mark
both as automatic.
4. Afterwards, add a Customizing transport to each group. If necessary, create a transport with transaction
SE09 beforehand.
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.
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 .
Either the MDG hub system and the MDG client 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 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 Master
Data Governance, Central Governance General Settings Data Replication Define Custom Settings for Data
Replication Define Technical Settings BAdI: Determination of Local System Name .
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 .
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 client systems.
Note
The profile names and versions should be identical in the SOA manager settings for both MDG hub and
client systems.
3. Select 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.
To configure the client setting in the MDG hub and the MDG client system carry out the steps described below
in both systems.
1. On the Technical Administration tab, choose SAP Client Settings, and open the Service Identifier section.
2. Copy the entry from the Business Application ID field (the field is automatically filled) and paste and save it
for later use.
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.
Note
To retrieve the own Business System ID, run transaction SLDCHECK and check the section Calling
function LCR_GET_OWN_BUSINESS_SYSTEM. As a prerequisite, SLD needs to be connected to your
system as described in Prerequisites section above.
Note
The SystemNumber can be found under System Status SAP System Data Installation
Number .
Similarly, the SystemHome can be found under System Status Database Data Host .
3. Enter the Access URL for WSIL and Logon Information under WSIL Services.
Format of WSIL URL: https://<hostname>:<port>/sap/bc/srt/wsil?sap-client=<client>
Verify that the Use WSIL User checkbox is selected.
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.
As a result, the Identifiable Business Context Reference (IBC reference) for the counterpart system is
automatically generated. To verify this, perform the following:
1. On the Service Administration tab, choose the link Identifiable Business Context Reference.
2. Choose Search. The IBC reference for the counterpart system should be displayed in the list in the form
XYZ_001, where XYZ_001 is the system ID and client of the counterpart system.
To create a user account in the MDG hub and the MDG client system carry out the steps described below in
both systems.
Note
To assign logon data to the IBC Reference of the counterpart system in the MDG hub and the MDG client
system, carry out the steps described below in both systems.
Service definitions and service groups that you configure to run SOA communications with SEM-BCS are
shown in separate tables.
To create an integration scenario configuration in the MDG client system, carry out the following steps:
3. To assign a profile to the service definitions in the MDG client system, carry out the previous steps for the
MDG hub.
4. Select Service Groups and assign the provider IBC reference as follows:
1. Choose Add to search for the service group.
2. Enter the service group FBS_CHTACCTSRPLCTNCO, select it in the result list, and choose OK.
3. Repeat the procedure for all required service groups.
UC0_FINCNSELMNTRPLCTNBCO UC0_FINCNSELMNTRPLCTNBCO
UC0_FINCNSSTRUCTRPLCTNCO UC0_FINCNSSTRUCTRPLCTNCO
5. To assign a provider IBC reference in the MDG client system, carry out the previous steps for the MDG hub.
6. Activate the integration scenario in the client 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 Rebuild List to refresh the list of all pending tasks.
4. Choose Process List to execute all pending tasks.
To activate the logical ports in the MDG client 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
client system that failed the activation again.
In the MDG hub client, create a business system for each client system:
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 New Entries and select the communication channel 1 Replication
via Services. Repeat this for all defined business object types.
7. Save your entries.
After the point-to-point communication has been defined in SOAMANAGER, create the replication models as
follows:
4. For each defined replication model, select the row with the replication model and select folder Assign
Outbound Implementation. Choose 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, select the row with the implementation
and select the folder Assign Target Systems for Repl. Model /Outb.Impl. Choose New Entries. Assign all
business systems with the ERP clients of the target systems.
6. Save your entries.
To improve performance, an outbound parameter can be set to bundle outgoing messages. You can add the
outbound parameter PACK_SIZE_BULK, e.g. with the value 500, for SOA replication for the objects account,
company, consolidation group, and unit.
Check the log and make sure that all selected replication models have been activated successfully.
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:
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_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:
CO_FBS_COMPANYRPLCTNBCO CompanyReplicationBulkConfirmation_Out
CO_FBS_CHTACCTSRPLCTNCO ChartOfAccountsReplicationConfirmation_Out
CO_FBS_FINRPTGSTRUCCO FinancialReportingStructureReplicationConfirmation_Out
CO_FBS_GLACCTMSTRRPLCTNRCO GeneralLedgerAccountMasterReplicationBulkConfirma-
tion_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 FinancialConsolidationElementReplicationBulkConfirma-
tion_Out
CO_UC0_FINCNSSTRUCTRPLCTNCO FinancialConsolidationStructureReplicationConfirma-
tion_Out
Result
You have configured the financial data for SOA manager using enterprise services on NetWeaver 7.40.
More Information
Use
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. For more information about how to use the SOA Manager
to configure a Web service-based communication, see Configuring a Consumer Proxy.
Note
If your MDG Client system has an SAP NetWeaver version below 7.40, please refer to the configuration
steps described in Configuring the SOA Manager for MDG-F in MDG Client Systems (NW 7.32 or lower)
[page 63]
Prerequisites
The following prerequisites must be performed in both the MDG hub and target systems.
Set up the technical configuration of the web service runtime using SAP Note 1043195 .
Authorizations
● SU01
● SUIM
● PFCG
Business Functions
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:
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.
1. Assign a transport request for an inbound service by running the Customizing activity in the MDG target
system under Cross-Application Components Processes and Tools for Enterprise Applications Master
Data Governance, Central Governance Master Data Governance for Financials Replication Enterprise
Services Inbound Services for Financials Master Data Manage Transport Requests . If the Customizing
activity is not available in the client, open transaction SM34 and enter the view cluster VC_TRN_REG_RQST.
Choose Maintain.
2. Enter the application FINMDM_DATA_REPLICATION and choose Continue.
3. Enter the groups FINMDM_DATA_COMPANY_RPLCTN and FINMDM_DATA_REPLICATION_GRP and mark
both as automatic.
4. Afterwards, add a Customizing transport to each group. If necessary, create a transport with transaction
SE09 beforehand.
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.
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 .
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 .
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 .
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.
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.
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.
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, 416.SystemName.QV6.SystemNumber.0020270862.SystemHome.uxdbqv6.
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.
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.
Note
Service definitions and service groups that you configure to run SOA communications with SEM-BCS are
shown in separate tables.
To create an integration scenario configuration in the MDG target system, carry out the following steps:
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.
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.
In the MDG hub client, create a business system for each target system:
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 pushbutton New Entries and select the communication channel 1
Replication via Services. Repeat this for all defined business object types.
7. Save your entries.
After the point-to-point communication has been defined in SOAMANAGER, create the replication models as
follows:
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.
6. Save your entries.
To improve performance, an outbound parameter can be set to bundle outgoing messages. You can add the
outbound parameter PACK_SIZE_BULK, e.g. with the value 500, for SOA replication for the objects account,
company, consolidation group, and unit.
Check the log and make sure that all selected replication models have been activated successfully.
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:
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:
CO_FBS_COMPANYRPLCTNBCO CompanyReplicationBulkConfirmation_Out
CO_FBS_CHTACCTSRPLCTNCO ChartOfAccountsReplicationConfirmation_Out
CO_FBS_FINRPTGSTRUCCO FinancialReportingStructureReplicationConfirmation_Out
CO_FBS_GLACCTMSTRRPLCTNRCO GeneralLedgerAccountMasterReplicationBulkConfirma-
tion_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 FinancialConsolidationElementReplicationBulkConfirma-
tion_Out
CO_UC0_FINCNSSTRUCTRPLCTNCO FinancialConsolidationStructureReplicationConfirma-
tion_Out
CO_UC0_FINREPSTRUCTRPLCTNCO FinancialReportingStructureReplicationConfirmation_Out
Result
You have configured the financial data for SOA manager using enterprise services on NetWeaver 7.40.
Use
This document describes the configuration steps required to enable the exchange of financial data using point-
to-point enterprise services communication without a process integration (PI) system.
Note
This document is relevant only for MDG client systems with SAP NetWeaver Basis release 7.32 or lower. For
systems with NetWeaver Basis release 7.40 or higher, follow the steps for the common MDG (hub) setup.
This document is not valid for the configuration of the MDG hub system.
Prerequisites
The following prerequisites must be performed in both the MDG hub and target systems.
Authorizations
● SU01
● SUIM
● PFCG
Business Functions
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:
For replication to an ERP system, activate the business function FIN_MDM_SOA_ORG in the MDG client system.
For replication to an ERP system with SEM-BCS installed, activate the business function FIN_MDM_SOA_CU in
the MDG client system.
1. Assign a transport request for an inbound service by running the Customizing activity in the MDG client
system under Cross-Application Components Processes and Tools for Enterprise Applications Master
Data Governance Central Governance Master Data Governance for Financials Replication
Enterprise Services Inbound Services for Financials Master Data Manage Transport Requests . If the
Customizing activity is not available in the client, open transaction SM34 and enter the view cluster
VC_TRN_REG_RQST. Choose Maintain.
2. Enter the application FINMDM_DATA_REPLICATION, and choose Continue.
3. Enter the groups FINMDM_DATA_COMPANY_RPLCTN and FINMDM_DATA_REPLICATION_GRP, and mark
both as automatic.
4. Afterwards, add a Customizing transport to each group. If necessary, create a transport with transaction
SE09 beforehand.
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.
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 .
Check whether the client system is 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 .
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 .
The following steps are required to configure the SOA Manager for MDG-F (transaction SOAMANAGER). Carry
out the following steps in the MDG client system.
Note
The profile names should be identical in the SOA manager settings for both MDG hub and client
systems. Reuse the corresponding name of the MDG hub.
1. On theTechnical Administration tab, choose SAP Client Settings, and choose Edit.
2. Enter a business system and a business system ID in the following format: 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.
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 format:
<Client>.SystemName.<ABC>.SystemNumber.<InstallationNumber>.SystemHome.<Host>, for
example, 416.SystemName.QV6.SystemNumber.0020270862.SystemHome.uxdbqv6.
Note
You can find the system number under System Status SAP System Data Installation Number
in the main menu.
You can find the system home under System Status Database Data Host in the main menu.
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 using the message
server host.
4. Enter the user for WSDL and a password for the WSDL documents.
5. Enter the service user you created in the backend system.
6. Enter the business application ID.
To determine the business application ID, run transaction SOAMANAGER in the counterpart system
(MDG hub), and navigate to Technical Administration SAP Client Settings .
Note
Service definitions and service groups that you configure to run SOA communications with SEM-BCS are
shown in separate tables.
UC0_FINCNSELMNTRPLCTNBCO UC0_FINCNSELMNTRPLCTNBCO
UC0_FINCNSSTRUCTRPLCTNCO UC0_FINCNSSTRUCTRPLCTNCO
Result
You have configured the financial data for SOA manager using enterprise services.
More Information
Use
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 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 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 .
If the company code is required for your data, you must define the global organizational units for company
code. Run this activity in Customizing for SAP NetWeaver under Application Server IDoc Interface/
Application Link Enabling (ALE) Modelling and Implementing Business Processes Global Organizational
Units Cross-System Company Codes . Create cross-system company codes and map all company codes in
use to the defined global company codes.
If the business area is required for your data, you must define the global organizational units for business areas.
Run this activity in Customizing for SAP NetWeaver under Application Server IDoc Interface/Application
Link Enabling (ALE) Modelling and Implementing Business Processes Global Organizational Units Cross-
System Business Areas . Create cross-system business areas and map all business areas in use to the defined
global business areas.
Procedure
The following steps are required to configure ALE for MDG-F (transaction SALE) in the MDG hub and MDG
target system.
To create a new distribution model in the MDG hub, carry out the following steps in both systems:
1. Run transaction SALE (Display ALE Customizing), and choose Modelling and Implementing Business
Processes Maintain Distribution Model and Distribute Views . Alternatively, run transaction BD64
(Display Distribution Model).
2. In editing mode, create a new model. Choose Create Model View. Enter a short text and a technical name.
3. Choose Add Message Type for the newly created model. Enter the logical sender system and receiver
system, and add a message type from the following table. Repeat this step for all required IDoc message
types.
For Internal Order, choose Add BAPI, and make the following entries:
Obj. name/interface: InternalOrder
Method: SaveReplica.
Save your entries.
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 Execute button.
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.
The configured distribution model needs to be enhanced to send a confirmation message back from the target
client to the client of the MDG hub:
1. Enter the client of the MDG hub and call transaction SALE.
2. Goto Modelling and Implementing Business Processes Maintain Distribution Model and Distribute
Views . Select 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 target system.
5. Choose the Create inbound parameter button.
In the client of the target system, the distribution model also needs to be enhanced:
1. Enter the client of the target system and call transaction SALE.
2. Goto Communication Maintain Distribution Model and Distribute Views . Select 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 Create outbound parameter button.
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.
In the client of the MDG hub, a business system for the target client needs to be created as follows:
6. Select each business object type, and choose the folder Define Bus. Systems, BOs, Communication
Channel. Choose the New Entries button, and select the communication channel 2 Replication via IDoc.
Repeat this for all defined business object types.
7. Save your entries.
5. For each outbound implementation you have described in step 4, select the line of the implementation, and
select the folder Assign Target Systems for Repl. Model /Outb.Impl. Choose the New Entries button. Assign
the business system with the ERP client of the target system.
6. Save your entries
More Information
8.1 Interlocking
Definition
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.
Use
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 [page 119].
Prerequisites
Make sure that data model 0F is not activated in your productive system.
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 .
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 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.
For information on how to extend the MDG-F data model, see Extend Data Model by New Fields (https://
scn.sap.com/docs/DOC-55226 ).
Use
You can transfer data models for Master Data Governance from your test system to your target system by
means of transport requests.
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.
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.
Use
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
In the Configuration Workbench screen, you can select a data model for editing or you can create a new data
model. By default, the system displays all data models that are available for processing.
For each data model you can see whether an inactive version of the data model exists alongside the active
version and whether that version differs from the active version. .
After you select a data model for editing or create a new data model in the Configuration Workbench screen,
the Data Model screen opens.
In the Data Model screen, you can complete the following tasks:
In the Data Model Details panel, you can edit the data model description and view details such as version, and
activation status
You can select an entity type or create a new one in the Entity Types panel. You can edit settings for a selected
or newly created entity type using the tab pages.
● General Details
You must define a Storage and Use Type for the entity type. In addition, you can provide other data, such as
a description and a data element.
● Hierarchies
You can indicate whether hierarchies are allowed and what properties they are allowed to have. You can
only allow a hierarchy to be set up for entity types with storage and use type 1.
● Key Assignment
You can indicate how keys are assigned to the entity type.
● Enablement Status
You can enable entity types that are relevant to your business and disable entity types that are irrelevant to
your business.
● Reuse
You can specify a reuse active area and references to elements of the data dictionary.
● Texts
You can specify the fields of the check tables that contain the texts for an entity type. This is only possible
for entity types of storage and use type 3.
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.
Relationships can be viewed from the perspective of each of the entity types that are involved. For example, the
HAS_ADRE relationship between BP_HEADER and ADDRESS can be viewed from the perspective of both entity
types.
● If you select the BP_HEADER entity type, you can view the relationship in the Outgoing Relationships tab
page.
● If you select the ADDRESS entity type, you can view the relationship in the Incoming Relationships tab
page.
You can assign the key fields of the from-entity type to the attributes and key fields of the to-entity type.
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.
You have to assign business object types only for entity types of storage and use type 1 that you want to
replicate, or for which you want to generate their own Enterprise Search template.
If you have assigned the same business object type to multiple entity types, then you have to specify the entity
type to be used for each business object type.
You can do this in Customizing for Master Data Governance under Data Modelling Specify the Entity Type to
Be Used for Each Business Object Type
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 the hierarchy of
the entity type (No Special Use or Ranges Permitted on End Nodes)
9.2 UI Modeling
The purpose of UI modeling is to define and customize user interfaces with which users process master data.
Use
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
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
Path in Customizing for Master Data Governance, Central Governance (transaction MDGIMG): General
Settings UI Modeling Manage UI Configurations
1. Select the UI configuration you want to copy and choose the Copy button.
2. To expand configurable components, choose the Configurable Components button.
3. In the Copy column, select the technical elements you want to copy, and enter appropriate names for the
target configurations.
4. Choose the Start Deep-Copy button.
5. Return to the Manage UI Configurations screen and refresh the table content. The system displays an
additional row in the table with the configurations you just created.
6. If the user interface is compatible with the MDG Communicator, the MDG Communicator Status is set to
Configuration missing. To make the MDG Communicator available, you must configure it by choosing the
Details link.
Subsequent steps depend on the type of user interface you are configuring and the type of configuration you
want.
The following documents provide detailed information on the concept behind the particular types of user
interfaces, and instructions on how to create new user interfaces either using the Web Dynpro application
USMD_UI_CONFIGURATION or using transaction SE80:
Single-Object Processing
● Concept: Creating User Interfaces for Single Object Processing [page 82]
● Instructions: Creating a Basic Configuration for the Single-Object Processing UI
Search
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
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 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.
The UI configuration is based on the active version of an MDG data model. At design-time, when you create the
configuration of a UI or customize a UI, the relevant data model is determined by the standard data model from
your user profile. You set the standard data model in the following way:
At run-time, when the UI is used to process data, the MDG data model is determined by the business object
type code given in the parameter USMD_OTC of the configuration of the Web Dynpro application
USMD_OVP_GEN or MDGF_OVP_GEN.
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:
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.
Every configuration of the Web Dynpro applications USMD_OVP_GEN and MDGF_OVP_GEN contains the
parameter USMD_OTC that must be set to the business object type code (OTC) of the object that the UI should
be used for. The OTC is defined in Customizing for Master Data Governance under General Settings Data
Modeling Define Business Object Type Codes . You need to assign the OTC to the data model and the entity
type in the view Business Object Type in the Customizing activity Edit Data Model under General Settings
Data Modeling . You also need to set the indicator Root in the same view. Additionally, you need to assign the
data model and the entity type to the OTC in the Customizing activity Define Entity Type to Be Used by Business
Object Type under General Settings Data Modeling .
The UI components of MDG require several DDIC structures that are specific to the data model used for the UI
configuration. Initially and also after every change to the data model, these structures need to be generated. If
you follow the recommendation and enter the required information for your data model in Customizing activity
Edit Data Model under General Settings Data Modeling , this generation is performed automatically.
The application configuration ID must be the same as the configuration ID for the MDG communicator settings.
Otherwise, the application cannot determine which settings to use and the integration with the MDG
framework will not work.
Highlight Changes
You can set the colors and the activation of the highlight changes function in the configuration of the used MDG
Web Dynpro application, for example USMD_OVP_GEN or MDGF_OVP_GEN, using the parameters
MDG_HC_DISABLE, MDG_HC_COLOR_SAVED, and MDG_HC_COLOR_UNSAVED. For more information, see
Highlight Changes.
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 [page 87]
● Business Address Services (BAS)-Based 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 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.
Use
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
1. In Customizing for Master Data Governance, enter your specific settings under SAP Customizing
Implementation Guide Cross-Application Components Master Data Governance General Settings
Data Quality and Search Define Search Applications :
○ Define your search application.
○ Define your access class.
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).
1. Initial load of index: Use the class CL_USMD_MODEL_EXT to read or extract data from the Master Data
Governance data models.
The configuration of governance scope, change requests, and workflow offers you flexible ways to model the
desired governance process.
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
Context
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.
Procedure
1. In Customizing for Master Data Governance under General Settings Process Modeling , choose Define
Governance Scope.
2. In the Data Models view, select the data model whose governance scope you want to define.
3. Make necessary changes to the Governed settings of entity types, attributes, and referencing relationships.
○ Changes to the Governed setting for entity types with a storage and use type of 1.
These entity types are shown in the Customizing activity, to enable navigation to attributes.
○ Changes the Governed setting of attributes that are key fields.
These attributes are not shown in the Customizing activity.
○ Changes to attributes for which the Required Field setting is set to Yes in the data model.
These attributes are not shown in the Customizing activity.
Results
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 [page 80].
Context
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
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:
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.
Use
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.
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.
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)
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 [page 104] and Add User-Agent Steps
[page 107] for examples to configure the rule-based workflow.
Use
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
Rule-based workflow
Use
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 Event 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:
More Information
For information on how to create and enhance your rule-based workflow, see Creating a Basic Change Request
Process [page 104] and Add User-Agent Steps [page 107].
Application specific information on rule-based workflow is available in Rule-Based Workflows for Material.
Use
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 [page 91].
● You have completed the Customizing settings as described in Workflow Set-Up [page 95].
● You have created a diagram of the change request process that you want to configure as described in
Designing the Change Request Process [page 91].
Process
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.
For information about an example of a process diagram that is enhanced for the rule-based workflow, see
Add User-Agent Steps [page 107].
● 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
The arrow of this diagram leads to the following values in the decision table: CR Previous Step = 90. New Chng. Req.
Step. = 91. Previous Action = 03. Condition Alias = ACT. New CR Status = 02.
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 [page 110].
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 [page 91] 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.
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 [page 91] 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 [page 110].
The information from this diagram leads to the following values in the decision table: Condition Alias = ACT. Process
Pattern = 06. Service Name = <not required>. Agent Group = 001 (arbitrary value).
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.
For information about examples of process diagrams related to the rule-based workflow, see Creating a Basic
Change Request Process [page 104] and Add User-Agent Steps [page 107].
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.
● 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.
Use
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 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.
You need to perform the following steps in order to configure the rule-based workflow for the basic change
request process:
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
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.
Use
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.
Prerequisites
You have configured the rule-based workflow for the basic change request process, as described in Creating a
Basic Change Request Process [page 104]. In the following example process, the change request type CR_TYPE
and the user FINAL_CHECK_USER are used.
You need to process the following steps in order to extend the basic workflow with a user step:
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
Use
The rule-based workflow allows the parallel processing of a change request for processors belonging to more
than one agent group. For example, you can define an approval step in which both one processor of the
controlling department and one processor of the purchasing department need to approve the change request.
Both groups of users will receive a work item for the processing of the change request at the same time and
can complete their work independent of each other.
Parent Step
The step from which parallel processing starts is called parent step. In contrast to regular change request
steps, you assign multiple agent groups to a parent step. For each assigned agent group, a subprocess is
started that is executed in parallel. The first step of each subprocess has the same step number as the parent
step. Therefore, the step number of the parent step and the agent group number of the subprocess are
additionally used to uniquely identify each step in subprocesses. The process that is started initially after the
change request was submitted is called root process.
Each subprocess is an instance of the rule-based workflow. Subprocesses provide the information of their
parent step and the agent group for which they were started. This information is used during the evaluation of
the single value decision table for determining the next change request step. Using these parameters in the
single value decision table, you separate the configuration of the process flow in the initial process from the
process flow in the subprocesses.
Ending of SubProcesses
Subprocesses have to be ended by using a change request step with the process pattern 99 Complete
(Sub-)Process.
When all subprocesses have ended, processing continues in the parent step by evaluating the action results of
the subprocesses. This is done by a result handler. For example, if any user of the two departments chooses to
reject the change request in a subprocess that the overall result of the parent step rejects the change request.
Result handlers are implementations of BAdI: Handling of Parallel Results in Rule-Based Workflow in MDG
Customizing under General Settings Process Modeling Workflow Rule-Based Workflow Business
Add-Ins and referenced by their service name.
For more information, see the documentation of BAdI: Handling of Parallel Results in Rule-Based Workflow.
Using the actions and steps returned by the subprocesses, the result handler returns a merge step and merge
action that are used in the next loop of the rule-based workflow to evaluate the single value decision table.
You need to specify the result handler in the row of the single value decision table that leads to the parent step
of the subprocesses. This is done by providing the value B in column Merge Type and the service name of the
result handler in column Merge Parameter.
Agent Groups
Agent groups are assigned to change request steps through the condition alias of the single value decision
table. User agent groups are defined in the user agent decision table for dialog steps. Non-user agent groups
are defined in the non-user agent decision table for background steps. Both types of groups are uniquely
identified by their group number and the condition alias.
A user agent group specifies the assigned processors of a change request step and the step type of the dialog
step. All users assigned to a user agent group will receive a workitem to process the change request step. You
can use multiple organizational objects to specify the members of the user agent group. In this case, you need
to create a row for each organizational object in the user agent decision table and use the same value in the
columns Condition Alias and User Agent Grp No.. This defines a user agent group with multiple rows.
You configure the parallel processing of a change request step by entering different values for User Agent Grp
No. and the same condition alias. For each value in User Agent Grp No., a separate subprocess is started.
It is not allowed to have rows with the same condition alias and the same user agent group, but different step
type, because a change request step can only have one change request step type. However, it is possible to
configure parallel steps that have different change request step types.
A non-user agent group specifies the process pattern that should be executed in the background in a change
request step. A non-user agent group is defined by entering the condition alias, the agent group, and the
process pattern in the non-user agent group decision table.
You configure parallel processing of a change request step by entering different values for the agent group and
the same condition alias. For each value in the agent group, a separate subprocess is started to execute the
respective process pattern.
It is not allowed to have more than one row with the same values for the condition alias and the agent group,
because only one process pattern can be executed in each change request step. However, you can define
parallel background steps, in which process patterns are executed in parallel.
It is not allowed to have a row in the non-user agent decision table that has the same values for condition alias
and agent group as a row on the user agent decision table, because a change request step can only be either a
dialog or a background step. However, you can define two parallel steps, one as a dialog step and the other as a
background step.
The phases in which the rule-based workflow handles parallel processing are as follows:
1. After having evaluated the decision tables, it is checked whether there is more than one agent group
assigned to the change request step.
2. For each agent group, a new instance of the rule-based workflow is started. The already determined agent
group and the step number of the parent step are passed to the instance. In the parent step, the processing
is suspended until every subprocess has ended.
3. In the initial loop of the rule-based workflow, the agent group is already known and processing can directly
continue by creating the workitem for the dialog step or executing the process pattern in case of a
background step. After that, a new loop is started.
4. In the second loop, the action result of the previous step, the information of the parent step, and the agent
group of this sub-process are used to find a matching row in the single value decision table and to find the
assigned condition alias in the user agent decision tables and non-user Agent decision tables.
5. If a step with process pattern 99 End (Sub-)Process is found, the workflow ends and control returns to the
parent step. If there are further steps defined for the subprocess they are processed in further loops of the
subworkflow.
6. After all subprocesses have ended, the result handler is called. It uses the action results' return and the
change request step numbers' return by the subprocesses to determine a merge step and merge action.
More Information
We deliver the standard workflow template WS60800086 for the rule-based workflow. This workflow template
consists of the following steps:
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.
The following workflow templates are available for Master Data Governance for Financials:
Related Information
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.
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
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.
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).
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.
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.
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.
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).
1. Start workflow
The workflow is started when a requester creates a change request in the universal worklist in the portal.
2. Determine number of processors for parallel steps
In the next workflow step, the system determines the number of users or user groups to which the change
request needs to be sent.
The Customizing for Financial Master Data Management lets you configure the system to do so dependent
on the entity type of the objects contained in the object list of the change request, under Workflow/
Process Modeling Assign Processor to Workflow Step (Advanced Workflow) .
3. Evaluate change request
The respective processors automatically receive a work item in their universal worklist and evaluate the
change request independently of one another. The system then determines the number of approvals and
objections:
○ If one or more processors objects to the change request, the requester receives an information SAP
express mail as soon as all the processors have evaluated the change request (→ step 4).
○ If all the processors approve the change request, the processors responsible for the consideration and
approval receive a work item in their worklists (→ step 5).
4. (Optional) SAP express mail after objection
The requester receives an SAP express mail in his or her Business Workplace indicating that one or more
processors objected to the change request. The employees responsible for the consideration and approval
also receive a work item in their worklists (→ step 5).
5. Consider and approve
The respective processors have received a work item in their worklists and consider the change request
independently of one another. The system then determines the number of approvals and rejections:
○ If one or more processors reject the change request the requester automatically receives an SAP
express mail for each rejection (→ step 6).
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.
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.
Definition
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.
Concept
You can define the scope of interlocking in Customizing for Master Data Governance under Process Modeling
Hierarchies Define Scope for Changes
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:
● Choosing the scope for hierarchy-specific changes involves striking a balance between centralized control
and process efficiency.
● The Interlocking setting also defines the locking of nodes to avoid competing changes by multiple users
who work on the hierarchy at the same time.
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.
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:
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
Use
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:
You must activate the business context viewer to be able to access side panels for the following Web Dynpro
applications that are used in the analysis of change requests:
● For instructions on how to activate the business context viewer, see Business Context Viewer in Single
Processing.
● For more information about the business context viewer, see Business Context Viewer (BCV).
You can only access the side panels after you change the authorization object Business Context Viewer
Execute Side Panel (BCV_SPANEL). Instructions on how to do this are provided in the Changing Authorization
Objects section of this document.
Note
After you activate the business context viewer, you can configure a side panel for any Web Dynpro
application.
You need to assign roles to your user. For more information, see .Authorization Concept in Business Context
Viewer (BCV)
Investigate if the role or roles you already have allow you to access the following Web Dynpro applications:
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 re
jected.
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.
● Specify the change request types to be analyzed and the level of access required
● Specify the Web Dynpro applications requiring a side panel.
For every role associated with the relevant Web Dynpro applications, proceed as follows:
SAP Master Data Specify the types of change Change Request Type Specify the level of the ac
Governance Type of requests users are allowed cess allowed to each the
to analyze and the level of change request types speci
Change Request
access allowed. fied under Activities. As a
(USMD_CREQ)
minimum, choose Display.
Choose other options, if re
quired.
Caution
Be careful when using
wildcards; you do not
want to accidentally
provide access to incor
rect change request
types.
Business Context Viewer Specify the Web Dynpro ap Context Key Enter the following context
Front End Integration Xcel Authorization for working RSXCLSID Specify the technical name
sius Dashboard with SAP BusinessObjects of the dashboard:
(S_RS_XCLS) Dashboards. 0XC_MDG_MONITOR_CR.
Integrating Dashboards
SAP Business Objects dashboards only work if a BI Java server is enabled. For more information, see SAP Note
1450981
A change request is late if it exceeds its due date (an optional field of the change request) or if it violates a
Service Level Agreement (SLA). You can define the SLA in Customizing for priorities of change request types.
To define a service level agreement for each priority of a change request type, proceed as follows:
1. In Customizing for Master Data Governance, Central Governance, choose General Settings Process
Modeling Change Requests Create Change Request Type
2. In the Type of Change Request view, choose a Change Request Type
3. In the Service Level Agreement view, define a target number of days and hours for each Priority.
When specifying hours, you can only specify 4 hours, which is a half day.
Result
After completing this procedure, it is possible to access meaningful analytical information about change
requests.
Use
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)
All interactions between applications and MDGAF are now handled by either the Governance API or the
Convenience API. It is not possible to use the Convenience API and the Governance API at the same time for
the same model. This restriction is introduced to prevent misuse of the both APIs.
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 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 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.
● 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)
● 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 components such as a UI application or background process.
● Manages application-specific context data
Application-specific context data is stored within the workflow container. This enables you to provide
application-specific context data throughout the workflow.
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.
Use
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.
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?
Data Modeling: Which entity type is a used as a hierarchy type? Is the hierarchy type synchronized? Is it
version-dependent?
The Is Hierarchy Type setting specifies which entity types are used as hierarchy types (described in the table
below), and whether the relevant hierarchies have versions and are synchronized. Hierarchy types define which
business objects can be used as nodes in the hierarchy. Synchronized hierarchies are useful if you want to
reuse subhierarchies in multiple hierarchies. Version-dependent hierarchies are useful if alternative views of
data are required for planning purposes.
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).
You have indicated in Customizing that Hierarchy type Airline (CARR) is synchronized. Airlines are the main
building block within airline alliances. As a result of airlines being synchronized across airline alliances, the
addition of a new airline to subhierarchy Alliances Regional EU Oyster Airline Alliance is mirrored in
subhierarchy Alliances - Tiers Tier 1 Oyster Airline Alliance . If the hierarchy type Airline is not
synchronized, no mirroring occurs (see figure below).
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.
Hierarchies
Setting: Use
Data Modeling: How do you define the relationships between nodes in a hierarchy of this hierarchy type?
References
For example, you can set credit/debit balances indica
tors on the account assignment in a financial reporting
structure. You can specify a hierarchy attribute for a re
lationship 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).
Entity Type
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
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.)
Process Modeling: If the hierarchy type is version-dependent, where are the versions defined?
Hierarchy versions are valid for all data models in your MDG
system landscape.
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:
Example
This example is for change request type CCT2P2 that
can be used to create a cost center and that allows hier
archy assignments in the creation of the cost center.
Process Modeling: When a user creates a change request for a hierarchy assignment, which nodes does
the system interlock with the pending change request?
Changes
Setting: Interlocking
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.
● 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
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
○ Validity / Hierarchy: No Edition. The complete name of this field is Validity Concept for Hierarchy.
2. In the column Entity Type, double-click the entity type CARR_HIER (Names for Hierarchies of Airlines). In
the group frame Entity Types, you can see the following configuration setting:
Storage and Use Type: Changeable via Change Request
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.
Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:
● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your
agreements with SAP) to this:
● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.
● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.
● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such
links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this
information.
Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax
and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of
example code unless damages have been caused by SAP's gross negligence or willful misconduct.
Gender-Related Language
We try not to use gender-specific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.
SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.