While MDM 5.5 had certain limitations in regards to Data Modeling (no deeply nested structures, only one main table) MDM 7.1 solved most of these issues by introducing the Multiple Main table and Tuples concept.
For MDM 5.5 customers who have multiple master data domains and each domain maintained in their own repository - the question comes up whether they should continue with this repository strategy under MDM 7.1 or whether they should merge several repositories into one, taking advantage of the multiple main table and the shared table concept.
Merging multiple domains into a single repository can also benefit from the functions and features that are available inside a single repository only, e.g. workflows, assignments and validations are available over multiple main tables in the same repository but they do not span different repositories.
It not always makes sense to merge several repositories into one – a list of decision criteria is explained in a separate blog, see here:
In this blog we describe in short the necessary steps to be performed to merge two repositories into one repository.
The whole procedure to merge repositories is described also in the How-to-guide “Best Practices for Migration from MDM55 to MDM71” which can be downloaded from SDN by clicking on the following link: https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/80765a21-78f3-2b10-74a2-dc2ab57a1bd2
A merge operation of several repositories into one repository consists of three major steps.
These are in the
Step 1 - Console
Perform Repository metadata migration (Tables, fields, Maps, XML-Schemas) by using the “Export Repository schema” and “Import Repository Schema” functions.
The migration of two repositories is not always an easy task, in many cases there will be conflicts, between already existing fields and tables and those to be imported.
Here are two examples for the merge of lookup tables, one without and one with a conflict:
Solution: Don’t merge the tables, instead rename them accordingly, so that both exist in the merged repository
All of these conflicts need to be handled very carefully cause ultimately you won't loose any data nor have any wrong data in your repository.
Step 2 - Console
Create Linkage between main tables (Lookup Main). This step is only necessary when the domains of the original repositories are somehow related to each other from a business process point of view, e.g. materials and suppliers. Via the Supplier Part Number a linkage between the two domains can be established.
Below screenshot shows a field added to the Products main table which refers to a record of the vendor main table (type Lookup[Main]).
Step 3 - Import Manager & Syndicator
After a succesful metadata migration it’s also necessary to migrate the records from second repository into the first repository. This is done by performing first a syndication of all records into an XML-File and afterwards an Import of the XML-File into the new repository. Consider that this step needs to be preformed for all remote-systems defined in the repository – otherwise you would lose key-mapping information for the different remote-systems.
For MDM 5.5 customers who have multiple master data domains and each domain maintained in their own repository - the question comes up whether they should continue with this repository strategy under MDM 7.1 or whether they should merge several repositories into one, taking advantage of the multiple main table and the shared table concept.
Merging multiple domains into a single repository can also benefit from the functions and features that are available inside a single repository only, e.g. workflows, assignments and validations are available over multiple main tables in the same repository but they do not span different repositories.
It not always makes sense to merge several repositories into one – a list of decision criteria is explained in a separate blog, see here:
In this blog we describe in short the necessary steps to be performed to merge two repositories into one repository.
The whole procedure to merge repositories is described also in the How-to-guide “Best Practices for Migration from MDM55 to MDM71” which can be downloaded from SDN by clicking on the following link: https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/80765a21-78f3-2b10-74a2-dc2ab57a1bd2
A merge operation of several repositories into one repository consists of three major steps.
These are in the
Step 1 - Console
Perform Repository metadata migration (Tables, fields, Maps, XML-Schemas) by using the “Export Repository schema” and “Import Repository Schema” functions.
The migration of two repositories is not always an easy task, in many cases there will be conflicts, between already existing fields and tables and those to be imported.
Here are two examples for the merge of lookup tables, one without and one with a conflict:
- No conflict: Two Lookup tables have the same name and structure => Merging is trivial
- Conflict:Two Lookup tables have the same name but are populated from different tables in a Backend system.
| Repository | Lookup Table | Corresponding Table in ERP |
| Material | Freight Groups | TMFGT |
| Vendor | Freight Groups | TSFGT |
Solution: Don’t merge the tables, instead rename them accordingly, so that both exist in the merged repository
All of these conflicts need to be handled very carefully cause ultimately you won't loose any data nor have any wrong data in your repository.
Step 2 - Console
Create Linkage between main tables (Lookup Main). This step is only necessary when the domains of the original repositories are somehow related to each other from a business process point of view, e.g. materials and suppliers. Via the Supplier Part Number a linkage between the two domains can be established.
Below screenshot shows a field added to the Products main table which refers to a record of the vendor main table (type Lookup[Main]).
Step 3 - Import Manager & Syndicator
After a succesful metadata migration it’s also necessary to migrate the records from second repository into the first repository. This is done by performing first a syndication of all records into an XML-File and afterwards an Import of the XML-File into the new repository. Consider that this step needs to be preformed for all remote-systems defined in the repository – otherwise you would lose key-mapping information for the different remote-systems.
Related Posts
