Problems with your Data Model in SAP NetWeaver MDM Do s and Don ts

Transcription

1 How-to Guide SAP NetWeaver 7.0 (2004s) How to Avoid Problems with your Data Model in SAP NetWeaver MDM Do s and Don ts Version 1.00 May 2007 Applicable Releases: SAP NetWeaver 2004 SAP NetWeaver 7.0 (2004s) Data Unification Master Data Management

2 Copyright 2004 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, and Informix are trademarks or registered trademarks of IBM Corporation 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 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, 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.

3 1 (Business) Scenario Introduction Things to consider Performance considerations Concrete suggestions (do s and don t do s) Overhead reduction Languages Unnecessary fields and tables Only store what really belongs there Use with caution! Key mapping Sorted Fields, Display fields Keyword search Calculated Fields Change tracking Lookup tables Keep the number of records and fields limited Qualified Lookup tables Keep the number of records limited and choose the right Non-Qualifiers Validate and reviewing the Data Model...8

4 1 (Business) Scenario A company is tasked with implementing SAP NetWeaver Master Data Management. During the discussions it was decided to implement the master data harmonization scenario with connectivity to several SAP systems and several legacy systems. The first project should deal with material master data used across all systems. At a later point in time, the company would like to implement also customer records to be centrally maintained on the MDM server. This document explains how to avoid mistakes when defining a repository on the basis of: Recommendations from SAP development Experiences from consultants and customers during repository design 2 Introduction As soon as a customer decides not to use the standard repositories delivered by SAP, there is a need to either enhance existing repositories, or to create a repository completely from scratch. Since there is no functionality in the MDM Console that checks a repository for potential performance problems, a system administrator has all the freedom in the definition of a repository, which could lead later on to performance problems. Many times these problems are discovered at a very late stage of an implementation, often when it comes to loading large bulk of data into the system or syndicating these data back to other systems, just to name a few situations. This guide lists general guidelines for designing MDM repositories, in order to optimize system performance. There are no hard rules which should be applied by the design of a new repository, and good judgment is involved mostly in every step of designing. This good judgment increases with the experience in design. A well designed repository should have these features: 1. Contains a limited number of tables and fields 2. Is easy to navigate in the MDM Data Manager 3. Performs well during search & maintenance of records 4. Shows good performance during Import load & syndication 5. Is free of workarounds 6. Has the data in the right context Given the concrete business case/process it is often not possible to meet all of above criteria, so they should act here as the ideal situation

5 3 Things to consider These rules are not exclusive, and, it depends a lot on the specific business case whether they can or should be applied or not. So the following list of recommendations should be considered rather as a note about potential consequences when doing certain things. 3.1 Performance considerations By design, access to tables and fields in MDM is optimized for the main table, which leads automatically to performance implications when other tables like lookup tables or qualified lookup tables contain large numbers of records. Repositories should always be designed in a way that the majority of records is kept in the main table with the sub tables containing only a minor part of the records in the repository. If a repository shows a different distribution of records, then this might be an indicator that the main table object should be different from the one chosen or that other errors have been made during the design. A lookup table or subtable is usually used to define the set of legal values to which a corresponding lookup field in the main table can be assigned; these tables hold the lookup information. For example, the main table of an MDM repository of product information may include a field called Manufacturer; the actual list of allowed manufacturer names would be contained in a subtable. Only values that exist in records of the subtable can be assigned to the value of the corresponding lookup field in the main table

6 4 Concrete Suggestions (Do s and Don ts) 4.1 Overhead reduction Languages Repositories preconfigured by SAP are designed to support numerous languages. These languages add overhead to the system, so it is recommended to delete all unnecessary languages and remember that a language can always be added to a repository at a later point in time. Also for completely new designed repositories only the required languages should be activated Unnecessary fields and tables The same is true for unnecessary tables and fields. During creation of a repository a couple of tables e.g. the Categories table is created automatically by the system some are linked to the main table and some not, e.g. the PDFs table. Standard repositories provided by SAP might also contain fields which are not required for your business process. Remove all of these they can always be added later if necessary Only store what really belongs there This recommendation may seem obvious, but the following example explains what is meant here. If you design a repository for customer data, then usually also address information is stored in this repository. If you would like to validate this address information, then this is normally done by calling some kind of address validation routine. The comparison data, which is the basis for the address validation routines should be stored not in MDM it simply would bust the repository structure to store all ZIPcodes, cities, streets, street numbers of the entire country in repository sub tables just for the purpose of a comparison. The right solution here would be either to call an address validation tool, or in case you use a homegrown address validation, to store the data outside MDM, either in normal DB tables or in a second repository. From MDM you could access these data using your own UI having access to the MDM repository data and having access as well to the address validation pool data

7 4.2 Use with Caution Key mapping Key mapping is used to map objects of a remote system to master data objects within MDM. A key added to a record is written into the database and during syndication also read from the database, not from the memory. Especially the reading from the database might cause potential performance impacts during syndication. Therefore the use of key mapping should be evaluated carefully. In addition key mapping should only be used to represent the keys of local instances in the context of a global instance for semantically identical master data objects in the system landscape. For instance, do not use it to reflect any kind of history for an object! Sorted fields, display fields MDM spends extra memory and processing time to maintain sort indices. Indexing can take a lot of time during repository load. Having larger repositories with numerous sorted fields can have a dramatic impact on the system performance, especially when it comes to importing and updating records. The fewer sort fields you use, the better. A display field for a table is a field whose value is used as: (1) The corresponding lookup field value for each record; (2) The node name for the record in hierarchy trees; and (3) The name of the record in the Product Relationships popup window. When a table has multiple display fields, the value that is used for each record is the value combination among the display fields, with each pair of values separated by a comma (,). Display fields are used to create a non technical key for the main object and the subobjects and to determine the fields shown to the user in case of a look up relation. Carefully evaluate what field to use as a display field. The combination of the display fields within a record should be a unique key in the system. The usage of display fields should be handled like the unique fields definition. The UI clients cache all display fields of non-main table records. More display fields require more memory Keyword search Fields enabled for keyword search might impact system performance during load, maintenance and import of records. Fields enabled for keyword search add memory overhead to the system so try to use it only where absolutely necessary. When you consider activating keyword search for a field, consider whether the set of unique words for all records in the field is fewer, or relatively fewer to the total number of records. Fields with unique fields setting should not have keyword search setting enabled - 4 -

8 since this setting adds memory load to the MDM Server without adding any benefit and costs only performance. Same is valid for display fields of a lookup table here as well keyword search does not add any value. Examples: A description field is an example of a field you want to keyword; even though the total number of words for all records will be large, the number of distinct words will be small because they are most likely all words from the dictionary. A part number field is an example of a field you should not keyword because it is likely to contain a different value for every record. Try to eliminate keyword search for fields where it is not necessary and do not use keyword index on unique fields. Consider also using free form search instead of enabling fields for keyword search Calculated fields Calculated fields are getting calculated each time, when a repository is getting loaded. The only exception here is, when a field has the setting Writeable Once, but this might occur rather seldom. The less calculated fields a repository has, the lower the CPU consumption during repository load. Also the complexity of a calculation formula makes a difference. While a simple calculation consumes nearly the same CPU time than a normal field, complex formulas can cost a lot of CPU time Change tracking The Change Tracking table tells the Master Data Server (MDS) which data modifications to track. Each entry set to Yes will cause the MDS to write one or more rows written to the history table in the DBMS depending on the operation. Set the entries to No when tracking is not needed. Examples: Setting a field such as the Products->Name field to Yes will cause one row to be written when a record is added or deleted or when that particular field is modified. Setting x # of fields in a table to Yes will cause x # of rows to be written to track the change when it is added, deleted or modified Moreover, if you have marked the Taxonomy lookup as Delete = Yes, for each linked attribute a record will be written to the Change Tracking table

9 4.3 Lookup Tables Keep the Number of Records and Fields Limited By definition, a lookup table is used to store values that are shared by many records in other tables, and also to act as a valid table that defines the set of legal values of the corresponding lookup field for data entry and search. Typical examples for lookup tables are Plant in the Material repository or Partner Type in the Business Partner repository. These examples make pretty clear that a lookup table should have a limited number of records. A lookup table should never be used to store hundreds of thousands of records. Taking into account what has been said in the beginning of this guide, A well designed repository should be easy to navigate in the MDM Data Manager, it is clear, that this goal can hardly be met when lookup tables have large numbers of records. Selecting a single value from a long list in a dropdown makes navigation clumsy. Therefore storing limited number of values in lookups makes navigation easy and performance better. The number of fields in a lookup table should be a concern too, since too many fields could make the navigation through records using the MDM Data Manager difficult. Therefore, as a best practice ensure that the number of fields in lookup tables is limited

10 4.4 Qualified Lookup Tables Keep the Number of Records Limited and Choose the Right Non-Qualifiers A qualified table in MDM stores a set of lookup records, and also supports qualifiers that apply not to the qualified table record by itself, but rather to each association of a qualified table record with a main table record. The limiting element in the usage of qualified lookup tables is the set of lookup records (this is what is considered the non-qualifier part), not the qualifier fields. Here the same principle as for the normal lookup tables can be applied the overall number of lookup records should be limited. In the repository definition an administrator can influence the number of lookup records by choosing the right fields as non-qualifiers (assuming it s in alignment with the overall business process). Try not to choose e.g. date fields, time fields as non qualifier fields. Example 1 for choosing non-qualifiers and qualifiers: Here we have quality management settings for materials. Settings (Inspection Percentage and Max Inspection Time) are determined by the plant and the inspection type. Material Plant Inspection Inspection Max Inspection Time type percentage 1001 Berlin Goods Receipt 2 24 h 1001 Berlin Production 10 2 h 1001 Munich Shipping 1 6 h 1001 Munich Goods Receipt 2 72 h 2001 Chicago Goods Receipt h The qualified table associated to this qualified lookup field will have two fields, Plant and Inspection-Type, as non-qualifiers and the Inspection Percentage and Max Inspection Time as qualifiers. The different plants and inspection type combinations are clearly limited in their numbers. Choosing in addition Max Inspection Time as a Non Qualifier would increase the number of records in the Lookup table dramatically besides the fact, that from a logical/process point of view it should not be defined as a non-qualifier

11 QM Settings: Non Qualifying fields Plant - Inspection type Qualified field Inspection percentage Qualified field Max Inspection Time Berlin - Goods Receipt 2 24h Berlin - Production 10 2h Munich - Shipping 1 6h Munich - Goods Receipt 2 12h Chicago - Goods Receipt 1 0.5h Based on this design, the structure of the catalog concerning the quantity based pricing looks as shown below: Material Lookup[QM Settings] 1001 Berlin - Goods Receipt; 2;24h Berlin - Production; 10;2h Munich - Shipping; 1;6h Munich - Goods Receipt; 2;72h 1002 Chicago - Goods Receipt; 1;0.5h 4.5 Validate and Review the Data Model For the validation of a data model you should consider the characteristics of a well designed repository explained in the introductory section. Besides reviewing the repository structure, which is also provided as a service by SAP, you should depending on your IT/business scenario also try to perform operations on the repository, e.g. manually create/update records as well as importing and syndicating records. Especially navigating through the repository gives you a pretty good feeling about the design. In some cases you may have several design approaches and the navigation in the MDM Data Manager could give a hint, which one is the better approach. Normally the easier a repository can be navigated the better. Perform maintenance and search operations for several records and see whether o The repository does what you originally wanted to do o Operations on the data can be performed easily or not o It takes long to create/update/search for records o The data is consistent Importing and syndication operations give you a first impression of how the repository will perform. Loading a repository with a limited number of records with the update indices option also gives you a pretty good indicator whether the repository design is good

12