MDG: Object Ids in Change Request

[former_member213018]

SAP Master Data Governance being used manage all master data objects for an Enterprise, it enables the enterprise to effectively manage their master data via governance and involving appropriate stake holders to validate and enrich the data when needed.

As enterprise thrives, so do changes in MDG system. We're going to talk about the way to view this master data modification/creations.

 

Business Need:

Need details CR/Objects on below criteria:

• Object Ids on a change request


• Change Requests raised for an Object


• Change Requests raised for a set of objects(probably a pattern search).

Additionally (we can add columns to this report):

• Users this CR is awaiting action from.


• If activated already, when it was done.

***************************************************************************************************************

Use Cases:

1. For audit/tracking purposes.


2. Gives a fair idea the frequency/reasons for CR being raised for the change request on any object/set of objects.


3. Other management reports can be built on this.

***************************************************************************************************************

For the purpose of this blog we're going to focus on reading/fetching Object Ids for a Change Request. We have std. APIs which can read Object Id, however they are good to be used when we're doing for a few records.

 

While trying to build a report to read data only using API is not feasible, as it's time consuming and causes serious performance concerns when filter criteria is Object Id instead of CR data.

Solution to above issue is; going old fashion way (via backend tables). We've carefully curated a logic to extract Object Ids for CRs via DB tables, and you can build logic whatever way you deem fit for your requirement.

Without making further delays, below is the pseudocode for your reference to connect the dots.

1. Read Change Request details from USMD120C


2. For Each CR above.
   
   
   
   1. CR of Flex Data Model:
      
      
      
      1. Object Ids would be available in USMD1213.
      
      
      
      
   
   
   2. CR of Reuse Data Model:
      
      
      
      1. Get Entity of CR Type from Tables (Single: USMD110C & Mass: USMD1101)
      
      
      2. For each Entity
         
         
         
         1. Prepare Logical Name by Concatenate "TMX_" & <DATAMODEL> & "_" & <ENTITY>.
         
         
         2. Fetch fields PHYSICAL_NAME from table MDG_GN_TGOBJ, where LOGICAL_NAME = <Val from above Step> and KIND = "TABL" and MAX(VERSION).
         
         
         3. Create dynamic internal tables.
         
         
         4. Fetch Key Value from table  PHYSICAL_NAME
         
         
         
         
      
      
      
      
   
   
   
   

 

Kindly take a note of below points before considering above logic:

• This logic is tested and working on system version MDG 9.0 - 9.2.


• For alternate labeling objects (Like Functional location), you'd need to use Conversion Exit.


• Temp Keys would also appear as is.

 

Conclusion:

Object Ids are always stored in backend tables, even after activation of data for reuse data models also, it's just a staging table instead of normal tables and shouldn't be hard coded. We need to read navigate to table holding the staging table name and play around there to optimize the code.

This optimization technique helped us save 90% of time consumed during execution of this report.

While writing this blog post it's pertinent me mention here, that we're aware best practice is to use APIs, but where is the fun in that? I encourage and try to find out of the box solutions.

 

Request you to let me know your thoughts about solution suggested above,  and shoot away your questions in comment section and I will try to get back.

 

If you find this blog post useful you can follow profile for more updates.

 

Regards,

Aditya Bajoria