How to Extend Standard Data Models in SAP MDG

The data that needs to be managed and governed via a governance process, like ones enabled with SAP Master Data Governance (SAP MDG), is determined by the data model definition.

The standard content provides the option to configure what data need to be governed based on the available data entities and attributes of the data model. It also provides the option to add additional entities or attributes that aren’t part of the standard data model.

Some of the common use cases for data model extension are adding industry-specific master data attributes, adding enhanced data fields that already exist in the master data repository tables (extended SAP S/4HANA and SAP ERP tables), adding process-specific attributes, adding fields that need to exist only in SAP MDG staging tables and not in SAP ERP tables (flex option), among others.

These requirements can be achieved by adding additional entities or extending the standard entities with new attributes. These new entities can be mapped to the reuse area or be flex entities. The relationships between the new entities and the existing entities need to be maintained to validate the data. The most common use cases for a data model extension include the following:

• Adding existing standard fields (reuse option): This involves the requirement to extend the standard SAP MDG data model with standard fields that aren’t part of the SAP MDG data model. Examples of such fields include those that come with industry-specific solution add-ons, fields related to standard database tables that aren’t in the SAP MDG standard scope, and so on. Based on the number of fields and the type of fields (check tables, text fields, etc.), these fields could be added as attributes to the standard entities or custom entities in the standard data model.
• Adding custom fields (reuse option): This involves the requirement to extend the standard SAP MDG data model with custom/enhanced fields that were added to the standard SAP ERP tables or custom tables that are linked to the standard tables. Based on the number of fields and the type of fields (check tables, text fields, etc.), these fields could be added as attributes to the standard entities or custom entities in the standard data model.
• Adding custom fields (flex option): This involves the requirement to extend the standard SAP MDG data model with custom fields that need not be mapped to the active area. Examples of such fields include process-specific fields that are used to determine process flows, fields based on user entry, extending data model with additional flex fields, and so on.

The following sections discuss various steps to implement these data model enhancements, from adding attributes to the standard data model to adding new entities to data models.

Adding Attributes to Standard Data Models

Adding attributes to the standard data model can be accomplished by adding attributes to the existing entities or defining an entity relationship. Attributes can be added only to storage type 1 or type 4 entities. The new entities can be flex entities or reuse entities, based on the entity definition and type of data (master, reference, process-specific, etc.).

If the newly added field is part of a check table or has foreign keys, then a storage type 3 entity is defined, and a relationship is configured with the linked entity. If the field already exists in the SAP ERP tables (reuse option), mappings between the staging and active area need to be maintained through Service Mapping Tool (SMT) mapping.

For the business partner data model, if the business partner-related field needs to be part of the customer or vendor UI, customer vendor integration (CVI) mapping needs to be defined to map the field from the business partner model to the corresponding customer or vendor field. Because the finance data model (0G), unlike the material master or business partner data model, is based on the flex option, SMT mapping isn’t required.

The customer namespace for adding fields is ZZ or YY. A namespace and custom package need to be provided on configuration; the structures are generated on activation of the data model. They can be visualized in the configuration view to display the graphical model. The generated tables can also be verified by Transaction MDG_DATA_MODEL.

After the data model is extended, the data model is activated and generated, so that the extended fields can be used in the governance process. The staging area need to be adjusted by running report USMD_ADJUST_STAGING, which helps in adjusting the staging area for the linked change requests. The generated structures are used to configure and extend the UIs, based on the entity/attribute relationships.

After the attributes to be enhanced or added are identified, the various steps to extend a standard data model are as follows. For the business partner data model enhancements, CVI mapping needs to be updated if the business partner fields need to be mapped to the customer/supplier structure.

1. Extend the SAP S/4HANA and SAP ERP table (for new reuse fields), if it doesn’t already exist (reuse option for business partner and material master data models).
2. Using Transaction MDGIMG, select the data model, and extend it with the new attributes in the corresponding entity definition associated with the SAP S/4HANA and SAP ERP table or with a referencing relationship.
3. Activate the date model.
4. Generate data model-specific structures. Structures for mapping between staging and active areas (for reuse area models) and field properties are mandatory. Other structure usage types (structures for PDF-based forms, for SAP Enterprise Search, and for field control) may be added as required. Additional metadata structures may need to be extended based on the domain (e.g., for the material domain, extend structure MDG_BS_MAT_S_MAT_DATA, check/adjust corresponding table type structures MDG_BS_MAT_S_<table>* and CMD_BS_MAT_S_<table>*, as needed. For more information check the help documentation.).
5. For the reuse option, enhance the access and respective handler classes (for the business partner model) to read and write in the reuse area. Access classes control the handler class calls. Handler classes need to be enhanced to read and save data for custom entities and attributes. A single handler class is responsible for a single object operation.
6. Define SMT mapping (for reuse fields). This defines the field mapping between the staging area and primary persistence area in both directions so that, upon activation of the change requests, the data is saved to the reuse area (active area).
7. Adjust the staging area for linked change requests.

Adding New Entities to the Data Model

The data model can be extended with additional entities. The data associated with these entities can be stored in SAP MDG or in SAP S/4HANA and SAP ERP tables upon activation of the change request. The newly defined entities need to be linked to other entities via relationships. The cardinality of the relationship is determined based on the data set.

The steps to extend the standard data model with new entities are the same as those mentioned in the previous section. For the material data model, the MDG_BS_MAT_API_SEGMENTS_EXT Business Add-In (BAdI) is also implemented.

After the data model is extended, the UI needs to be enhanced. For the business partner model, the Generic Interaction Layer (GenIL) model is also extended to connect the data model with the GenIL model, which integrates the model fields to the UI. The mapping of the GenIL model to the data model is done through view cluster VC_MDG_BS_GENIL_C (Transaction SM34).

Conclusion

We hope this blog post has given you a better understanding of your options for SAP MDG extensibility. However, there is always more to learn. What SAP MDG topics are you interested in?

Editor’s note: This post has been adapted from a section of the book SAP Master Data Governance: The Comprehensive Guide by Bikram Dogra, Antony Isacc, Homiar Kalwachwala, Dilip Radhakrishnan, Syama Srinivasan, Sandeep Chahal, Santhosh Cheekoti, Rajani Khambhampati, Vikas Lodha, and David Quirk.