Show TOC

Process documentationConfiguring Master Data Governance for Custom Objects

 

  1. Data Model

    The basis for the configuration of your custom master data governance process is a data model. This document describes how you can derive the required Master Data Governance (MDG) entity types and relationships from an entity relationship model. The SAP Flight Data Model is used as an example. This example shows the basic steps in Customizing, which are a prerequisite for all subsequent steps, such as the UI configuration.

    Note Note

    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 Data Model you need to assign the values for the authorization field USMD_MODEL Data Model (for example MM, BP, or 0G) and the values for the authorization activity ACTVT Activity (for example 01:Create or generate, or 02: Change).

    End of the note.

    Note Note

    Instead of creating your own data model, you can also add entity types to the delivered MDG data models 0G, BP, or MM.

    End of the note.
    1. MDG Data Model: Details

      This section describes the entity types and the relationship types used in the MDG Application Framework (MDGAF).

      1. Entity Types

        An MDG data model consists of the following entity types:

        • Entity Type with Storage and Use Type 1 (Type–1 Entity Type)

          Storage and use type 1 must be used for entity types that can be processed in MDGAF. They have the following characteristics:

          • They represent root objects that are subject to governance.

          • More than one type–1 entity type is possible in one data model.

          • Data storage is generated (edition dependent and staging area).

          • They are used for modeling attributes and relationships.

          • They are processed in the first step of the change requests

          • Non-assignment of data elements is optional.

          • Input help is linked to a generated check table.

        • Entity Type with Storage and Use Type 2 (Type–2 Entity Type)

          Storage and use type 2 must be used for entity types that cannot be processed with MDG and which are not available in the system. They have the following characteristics:

          • They model lists of values and descriptions that can be uploaded.

          • They model key enhancements for type-1 and type-4 entity types.

          • Data storage is generated (no edition, no staging area).

          • No further modeling is possible (only check tables and text tables generated).

          • No processing in change requests is possible.

          • They require an assignment of a data element.

          • Check table values of data elements are ignored.

          • Input help is linked to a generated check table.

        • Entity Type with Storage and Use Type 3 (Type–3 Entity Type)

          Storage and use type 3 must be used for entity types that should not be processed by MDG, but are available in the system. They have the following characteristics:

          • They model external entities used in the data model.

          • They model additional primary keys for the tables of type-1 and type-4 entity types.

          • No data storage is generated

          • No further modeling is possible.

          • No processing in MDG is possible at all.

          • They require an assignment of a data element.

          • Check tables and domain fixed values are used.

          • Input help is linked to a check text table and a domain fixed value of data elements; only key fields are processed in check tables.

        • Entity Type with Storage and Use Type 4 (Type–4 Entity Type)

          Storage and use type 4 must be used for entity types that can be processed in MDG within the context of other entity types. They have the following characteristics:

          • They represent dependent nodes of objects to structure object data.

          • Entity type 4 must be processed on the UI together with required leading type-1 entity types.

          • Data storage is generated (edition dependent and staging area).

          • They model attributes and relationships.

          • No assignments of data elements are possible.

      2. Relationship Types

        An MDG data model consists of the following relationship types:

        • Leading Relationships

          • Type-1 entity type can lead type-1 entity types and type–4 entity types.

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

            • A type-1 entity type can have a leading type-1 entity type.

        • Qualifying Relationships

          • Entity types are qualified using additional key attributes.

          • Type-2 and type-3 entity types can enhance the keys of type-1 and type-4 entity types.

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

        • Referencing Relationships

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

    2. Example: Flight Customers

      This example shows how a governance process for flight customers is defined. The SFLIGHT example defines three related database tables: SCUSTOM, SBUSPART and STRAVELAG. For more information, see Flight Model.

      Although the tables in this data model use the SAP namespace, the steps and requirements necessary for bringing the tables under governance are the same as those used in the customer namespace. The names of your entity types must be in the customer namespace. In this example, the table SBUSPART represents entity type ZSBUSPART. Since the governance process should be based on airline partners (table SBUSPART), ZSBUSPART shall be the entity type of storage and usage type 1. During this process, airline partners and travel agencies are created as well. Therefore, entity types need to be created. Since they are created only together with airline partners, these entity types need to have storage and usage type 4.

      A key of the SCUSTOM table is the field ID. The field ID uses the check table SBUSPART. Therefore, ZSCUSTOM is defined as an entity type with storage and usage type 4 with a leading relationship to ZSBUSPART.

      A key field of the table STRAVELAG is the field AGENCYNUM. The AGENCYNUM field uses the check table SBUSPART. Therefore, ZSTRAVLAG is defined as an entity type with storage and usage type 4 with a leading relationship to ZSBUSPART.

      SCUSTOM : Flight Customers

      Field

      Data Element

      MANDT

      S_MANDT

      ID

      S_CUSTOMER

      NAME

      S_CUSTNAME

      FORM

      S_FORM

      STREET

      S_STREET

      POSTBOX

      S_POSTBOX

      POSTCODE

      POSTCODE

      CITY

      CITY

      COUNTRY

      S_COUNTRY

      REGION

      S_REGION

      TELEPHONE

      S_PHONENO

      CUSTTYPE

      S_CUSTTYPE

      DISCOUNT

      S_DISCOUNT

      LANGU

      SPRAS

      EMAIL

      S_EMAIL

      WEBUSER

      S_WEBNAME

      SBUSPART: Airline Partner

      Field

      Data Element

      MANDANT

      S_MANDT

      BUSPARTNUM

      S_BUSPANUM

      CONTACT

      S_CONTACT

      CONTPHONO

      S_CPHONENO

      BUSPATYP

      S_BUSPATYP

      STRAVELAG: Travel Agency

      Field

      Data Element

      MANDT

      S_MANDT

      AGENCYNUM

      S_AGNCYNUM

      NAME

      S_AGNCYNAM

      STREET

      S_STREET

      POSTBOX

      S_POSTBOX

      POSTCODE

      POSTCODE

      CITY

      CITY

      COUNTRY

      S_COUNTRY

      REGION

      S_REGION

      TELEPHONE

      S_PHONENO

      URL

      S_URL

      LANGU

      SPRAS

      CURRENCY

      S_CURR_AG

    Data Modeling

    In this process, you create entity types for SBUSPART, SCUSTOM, and STRAVELAG, their attributes, and the relationships between the entity types.

    1. Create Data Model

      Define the data model in Customizing for Master Data Governance under Start of the navigation path General Settings Next navigation step Data Modeling Next navigation step Edit Data Model End of the navigation path.

      Select the Data Models view, choose New Entries, and enter a new data model called YZ with the description Airline Business Partner.

    2. Create Entity Types

      Select the Entity Types view, choose New Entries, and make the following entries for the entity type ZSBUSPART :

      Fields

      Entries

      Comment

      Storage/Use Type

      Changeable via Change Request; Generated Database Tables

      Type-1 Entity Type

      Validity of Entity

      No Edition

      n.a.

      Data Element

      S_BUSPANUM

      Defines the key of the entity type and the field labels

      Hierarchies

      No Hierarchies

      n.a

      Validity/Hierarchy

      Hierarchy is Not Edition Dependent

      n.a.

      Key Assignment

      Key Cannot Be Changed; No Internal Key Assignment

      User needs to provide the key when creating new entities

      Deletion

      Deletion Allowed

      n.a.

      Description

      Airline Partner

      n.a.

      Leave all other fields of the entity type blank, which is the default.

      Create a new entry for the type-4 entity type ZSCUSTOM

      Fields

      Entries

      Comment

      Storage/Use Type

      Changeable via Other Entity Type; Generated Database Tables

      Type-4 Entity Type

      Validity of Entity

      No Edition

      n.a.

      Data Element

      <BLANK>

      Left blank for ZSCUSTOM as the key will be derived from the relationship to the leading entity type ZSBUSPART (see below)

      Hierarchies

      No Hierarchies

      n.a

      Validity/Hierarchy

      Hierarchy is Not Edition Dependent

      n.a.

      Key Assignment

      Key Cannot Be Changed; No Internal Key Assignment

      User needs to provide the key when creating new entities

      Deletion

      Deletion Allowed

      n.a.

      Description

      Flight Customers

      n.a.

      Create a new entry for the type-4 entity type ZSTRAVLAG

      Fields

      Entries

      Comment

      Storage/Use Type

      Changeable via Other Entity Type; Generated Database Tables

      Type-4 entity type

      Validity of Entity

      No Edition

      n.a.

      Data Element

      <BLANK>

      Left blank for ZSTRAVLAG as the key will be derived from the relationship to the leading entity type ZSBUSPART (see below).

      Hierarchies

      No Hierarchies

      n.a

      Validity/Hierarchy

      Hierarchy is Not Edition Dependent

      n.a.

      Key Assignment

      Key Cannot Be Changed; No Internal Key Assignment

      User needs to provide the key when creating new entities

      Deletion

      Deletion Allowed

      n.a.

      Description

      Travel Agencies

      n.a.

      Note Note

      If you save your data at this point, the check log shows various errors, which you can ignore at this time.

      End of the note.

      Enter the attributes of the entity types ZSBUSPART, ZSTRAVLAG, and ZSCUSTOM. Select the entity type you want to process and navigate to the Attributes view.

      • Choose New Entries and enter the following attributes and data elements for entity type ZSBUSPART:

        Attribute

        Data Element

        BUSPATYP

        S_BUSPATYP

        CONTACT

        S_CONTACT

        CONTPHONO

        S_CPHONENO

        Leave all other fields of the attributes blank, which is the default.

        Note Note

        Data in MDG is always client dependent. Therefore, the MANDT field is not modeled as an attribute.

        End of the note.
      • Choose New Entries and enter the following attributes and data elements for the entity type ZSTRAVLAG:

        Attribute

        Data Element

        CITY

        CITY

        COUNTRY

        S_COUNTRY

        CURRENCY

        S_CURR_AG

        NAME

        S_AGNCYNAM

        POSTBOX

        S_POSTBOX

        POSTCODE

        POSTCODE

        REGION

        S_REGION

        STREET

        S_STREET

        TELEPHONE

        S_PHONENO

        URL

        S_URL

        ZLANGU

        SPRAST

        MDG uses the value table of the domain as defined in the data element of the attribute. This lets you perform checks and call up input help in the user interface.

        In transaction SE11, you can see that the attribute LANGU with the data element SPRAS is used in the data dictionary (DDIC) table STRAVELAG. This cannot be reflected in the MDG data model. The attribute name LANGU cannot be used. Therefore, the name ZLANGU is used. The data element SPRAS cannot be used as well, but it can be replaced by SPRAST. The attribute names MANDT, SID, TXTLG, TXTMI, and TXTSH cannot be used as well.

      • Choose New Entries and enter the following attributes and data elements for the entity type ZSCUSTOM:

        Attribute

        Data Element

        SCITY

        CITY

        SCOUNTRY

        S_COUNTRY

        SCUSTTYPE

        S_CUSTTYPE

        SDISCOUNT

        S_DISCOUNT

        SEMAIL

        S_EMAIL

        SFORM

        S_FORM

        SLANGU

        SPRAST

        SPOSTBOX

        S_POSTBOX

        SREGION

        S_REGION

        SSTREET

        S_STREET

        STELEPHON

        S_PHONENO

        SWEBUSER

        S_WEBNAME

        Attributes such as CITY can only be assigned once to a type-1 entity type. Therefore, you have to rename the attributes of entity type ZSCUSTOM. This is also true for indirect assignments that involve leading type-4 entity types. When renaming, insert an S as the prefix.

    3. Create Relationships

      Select the Relationships view, choose New Entries, and enter the following relationship details:

      From-Entity Type

      Relationship

      To-Entity-Type

      Relationship Type

      Cardinality

      ZSBUSPART

      BUSP2CUST

      ZSCUSTOM

      Leading

      1:1

      ZSBUSPART

      BUSP2TRAV

      ZSTRAVLAG

      Leading

      1:1

      Leave all other fields of the relationships blank, which is the default.

    4. Save and Activate the Data Model

      First, you need to save the data model. This will automatically perform a check. For the data in this example data the warning messages, which are related to change documents. Now activate the data model.

      You can choose Visualize Data Model to display an overview.

  2. UI Configuration

    You need to create a UI configuration to display or change data as part of the change request process.

    Start the UI configuration in Customizing for Master Data Governance under Start of the navigation path General Settings Next navigation step UI Modeling Next navigation step Edit UI Configuration End of the navigation path.

    Choose Create to create a new UI configuration.

    Rename the Target Configuration ID entries to YZ_MDG_APPL (for Application Configuration), YZ_MDG_IDR (for Identification Region), and YZ_MDG_OIF (for Object Instance Floorplan). Then choose Start Deep Copy.

    If you want to transport the UI configuration, assign a package and a transport request, otherwise choose Local Object and OK. When the copy is finished, the system displays a message confirming the successful creation of the deep copy.

    Select the target configuration ID YZ_MDG_APPL of the application configuration.

    The UI configuration needs to be linked to the data model. Choose Change and go to the Application Parameter and enter the data model YZ in the field USMD_MODEL.

    Save your entries and select the configuration name YZ_MDG_OIF in the section Assign Web Dynpro Component.

    You create a simple UI layout that displays the three entity types ZSBUSPART, ZSTRAVLAG, and ZSCUSTOM on one screen.

    If the section Navigation is not displayed, choose pushbutton Navigation.

    In the section Navigation choose New Start of the navigation path Variant End of the navigation path. For the variant ID select ZSBUSPART from the value help and choose OK.

    The component configuration contains a dummy variant. This entry needs to be deleted.

    Select the line VariantMust Be Deleted and choose the Delete pushbutton.

    Select the variant ZSBUSPART

    Not only the attributes of ZSBUSPART will be available in the UI configuration of this variant, but also the attributes of the entity types ZSTRAVLAG and ZSCUSTOM. This is because there is a 1:1 relationship to these entity types from ZSBUSPART.

    Choose UIBB and select Form Component (GL1.1). The default values for Component and View appear. Provide a new configuration name.

    Since the component configuration contains a default UIBB that you are not going to use, delete this UIBB. In the Hierarchy section, select other UIBB and choose Delete.

    Choose Save and ignore the error message stating that the configuration ID does not yet exist. You are going to create this configuration ID in the next step. Select UIBB and choose Configure UIBB.

    Choose New to create the new configuration ID. Provide a description for the configuration.

    If you want to transport the component configuration, assign a package and a transport request, otherwise choose Local Object and OK.

    In the next window, Edit Parameters, choose OK.

    Choose Add Group.

    Enter Airline Business Partner in the Text attribute of the group.

    Choose Configure Group.

    Drag the following fields from the Available Fields section to the Displayed Fields section so that they appear on the UI.

    • BUSPATYP

    • BUSPATYP_DESCRIPTION

    • CONTACT

    • CONTPHONO

    Choose OK to display the added fields in the preview.

    Select the description Business Partner ID Number and change the attribute Display Type to Text View.

    Choose Save.

    The UI configuration can now be used for the change request process.

    In this example, we only created a very simple configuration with a small number of fields. For more information on UI configuration features, see Managing of UI Configurations.

Process

  1. Process Modeling

    1. Create Business Activity

      Create a business activity in Customizing for Master Data Governance under Start of the navigation path General Settings Next navigation step Process Modeling Next navigation step Change Requests Next navigation step Create Business Activity End of the navigation path.

      Choose New Entries and enter the following:

      Bus. Activity

      Description

      Data Model

      YZBP

      Process Airline Business Partner

      YZ

      Choose Save and create a transport request or select an existing transport request.

    2. Create Change Request Type

      Create a change request type in Customizing for Master Data Governance under Start of the navigation path General Settings Next navigation step Process Modeling Next navigation step Change Requests Next navigation step Create Change Request Type End of the navigation path.

      Choose New Entries and enter a new change request type as follows:

      Type of Change request

      Data Model

      Description

      Objects Required

      Single Object

      Main Entity

      Type Workflow

      YZBP01

      YZ

      Process Airline Business Partner

      No

      Yes

      ZSBUSPART

      WS75700040

      Choose Entity Types and select New Entries. Enter entity type ZSBUSPART. Enter UI Configuration YZ_MDG_APPL. Choose Business Activities. Choose New Entries and enter YZBP.

      Choose Save and create a transport request or select an existing transport request.

    3. Define Workflow

      The standard workflow template WS75700040 will be used for the change request process. This template provides workflow step numbers, which need to be entered in Customizing for Master Data Governance under Start of the navigation path General Settings Next navigation step Process Modeling Next navigation step Workflow Next navigation step Other MDG Workflows Next navigation step Define Workflow Step Numbers End of the navigation path.

      In case the following entries do not exist already, choose New Entries and enter the following.

      Workflow

      Step Number

      Description

      Keys

      Suc.Val.Req'd

      WS75700040

      1

      Processing

      Yes

      No

      WS75700040

      2

      Final Check

      No

      Yes

      WS75700040

      3

      Revision

      No

      No

      Choose Save and create a transport request or select an existing transport request.

    4. Setup of Organizational Structure

      The system uses organizational structures to assign processors to the workflow steps of the change request. Create 2 positions and 1 organizational unit for this assignment. You can use transaction PPOMW to create these structures and also to assign users to these structures. This configuration description assumes an organizational structure as follows:

      Organizational Unit

      Position

      User

      Flight Alliance Inc. (Code: FAI, ID: O 50001125)

      Flight Application Process Expert (Code: FLAPPEXPERT, ID: S 50001127)

      FLAPPEXPERT

      Flight Operations Manager (Code: FLOPMAN, ID: S 50001128)

      FLOPMAN

      Organizational Unit: Flight Alliance Inc. (Code: FAI, ID: O 50001125) -- Position: Flight Application Process Expert (Code: FLAPPEXPERT, ID: S 50001127) ---- User: FLAPPEXPERT -- Position: Flight Operations Manager (Code: FLOPMAN, ID: S 50001128) ---- User: FLOPMAN

      Note Note

      You use the column configuration to display the codes and IDs of the objects. You will need the IDs in the Assign Processors activity. The system will generate the IDs. These IDs will be different than the example data in your settings.

      You can use the same user and assign it to each position. This enables you to use the change request process with a single logon. In order to demonstrate the segregation of tasks, we recommend that you use a dedicated user for each position, whereas one user, for example FLPRODMAN, is not assigned to a position and the users FLAPPEXPERT and FLOPMAN are assigned to positions.

      End of the note.
    5. Assign Processors

      Assign processors to the workflow step numbers in Customizing for Master Data Governance under Start of the navigation path General Settings Next navigation step Process Modeling Next navigation step Workflow Next navigation step Other MDG Workflows Next navigation step Assign Processor to Workflow Step Number (Simple Workflow) End of the navigation path.

      Choose New Entries and enter the following:

      Type of Change request

      Step

      Description

      Ob

      Agent ID

      Complete Name

      YZBP01

      1

      Processing

      S

      50001127

      Flight Application Process Expert

      YZBP01

      2

      Final Check

      S

      50001128

      Flight Operations Manager

      Choose Save and create a transport request or select an existing transport request.

      Note Note

      You do not assign a processor to step number 3 (Revision), since the workflow template automatically determines the processor.

      End of the note.
    6. Create Role

      In order to provide a menu and authorizations for the users, create a role using transaction PFCG.

      Create a menu entry with the following settings:

      Web Dypro Application

      USMD_ENTITY_SEARCH

      Description

      Process Airline Business Partner

      Parameter

      Name

      Value

      PROCESS

      YZBP

      On the Authorizations tab, create a profile with the following authorizations:

      Authorization Object

      USMD_CREQ (Type of Change Request)

      Activity

      All Activities

      Type of Change Request

      YZBP01

      Authorization Object

      USMD_UI2 (UI Configuration)

      Activity

      Execute

      Configuration Identification

      YZ_MDG_APPL

      Authorization Object

      USMD_MDAT (Master Data)

      Activity

      All Activities

      Data Model

      YZ

      Assign this role to the users in the organizational structure of activity Setup of Organizational Structure.

      In this example, we only add the search Web Dynpro application (WDA) of Master Data Governance (MDG) to the menu. For more information on other WDAs of MDG, see Master Data Processing.

  1. Execute Process

    After implementing all configuration settings, you can now execute this example process. For this process, you use the users you assigned to the organizational structures earlier.

    1. Create Change Request

      Log on with the user assigned to position Flight Product Manager. Choose Process Airline Business Partner. Search for airline partners to change one of these airline partners. Select an airline partner to change an existing airline partner and choose Change. To create a new airline partner choose Create and, on the next screen, enter an airline partner ID and choose Start.

      Enter a description for the change request and provide the data for the attributes of the airline partner. Choose Submit to create the change request and send it to the next processor.

    2. Process Change Request

      Log on with the user assigned to position Flight Application Process Expert. Select SAP Business Workplace (transaction SBWP). Select Inbox to display your workflow items. Double-click the work item belonging to the change request you just created. Now you can review and change the data of the airline business partner. Choose Finalize Processing to send it to the next processor. Alternatively, choose Send for Revision to send it back to the requestor.

    3. Approve Change Request

      Log on with the user assigned to position Flight Operations Manager. Select SAP Business Workplace (transaction SBWP). Select Inbox to display your workflow items. Double-click the work item belonging to the change request. You can now finally approve or reject the change request. The final approval will activate the data.

    Now, when you search for the updated airline business partner, the system lists the one that has been activated.

Configuring Data Replication

You can replicate master data stored within MDG as well as reference data, stored in configuration tables. The replication process is slightly different in each case.

MDG offers the following options to store active master data (data that has been approved):

  • The reuse option used by MDG-M and MDG-S stores data in the SAP ERP tables such as MARA or LFA1.

  • The flex option used by MDG-F and MDG for Custom Objects stores data in generated tables.

In both options, inactive master data (data that has not yet been approved) is stored in the generated tables.

Data that the MDG system replicates to target systems is always active data. The MDG system takes the active data from the SAP ERP tables or from the generated tables depending on the option in use (reuse option or flex option).

MDG applications such as MDG-M, MDG-S, and MDG-F include standard implementations of the Data Replication Framework (DRF) that read the data and send the messages to the target system. The standard implementations support key mapping and value mapping.

About the Configuration of Reference Data

Reference data, which is stored in Customizing tables, is typically stable and available for use across an organization. Currency codes, for example, may be stored as reference data. You can model reference data in MDG data models, govern changes, and replicate changes.

Once configured, the replication process for reference data is as follows:

  • Replication from the MDG hub to Customizing tables in one or more target systems.

  • Creation and release of transport request in target system.

Prerequisites for Data Replication

At least one data model, with entity types, attributes, and relationships is defined using the flex model. The user interface, workflow, and processors are defined.

Prerequisites for the replication of Reference data are as follows:

  1. The target system of replication is a development system.

  2. The user who replicates the data has the same ID in the source system and in the target system.

  3. The RFC destination for the target system has the following settings:

    1. Under Logon & Security, you have selected Trust Relationship.

    2. Under Start of the navigation path Logon & Security Next navigation step Logon Procedure End of the navigation path, you have selected Current User.

  4. In the target system, the user who replicates the data is added to the list of RFC Users authorized to execute RFC calls in trusted systems.

Steps for Replicating Data
  1. Define mapping contexts across clients for the Unified Key Mapping Service (UKMS).

    • Path: Customizing for Key Mapping (transaction IDMIMG) underDefine a Mapping Context for UKMSDefine Mapping Contexts.

    • Instructions: Copy the default Main Context to a new table and give the new mapping context a prefix of Z. The system generates a set of tables based on the standard tables. The Z prefix indicates that the objects in those tables belong to the Customer namespace.

    • Example: Copy table UKMDB_AGC00000 to ZUKMDB_AGCZZSF0.

  2. Define the business object types to be replicated using outbound implementations and assign the defined business object types to a main context ID that is defined within the UKMS (Unified Key Mapping Service).

    Business object types used in data replication are based on entity types with a storage and use type of 1 within data models.

    1. Define business object types to be replicated.

      Path: Customizing for Key Mapping (transaction IDMIMG) under Define Business Objects

      Example: Specify business object type ZZSF, which is for the customer implementation of SFLIGHT (Flex).

    2. Assign the business object types you defined to the mapping context for key mapping.

      Path: Customizing for Key Mapping (transaction IDMIMG) under Enhance Key Mapping ContentAssign Business Objects to the Main Context

      Example: Assign business object type ZZSF to the main context (defined in the previous step.)

  3. If multiple object identifier types that already belong to the same business object type must belong to the same mapping group, define an object node type. Then assign the object node type to the object identifier types.

    1. Define an object node type.

      Path: Customizing for Data Replication (transaction DRFIMG) under Start of the navigation path Enhance Default Settings for Outbound Implementation Next navigation step Define Business Objects and Object Identifiers Next navigation step Define Business Object Nodes End of the navigation path

    2. Specify the object node type in the definitions of the object identifier types.

      Path: Customizing for Key Mapping under Start of the navigation path Enhance Key Mapping Content Next navigation step Define Object Identifiers. End of the navigation path

      • Row for Business Partner Number

        • Business Object Type: 147

        • Business Object Node Type: 368

        • Business Object ID Type: 888

        • Constant Name for Business Object ID Type: BPARTNER_UUID.

      • Row for Business Partner UUID

        Same as above, except for the following:

        • Business Object ID Type: 889

        • Constant Name for Business Object ID Type: BPARTNER_UUID.

  1. Define business object identifier types so it is possible to differentiate an identifier of a business object from other identifiers of the same business object. Assign the business object identifiers types to the relevant business object types.

    1. Create business object identifier types.

      Path: Customizing for Key Mapping (transaction IDMIMG) under Start of the navigation path Enhance Key Mapping Context Next navigation step Define Object Identifiers End of the navigation path

      Example: Object ID Type = ZZSF; Description of Object ID Type = SFLIGHT - Airline Code; BO Type = ZZSF; Ob ID Constant Name = ZZSF_AIRLCODE; Object Node Type = ZZSF

    2. Assign the business object identifier types to the definition of the business object types.

      Path: Customizing for Key Mapping (transaction IDMIMG) under Start of the navigation path Enhance Key Mapping Context Next navigation step Define Business Objects End of the navigation path

      Example: Business Object Type = ZZSF; Description = SFLIGHT (Flex Option); Constant Name = ZZSF_AIRLCODE; Object Identifier Type for Key Structure Access = ZZSF

  2. Create a package in preparation for the generation of data model-specific structures in the ABAP Dictionary. Generate the structures for each entity type that you want to replicate. Verify that the system generated the structures correctly.

    1. Run transaction SE80 and create a package.

      Example: Object Name = ZZ_DRF, Description = Custom Object SFLIGHT Data Replication

    2. Generate the data model-specific structures.

      Path: Customizing for Master Data Governance (transaction MDGIMG) under Start of the navigation path Data Modeling Next navigation step Generate Data Model-Specific Structures End of the navigation path

      Example: Data Type = ZXX_S_ZZ_ZDRF_CARR, Where Used = DRF Structures, Prefix / Namespace = ZXX, Name of Structure = ZDRF_CARR

    3. Run transaction SE11 and check the structures for the generated data model-specific structure. Whenever MDG generates structures, it activates them, so the word Active displays beside the structure name.

      Example: Data Type = ZXX_S_ZZ_ZDRF_CARR

  3. Assign a key structure to the object identifier types so the key mapping functions can break down concatenated keys into their constituent parts.

    Path: Customizing for Data Replication (transaction DRFIMG) under Start of the navigation path Enhance Default Settings for Outbound Implementation Next navigation step Define Business Objects and Object Identifiers Next navigation step Assign Key Structures to Object Identifiers End of the navigation path

    Example: Business Object Type = ZZSF; Key Structure = ZXX_S_ZZ_ZDRF_CARR.

  4. Assign an entity type within a data model to a business object type, generate the data model, and verify that the confirmation message returns no errors.

    Path: Customizing for Master Data Governance (transaction MDGIMG) under Start of the navigation path General Settings Next navigation step Data Modeling Next navigation step Edit Data Model End of the navigation path In the Inactive Data Models view, select a data model. In the Entity Types view, select an entity type. In the Business Object Type view, enter the business object type for the entity type. Then generate the data model.

    Example: In the Inactive Data Models view,: select CARR. In the Entity Types view, select ZZ. In the Business Object Types view, enter the following details:Business Object Type = ZZSF. Choose the Generate Data Model button.

  5. Prepare for the creation of an outbound interface model by creating a package that contains a function group.

    1. Run transaction SE80.

    2. Create a package.

      Example: Package = Z_ZZ_PACKAGE. Short Description = Package for Outbound Implementation for ZFLIGHT (ZZ). Software Component = HOME. Transport Layer = ZZNE. Package Type = Not a Main Package.

    3. Create a function group for the package.

      Example: Function Group = Z_ZZ_FUNC_GROUP. Short Text = Function Group for Outbound Sflight (ZZ)

  6. Generate an outbound interface model that contains the entities and attributes from a data model that you want to replicate from the Master Data Governance hub to one or more target systems. This model also generates interfaces (RFCs and service interfaces) that can be used for such a data replication. After creating the outbound interface model, you can view the generated function module in transaction SE80.

    Path: Transaction OIF_MAINTAIN or Customizing for Data Replication (transaction DRFIMG) under Start of the navigation path Enhance Default Settings for Outbound Implementation Next navigation step Define Outbound Interface Models End of the navigation path

    Example: Complete the following steps:

    1. Wizard step: Enter Header Data.

      Specify and describe an identifier for the interface model, an object type code, a package name, a name for the outbound interface model, and a description for the interface model. If you want to replicate reference data, so triggering the generation of a function module enabling the replication of such data, select the Configuration Data checkbox.

      Note Note

      You can adjust the generated function module according to your needs, for example, in the case of reference data, you can omit the release of the transport request in order to enable data enrichment. The user can then release the transports manually.

      End of the note.

      Example

      Select the CARR entity type and all of its attributes. Choose the Name ABAP Dictionary Objects button. Enter the following details for the new structure:

      Interface Model ID = ZZ_SFLIGHT

      Interface Model Description = SFlight Outbound Model (ZZ)

      Object Type Code = ZZSF

      Package Name = Z_ZZ_FUNC_GROUP

      Name = ZZ_SFLIGHT

      Description = Generated RFC for SFlight Outbound Model (ZZ)

    2. Wizard step: Select Entity Types and Attributes. Select entity types and attributes you want to include in the interface model. Then enter names for the resulting dictionary objects, by choosing the Name ABAP Dictionary Objects button.

      Example: Select the CARR entity type and all of its attributes. Choose the Name ABAP Dictionary Objects button. Enter the following details for the new structure:

      • Structure Name = ZZSF_S_CARR

      • Structure Description = Structure for CARR

      • Table Type Name = ZZSF_T_CARR

      • Table Type Description = ZZSF_T_CARR

    3. Wizard Step: Review and Submit. Review and submit your work. Create a transport request or assign an existing transport request. You can use the same transport to transfer the function module to the target system later on.

    4. Wizard Step: Check Application Log. Check the application log that displays after you review your submitted work..

    5. Review the code of the function module. Run transaction SE80. Open the Repository Browser and browse by the Function Group you created earlier. Open the Function Modules folder, and review the system-generated function module for the outbound interface model.

      The outbound implementation you define in the data replication framework calls this function module to replicate the data.

  7. Create an outbound implementation to define how specific business object data is replicated. The creation of the outbound implementation involves specifying business object data to be transmitted, a class that retrieves and sends the data, and a communication channel.

    When defining an outbound implementation, use the generic outbound implementation class (CL_MDG_OIF_DRF_OUTBOUND_IMPL). You can copy this class to allow additional capabilities that are not supported by default such as key mapping and value mapping. For more information, you can refer to the standard outbound implementations that SAP delivers for other objects.

    Path: Customizing for Data Replication (transaction DRFIMG) under Start of the navigation path Enhance Default Settings for Outbound Implementation Next navigation step Define Outbound Implementations End of the navigation path.

    Example:Outbound Implementation = ZZSF_01; Outbound Implementation Class = CL_MDG_OIF_DRF_OUTBOUND_IMPL; Communication Channel = 4 Replication via iDoc; Business Object Type = ZZSF; Outbound Interface Model ID = ZZ_SFLIGHT.

  8. Create a filter object to restrict the data can be selected and transferred to a target system during data replication through the use of filters. Define filters for the filter object.

    Path: Customizing for Data Replication (transaction DRFIMG) under Start of the navigation path Enhance Default Settings for Outbound Implementation Next navigation step Define Filter Objects End of the navigation path.

    1. Enter data in the Define Filter Objects

      view and select the relevant row.

      Example: Filter Object = ZZSF_FROOT; Description = Filter SFlight (ZZ) - Root. Leave the Table Name field blank.

      Note Note

      A complex filter such as the one in the example does not require a table name. The system only requires table names for simple filters. Such filters are only available for standard applications that are built using the reuse option.

      End of the note.
    2. Define the filters for the filter object in the Assign Filters subview.

      If required, you can define your own structure to include all relevant fields from the generated table. In the Assign Filters view, apply the following settings.

    1. For the Filter field, use codes between 80 and 99. This range is assigned to the customer namespace.

    2. Specify a filter class. Example: Use the generic Filter Class CL_MDG_OIF_DRF_FILTER.

  9. Assign a filter object to a business object type (specific filtering) or to an outbound implementation.

    • Assignment of a filter object to a business object type (specific filtering).

      Path: Customizing for Data Replication (transaction MDGIMG) under Start of the navigation path Enhance Default Settings for Outbound Implementations Next navigation step Define Business Objects and Object Identifiers Next navigation step Assign Filter Objects to Business Objects End of the navigation path

    • Assignment of a filter object to an outbound implementation:

      Path: Customizing for Data Replication (transaction MDGIMG) under Start of the navigation path Enhance Default Settings for Outbound Implementations Next navigation step Define Outbound Implementations End of the navigation path

      Example: Business Object Type = ZZSF; Filter Object = ZZSF_FR00T; Outbound Interface Model ID = ZZ_SFLIGHT

  10. Create a filter to indicate precisely what data you want to replicate.

    1. Run transaction DRFF.

    2. Select the Business Object for which you want to define filter criteria.

      Example: SFLIGHT (Flex Option).

    3. Define a filter.

      Example: Under Filter Criteria to Include Business Objects, choose Airline local currency is EUR.

  11. Create a replication model, assign the outbound implementation to the replication model, and assign the business systems that act as target systems for replication to the combination of the outbound implementation and the replication model. Each replication model specifies one or more outbound implementations.

    1. Create a replication model.

      Client-Specific Path: Customizing for Data Replication (transaction MDGIMG) under Start of the navigation path Define Custom Settings for Outbound Implementations Next navigation step Define Replication Models End of the navigation path

      Example:

      In the Define Replication Model view, create a new entry with the following settings:

      Replication Model = ZZSF; Description = Replication Model for SFLIGHT; Log -Days: 15.

      Select the new entry.

    2. Assign an outbound implementation to the replication model.

      Example: In the Assign Outbound Implementation view, apply the following settings: Outbound Implementation = ZZSF_01; Communication Channel = 4 Replication via RFC; Replication via RFC; Filter Time = 2 Filter After Change Analysis.

      Select the assigned Outbound Implementation.

    3. Assign the business system or business systems to which you want to replicate data using the combination of the replication model and the outbound implementation.

      Example: Open the Assign Receiver Systems view, and enter the following value: Business System = QV5_410

    4. Activate the replication model.

      Choose the Activate Replication Model pushbutton.

Additional Steps for the Replication of Reference Data
  1. Generate an outbound interface model that contains the entities and attributes from a data model that you want to replicate from the Master Data Governance hub to one or more target systems. This model also generates interfaces (RFCs and service interfaces) that can be used for such a data replication. After creating the outbound interface model, you can view the generated function module in transaction SE80.

    Path: Transaction OIF_MAINTAIN or Customizing for Data Replication (transaction DRFIMG) under Start of the navigation path Enhance Default Settings for Outbound Implementation Next navigation step Define Outbound Interface Models End of the navigation path

    Example: Complete the wizard as follows:

    1. Wizard step: Enter Header Data.

      Specify and describe an identifier for the interface model, an object type code, a package name, a name for the outbound interface model, and a description for the interface model. To trigger the generation of a function module enabling the replication of such data, select the Configuration Data checkbox.

      Note Note

      You can adjust the generated function module according to your needs, for example you can omit the release of the transport request in order to enable data enrichment. The user can then release the transports manually.

      End of the note.

      Example

      Select the CARR entity type and all of its attributes. Choose the Name ABAP Dictionary Objects button. Enter the following details for the new structure:

      Interface Model ID = ZZ_SFLIGHT

      Interface Model Description = SFlight Outbound Model (ZZ)

      Object Type Code = ZZSF

      Package Name = Z_ZZ_FUNC_GROUP

      Name = ZZ_SFLIGHT

      Description = Generated RFC for SFlight Outbound Model (ZZ)

    2. Wizard step: Select Entity Types and Attributes. Select entity types and attributes you want to include in the interface model. Then enter names for the resulting dictionary objects, by choosing the Name ABAP Dictionary Objects button.

      Example: Select the CARR entity type and all of its attributes. Choose the Name ABAP Dictionary Objects pushbutton. Enter the following details for the new structure:

      • Structure Name = ZZSF_S_CARR

      • Structure Description = Structure for CARR

      • Table Type Name = ZZSF_T_CARR

      • Table Type Description = ZZSF_T_CARR

    3. Wizard Step: Review and Submit. Review and submit your work. Create a transport request or assign an existing transport request. You can use the same transport to transfer the function module to the target system later on.

    4. Wizard Step: Check Application Log. Check the application log that displays after you review your submitted work.

    5. Review the code of the function module. Run transaction SE80. Open the Repository Browser and browse by the Function Group you created earlier. Open the Function Modules folder, and review the system-generated function module for the outbound interface model.

      The outbound implementation you define in the data replication framework calls this function module to replicate the data.

  2. Create a mapping using the service mapping tool to map data from the staging area in the source system to the reuse table in the target system.

    Ensure the following:

    • The source structure is the data model-specific structure for the outbound interface model.

    • The source structure uses the flex option and the target structure uses the reuse option.

    Path: Customizing for Master Data Governance (transaction MDGIMG) under Start of the navigation path Data Modeling Next navigation step Generate Data Model-Specific Structures End of the navigation path

  3. Maintain a mapping table to map the tables to the objects.

    Run transaction SM30.

    Example:

    • Table Name: ZFX_S_ZT024E.

      Specified when you created an outbound interface model.

    • Object: V_T024E

      The target business object stored in Customizing.

    • Type: view.

    • SMT_Mapping: ZF_PO_MAP.

      Created previously in the Service Mapping Tool (SMT).