Maintaining the MDM ID on the target systems

[Former Member]

Hi

I understand that maintaining the MDM Id on the target helps in better traceability. But is it absolutely necessary to maintain MDM Id on target systems? this would require identifying an additional field on all the target systems.This will be quite challenging some times and would require business justification if we plan to use an existing field for a different purpose. Can you pls help me with all the conditions or reasons that you have come across that makes it an absolute necessity.

Thanks & Regards

Arvind

[Former Member]

Hi,

I wouldn't use the MDM-Id type AutoId as a field in the target structure, because:

- When you continue to consolidate data in MDM with merging, the new merged record gets a new ID and cannot be matched to your target system anymore.

- AutoId would make sense to be able to identify uniquely the records in case of importing something back from legacy system. But Import manager doesn't allow to match on AutoID. I've tried it with a workaround in creating a calculated field in MDM with AutoId as content, it works but costs a lot of performance.

- You've mentioned it already, in some systems it is a big effort to create or assign a field with this content in the target systems

After 3 years experience I try to keep on the remote key principle, even it is not visible

(Does anybody know wether it is visible in 7.1, we're working in 5.5?)

it is the most reliable and performant way to identify target system records.

Rgds Jutta

[Former Member]

Hi Jutta

I agree with your answers. But still have few scenarios which might require MDM id to be stored on the target system. Let me know if you differ.

1. If the target system Id's are not maintained on MDM as separate fields & referenced only via key mapping, how would one cross reference the corresponding records from the target system.The key mapping table is virtual table & cannot be looked up easily or searched.

2. If PI uses the MDM id as a key to update the record on MDM after syndication via a subsequent import from the target system.

3. If all the target systems are not directly connected to MDM, some of the target systems may continue to receive master data from an intermediate system which is actually receiving master data from MDM. The key between the MDM & intermediate system may be different from that between the intermediate & the end system. In such a case it makes sense to maintain MDM id on the end systems also as a key.

Thanks

Arvind

[Former Member]

Hi Arvind,

will you have an automatic transport between your different target systems?

If yes, you should refer on the legacy remote keys.You ensure the matching even when records

are merged in MDM and Import server is able to match on the record in case of subsequent loads

from target system. AutoId doesn't allow to map and match in Import manager.

For the syndication or other transport via APIs you're able to retrieve the remote keys and map it to the target systems.

The remote key / remote system combination is also unique in MDM like the Auto ID so in case of load/syndication of subsets of data belonging to only one system it makes even more sense.

If somebody references manually in the data manager to different records it's in fact an issue only to

use remote keys. In a lot of cases it still makes sense to have "old" keys visible. In our repositories we did created a field / Q-Lookup with the legacy key in order to enable the users to find "their" records.

When target system and MDM have the same key, why shouldn't have the intermediate systems

this key? If you will create the record in MDM, syndicate to the intermediate system and at the same time to the target system, the key creation should be done in MDM, according to the rules in the target system.

Hope it helps

regards Jutta

[Former Member]

Hi Jutta

will you have an automatic transport between your different target systems?

If yes, you should refer on the legacy remote keys.You ensure the matching even when records

are merged in MDM and Import server is able to match on the record in case of subsequent loads

from target system. AutoId doesn't allow to map and match in Import manager.

For the syndication or other transport via APIs you're able to retrieve the remote keys and map it to the target systems.

The remote key / remote system combination is also unique in MDM like the Auto ID so in case of load/syndication of subsets of data belonging to only one system it makes even more sense.

I am talking about an auto import/syndication scenario. Here the remote keys along with system id are stored in key mapping table. If a user requires to search for a record in MDM using the id in a local system, how would that be accomplished.

If somebody references manually in the data manager to different records it's in fact an issue only to

use remote keys. In a lot of cases it still makes sense to have "old" keys visible. In our repositories we did created a field / Q-Lookup with the legacy key in order to enable the users to find "their" records.

Best practice suggests that Q lookup table values should be limited to a few 1000 records. Would storing the legacy key in a Q lookup table be an appropriate approach

When target system and MDM have the same key, why shouldn't have the intermediate systems

this key? If you will create the record in MDM, syndicate to the intermediate system and at the same time to the target system, the key creation should be done in MDM, according to the rules in the target system.

I think you got the scenario wrong. Here for eg. MDM & intermediate system are referenced by remote key of MDM. The intermediate & end system reference a record using the local key of the intermediate system. MDM is not directly connected to the end system.

pls let me know your views

Thanks

Arvind

[Former Member]

Hi Arvind,

In your system you're using an Auto import/syndication scenario

- here the only solution is remote key as AutoId has several weak points like mapping in IM and disappearing after merging

Users want to search for the end system key.

- here I'd also prefer to store the end system key in a Q-Lookup. The Non-Qualifier can be one value ("Remote key") or different values ("Remote systems") but will not exceed at all several 1000 records. The Qualifier (end system key value) is not part of the Lookup but of the record in the main table so you won't get performance issues. Also please take into account the user acceptance: Rather in having a non speaking number which might change due to deletions/merges, they want to see their old number.

Generally, the discussion is about where to store the key mapping, Yet you manage the reference table in the intermediate system. I'd prefer to move the key mapping to MDM as it is designed to handle this instead of planning to have the MDM Id in the end system and have the key mapping there.

The only scenario I can imagine where a MDM ID in end systems might make sense is when two different end systems with different keys are directly referencing to each other.

Rgds

Jutta

[Former Member]

Thanks Jutta

Your suggestions have been extremely useful.

[Former Member]

Hi Arvind,

There can be 2 MDM ID's which you can refer to.

1. MDM- AutoiD - This is generally used when the source file soes not contain any field which has unique values. Hence, MDM uses this field of type MDM ID to generate unique numbers internally for each record.

You might be refering to the 2nd ID.

2) Remote Key Value- This is used for idenifying the source system and relates the incoming data with the respective source systems. There might be many source systems from which the data might be coming into MDM. Now, once the data enters MDM, there should be a capability in MDM which identifies the source systems and their corresponding records, so that later on while sending back you can send it to the correct target system.

This Need not be sent to the target system. However, can just be used for identifcation of the correct records to the correct remote system. To systems like BI, this can be done quite easily.

However, the transactional systems like ECC, we can avoid creating an extra field. It all depends upon the requirement. You can even use any search field which is generally not used in ECC and populate it with the merged ID.

The mapping can be managed in the syndicator according to your needs.

Please refer to the link below for better understanding of Remote systems and ports concept.

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30843106-5539-2b10-75a9-da483911...

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/7051c376-f939-2b10-7da1-c4f8f9ee...

Hope it helps.

Thanks and Regards

Nitin Jain

[Former Member]

Hi

Thanks for your answers. But my Question is still unanswered. I completely understand that the MDM maintains the traceability of the record via the key mapping table & the remote keys when consolidation or during syndication. My question is

- whether we need to syndicate the MDM Id (Auto id generated in MDM) to the target system at all? (For eg. do we need to identify a field in R/3 which can hold MDM id.) If yes, for what all purposes can it be used.

Pls let me know if you have implemented such scenarios & what business justification you can provide for this.

Thanks

Arvind

[Former Member]

Hi Arvind,

If the MDM Id here in qusetion is the Auto ID field generated by MDM Auto ID data type for every record maintained in MDM then MDM need not syndicate this field data to the target systems in most cases.

The MDM auto ID is just a serial number assigned to the Mater records in MDM nad gets incremneted serially so say even if you delete a record in between, the MDM ID is not adjusted automatically but keeps on incresing in order eg a record 100 is deleted then the next records will still have 101 as the Id so we will have rec with number 99 followeed by 101 so that means it is not storing any significant information for the target sytems as such and so may not need to be syndicated acc to my knowledge..

The MDM ID when talking in terms of remote keys and Matching merging is the remote sytem ID itself (Local ID) which gets merged with the duplicate records to have aglobal consolidated ID,This ID in qusetion is necesaary to be syndicated to the target sytems as it holds the local as well as the global info.

Hope It Helped,

Thanks & Regards

Simona Pinto

[former_member198313]

HI Arvind,

This is very important aspect in MDM solution architecture and completely based on the scenario and landscape.

for example in consolidation, It is not useful to send the auto-id in case of existing systems since they might not able to make use of it. However it makes sense that auto-id along with local IDs to analytics system to make reports.

However if a new system is coming in place after MDM or new number range in existing systems can be used after implementing MDM then it auto-id will be the local id as well.

Hope this makes little clear,

+ An

[former_member198313]

Yeah I agree with Jetta that new auto-ID after merging is big issue,

in our CMDM project, we sent compounded auto-id along with local system ID to BI.

+ An

[Former Member]

Hi Arvind,

When ever MDM is been used for consolidation and Deduplication purpose of Master Data a Global ID is assigned to the merged records to identify them as possible duplicates by the target system.But when this Global id is send to the target sytem it will have to be accomodated on the receiveing end which is not possible in most cases:

Below are the Few Scenario where and how can the Global ID be accomodated:

- BI-MDM: One of the major areas where Master data management is required is for BI reporting without MDM is place Bi will be reporting on inconsistent data which will result in wrong reports and thus wrong business decisions So Master data are first filtered out in MDM and then passed to BI for correct reporting in this case. If we are using BI 7 then we have a MDM-BI package that needs to be deployed on BI By doing this an Additionla Field is generated in BI which handles the Global Id send from MDm without much difficulty so this justification is sufficient as the receipient system has provision to handle it.This can also be taken care when working with BI3.5

You can follow the below link to understand the same:

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d06a92de-614e-2b10-4989-d913c215...

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b01e4269-f744-2b10-929b-fa7b49aa...

- R/3/ECC- MDM:This is the second Major area where MDM is used for consolidation and harmonization of master data,but in this case ERP system has no provision to take care of the global id field as that would require modifying the std tables and fields in ECc which are not desirable.In this case i would suggest that MDM be used for inding duplicates howeevr the deuplictaes rec need not be merged and send back rather just be marked as duplicates to notify that thaey ar similar rec and then the care be taken to handle them in ECC iself.

- SRM-MDM etc:In most other scenario besides the two mentioned above MDM is used for data enrichment such as RPCM(Rich product catalog managemnet) where matching and merging is not the prime focus.

It is important to note that although MDM is primarily used for finding duplictaes it has many other functionlaities which it can perform like ensure Data completeness,Data accuracy,Enrichment,Governance etc

Hope It Helped,

Thanks & Regards

Simona Pinto