A step-by-step guide to extend Standard Data Models in SAP MDG

The data that has to be managed and controlled through a governance procedure, like ones enabled with SAP MDG, is determined by the data model definition.

The standard content provides the choice to configure what information needs to be governed based on the available data entities and also the characteristics of the data model. It additionally offers the ability to add additional entities or qualities that aren’t part of the conventional data model.

Some of the common use cases for data model extension are adding industry-specific master data qualities, adding enhanced data areas that currently exists in the master data repository tables (expanded SAP ERP tables), adding process-specific qualities, adding fields that require to exist just in SAP MDG hosting tables and not in SAP ERP tables (flex option), among others.

These tasks can be accomplished by adding additional entities or extending common entities with new features. These new entities can be mapped to the reuse area or be flex entities. The connections between the brand-new entities and the existing entities need to be maintained to verify the data. One of the most common use cases for information design expansion include the following:

• Adding standard files (reuse option): This includes the requirement to expand the basic SAP MDG data design with conventional fields that aren’t part of the SAP MDG data design. Instances of such areas consist of those that feature industry-specific service attachments, fields related to standard database tables that aren’t in the SAP MDG standard range, and more. Based on the number and the kind of fields (check tables, text areas, etc.), they could be added as credit to the standard entities or custom entities in the typical data model.
• Adding custom fields (reuse option): This includes the need to extend the standard SAP MDG data design with custom/enhanced fields that were included in the common SAP ERP tables or custom-made tables that are linked to the standard tables. Based on the number of fields and the kind of fields (check tables, text areas, etc.), they can be included as attributes to the common entities or custom-made entities in the standard data design.
• Including custom-made fields (flex alternative): This entails the need to expand the basic SAP MDG data model with custom fields that need not be mapped to the active points. Examples of such areas consist of process-specific fields that are used to determine process flows, fields based on user entry, extending data design with additional flex spots, and so on.

The following sections discuss different steps to apply the data design improvements, from adding credit to the standard data model to including new attributes to the data models.

Adding Attributes To Standard Data Models

Adding attributes to the conventional data model can be completed by including attributes to the existing entities or defining an entity-relationship. Attributes can be added just to storage space kind 1 or type 4 entities. The new entities can be flex entities or reuse entities, based on the entity interpretation and also type of data (master, recommendation, process-specific, etc.).

If the newly added field belongs to a check table or has foreign tricks, then the storage type 3 entity is defined, and a relationship is set up with the linked entity. If the field currently exists in the SAP ERP tables (reuse choice), mappings between the hosting and active areas must be preserved via Service Mapping Tool (SMT) mapping.

For the business partner data model, if the business partner-related field requires to be part of the consumer or vendor UI, consumer vendor integration(CVI) mapping requires to be defined to map the field from the business partner model to the equivalent consumer or vendor field. Since the financial data model (0G), unlike the product master or service partner data model is based upon the flex options, SMT mapping isn’t required.

The customer namespace for adding fields is ZZ or YY. A namespace and customized package must be provided during configuration; the frameworks are created on activation of the data design. They can be visualized in the arrangement view to present the graphical model. The produced tables can be confirmed by Purchase MDG_DATA_MODEL.

After the data model is expanded, it is triggered and created, to ensure that the expanded fields can be used in the governance process. The staging field must be changed by running report USMD_ADJUST_STAGING, which helps in changing the staging field for the linked change requests. The created structures are used to configure and extend the UIs, based on the entity/attribute relationships.

After the attributes to be enhanced or added are recognized, the various actions to prolong the standard data model are as follows. For the business partner data model enhancements, CVI mapping requirements must be updated if the business partner fields require to be mapped to the customer/supplier structure.

• Extend the SAP ERP table (for new reuse areas), if it does not already exist (reuse choice for organization companion and material master information models).
• Using Purchase MDGIMG, choose the data model and extend it with the new features in the equivalent entity definition related to the SAP ERP table or with a referencing partnership.
• Activate the data model
• Produce data model-specific frameworks. Frameworks for mapping between staging and active areas (for reuse area versions) and area buildings are mandatory. Other structure usage kinds (structures for PDF-based types, for SAP Venture Search, and area control) might be added as required. Additional metadata structures might need to be expanded based on the domain name (e.g., for the material domain name, expand framework MDG_BS_MAT_S_MAT_DATA, check/adjust matching table kind structures MDG_BS_MAT_S _<table>* and also CMD_BS_MAT_S _<table>*, as needed).
• For the reuse option, boost the access and respective handler classes (for business partner design) to review and also write in the reuse location. Gain access to classes controls the Handler course calls. Handler courses need to be improved to read and conserve information for customized entities and characteristics. A single handler course is responsible for a single object operation.
• Define SMT mapping (for reuse fields). This defines the field mapping between the staging field and primary determination area in both directions to ensure that, upon activation of the change demands, the data is conserved to reuse field (active field).
• Adjust the staging area for linked change demands.

Addition of new entities to the data models

The data models can be expanded with extra entities. The information associated with these entities can be saved in SAP MDG or SAP ERP tables upon activation of the change request. The newly specified entities must be linked to various other entities through connections. The cardinality of the relationship is established based on the data set.

The steps to extend the standard data model with new entities coincide as those stated in the previous area. For the material data design, the MDG_BS_MAT_API_SEGMENTS_EXT Business Add-In (BAdI) is also applied.

After the data model is extended, the UI requires to be enhanced. For the business companion model, the Generic Interaction Layer (GenIL) model is additionally included to connect the data model with the GenIL model, which integrates the model fields to the UI. The mapping of the GenIL version to the data design is done through view collection VC_MDG_BS_GENIL_C (Deal SM34).

Final thoughts

We wish this article post has offered you a better understanding of your choices for SAP MDG extensibility. However, there is always more to learn. At ZaranTech we offer market-relevant online SAP training programs. Feel free to visit our website for informative blogs and also to find course details.