Best Practices for Repository Migration From SAP Netweaver MDM 5.5 to SAP NetWeaver MDM 7.1

SA P N e t We a v e r H o w -T o G u i d e

B e s t P r a c t i c e s f o r Re R e p o si si t o r y M i g r a t i o n f r o m SA S A P N e t w e a v e r M DM DM 5 .5 . 5 t o SA SA P N e t We a v e r M DM 7 . 1

A p p l i c a b l e Re l e a s e s : SAP NetWeaver MDM 7.1

Topic Area: I n f o r m a t i o n M a n a ge ge m e n t Capability: Master Data Management

Version 1.0 March 2009

© Copyright 2009 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. SAP NetWeaver “How-to” Guides are intended to simplify the product implementation. While specific product features and procedures typically are explained in a practical business context, it is not implied that those features and procedures are the only approach in solving a specific business problem using SAP NetWeaver. Should you wish to receive additional information, information, clarification or support, please refer to SAP Consulting. Any software coding and/or code lines / strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent. Disclaimer Some components of this product are based on Java™. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java™ Source Code delivered with this product is only to be used by SAP’s Support Services and may not be modified or altered in any way.

© Copyright 2009 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. SAP NetWeaver “How-to” Guides are intended to simplify the product implementation. While specific product features and procedures typically are explained in a practical business context, it is not implied that those features and procedures are the only approach in solving a specific business problem using SAP NetWeaver. Should you wish to receive additional information, information, clarification or support, please refer to SAP Consulting. Any software coding and/or code lines / strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent. Disclaimer Some components of this product are based on Java™. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java™ Source Code delivered with this product is only to be used by SAP’s Support Services and may not be modified or altered in any way.

Do c u m e n t H i s t o r y Document Version

Description

1.00

First official release of this guide

Typographic Conventions

Icons

Type Style

Description

Icon

Example Text

Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Cross-references to other documentation

Example text

Emphasized words or phrases in body text, graphic titles, and table titles

Example text

File and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools.

Example text

User entry texts. These are words or characters that you enter in the system exactly as they appear in the documentation.

Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system.

text>

EXAMPLE TEXT

Keys on the keyboard, for example, F2 or ENTER.

Description Caution Note or Important Example Recommendation or Tip

T a b l e o f Co Co n t e n t s 1.

Business Scenario......................................................................................................... Scenario............................................................................................................... ...... 1

2.

Prerequisites Prerequisites ............................................................................ ........................................................................................................................ ............................................ 1

3.

MDM 7.1 Data Model Enhancements Enhancements ....................................................................... ................................................................................. .......... 2 3.1

Migrating from two Repositories to one Repository with two Main Tables................... 3 3.1.1

3.2

3.3

3.4

4.

5.

Migrating Data Data Model Structure ....................................................................... .......................................................................4 4

Relationships between multiple Main Table Records of different Types ................... 22 3.2.1

Enhance Data Structure................................................................................. 23

3.2.2

Importing Records into the “Relationship Products Supplier” Table.............. 25

3.2.3

Performing Searches in MDM MDM Data Manager................................................ 26

Recursively link Main Table Objects .......................................................................... 28 3.3.1

Create Lookup [Main]..................................................................................... 28

3.3.2

Import Relationship File ................................................................................. .................................................................................29 29

Additional Information ........................................................................................ ................................................................................................. ......... 30

Replacing Relationship Relationship Table with New Data Structures Structures in SAP NW MDM 7.1 7.1 .......... 33 4.1

Enhance Data Structure .................................................................................. ............................................................................................. ........... 33

4.2

Performing the Migration ................................................................................. ............................................................................................ ........... 34 4.2.1

Determining the Children Elements for each Material in the Materials Table35

4.2.2

Syndicating the Child Info from the Materials Table ...................................... 36

4.2.3

Importing the previously syndicated Child Info in the BOM Header Table .... 37

4.3

Verification of your Work Work in the MDM Data Manager................................................. Manager ................................................. 38

4.4

When does it make Sense to replace a Relationship Definition by Tuples?.............. 40

4.5

When does it make no Sense to replace a Relationship Definition by Tuples?......... 41

Migrating from from Qualified Qualified Lookup Table Table to Tuple ........................................................... ...........................................................42 42 5.1

Why should should I use Tuples? ............................................................................... .......................................................................................... ........... 42

5.2

How do I migrate? ............................................................................... ...................................................................................................... ....................... 43

5.3

Qualified Lookup Table versus Tuple ......................................................................... 45 5.3.1

Import and Syndication .................................................................................. ..................................................................................45 45

5.3.2

Validation and Assignment ........................................................................... ............................................................................. 46

5.3.3

Matching and Merging ................................................................................... ...................................................................................50 50

5.3.4

Workflow ................................................................................. ........................................................................................................ ....................... 52

Best Practices for Repository Migration from SAP Netweaver MDM 5.5 to SAP NetWeaver MDM 7.1

1.

B u s i n e s s Sc e n a r i o

With SAP NetWeaver MDM 7.1 two new data modeling features have been introduced: •

Multiple main tables

•

Tuples

While it’s relatively easy to use these functions when designing completely new repositories, it’s often not clear, whether and how to apply these new features to already existing SAP NetWeaver MDM 5.5 repositories, which got upgraded to SAP NetWeaver MDM 7.1. Customers with existing MDM implementations often already had several repositories in place. An often asked question is then, whether these several repositories should stay in place also after upgrading to SAP NetWeaver MDM 7.1 or whether some of these repositories can be merged together into a single repository consisting then of several main tables and potentially having linkages between these main tables. Another example would be that a customer has a 1:n relationship between a main table record and a sub table record. Here it might be evaluated whether to use a qualified lookup table to model this or instead going with tuples, newly introduced with SAP NetWeaver MDM 7.1 This guide gives answers to above questions and explains also when it makes sense to use the new functions and when not.

2. •

•

Prerequisites SAP NetWeaver MDM 7.1 Repositories to be used for migration must have been worked with using the latest SAP NetWeaver MDM 5.5 SP06 Patch

March 2009

1


3.

M DM 7 .1 Da t a M o d e l En h a n c e m e n t s

There are some data modeling limitations with SAP NetWeaver MDM 5.5 which have been resolved with SAP NetWeaver MDM 7.1:

•

Sharing of lookup tables (e.g. country) across repositories not supported

•

Linking of business objects residing in 2 repositories is not supported natively

•

Workarounds via the integration into SAP NetWeaver Portal 

Use of “eventing technology” → mapping of key fields and match of respective values



Not sufficient for each and every use case

SAP NetWeaver MDM 7.1 will support the following options: •

Multiple business objects (main tables) can reside in a single repository

•

Multiple main tables can reference the same look-up tables

March 2009

2


Key benefits of this concept •

Main table objects can reference each other using a Lookup [Main] field type (e.g. a supplier can be related to several products)

•

Main table objects can recursively reference themselves (e.g. Employees reference Employees)

•

Increased consistency of lookup table entries and reduced maintenance effort (e.g. only one table for countries, currencies etc.)

As you have to consider also some side effects when having multiple main tables in a single repository like: •

a downtime will impact both main tables

•

performance (like load time of the repository)

•

increase of the number of users working with multiple main tables in one repository

we recommend •

to implement multiple main tables when each main table is an entity of its own (like vendor, customer, material, etc.). Objects that have been handled in lookup tables before (which means the object is not an entity of its own) should be considered on a case to case basis.

and •

multiple main tables are related with each other for business reasons or that they share the same multiple lookup tables.

In the following chapters typical use cases and the migration path are described.

3 .1

M i g r at i n g f r om t w o Re p o s i t o r i e s t o o n e Re p os i t o r y w i t h t w o M a i n Ta b le s

In the following example the schema of the “Vendor” repository is imported into the “Material” repository.

Use case 1: Linking of objects residing in 2 repositories Example

Supplier – “Material”

Use case 2: Usage of the same lookup table Example

Supplier Lookup “Country” “Material” Lookup “Country”

March 2009

3


3.1.1

M i g r a t i n g Da t a M o d e l St r u c t u r e

3.1.1.1

Ex p o r t t h e “ V e n d or ” Re p o si t o r y S c h e m a

3.1.1.2

I m p o r t t h e „ V e n d o r “ R ep o s i t o r y Sc h e m a i n t o t h e “ M a t e r i a l ” Repository

March 2009

4


Import Schema dialog elements are color-coded in the three panes in black, red, magenta, and green, and highlighted in bold, as summarized.

The following conflicts during the import have to be resolved or adjusted manually after the import. Please keep aware that changing the data structure could lead to a loss of data.

3.1.1.3

M i g r a t e / M e r g e t h e D i f f e r e n t S u p p o r t i n g St r u c t u r e s

M i g r a t e / M er g e t h e C o r r e s p o nd i n g L o o k u p T a b l e s To keep the structure of the original „Material“ repository, the structure of the “Vendor” repository is matched to the structure of the “Material” repository for the following lookup tables.

Important

Before merging corresponding lookup tables you should keep in mind that although some lookups might have equal names, they can reside in different tables in the remote systems and therefore may have different fields, field lengths, same keys for different customizing values, and so on.

March 2009

5


Example

Vendor freight groups are stored in ERP table TSFGT whereas Material freight groups are stored in TMFGT. Tip

In this case those tables might not be merged but renamed accordingly.

The „Countries“ table exists in both repositories with a different number of fields.

Material:

Vendor:

This leads to the following conflict:

The conflict is resolved by matching the “ISO Code” to “ISO Alpha Code”:

March 2009

6


Further examples are the tables „Freight Groups”, “Industries” and “Regions.

Material:

Vendor:

Conflict:

Material:

Vendor:

Conflict:

March 2009

7


Regions – Conflict:

Migrate Maps As some of the lookup tables have been adjusted the corresponding import maps also have to be adjusted manually after the schema import.

This has also to be checked for the syndication maps.

March 2009

8


M i g r a t e Po r t s Ports represent the logical point of contact between MDM and the outside world (e.g. XI or a user of the MDM Import Manager). Within the MDM Import Manager and MDM Syndicator, it represents the physical staging location of data and a logical handle by which to identify all of the encapsulated information. The port sequence is the same for both repositories but with different ports.

Material:

Vendor:

Therefore, you have to decide which ports will be processed first in the productive environment. If you reject the import of the port sequence, ports of the “Material” repository will be processed first as the ports of the “Vendor” repository will be added to the sequence. If you accept the import of the port sequence the ports of the “Vendor” repository will be inserted before the existing ports. We would recommend adjusting the port sequences after the import of the schema according to your business needs. Tip

There are some dependent ports like Bank Master (requires the import of countries), Transportation Zones, and so on. In general one could say that: if a lookup up table has a member field that itself refers to another lookup table, the other lookup table must be imported before.

March 2009

9


The deletion of the existing ports of the “Material” repository has to be rejected, the import of the new ports of the “Vendor” repository have to be accepted. Identical ports will be automatically merged.

If the maps of these automatically merged ports differ, the ports have to be adjusted after the import of the schema.

March 2009

10


In this example the ports of the “Vendor” repository have been added before the ports of the Material repository:

March 2009

11


M i g r a t e X M L Sc h e m a Check if the XML schema has the same name and content. In this example, the XML schema “ReferenceData R/3 & ERP” is named the same in both repositories but one reflects “Vendor” the other one “Material” reference data. Therefore, the XML schema for the “Vendor” reference data has to be added with a new name after the import, and all ports have to be adjusted manually.

March 2009

12


M i g r a t e R ol e s Check if the “Roles” have the same name. Authorizations will then be added to the role.

Keep Original Structure All tables and fields in “magenta” have to be set to “reject”. Otherwise the Material related tables will be deleted. ...

After the successful import, two main tables “Material” and “Vendor” are available in the repository. Corresponding lookup tables are used by both main tables.

March 2009

13


3.1.1.4

Create Lookup [Main]

Now the “Vendor” table should be referenced to the Material table. Therefore create a lookup main field in the “Material” main table pointing to the “Vendor” main table.

3.1.1.5

Migrate Data Records

After the successful schema migration the records and customizing data have to be re-imported to the joined repository. In addition, as the structure of some of the lookup tables has changed, values might get lost.

Therefore we recommend the following approach. If the structure of the tables of one repository hasn’t changed you could consider only importing the values of the second main table and lookup tables. Otherwise the content of both repositories has to be re-imported into the joined repository. As the key mapping information can not be imported in one import for several Remote Systems you need one syndication/import file per remote system. ...

1. Syndicate main table of repository 1 per Remote System 2. Syndicate lookup tables of repository 1 per Remote System

March 2009

14


3. Syndicate lookup tables of qualified lookup table of repository 1 per Remote System

Material:

4. Syndicate main table of repository 2 per remote system 5. Syndicate lookup tables of repository 2 per remote system

March 2009

15


6. Syndicate lookup tables of qualified lookup table of repository 2 per remote system

7. Migrate schema as described in chapter 2.1

March 2009

16


8. Manual adjustments as described in chapter 2.1

9. Import lookup tables of repository 1 per remote system 10. Import lookup tables of qualified lookup table of repository 1 per remote system 11. Import main table of repository 1 per remote system

Products:

12. Import lookup tables of repository 2 per remote system 13. Import lookup tables of qualified lookup table of repository 2 per remote system

March 2009

17


14. Import main table of repository 2 per remote system

Vendor:

March 2009

18


15. Import relationship file “Vendor” → “Material” Example:

Note

Once the field-mapping is done, the value mapping occurs automatically. In pane (4) only those values show up for which the system performed a successful automap (based on the keys, not on the display fields).

When in the “Value conversion and mapping” pane a new “Vendor” value is getting added manually from (2) to (4) then this “Vendor” is getting added to the lookup table “Vendors”. The value taken over from (2) populates the remote-key AND the first Display field of the table. Therefore it’s not really recommended to use it to populate the whole “Vendor” table that way instead of having three separate imports as described above: •

Import first main table “Material”

•

Import second main table “Vendor”

March 2009

19


•

Import relationship file Vendor → “Material”

The new data structure is supported by import and syndication.

Remarks regarding Import: By using XML-schemas with more than one root element in the schema definition you can have one XSD schema file defining import structures for several main tables.

March 2009

20


Remarks regarding Syndication: During syndication, main tables can share the same customizing/ lookup tables; E. g. the main tables “Products” and “Suppliers” can be connected to the “countries” table in order to ensure consistent information.

Syndication supports deeply nested structures.

Note

At the moment it is not possible to syndicate qualified lookups from under the main table lookup. Tuples are supported as shown in the diagram above. March 2009

21


3 .2

Re l a t i o n s h i p s b et w e e n m u l t i p l e M a in T a b l e Re c o r d s o f d i f f e r e n t T y p e s

Use case 3: Relationship between two main table records This use-case can be seen as a logical consequence once you’ve migrated two repositories into one single repository. You have a main table “products” and a main table “suppliers”. You would like to model a relationship that way, that you’re able to search all suppliers for a product and as well get all products a supplier has in its portfolio.

Repository containing two main tables:

Technically it is possible to have Products + Lookup [Main Suppliers] and Suppliers + Lookup [main Products] without using Tuples. However this solution has one shortcoming - both links are not related to each other. So creating a new linkage between a product and a supplier during record maintenance you would have to perform two steps, create: 1. in the table products a link via to Lookup Main to [Suppliers] 2. in the table Suppliers a link via to Lookup Main to [Products]

The problem here is obvious. If for some reason a user only performs one of the two steps, a data inconsistency has been created. The same problem of course is the case for the opposite way, means the deletion of a relationship. By introduction of a third main table which has the solely purpose to store the linkages between the product table record and the supplier table record, this problem can be solved. This is outlined in the following chapter.

March 2009

22


3.2.1

En h a n c e D a t a St r u c t u r e

A mapping table is used to represent a bidirectional link. The relationship table consists of three fields, which will be explained in detail below. New introduced table Relationship Products Supplier:

The field “Relationship id” is necessary for a couple of reasons: 1. It’s the only field in the table whose type allows to act as a Display field. The field types of the other two fields in the table don’t allow them to act as a Display field (this may be possible in future versions) 2. The relationship id is used for matching in the Import Manager 3. It’s possible to define the field as “Unique” 4. This field is used in the Data Manager to define relationships

March 2009

23


The field “Supplier” refers to the main table “Supplier”. The field is defined as single-valued. This way we can make sure that the “Relationship Products Supplier” table doesn’t need to have more records than there are suppliers in the system.

The field “Product” refers to the main table “Products”. The strategy is that a supplier can supply more than one part to a company, so we define this field as multi-valued.

March 2009

24


Theoretically it would have been possible to define both the fields “Supplier” and “Product” as singlevalued. As a consequence each relationship between a supplier and a single product would result in one record. Assume there would be X amount of records in table “Supplier” and Y amount of records in table “Products”. In the theoretical case, each supplier would supply all products in the repository, the number of records in the relationship table would be X*Y records, means then relationship table would have way more records then the other main tables, which would results in a negative performance impact.

3.2.2

I m p o r t i n g Re c o r d s i n t o t h e “ R e l a t i o n s h i p Pr o d u c t s Su p p l i e r ” T a b l e

The import procedure is described here under the assumption that the Supplier and Products main tables are already populated.

We import the following relationship information Product

Supplier

60-100F

1000

100-300

1000

100-300

2000

60-200F

2000

100-300 MV

2000 MV

100-300

2000 MV

In the MDM Import Manager, we create a clone of the Supplier field.

March 2009

25


And perform the following mappings Source field

Destination field

Product

Product

Supplier

Supplier

Supplier

Relationship Id

The cloned field “Supplier ” acts as the relationship id, however theoretically we could have also used an “abstract” id, means the id could be any number to represent the relationship. We used the cloned field here just for the purpose of simplicity. The field Supplier is a unique field, so its values can be used perfectly for matching so we map it to the field Relationship Id. The matching is performed on the field Relationship Id. It’s the only field which can be used for matching.

3.2.3

P e r f o r m i n g S e a r c h e s i n M DM Da t a M a n a g e r

After a successful import you can switch to the MDM Data Manager and perform searches to answer questions like •

Which products are provided by supplier 2000

•

Which are the suppliers for product 100-300

March 2009

26


There you select the “Relationship Products Supplier” main table and perform a free-form search

Avoiding redundant Data Entry: There are a couple actions necessary to avoid redundancy not only during import but also when entering values in the system. 1. The field Relationship Id is defined as unique. Since the relationship Id is a copy of the supplier number (this can be ensured during the import or during an assignment always performed during record maintenance) we can avoid that under normal circumstances several records for the same supplier are created. 2. In addition we introduce a validation which checks during saving a record whether the field Relationship Id is populated. The validation triggers an error when the field is empty Both above actions should under normal circumstances (means end users don’t make errors on purpose) be sufficient to avoid redundancies.

Manual Record Maintenance: Deletion of relationships and adding of new relationships can be done without any problems

Data Volumes and alternative Modeling Approaches: Another approach from a Data Modeling perspective would be to have both fields “supplier” and “product” defined as single-valued. This would mean that each supplier-product combination would be an own record in the relationship table. Example

Supplier 1000 delivers products 60-100F, 100-100 and 100-300 => 3 records in the table

Assuming in the main table suppliers there would be X amount of records and in the main table products Y amount of records, in the worst case the relationship table could end up having X*Y amount of records. This is a theoretical case, but during design of the relationship table volumes should be taken into consideration.

March 2009

27


3 .3

Re c u r s i v e l y l i n k M a i n T a b l e Ob j e c t s

Main table objects can recursively reference themselves. In the following example, Employees will reference employees to implement an employee – manager relationship.

Use case 4: Recursively link main table objects

Now the Employee should be linked to a manager. Therefore create a lookup main field in the employee main table pointing recursively to the main table.

3.3.1

March 2009

Cr e a t e L o o k u p [ M a i n ]

28


3.3.2

I m p o r t Re l a t i o n s h i p F i l e

Example:

The values shown in the field “Manager” are the display fields of the main table:

Note

Currently it is not possible to syndicate self-referencing lookup [main] field. This field does not appear in the syndicator. A short term solution would be the following: •

•

March 2009

Create a Calculated Text field which will contain the field from the lookup [main] field that you want to syndicate. In the Syndicator, map the calculated field to the destination Item.

29


Note

The Import Manager currently does not support both importing and creating references to records in the same import file.

3 .4

A d d i t i o n a l I n fo r m a t i o n

When defining your data model, please consider that at the moment lookup [main] fields:

•

can not be defined as qualifier fields of a qualified lookup table or as fields of a lookup table

March 2009

30


•

can not be defined as display fields

•

Matching will not/ partly be supported on lookup [main] fields

For lookup [main] fields that are single-valued however it is supported.

For lookup [main] fields that are multi-valued, you will not get a match for 

Bosch <--> Boss; Bosch



Boss <--> Boss; Bosch



Bosch; Boss <--> Boss; Bosch

This is the same behavior as for lookup [flat] fields for example.

March 2009

31


For lookup [main] fields that are multi-valued, you should get a match for 

Boss; Bosch <--> Boss; Bosch

Hence, you will notice, that the order of the values is important!

Token Equal is not supported for lookup [main].

•

Reverse navigation or search across lookup [main] is not supported (e.g. If “Material” has a lookup [main] into Supplier (“Material”->Supplier), you can find and view all Suppliers for a Product (forward navigation) but cannot find Products for a Supplier (reverse navigation)

•

Lookup [main] fields will not be supported by Publisher

•

The Data Manager’s export and import capabilities will not support data contained in lookup [main] fields

•

Archive by mask will not be supported

March 2009

32


4.

Re p l a c i n g Re l a t i o n s h i p T ab l e w i t h N e w Da t a St r u c t u r e s i n S A P N W M DM 7 . 1

Use case 5: Handling of a simple BOM in MDM. Already with SAP NetWeaver MDM 5.5 it was possible to handle simple Bills of Materials (BOM’s) by using relationship tables. However, using this approach there were numerous limitations such as no search capabilities, and a fixed set of fields. With SAP NetWeaver MDM 7.1, it’s possible to model simple BOM’s and take in addition advantage of the known MDM search capabilities and as well the fact that BOM relevant fields can be enhanced. In SAP NetWeaver MDM 5.5, a BOM was modeled by using relationship tables. While the main table was in charge of the material records, a Parent/Child relationship could be utilized to model a BOM. The Parent element represented the BOM header or header material, while the children elements represent the different BOM elements.

4 .1

En h a n c e D a t a S t r u c t u r e

In SAP NetWeaver MDM 7.1, the following approach to model BOMs is recommended. •

One main table containing the different materials

•

One main table containing the BOM Header

•

One tuple linked to the table BOM Header containing all BOM item information

This could be done via the following structure: Using one main table for the materials itself:

March 2009

33


Besides the normal material fields remember also the field “Children(For Migration)”. This field is only temporary introduced and can be deleted after a successful migration. We’ll explain its purpose at a later point in time. Using one main table for the BOM-Header information:

In the BOM Header table there’s one field “BOM_STRUCTURE” which contains the different BOM elements. It is of type multi-valued so that it can hold numerous materials.

The tuple BOM-STRUCTURE holds all relevant information regarding a BOM item and is defined as follows.

4 .2

Pe r f o r m i n g t h e M i g r a t i o n

The steps explained below need to be performed in case you don’t want to import your BOM data again from a Client system. Instead you simply migrate the data from the relationship tables into the separate main table. The migration consists of four steps. These are 1. Determining the Child elements for each material in the Materials table 2. Syndicating the Child info from the Materials table 3. Importing the previously syndicated Child Info in the BOM Header table 4. Verification of your work in the MDM Data Manager

March 2009

34


4.2.1

De t e r m i n i n g t h e C h il d r e n El e m e n t s f o r e a c h M a t e r i a l i n the Mat erials Table

Before we explain the step in detail, we first have a look at a sample record in our materials main Table. We can see that the record with the item number “011” has a BOM related to it containing two elements (represented via the relationship), Item numbers “010” and “008”.

The challenge here is to bring this relationship information out of the relationship table (relationship tables can’t be syndicated) and into the BOM Header main table. We need to perform an intermediate step – via an assignment we’ll bring the relationship information into the materials main Table (remember we introduced for the main Table a temporary field named “Children(ForMigration)”). This field will be populated via an assignment. The assignment formula can be seen in the next screenshot.

March 2009

35


The assignment formula determines all Children elements of the parent and writes them into the field. During field definition you’ve to make sure that the field is long enough to cover the whole length of the assignment results, especially when your BOMs contain a very large item list. After successful performing the assignment, your record looks like in the following screenshot. The field “Children(ForMigration)” contains now the linkages to the Children separated by semicolon.

4.2.2

Sy n d i c a t i n g t h e C h il d I n f o f r o m t h e M a t e r i a l s T a b l e

In the MDM Syndicator we perform a simple syndication, see the mapping below

and the sample output. We only would like to syndicate the records which have the field “ChildrenForMigration” populated. Therefore we added additional selection criteria to check whether the respective field is NULL or not.

March 2009

36


In the next step, the now syndicated file will be imported into the same repository. Before you start the Import, it’s required to perform a transformation on the generated XML-File. The tag contains several BOM-Items all separated by a “;” character. Best is to apply here an XSLT-Transformation to split these lines into several lines, each containing only one BOM-Item entry.

4.2.3

Import ing the previously syndicated Child Info in the BOM Header Tabl e

Our main table “Materials” is already in perfect shape since this one was the table which already existed in SAP NetWeaver MDM 5.5. We only have to populate the “BOM Header” table, which we’ll do now. For demo purposes we perform here only a minimum mapping.

In Detail the following operations have been performed: •

Field Children has been cloned

•

Field Children has been mapped to BOM_STRUCTURE->Item Number

•

•

Field Children has been mapped to BOM_STRUCTURE->Item ID. The field BOM_STRUCTURE->Item ID has been introduced just for the purpose to have a meaningful display-field (Remember a lookup[main] field can’t act as a display field, otherwise BOM_STRUCTURE->Item Number might have been chosen Field Item_ID has been mapped to BOM Header

March 2009

37


4 .3

V e r i f i c a t i o n o f y o u r Wo r k i n t h e M DM Da t a Manager

After successful import, switch to the MDM Data Manager and select the main table “BOM Header”. There you can see the previously imported records. When looking at our tuple field “BOM_STRUCTURE” you can see that it contains two records referring to the main table with the Materials.

March 2009

38


It’s also now possible to search for BOM’s containing a certain Material. This can be done via the free form search, in this case we’re searching for all BOM’s containing the Item ID P-100.

After having performed the successful import of the BOM information, the fields which are not anymore necessary in the repository, can be deleted. Furthermore, we can add now additional fields (if not yet already done) into the BOM Header main table in order to define the relationships better.

To consider when using this solution: There’s currently no comfortable functionality in MDM to perform a BOM-explosion, so applying this concept to complex multilevel BOMs is not feasible due to the missing explosion functionality. It would only be possible to explode from one level to the underlying level and from there again to the underlying level and so on. In addition as of now time dependency for BOM’s and versioning isn’t yet supported. Also in case you would like to use this functionality in the portal, consider, that with the current SP of MDM 7.1, tuples can’t be displayed in a portal iView.

March 2009

39


4 .4

Wh e n d o e s i t m a k e Se n s e t o r e p l a c e a Re l a t i o n s h i p De f i n i t i o n b y T u p l e s ?

1) A relationship is of type Parent-Child. Only for Parent-Child relationships it’s possible to guarantee that your data are free of redundancies. As soon as relationships are bidirectional (sibling) redundancies are possible. Bidirectional relationships require that the relationship is maintained two times, going from record 1 to record 2 and back into the opposite direction. If users make here a mistake e.g. by only maintaining a relationship in one direction instead of both directions, data consistency issues could come up. Neither multiple main tables nor tuples have any functionality in place to maintain both directions of a relationship in one step and thus avoid data consistency problems.

2) Additional fields are needed to describe a relationship Using relationship tables in a repository comes with the fact, that there’s no possibility to add additional fields to the relationship definition, the structure of the relationship table is fixed and can’t be enhanced. Replacing the relationship table with a tuple structure provides the flexibility to add additional fields (e.g. whether a single BOM- item is an assembly) into the relationship.

3) Several different relationships are having the same structure. Since tuple definitions can be reused, it would be possible to have one tuple definition describing the fields of the relationship and reference to this tuple definition several times, each under a different relationship type name.

March 2009

40


4 .5

Wh e n d o e s i t m a k e n o Se n s e t o r e p l ac e a Re l a t i o n s h i p De f i n i t i o n b y T u p l e s ?

Sibling Relationships Reasons why this is not recommended and shouldn’t be done: •

Data Consistency issue 1 – dual maintenance of sibling relationships In case you would like to model a symmetric relationship by using tuples, you have to consider that you would have to maintain the relationship two times, one time from the direction of sibling1 and one time from the direction of sibling2. In the Data Manager there’s no possibility to ensure this, so this could lead to Data consistency problems. If you’re using a custom UI you would have to make sure via application logic, that the data are consistent. It’s planned to provide this functionality in one of the future MDM releases.

•

Data Consistency issue 2 – a record has several siblings

Consider the nature of sibling relationships. If record A is sibling to record B and record B is sibling to record C then automatically record A is also sibling to record C. While the pre-delivered relationship tables are able to handle the addition of a new sibling to an already existing sibling relationship (all three records would have now two sibling relationships), an approach with a second main table wouldn’t be able to handle this out of the box. It would be in the users responsibility to ensure here data consistency, a task which would be very challenging with growing repository size. The same of course would be also valid for the deletion of a relationship. Numerous records would be affected and needed to be maintained.

March 2009

41


5.

M i g r at i n g f r o m Qu a l i f i ed L o o k u p T a b l e t o Tuple

5 .1

Wh y s h o u l d I u s e T u p l e s ?

Tuples generalize the concept of other specialized MDM structures, especially of qualified lookup tables. For more details about MDM tuples, please refer to the MDM tuples chapter within the MDM 7.1 Console Reference Guide, available on SAP Service Marketplace at http://service.sap.com/installmdm71. There you can also find information about features and benefits of MDM tuples in general, and especially when it comes to replacing qualified lookup tables. In the following, we list pros and cons of using tuples as fully qualified references compared to qualified lookup tables:

Pros •

Since a tuple is rather a record template than a table itself, you can reuse the same within different tuple fields.

•

New, more flexible design possibilities like deeply nested structure.

•

Enhanced matching and merging functionality like merging of tuple records, see below.

Cons •

•

Right now, tuples can either be maintained in MDM Data Manager or via API, however they are not supported via Web Services and Portal iViews (support to be planned with SAP NetWeaver MDM 7.1 SP02). Not all field types are supported, see also table of supported field types in tuples definitions within MDM 7.1 Console Reference Guide. 



•

The following fields are not supported by tuples, however supported by qualified lookup tables: 

Create Stamp, Time Stamp, User Stamp



Currency



Text Normalized



Calculated Field

The following fields are not supported by qualified lookup tables, however supported by tuples: 

Text Large



Lookup main



Tuple

Change History for tuples is supported only partly (changes for tuple itself is written, however reference between tuple and main record is missing). Full support is planned with SAP NetWeaver MDM 7.1 SP02.

March 2009

42


5 .2

How do I migrate?

Step by step There is as of now no automatism, you have to redesign and create the new MDM tuple from scratch. In general, the process looks as follows: •

Create tuple definition, and tuple fields in MDM Console.

•

Create syndication map in MDM Syndicator, and syndicate data of qualified lookup table.

•

Create import map in MDM Import Manager, and import the beforehand syndicated data into tuple records, see also below. Note

Before migrating from qualified lookup tables to tuples, check if current limitations of tuples do not jeopardize your requirements, see also limitations above.

Sample: Manufacturer Part Number (MPN) in standard Products repository Manufacturer Part Number field in standard Products repository refers to qualified lookup table Manufacturers. For each product record in the main table, you can store additional manufacturerspecific information for multiple manufacturers. For different manufacturers, you can store qualifiers like MPN, country of manufacture, manufacturer serial number, etc. The schema of the Manufacturers table is shown in figure below.

In figure below, you see the corresponding tuple that has been created. Most of the fields can be adopted from the qualified lookup table except for Create Date and Manufacturer [CALC] which are both not supported in tuples.

March 2009

43


The address related fields like Street, Postal Code, City, and Country have been designed differently compared to the qualified lookup table. Here, we refer to an additional tuple that keeps the address data. By doing so, we are able to reuse data structures. Furthermore, multiple addresses can be maintained.

The Address tuple is defined as follows:

March 2009

44


5 .3

Qu a l i f i e d L o o k u p T a b l e v e r s u s T u p l e

In the following, the characteristics of qualified lookup tables and tuples are examined for different tasks that you can carry out in MDM like import, syndication, matching, etc. For each of those tasks, different behavior is outlined.

5.3.1

I m p o r t a n d Sy n d i c a t i o n

Update option during Import For qualified lookup tables, you have the option either to append, to replace, or to update the qualified links of a qualified lookup field, see figure below.

March 2009

45


The tuple update options for new and existing records can be maintained separately. You can either create or skip new records whereas for existing records you have the options to skip, update, replace, or delete the same. In the figure below, you see the global configuration settings. However, you can define those settings individually for each tuple. So, when having nested structures, the update settings for a superior tuple can influence the behavior of a child tuple.

For more details about the update options, please refer to the MDM 7.1 Import Manager Reference Guide, available on SAP Service Marketplace http://service.sap.com/installmdm71. For more details about how to map tuples in a syndication map, please refer to the MDM 7.1 Syndicator Reference Guide, available on SAP Service Marketplace http://service.sap.com/installmdm71.

5.3.2

Validation and Assignment

You can use tuple fields and qualified lookup table fields in both, validations and assignments, however they can not be written by an assignment.

Validating Tuple records versus Validating Tuple fields Qualified lookup table fields can be used within validations for a main table. Since tuples can be reused within multiple record fields, the validation scope has been enhanced. Validations using tuple records or tuple member fields can be defined either for a main table or for a tuple itself. Latter is called Tuple Validation . A validation on a tuple runs for all instances of a tuple, i.e., for all fields which references the same tuple. If you like to run the validation for one tuple field only or you need to run a validation comparing two fields that references the same tuple, you need to define a validation for the main table. For a validation on the main table, the record itself ([record]) and all tuple member fields are supported for single-valued tuple fields only. For performance reasons, a validation on a multi-valued tuple field

March 2009

46


can use the record only. This limitation does not apply to tuple validations, i.e., all tuple member fields can be used within the validation regardless of being single-valued or multi-valued. Example

Assuming you have two different address fields in your main table which refer to the same Address tuple, namely ship-to address and bill-to address. It is required that both fields are filled, so you have to run a validation to check the same. Here, you would define a tuple validation. Whenever you run the tuple validation, it will check both address fields at the same time. Furthermore, shipments into foreign countries will be handled differently to domestic shipments, so the respective validation should run on the ship-to address only. Here, you would need a validation on the main table.

Note

The same restrictions as described above apply to assignments, i.e., only the record of multi-valued tuple fields can be used in assignments whereas all member fields can only be used for single-valued tuple fields.

Note

A callable tuple validation can only be called from within another tuple validation. It can not be called from within a validation.

To create a validation on a tuple, select Records → Validations → Tuple Validations from the menu in MDM Data Manager:

March 2009

47


Choose the tuple:

Create the validation expression. As stated above, all member fields can be used:

To create a validation on the main table, switch to Validation tab in MDM Data Manager. As stated above, for multi-valued tuple fields only the record is supported:

March 2009

48


For single-valued tuple fields both are supported, record and member fields:

For more details about validations for tuples, please refer to the MDM 7.1 Data Manager Reference Guide, available on SAP Service Marketplace http://service.sap.com/installmdm71.

Validation behavior

CAUTION

The validation for multi-valued tuple fields and qualified lookup table fields might behave differently, see example below. Please test all your validations after having migrated.

Example

In the example above, we check if the qualifier Manufacturer Part Number is filled using the function IS NOT NULL in the validation expression. For the qualified lookup table field, the validation result is TRUE if at least one record is not null, it is FALSE only if all records are empty. For the tuple field, the validation result is TRUE only if all entries are not null, it is FALSE if at least one entry is empty.

Validation failure Assuming, you created a validation using a multi-value field either based on a tuple record or a qualified lookup table. In case of a validation failure, you won‘t see which tuple record or qualified table record caused the error. Furthermore, for tuple fields where the same tuple is used multiple times, you won‘t see which tuple field caused the error.

March 2009

49


5.3.3

M a t c h i n g a n d Me r g i n g

Qualified lookup table fields and tuple fields can be used in transformations, rules, and strategies. Matching rules defined on multi-valued fields behave the same. The order of the multiple records does not affect the matching result. If at least one record is equal, it results in full score. When merging records, qualified lookup table fields and tuple fields support functions set, append, copy, and paste. Those functions only allow you to choose all entries of the qualified lookup table or tuple field of a main table record. Besides this, tuple fields support to select only specific entries to be merged. This can be done using functions Set Values and Append Values .

A pop-up comes up where you can explicitly select which tuple records should be include in the merged record.

March 2009

50


Furthermore, other than for the qualified lookup table, you can merge tuple records. Choose Merge Values in the context menu:

Select the tuple records which should be merged:

March 2009

51


Select which values should be added to the merged tuple record:

5.3.4

Workflow

You can define a workflow on top of a qualified lookup table, however you can not define a workflow on top of a tuple since this is considered to be a reusable template. A tuple validation can not be called from within a workflow. This means that validations on multi-valued tuples which uses tuple member fields can not be used within workflows, see also above.

March 2009

52

Best Practices for Repository Migration From SAP Netweaver MDM 5.5 to SAP NetWeaver MDM 7.1

Recommend Documents