This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: September 2011
Production Reference: 1070911
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-849682-14-5 www.packtpub.com
Project Coordinator Leena Purkait Proofreader Linda Morris
Patrick Rayes Swarnadeepika Subramanian Sebastian Tinnirello
Indexers Tejal Daruwale Hemangini Bari
Acquisition Editor Dhwani Devater
Graphics Geetanjali Sawant
Development Editor Hyacintha D'Souza Technical Editors Sakina Kaydawala
Nilesh Mohite Valentina D'silva Production Coordinator Melwyn D'Sa
Shreerang Deshpande Aditi Suvarna
Cover Work Melwyn D'Sa
About the Author Uday Rao is an Engineering graduate with a Bachelors of Engineering Degree in
Information Technology from PESIT college, Visvesvaraya Technological University. He started his career as a Java programmer and soon started writing Enterprise Java Beans for the SAP MDM Enrichment Adapter. He is a certified SAP NetWeaver MDM 5.5 Technology Consultant and is also certified in SAP ABAP with over four years of work experience in the IT industry including over three years work experience on SAP NetWeaver MDM. Apart from the MDM core implementations, he has also worked on creating SAP NetWeaver MDM Enrichment adapters, incorporating MDM Java APIs, MDM ABAP APIs, developing SAP WebDynpro Java applications, and SAP MDM Portal integration. His experience on other SAP technologies include: working on SAP WebDynpro ABAP, creating and testing SAP ABAP programs for various support and development projects, performing product testing for SAP MDM 7.1 and SAP Master Data Governance. He has also published SAP SDN community network blog on the SAP MDM Enrichment Adapter titled SAP MDM Enrichment Adapter - more than just enrichment. Contact Uday Rao: E-mail: [email protected]
LinkedIn: http://www.linkedin.com/pub/uday-rao/7/9b5/9a Thank you Leena, Rebecca, Vincila, Dhwani, Hyacintha, Sakina, and all the folks from Packt Publishing for giving me the opportunity to author this book. Finally and most importantly, I would like to thank my parents Poonam and Vittal, my brother Prateek, and my wife Deepika for their continuous support and encouragement to author this book.
About the Reviewers Ankur R Goel is a SAP AG Certified MDM freelancer Consultant. He has worked
with some of the greatest SAP consulting organizations like IBM, Satyam, and also SAP itself on various Implementations, Scoping exercises, Strategy studies, pre-sales and Enhancement co-ordinations in SAP-MDM, SAP-BW, SAP-ABAP in various roles of Team member, Consultant, Coordinator, and Team Lead to Solution Architect, and handled multiple projects simultaneously. He has authored more than 20 blogs and 20 whitepapers in SAP MDM, BI and has been a lead contributor in SDN forums. He is also authoring a book. Ankur has many awards and customer appreciations to his credit. He can be found on http://in.linkedin.com/in/ ankurrgoel.
Patrick Rayes is a Senior Project Manager and Solution Architect with a proven 10-year track record in successful global and large-scale ERP and e-Commerce implementations. Specialized in SAP and Microsoft business solutions, and accredited with industry-recognized certifications and formal educational background in software architecture and design, he has worked on numerous midto-large scale projects of up to 50 resources and budgets of well over $15 million. Combined with his global experience of working in countries such as the US, Canada, and Europe, he carries enterprise-class experience from companies such as FootLocker, IATA, Nestle, IBM, and the New York Times. I would like to personally thank the amazing team at Packt Publishing for providing the valuable resources I needed to review this book, including the author who worked tirelessly towards delivering a quality guide. Also to my wife and parents, who have supported my ambitions and career. Lastly, to my dog who for many nights has patiently waited for me during late night working hours eager for her next walk.
Swarnadeepika Subramanian completed her Bachelor of Technology Degree
from Anna University in 2005. She joined Cognizant the same year and started her career as a SAP Enterprise Portal consultant. Her expertise was eventually enhanced in SAP Master Data Management with experience on varied areas through numerous client engagements. She has to her credit many organization-wide MDM training sessions for entry-level trainees as well as experienced professionals. Thank you to my husband, who is also the author, for his support towards helping me spend time to review this book.
Sebastian Tinnirello is an IT Engineer working since 1993 on business-oriented IT projects. Over the last 10 years, the projects he was involved on have been in the Supply Chain Management (SCM) and E-Procurement areas and he has a demonstrated experience of implementing and managing full cycle SAP ERP MM, SRM, CCM, MDM-CAT, requisite projects in some twenty societies around the world. He has been fortunate in the last ten years to have worked for large multi-national companies such as Repsol-YPF and TOTAL (both from the Oil and Gas Sector), Endesa Group (Energy), and Tenaris (Steel Industry). His roles have varied between Project team member, Lead consultant, Project/Division manager, and currently CEO. Founder of his own company, called eProcure.AR (http://www.eprocure-ar.com), based on consulting services around SAP SRM, MDM-CAT, SAP ESourcing, and SAP CLM. In addition to attending the company's management aspects, he still works in several projects as expert Consultant, including implementations, Q&A, trainings, and so on. I would really like to thank my family and all my friends for supporting me during my entire career
www.PacktPub.com Support files, eBooks, discount offers and more You might want to visit www.PacktPub.com for support files and downloads related to your book. Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details. At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
http://PacktLib.PacktPub.com Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can access, read and search across Packt's entire library of books.
Why Subscribe? •
Fully searchable across every book published by Packt
•
Copy and paste, print and bookmark content
•
On demand and accessible via web browser
Free Access for Packt account holders If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view nine entirely free books. Simply use your login credentials for immediate access.
Instant Updates on New Packt Books Get notified! Find out when new books are published by following @PacktEnterprise on Twitter, or the Packt Enterprise Facebook page.
My efforts in this book are dedicated to my wife, my family, my colleagues, and my friends.
Table of Contents Preface Chapter 1: MDM Scenarios and Fundamentals Master Data Management Benefits of Master Data Management MDM scenarios IT scenarios Master Data Consolidation Master Data Harmonization Central Master Data Management
Business scenarios Rich Product-Content Management Global Data Synchronization Customer-Data Integration
MDM Server know how What is an MDM Server? MDM auxiliary servers
What is an MDM repository? What makes a database a master data repository? MDM repository structure Other key capabilities of an MDM repository
Summary
Chapter 2: Getting to Know the MDM Console Launching the MDM Console MDM Console Settings file Loading the MDM Console Settings file
Tables and Fields tab Status bar Configuration parameters MDM Console settings MDM server settings MDM auxiliary server settings Repository settings DBMS settings Keyboard shortcuts Summary
44 45 45 46 46 46 47 47 47 48
Chapter 3: Accessing the MDM System Accessing the MDM servers Mounting and unmounting an MDM server Starting and stopping an MDM server MDM repository properties DBMS server Repository port numbers Accessing the MDM repository Mounting and unmounting an MDM repository Connecting to and disconnecting from an MDM repository Loading and unloading an MDM repository Summary
Chapter 4: MDM Repository Maintenance
49 49 49 54 60 62 62 63 63 68 72 79
81
Working with MDM repositories Creating an MDM repository
81 82
Creating a default repository Creating a repository from an archive Repository creation options
82 89 94
Deleting an MDM repository Working with tables and fields Table properties Adding tables Editing tables
96 99 99 101 103
Display Fields Unique Fields
103 106
Deleting tables Field properties Adding fields Editing fields
109 110 114 117
Reordering fields
119
Deleting fields
121 [ ii ]
Table of Contents
Working with tuples Tuple properties Adding or deleting tuples Working with tuple member fields
123 123 124 126
Adding tuple member fields Deleting tuple member fields
126 128
Summary
130
Chapter 5: MDM Repository Administration Appropriating an MDM repository Updating an MDM repository Verifying an MDM repository Duplicating an MDM repository Maintaining a master/slave repository Benefits and limitations of master/slave concepts Master/slave landscape strategies Publication slave Master/slave repository in the Console Identifying master and slave repositories in the Console Creating a master and slave repository Synchronizing a slave repository Normalizing a slave repository
Broken master/slave repository Repository archive and unarchive Archiving Archive Options Unarchiving Publication model archive and unarchive MDM schema transportation Exporting schemas Importing schemas CTS+ Schema migration vs. CTS+ Summary
Chapter 7: Import Server Administration Master Data Import Server Difference between the MDIS and the Import Manager MDIS's Ports File types supported by the MDIS MDIS's support for text files MDIS's support for XML files Working with other XML types Virtual Extended Records Structural Transformation phase Value Transformation phase Import phase Using the MDIS Exception handling Structural Exceptions Value and Import Exceptions Block on Structural Exceptions The MDIS configuration Global MDIS parameters Repository specific MDIS.ini parameters Configuring the MDIS from the MDM Console Configuring optimal performance Troubleshooting Import files are not being processed by the MDIS Port has exceptions Source fields or values not being imported Source file is too large to open in the Import Manager Enabling tracing and audit trails in the Import log Summary
Chapter 8: Syndication Server Administration Master Data Syndication Server Difference between MDSS and the Syndicator MDSS Ports Automated Scheduled Manual
233 233 234 235 237 237 240
Using MDSS Monitoring MDSS activities MDSS configuration Global MDSS Parameters Repository specific MDSS parameters MDSS - Auxiliary Servers node in the MDM Console
Troubleshooting Problem 1: No syndications are executed Server and repository status Outbound port settings Map properties MDSS configuration errors
241 243 244 245 246 247
248 249 249 249 250 250
Problem 2: Syndications are not executed as per scheduled time Problem 3: Unchanged records are not suppressed Problem 4: Changed records are not syndicated Syndication tips Tip 1: Syndicating large files Tip 2: Avoid changes to master data during syndication Summary
Chapter 9: MDM System Administration MDM security: at a glance Managing MDM users, roles, and privileges Managing MDM users Managing MDM roles Functions tab Tables and Fields
250 251 251 251 252 252 253
255 255 258 259 260 262 264
Trusted connections Additional system tables Connections Change tracking Links XML schemas Summary
267 269 269 270 271 275 276
[]
Table of Contents
Chapter 10: Security
277
Users, roles, and authentication Password protecting the MDM servers Password protecting the MDM repositories Changing password on login Password expiration Avoiding weak passwords Minimal password length Deactivation due to inactivity Resetting the admin password Network and communication security SSL support for securing the communication channel MDM server configuration Authorization concepts and management Auditing Content security MDM file locations and file system security Summary
Chapter 11: MDM Integration Scenarios MDM BI integration Pre-requisites Integrating BI and MDM MDM XI/PI integration Communication Implementation Configuration of the Adapter Monitoring the MDM Adapter MDM Portal integration MDM Portal integration prerequisites Before working with SAP Enterprise Portal Integrating SAP NetWeaver MDM with Enterprise Portal Summary
Appendix: Getting Started with MDM MDM concept MDM functional components Key capabilities Setup and installation of MDM 7.1
Preface SAP Master Data Management (SAP MDM) enables information integrity across the business network, in a heterogeneous IT landscape. SAP MDM enables the sharing of harmonized master data, formerly trapped in multiple systems, and ensures cross system data consistency. This book will guide you through all the aspects of this software making it possible for you to get optimum output. This book is a step-by-step tutorial that shows you how to successfully administer SAP NetWeaver MDM 7.1. You will learn to plan and manage master data with SAP NetWeaver MDM. It will highlight the best practices and life cycle implementation using MDM and the concepts behind various aspects of SAP MDM administration.
What this book covers Chapter 1, MDM Scenarios and Fundamentals, covers the fundamentals of Master Data Management and discusses the various IT and Business scenarios that exist for an MDM implementation within an organization. You will also find discussion about repository structure, the various types of tables and some key capabilities supported by an MDM repository. Chapter 2, Getting to Know the MDM Console, discusses about saving the MDM server list to a console settings file and loading this file in three different ways. Later on, you will see how to analyze the MDM Console main window and understand its GUI comprising of panes and tabs. Finally, you will see brief discussion about various types of configuration settings available in MDM.
Preface
Chapter 3, Accessing the MDM System, you learn to mount and unmount the MDM Server in a step by step manner. Then you move on to starting and stopping the MDM server. You will understand the various properties of the MDM repository. Finally, you will learn the repository access operations which cover: mounting and unmounting, connecting and disconnecting, and loading and unloading an MDM repository. Chapter 4, MDM Repository Maintenance, you learn how to how to work with MDM repositories, fields and tables. There is also a separate section which explains about the addition and deletion of a new table/field type Tuple introduced with MDM 7. Chapter 5, MDM Repository Administration, teaches various commands operated on an MDM repository like Appropriate repository, Update repository, and Verify repository. In addition, this chapter also talks about methods to back-up a repository like duplicating a repository, Master/Slave concept, and repository Archive/ Unarchive. This chapter also discusses techniques that can be used to replicate a schema of a repository (without the data) like Exporting/Importing Schema and the Change Transport System (CTS+). Chapter 6, Server Administration, discusses the options available in configuring the settings of the MDM server, repositories, and the backend DBMS. Chapter 7, Import Server Administration, familiarizes the concepts and techniques used by the MDIS for efficiently importing large source data with exception handling capabilities. You will also learn common troubleshooting tips and tricks for resolving problems while importing data using the MDM Import Server. Chapter 8, Syndication Server Administration, covers the administration of the MDM Syndication Server. This chapter starts with the features of the MDM Syndication Server or the MDSS. Then we highlight the differences between the Syndicator and the MDSS. Next, we describe the procedure for utilizing the MDSS and monitoring its activities. Configuring the MDSS using the various standard and optional parameters is described next. The last section covers simple tips and tricks for troubleshooting the MDSS. Chapter 9, MDM System Administration, gives an overview of the security features available in MDM 7.1. Some administrative features and functions of some system tables are also explained in this chapter. Chapter 10, Security, discusses about the security features of SAP MDM 7.1. We will talk about the various aspects of security for accessing the MDM system keeping in mind the perspective of the end users, network, auditing, and the repository's content.
[]
Preface
Chapter 11, MDM Integration Scenarios, discusses about the MDM integration scenarios with these SAP offerings: BI, PI/XI, and the Enterprise Portal. Appendix, Getting Started with MDM, discusses the need for MDM and provides an overall understanding of its key capabilities.
What you need for this book You need to have the following servers installed in your system landscape. Servers: • • •
SAP MDM Server 7.1 Service Pack 06 Patch 225 or above SAP MDM Import Server 7.1 Service Pack 06 Patch 225 or above SAP MDM Syndication Server 7.1 Service Pack 06 Patch 225 or above
In order to access these servers you need to install the following GUI clients on your local machine. GUI Clients: • • • •
SAP MDM Console 7.1 Service Pack 06 Patch 225 or above SAP MDM Data Manager 7.1 Service Pack 06 Patch 225 or above SAP MDM Import Manager 7.1 Service Pack 06 Patch 225 or above SAP MDM Syndicator 7.1 Service Pack 06 Patch 225 or above
NOTE: The GUI client SAP Data Manager requires the following software installed as a pre-requisite: 1. Adobe Reader (Standard or Professional) 2. [Optional] Microsoft Visio 2003 standard /professional is required to work with MDM 7.1 workflows. 3. [Optional] Microsoft Excel 2003 or 2007 standard / professional is required to export or import files in .XLS or .XLSX format. 4. [Optional] Microsoft Access 2003 or 2007 standard / professional is required to export or import files in .mdb format.
Who this book is for This book will appeal to administrators, who are responsible for implementing and managing SAP NetWeaver MDM in their systems. Basic knowledge of MDM is desired, but not for SAP Netweaver MDM. If you are already familiar with NetWeaver it will be easy for you to follow the book. []
Preface
Conventions In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning. Code words in text are shown as follows: "To use this property, add the function Required_Fields to a validation expression." A block of code is set as follows: 167772170
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold: 167772170
New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "Expand the Tuples node in the Console Hierarchy tree and select the desired tuple." Warnings or important notes appear in a box like this.
Tips and tricks appear like this.
Reader feedback Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of. []
Preface
To send us general feedback, simply send an e-mail to [email protected], and mention the book title via the subject of your message. If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or e-mail suggest@ packtpub.com. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer support Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Errata Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub. com/support, selecting your book, clicking on the errata submission form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy. Please contact us at [email protected] with a link to the suspected pirated material. We appreciate your help in protecting our authors, and our ability to bring you valuable content.
[]
Preface
Questions You can contact us at [email protected] if you are having a problem with any aspect of the book, and we will do our best to address it.
[]
MDM Scenarios and Fundamentals Welcome to the first chapter of this book. If you are a newbie to MDM and want to start from the basics, this is the right chapter for you. Even if you have hands on experience with an MDM system, you can refresh your basics by reading this chapter and understand the high-level aspects of MDM and the key capabilities supported by an MDM repository. In this chapter, you will learn the following topics: •
•
MDM IT Scenarios °
Master Data Consolidation
°
Master Data Harmonization
°
Central Master Data Manager
MDM Business Scenarios °
Rich Product Content Management
°
Customer Data Integration
°
Global Data Synchronization
•
MDM Server know how
•
MDM repository structure
•
Key capabilities supported by an MDM repository
MDM Scenarios and Fundamentals
Master Data Management Master Data Management seeks to ensure consistent and high-quality master data in a heterogeneous system environment. It includes determination and future avoidance of duplicate and inconsistent data, thus allowing reliable global reporting and operational efficiency of business execution.
Benefits of Master Data Management MDM enables an organization to link all of its critical reference or master data shared by several disparate IT systems and groups under one single version of truth. This ensures that multiple inconsistent versions of the same master data are not used in different parts of an organization's operations. By providing front-line employees with more accurate and complete data, instead of inconsistent, incomplete, and often inaccurate data, organizations can realize many added benefits. The business analytical capability of an organization can be increased by utilizing MDM to provide consistent master data across all its operational applications. By achieving this, the master data that flows into a data warehousing system would also be consistent thus allowing the organization to leverage company-wide analytics and reporting. The benefits of MDM increase as the number and diversity of organizational departments, worker roles, and computing applications expand. The implementation of MDM is especially useful when companies merge as it can minimize confusion and optimize the efficiency of the new, larger organization. In addition, companies with a global footprint having an independent region-wise ERP implementation tend to consolidate with one ERP solution for all countries. In this scenario, MDM proves to be the necessary solution by unifying master data from each ERP system into a single unified master data such as Supplier, Material master, or Customer.
MDM scenarios SAP NetWeaver MDM scenarios can be easily implemented by the customers to utilize the core functionality of SAP NetWeaver in a phase-wise manner. It includes streamlined IT scenarios as well as product-content management and global data synchronization capabilities.
[]
Chapter 1
SAP NetWeaver MDM scenarios are broadly classified into the following two categories: •
IT scenarios
•
Business scenarios
IT scenarios IT scenarios are based on the lines of viewing the system comprising of various IT components and the flow of data between these entities. These scenarios can be applied to specific master data objects based on a model-driven approach. The following IT scenarios are listed within SAP NetWeaver MDM: •
Master Data Consolidation
•
Master Data Harmonization
•
Central Master Data Management
Master Data Consolidation Consolidation involves matching, normalizing, cleansing, and storage of master data imported from heterogeneous client systems. SAP NetWeaver MDM offers out-of-the-box models covering globally relevant attributes for the following: •
Material
•
Product
•
Retail article
•
Supplier
•
Customer
•
Business partner
•
Employee
This allows customers to also model additional content on an ad-hoc basis. Organizations can cleanse and consolidate master data on materials, retail articles, suppliers, customers, and employees in an interactive manner within heterogeneous environments. The cleansed and consolidated master data can then be consumed to perform company-wide analytics, for example, global spend analysis. []
MDM Scenarios and Fundamentals
The key capabilities of Master Data Consolidation include: •
Identification of identical or similar objects spread across the local systems
•
Cleansing of master data objects on a need basis
•
Providing ID mapping for unified, company-wide analytics, and reporting
Components required for implementing Master Data Consolidation Masterdata consolidation utilizes the following SAP NetWeaver components: •
Process Integration (PI)
•
Components of MDM such as:
•
°
MDM Import Manager (required for map creation and for manual data import)
°
MDM Import Server (required for automated master data import)
°
MDM Data Manager (required for updating master data)
°
MDM Syndication Server (required for automated master data export)
°
MDM Syndicator (for manual master data export)
Business Intelligence (BI) (only if data needs to be consumed for consolidated analytics such as global spend analysis)
In the following diagram, we illustrate Master Data Consolidation:
[ 10 ]
Chapter 1
How this scenario integrates with other scenarios? MasterData Consolidation is the prerequisite for subsequent phases lying within the incremental approach followed by SAP NetWeaver MDM. Subsequent scenarios that follow Master Data Consolidation are Master Data Harmonization and Central Master Data Management.
Master Data Harmonization Harmonization involves distribution of cleansed and consolidated high-quality master data within heterogeneous system landscapes. Organizations can make use of the out-of-the-box models offered by SAP NetWeaver MDM to cover globally relevant attributes for the following: •
Material
•
Product
•
Retail article
•
Supplier
•
Customer
•
Business partner
•
Employee
Additional content can also be modeled by the customers on an ad-hoc basis. This scenario includes Master Data Consolidation to ensure high-quality master data within connected business systems in an interactive manner. An added benefit in this scenario is that it allows client-specific control on master data. Organizations can utilize the consolidated and harmonized master data to perform company-wide analytics, for example, global spend analysis. The key capabilities of Master Data Harmonization include: •
Streamlined processes for data load, consolidation, and distribution
•
High-quality cleansed and de-duplicated master data within a heterogeneous system landscape
[ 11 ]
MDM Scenarios and Fundamentals
Components required for implementing Master Data Harmonization MasterData Harmonization utilizes the following SAP NetWeaver components: •
Process Integration (PI)
•
Components of MDM such as:
•
°
MDM Import Manager (required for map creation and for manual data import)
°
MDM Import Server (required for automated master data import)
°
MDM Data Manager (required for updating master data)
°
MDM Syndication Server (required for automated master data export)
°
MDM Syndicator (for manual master data export)
Business Intelligence (BI) (only if data needs to be consumed for consolidated analytics such as global spend analysis)
In the following diagram, we illustrate Master Data Harmonization:
[ 12 ]
Chapter 1
How this scenario integrates with other scenarios In SAP NetWeaver's incremental approach, Master Data Harmonization is preceded by the Master Data Consolidation scenario. You can also leverage the consolidation and harmonization capabilities of Business Objects Data Services.
Central Master Data Management Allows centralized maintenance and storage of master data with distribution mechanisms that ensure master data is delivered to remote systems that need it. Central Master Data Management puts into place corporate master data governance policies that ensures the overall master data quality of an organization. The differentiating aspect in this scenario with reference to Master Data Harmonization is that master data is created centrally using a rich client. Information is then delivered to target remote systems in an interactive manner. The key capabilities of Central Master Data Management include: •
Achieving Central Data ownership resulting in dramatic quality improvements
•
Empowers companies to set their own standards for master data management
•
Guarantees client-specific control on master data via local completion
SAP NetWeaver MDM offers out-of-the-box models covering globally relevant attributes for the following: •
Material
•
Product
•
Retail article
•
Supplier
•
Customer
•
Business partner
•
Employee
This allows customers to also model additional content on an ad-hoc basis.
[ 13 ]
MDM Scenarios and Fundamentals
Components required for implementing Central Master Data Management Central Master Data Management utilizes the following SAP NetWeaver components: •
Process Integration (PI)
•
Components of MDM such as:
•
°
MDM Data Manager (required for updating master data)
°
MDM Syndication Server (required for automated master data export)
Business Intelligence (BI) (only if data needs to be consumed for consolidated analytics such as global spend analysis)
In the following diagram, we illustrate Central Master Data Management: ABAP R/3 SRM
Oracle
SAP
CRM
Legacy Systems
SAP Business Process Integration (PI) Customer#
Name
SSN#
123
Jacob Right
1234-111-789
SAP Master Data Management (MDM) Backend Database
How this scenario integrates with other scenarios In SAP NetWeaver's incremental approach, Master Data Consolidation is a prerequisite for subsequent Central Master Data Management.
[ 14 ]
Chapter 1
Business scenarios In addition to IT scenario variants, SAP NetWeaver MDM also features business scenarios. This allows flexibility in adapting SAP NetWeaver Master Data Management to whatever business process flow the customer wants. The following business scenarios are described: •
Rich Product-Content Management
•
Global Data Synchronization
•
Customer Data Integration
Rich Product-Content Management This scenario targets requirements of a centralized product-content management and multi-channel catalog publishing. It allows for importing and exporting product data, centrally managing content, and publishing disparate product data across the enterprise and between trading partners. Organizations can create custom print catalogs, web catalogs, or expose an MDM product repository to a business application (for example SAP SRM) through the Open Catalog Interface (OCI). Consequently, the capabilities of MDM are extended with business processes such as product introduction, cataloging, and publishing. The key capabilities of Rich Product-Content Management are as follows: •
High-performing load, aggregation, and search of product data
•
Multidimensional search
•
Flexible taxonomy
•
Intelligent imaging and Web/print publishing
•
APIs for seamless, multiplatform integration
•
Scalability (up to millions of products)
Organizations can utilize the following key benefits of implementing Rich Product-Content Management: •
Manage or exchange product data locally and globally
•
Manage internal content
•
Search electronic catalogs
•
Print customized catalogs
[ 15 ]
MDM Scenarios and Fundamentals
•
Syndicate product catalog content through multiple channels such as OCI, Web, and Print
•
Presents role-based interfaces through a portal
Process flow This business scenario includes the following processes:
The following section discusses each of these processes in detail.
Importing product data Start the upload of product master data (flat files) from the specified remote systems, or product information from suppliers (in Excel or TXT format) to MDM. This process has the following prerequisites: •
The Repository has been set up using the MDM Console and import maps have been created using the MDM Import Manager
•
The inbound port has been defined using the MDM Console
•
The MDM Import Server is running
•
The inbound source data is staged in the inbound port
Once the data is delivered to a specific inbound port, it is automatically picked up within a configurable time interval and queued up for import processing. The MDM Import Server maps and matches the imported data to the repository structure as per the import maps defined in the MDM Import Manager. [ 16 ]
Chapter 1
Re-categorizing and enriching product data In this process, you search and merge identical records interactively using the MDM Data Manager. It provides different search patterns such as tree search, keyword search, free search, and so on. After de-duplication you can check if new data has been attached to the correct category and re-categorize it, if necessary. You can also enrich additional information in the MDM Data Manager and custom validations can be applied to check master data updates. Workflows can also be configured which are triggered to support the change processes. Support for adding images as additional information for repository items is available in the MDM Image Manager. Images can be imported into the repository and image variants (example thumbnails) can be created (using the MDM Console) for each image in addition to the original copy. These images are linked to the corresponding product items in the repository using the MDM Data Manager.
Providing catalog content Using this process, you can choose to syndicate the product data, apart from print publishing such as Web publishing or exposing the MDM product repository, to a business application (such as, SAP SRM) through the Open Catalog Interface (OCI). The SRM-MDM web catalog provided by SAP contains the web interfaces developed by SAP to access the MDM catalog. The implementation would require a deployment into an additional NetWeaver component called SAP Enterprise Portal. In the case of web publishing, a custom Web Catalog can be developed using the APIs. As a prerequisite, a web application should have been created and deployed on a web server with an open connection to the MDM catalog. An MDM API can be used to perform search, read, and maintain the repository content. On the other hand, if the MDM product repository needs to be exposed to a business application, we can provide the content via the OCI. Using the OCI you can search for products and add the required items to a selection list. The list is then transferred to the shopping cart of the business application and the order is completed.
Enabling print publishing Using this process, you can compose and set up a printed product catalog using the MDM Publisher. In order to do this you need to first create a family table using the MDM Console to enable the initial partitioning. As catalog printing is based on category-dependent pages and different product groups in a category have different layouts, further category partitioning can be defined in the MDM Data Manager. We can partition such categories using the field or attribute values to create product families. [ 17 ]
MDM Scenarios and Fundamentals
With the help of the MDM Publisher, you can assign default settings to create a common layout structure for the publication. We can then arrange a specific layout for the given product family such as eliminate redundancies, apply printed version display name, and structure tables. In order to start the publishing activities, a collection of families or non-family based records can be defined as a publication. The publication hierarchy, thus created, is not limited to the repository's taxonomy unlike the family hierarchy. You can freely add, delete, move, and split nodes to create your own structure for the catalog. Spread editor will enable you to concentrate specifically on page layout and design such as creating layout templates for publication. The next step involves using the DTP plug-in to send the publication data from MDM to a Desktop Publishing (DTP) application such as Adobe InDesign. Using the DTP application, some specialized format changes can be done and saved with the publication in MDM. This can be re-used with the next publishing run. Finally, an index for the complete publication is generated using the MDM Indexer.
Global Data Synchronization The Global Data Synchronization (GDS) business scenario supports product data consistency and distribution between trading partners. It is considered a strategic, imperative, and critical foundation for all manufacturers and retailers to effectively manage trade item data exchange. Using SAP's GDS solution, you can effectively manage trade-item exchange between Consumer Packaged Goods manufacturers and retailers via The Global Data Synchronization Network (GDSN) using global data pools such as 1Sync. These global data pools are certified by GDSN which provides the standards and the industrial format for data exchange. SAP MDM GDS operates as an integral part of SAP Master Data Management (MDM), a key capability of SAP NetWeaver. It provides for global synchronization of trade item data between suppliers, data pools, and the GS1 Global Registry. GDS conforms to the EAN.UCC standard and currently supports the foremost data pool: 1Sync with UCCnet and Transora messaging. With GDSN, trading partners always get the latest information. Updates from one company's database are automatically, and immediately, provided to all the other companies who do business with them.
[ 18 ]
Chapter 1
1Sync has emerged as the new U.S-based data synchronization organization for both retailers and manufacturers, replacing the retailer's organization UCCnet and the manufacturers' group Transora. The GDSN is built around the GS1 Global Registry®, GDSN-certified data pools, the GS1 Data Quality Framework, and GS1 Global Product Classification, which when combined provide a powerful environment for secure and continuous synchronization of accurate data.
By adopting a common set of global standards, defined by the GDSN, manufacturers and retailers can optimize their business processes through complete, comprehensive communication through data pools that are in turn linked to a single global registry. In the following diagram, we illustrate how the GDSN connects retailers and manufacturers using their selected data pools to the GS1 Global Registry™: ABAP R/3 SRM
Oracle
SAP
Legacy Systems
CRM
SAP Business Process Integration (PI) Customer#
Name
SSN#
123
Jacob Right
1234-111-789
SAP Master Data Management (MDM) Backend Database
The key capabilities of Global Data Synchronization (GDS) are as follows: •
Meets the GDS process needs in the Consumer Products Industry
•
Seamless and permanent integration with mySAP ERP backend
•
Flexible end-to-end solution
•
First step towards a full-blown MDM solution
•
Fits on top of an existing system landscape (low total cost of ownership)
[ 19 ]
MDM Scenarios and Fundamentals
Using GDS, organizations derive the following benefits: •
Reduce the error-processing costs resulting from inconsistent product data
•
Exchange standardized information through established channels such as data pools (for example, 1Sync) for further publication to trading partners
•
Faster time to market for new products thereby increasing efficiency and productivity
•
Implement a quick but complete solution for complying with trading-partner requirements
•
Seamless and permanent integration with mySAP ERP
•
Achieve a lower total cost of ownership, as GDS is based on top of your existing landscape
Customer-Data Integration The Customer-Data Integration (CDI) scenario supports the consolidation and management of customer data from all available sources. It ensures a consistent and up-to-date view of available customer data to all the departments of an organization looking up the customer information. CDI combines the technology, processes, and services needed to set up and maintain an accurate, timely, complete, and comprehensive representation of a customer across multiple channels, business-lines, and enterprises—typically from multiple sources of associated data in multiple application systems and databases. It applies data integration techniques in this specific area. This helps in streamlining cross-sell and up-sell activities and facilitates customer processes across business units and locations while enabling consolidated analysis for strategic business decisions. With respect to the process perspective, the CDI scenario operates on the basis of the Master Data Harmonization scenario. The following list shows the key capabilities of the CDI scenario: •
Flexible data hub that allows autonomy of customer data from business applications
•
Business Partner data model that supports both B2B & B2C interactions
•
Pre-packed integration to SAP CRM and ERP
•
Pre-integrated with SAP NetWeaver, including CDI-specific web services
•
Customer data management capabilities such as matching, standardization, and survivorship [ 20 ]
Chapter 1
•
Interfaces to third-party data quality tools and content providers
•
Unbeatable performance based on the in-memory MDM core engine
Using CDI, organizations derive the following benefits: •
360° view of customers and customer interactions
•
Easier maintenance of customer data—change once and propagate many
•
Reduced marketing costs with less duplication and greater personalization
•
Accuracy and reliability of all customer data-related analysis
MDM Server know how In the following section, we describe the fundamental components of an MDM environment and discuss about the qualities of a master data repository. Finally, we briefly talk about the table structure and various types of tables available in MDM. This knowledge is useful in proper creation and maintenance of MDM repositories.
What is an MDM Server? An MDM Server is the heart of an MDM system. It does the job of managing the master data in multiple MDM repositories along with catering to various clients across the network. An MDM Server sits on top of a commercial SQL backend database. Various backend databases are compatible with the SAP NetWeaver MDM 7.1 Server such as Oracle, Microsoft SQL Server, IBM DB2, and SAP MaxDB. The MDM software environment consists of the following components: •
MDM Console It is the administrative tool for monitoring MDM Servers, creating and maintaining the structure of MDM repositories as well as managing the repository access control for various users.
•
MDM Rich GUI Clients By interacting with the MDM Server, MDM clients are able to import, access, manage, syndicate, and publish master data.
[ 21 ]
MDM Scenarios and Fundamentals
The following are rich user interface clients available in SAP MDM: °
MDM Data Manager
°
MDM Import Manager
°
MDM Syndicator
Apart from the ones aforementioned, SAP MDM also provides customizable interfaces such as iViews (used in SAP Enterprise Portal applications) and APIs (such as Java APIs, ABAP APIs, and so on). •
DBMS engine A commercial SQL Database Management Server (DBMS) stores the master data with controlled access by the MDM Server. SAP NetWeaver MDM 7.1 supports Microsoft SQL Server, Oracle, IBM DB2, and SAP MaxDB.
MDM auxiliary servers An MDM system, in addition to the MDM Data Server, can also include the following auxiliary servers: •
Master Data Import Server (MDIS) This server interacts with the MDM Data Server to perform automated data imports into an MDM repository. It is an automated version of the MDM Import Manager.
•
Master Data Syndication Server (MDSS) The MDSS interacts with the MDM Data Server to perform automated syndication of data from an MDM repository. It is an automated version of the MDM Syndicator.
•
Master Data Layout Server (MDLS) The MDLS works with the MDM Data Server and enables the publication of master data from an MDM repository. Administration of each of these auxiliary servers has to be performed using the MDM Console. Each auxiliary server's interaction with the MDM Data Server is independent of each other.
[ 22 ]
Chapter 1
What is an MDM repository? Simply put, an MDM repository is a database consisting of text, images, PDFs, and other data about each record, and in some cases containing up to millions of records. Size alone does not qualify a database to be called a master repository. It is also characterized by its richness and complexity of the underlying information. SAP MDM's underlying data is maintained in a unique way in the database. A feature that sets an MDM repository apart from the rest is the way it can be searched and published. As described before in Rich Product-Content Management scenario, an MDM repository published as a catalog allows a potential customer to browse the products of a vendor in a convenient way. This makes the presentation, organization, and design of the published catalog critical for a vendor's brand creation and serves as a unique selling point. Thus, a master repository helps in creating and reinforcing a corporate image.
What makes a database a master data repository? In order to consider a database as an essential master repository, the following points must be kept in mind: •
Rich master data High quality and well-structured master data is the basis of a master repository. Master data used for product information that only provides fields such as part number, price, and product description does not serve the purpose. Apart from the information common to all the products (such as part number and price) a good master data must also include detailed product specifications (or attributes) applicable to a handful of products. Rich content such as images, text blocks, and PDFs are also the qualities of master data.
•
Classification Master data records are classified based on a taxonomy consisting of an arbitrary hierarchy that further includes categories and subcategories. An MDM repository may include multiple simultaneous taxonomies co-existing with an unlimited number of categories and sub-categories. A single category may be included more than once within the hierarchy. For instance, consider an MDM repository of product information. It may include computer storage accessories (such as a 4 GB flash memory) under both the memory category and the accessories category.
[ 23 ]
MDM Scenarios and Fundamentals
•
Product families Also known as units, presentations, or modules, a product family allows us to further partition the products in each category of an MDM repository (representing product information) into smaller groups based upon the values of other fields and/or attributes. This is very easily seen in a printed catalog which provides a model for organizing information on groups of records into product families within an MDM repository. Family data within a product family may contain images, descriptive paragraphs, and feature bullets. A detailed specification on each product arranged into a well-structured tabular layout is also within the storage capabilities of a product family.
•
Product relationships Relationships for products may include structural relationships such as assemblies, kits, bundles, and matching sets (like nuts and screws) as well as merchandising relationships such as cross-sells, up-sells, accessories, and consumables. Such a wide variety of product relationships can be used as a sales tool for effective selling in a published catalog. This makes it important for an MDM repository to effectively capture and represent product relationships such as the ones mentioned before.
•
Product hierarchies Master data may contain data which is hierarchical in nature. This hierarchical information needs to be stored in a separate hierarchy sub-table associated with the master data. For example, a manufacturer field requiring division and subdivision information needs to be maintained as a hierarchy.
MDM repository structure Proper creation and maintenance of an MDM repository requires a thorough understanding of the available tables and data types. The following section familiarizes introductory concepts related to the structure of an MDM repository. A typical MDM repository consists of the following types of tables: •
Main tables Usually information about a master data record is looked up in a main table. A main table stores primary information about a business object such as a product or a supplier. Starting with SAP NetWeaver MDM 7.1, every MDM repository has one or more main tables. For instance, a repository might contain separate main tables for products and business partners. Individual records within a product's main table would contain a particular product's data in the form [ 24 ]
Chapter 1
of fields such as SKU, product name, product description, manufacturer, price, and business partner. Whereas each record within a business partner main table would contain individual fields describing information about each partner. A freshly created MDM repository consists of a default main table named Products. This repository provides a base for designing a custom master data repository to suit customer requirements.
•
Sub-tables A sub-table stores the lookup information about every record in the main table. An MDM repository can have any number of sub-tables. A sub-table can define the set of legal values to which a corresponding lookup field in the main table can be assigned. For instance, consider an MDM repository holding product information. A manufacturer field within the main table of this repository may lookup from a sub-table the actual list of allowed manufacturer names. Only those values entered as records in the sub-table can be assigned to the manufacturer lookup field of the main table. With the help of lookup sub-tables MDM also enforces Data Integrity. Main table records have data links to lookup sub-table records which also helps in reducing the size occupied by a database. Another useful consequence of using lookup sub-tables is that it makes the MDM repository more search-friendly by associating a set of legal values with lookup fields. Thereby ensuring a consistent set of values being used across the entire repository.
•
Object tables These are special types of lookup sub-tables where each object table stores a single type of object. Examples of object tables are: °
Images
°
Sounds
°
Videos
°
Binary objects
°
Text blocks
°
Copy blocks [ 25 ]
MDM Scenarios and Fundamentals
°
Text HTML
°
PDF tables
MDM does not allow for storing such objects directly in the main or sub-table fields of an MDM repository. Instead, each object is defined or imported into the repository once and then linked to a main or sub-table field as a lookup into the object table of that type. Data Integrity is ensured by MDM using object tables as they eliminate redundant information. Each object appears only once in the MDM repository and linked one or more times to the main table records. A freshly created MDM repository contains, by default, an object table for each type of object. As an exception, text blocks alone can be stored in a large text field in the main and sub-table records rather than as a lookup into a text block sub-table. This should be done only with the intention of not reusing the blocks of text.
•
Special tables The following are included as special tables in an MDM repository: °
Image variants
°
Masks
°
Families
°
Relationships
°
Workflows
°
Named searches
°
Tuples
°
Data groups
°
Validation groups A freshly created MDM repository, by default, contains a single instance of each of these special tables. In the MDM Console, a user cannot view the Data Groups and Validation Groups tables as they are available in the MDM Data Manager.
[ 26 ]
Chapter 1
•
System tables The following are the system tables available in an MDM repository: °
Roles Stores the user roles defined in the MDM repository
°
Users Maintains the details of all users created in the MDM repository
°
Connections Holds information about the currently ongoing connection sessions
°
Change tracking Stores all the changes made to a field being tracked providing an audit log.
°
Remote systems Each record in this table corresponds to a logical system that supplies data to, or consumes data from, MDM
°
Ports Each record in this table corresponds to an inbound or an outbound port
°
Links Maintains URL links containing one or more placeholders for parameters
°
XML schemas Stores all the XSD (XML Schema Definition) files to be used in import or syndication
°
Reports Each record in this table stores a report generated due to various activities performed in the Console.
°
Logs Stores all the system's logs maintained by MDM server
System tables can be viewed under the Admin node in the Console Hierarchy.
[ 27 ]
MDM Scenarios and Fundamentals
A freshly created MDM repository automatically creates a single instance of each of the above system tables. The Logs table is independent of the MDM repositories and is specific to the MDM Server. Hence, it appears in the Console Hierarchy under an MDM Server node at the end of all the MDM repository nodes.
Other key capabilities of an MDM repository Apart from understanding the different table types in MDM, there are other key functionalities supported by MDM that need a brief mention. The following section gives a quick introduction to such key capabilities of an MDM repository.
Taxonomies Taxonomy enables us to perform a quick search and locate a few specific MDM records in a database of up to a million records. The purpose of taxonomy is to classify like master data records together into categories, based on a set of common, category-specific characteristics. In MDM, taxonomy is a hierarchical representation that allows categories to be part of other categories. As we progress down a taxonomy, the type of records included are narrowed down based upon the category. MDM utilizes this hierarchical concept of taxonomies to represent them as a tree. It supports eClass taxonomies, UNSPSC, and custom classifications.
Attributes As we progress down taxonomy, every category has a defining characteristic in addition to the ones corresponding to every category above it in the hierarchy. For instance, in the taxonomy of rocks, igneous rocks have certain specific attributes such as color, texture, and chemistry as well as common characteristics (such as weight and shape) shared with other types of rocks. In MDM terminology, characteristics are known as attributes and represent fields of information applicable to a handful of main table records in the repository. Every taxonomy table has a pool of attributes which can be linked to one or more individual categories. Using the Taxonomy mode, you can carry out the management of the attributes in the taxonomy pool.
[ 28 ]
Chapter 1
Attributes linked to categories are associated with main table records only when a record is assigned to a particular category within the taxonomy. The attributes of the parent category are automatically inherited by the main table record assigned to the child category. A main table record, therefore, consists of common fields, inherited attributes, and category-dependent attributes. An attribute in an MDM repository is represented as a field specific to only a few records in the main table. Whereas a field defined in the main table is part of every main table record. This requires that a field applicable to every record in an MDM repository must not be set as an attribute. For example, customer number should be defined as a field and not an attribute as it applies to every customer record.
Qualified tables and qualifiers Qualified tables allow extreme versatility in MDM. These are special kind of lookup tables that can store complex relationships. These relationships exist between the main table record and one or more lookup table records that contain other additional information. A qualified table contains fields called qualifiers whose values do not apply to the qualified table record. The value of a qualifier is specific to the association of each main table record with the qualified table record. Qualified tables support for multiple prices (based on regions or types including quantity price breaks), cross-reference part numbers, other distributor/supplier/customer-specific information, and product applications. For example, consider a scenario where a product has multiple prices based on its region. We can utilize the qualified tables to support this scenario out-of-the-box.
Product family In a situation when the contents of an MDM repository needs to be published containing product information, a finer organization of the records is required than that provided by the categories of a taxonomy. Such as grouping main table records based on not only the category but also the manufacturer. Product families enable support for such granular classifications of records such as eClass taxonomies or UNSPSC within an MDM repository. A group of main table records can be related based on the value of one or more common fields and/or attributes. Such related main table records form a product family which contains additional family data fields such as image, logo, description, specifications, and so on. [ 29 ]
MDM Scenarios and Fundamentals
The terms presentation, a unit, or a module are also used in place of product families in other systems. The MDM system makes use of a patent-pending technology that intelligently automates the creation and management of product families. This gives an innovative approach to structure, store, and maintain product family information. Any changes to the main table records, family structure, and the taxonomy does not affect the integrity of the family records.
Product masks A single master repository can be sliced into a number of custom virtual repositories with the help of product masks in MDM. This considerably simplifies the maintenance of a single repository which needs to be targeted to multiple audiences. A user sees each virtual repository as a completely private repository containing a subset of the records from the master repository. Virtual repositories created using product masks can, for example, be used for custom subsets for contact customers and targeted market segments driven by a single MDM repository. The added advantage of product masks is that they impose no performance limitations on the DBMS as they are defined at the individual product level rather than at the query level (in contrast to SQL views that are defined at the query level). In the electronic catalog's web page, a mask can automatically be applied upon site entry thereby controlling the view of the user to see only a part of the MDM repository that is relevant.
Data groups An MDM repository containing a large volume of images, text blocks, and PDF files needs to have an organization mechanism which enables them to be easily located and linked to a particular master data record. Data groups allows such organization wherein each object is assigned to a data group when it is first created or imported into the system. Data groups can further be organized in a hierarchy similar to the taxonomy hierarchy. Thus data groups allow a parallel classification scheme like taxonomy hierarchy to organize objects into subgroups called data groups. Individual data groups can exist for product images, category icons, and manufacturer logos.
[ 30 ]
Chapter 1
Validations and validation groups Validations in MDM are similar to formulas in Excel that return a Boolean result to denote success or failure. Validations include the following capabilities: •
Reference fields and attributes
•
Perform arithmetic, string, and logical operations
•
Call built-in functions
•
Reference other previously defined validations
Validations are created and executed using the MDM Client. A user can run complex tests for different types of conditions against a group of one or more records. Validations can be branched based on a specific condition in the main validation. MDM automatically executes the relevant validation based on the condition such as the category value of each record. Validations can be aggregated and grouped into validation groups and executed as a batch. Thus, multiple related validations can be grouped under a single validation group and run together by running the validation group against the master data records. This simplifies the task of multiple validations one-by-one and reduces time and effort. In validation expression fields, attributes, operator, or function names can be selected from a drop-down list. This significantly reduces the scope of typos.
Summary In this chapter, we have covered the fundamentals of Master Data Management and discussed the various IT and Business Scenarios that exist for an MDM implementation within an organization. Firstly we listed the basic components within an MDM environment such as the MDM server, console, clients, DBMS engine, and the auxiliary MDM components. Then we moved on to the typical characteristics of what makes an MDM repository tick. Finally, we closed with touching upon the repository structure, the various types of tables, and some key capabilities supported by an MDM repository. In the next chapter, we will introduce the SAP MDM Console application and learn about its features and settings.
[ 31 ]
Getting to Know the MDM Console It is time to meet the MDM Console. This chapter introduces you to the SAP NetWeaver MDM Console application. It aims to familiarize the console's GUI (Graphical User Interface) along with describing its commands and underlying functions. With this chapter, you should be able to understand the following: •
Starting and exiting the MDM Console
•
GUI of the MDM Console main window
•
Various configuration settings available
Launching the MDM Console This section quickly gets you up and running in the MDM Console. Before jumping in and getting our hands dirty, let us recap what is the MDM Console: MDM Console is the administrative tool for monitoring MDM Servers, creating and maintaining the structure of MDM repositories as well as managing the repository access control for all users. So the Console is used for the administrative tasks of MDM such as: •
Mounting/unmounting the MDM servers
•
Loading/unloading the MDM repositories
•
Archiving and unarchiving the repository
Getting to Know the MDM Console
•
Data modeling
•
User and role management
•
Enforcing access control
•
Verifying integrity of repositories
•
Change tracking
Use the MDM Console to perform these steps before accessing an MDM repository: 1. Mount the MDM server. 2. Start the MDM server. 3. Create a new MDM repository or unarchive an already existing MDM repository. 4. Mount the MDM repository in the Console. 5. Load the MDM repository. Now we discuss the various ways of starting and exiting the MDM Console application. In order to start the Console application, we need to ensure the following pre-requisites: •
SQL DBMS (SQL Server, Oracle, DB2, or MaxDB) is up and running
•
MDM software (MDM server and clients) is installed in your landscape
•
The MDM server and the clients installed should have exactly the same version including service pack, patch, and hot fix. Executables for the MDM server and the clients can be found in the installation media or downloaded from the Sap Service Marketplace website.
MDM Console can be launched in either of the following two ways: 1. Desktop Double-click the MDM Console shortcut-icon on your desktop. The icon is illustrated next:
[ 34 ]
Chapter 2
2. Start menu To open the Console from the Start menu, click on Start | All Programs | SAP MDM | MDM Console. There are two alternatives to exit the MDM Console: •
Click on the close button in the upper-right corner of the window
•
Click on File from the main menu and then choose Exit
When we try to exit the MDM Console without unmounting the MDM server(s), the Console prompts you to ask if you would like to save the list of currently mounted servers to an MDM Console Settings file. We can choose to click on: •
Yes—saves the settings file and exits the Console
•
No—exits the Console without saving the settings file
•
Cancel—returns to the MDM Console session window
MDM Console Settings file saves time by allowing us to quickly re-mount the MDM servers as a group next time we open the Console application. We discuss more on the MDM Console Settings file next.
MDM Console Settings file If you close the MDM Console session with the servers mounted, the next time you start the Console you have to manually mount one or more MDM servers one at time. Fortunately, the MDM Console provides the option of saving the list of currently mounted servers to an MDM Console Settings file. We can load this settings file in the Console session and automatically get the previously saved server(s) list mounted as a group. MDM Console Settings file is saved with the extension .mcs. Each MDM server internally maintains a list of currently mounted MDM repositories. This list persists even after the MDM server is stopped. After the server restarts, all these repositories are automatically remounted.
[ 35 ]
Getting to Know the MDM Console
You can save different sets of mounted MDM servers in different .mcs settings files. This will allow you to define and choose specific sets of MDM servers to be mounted as a group.
We now look at how to utilize the MDM Console Settings file in various ways.
Loading the MDM Console Settings file When the Console session is open, we can load the MDM Console Settings file in any of the following ways: •
Using the Console main menu
•
Using the Console desktop shortcut
•
Using the command line
We now look into each alternative in detail.
Using the Console main menu In the main window of the MDM Console application, click on File from the main menu and then click on the Open command. If there are currently mounted servers, or the console application was opened with a settings file, MDM prompts you to save the list of currently mounted servers to a settings file. You can click on: •
Yes—saves the settings file and shows the Open dialog
•
No—shows the Open dialog without saving the settings file
•
Cancel—returns to the MDM Console session window
When the Open dialog is displayed, navigate to the desired folder, select the .mcs settings file and then click Open. MDM replaces the current set of mounted servers (if any) with the group of servers listed in the settings file. You can save the list of currently mounted MDM server(s) to the current .mcs file, any time, by clicking File from the main menu and choosing Save. In order to save the list to a different file, choose Save As from the File menu.
[ 36 ]
Chapter 2
Keyboard shortcuts You can use the keyboard shortcut Ctrl + O for loading the MDM Console Settings file from within the current session of the MDM Console application. Use Ctrl + S as a shortcut to save the list of currently mounted MDM server(s) to the current .mcs file. For additional keyboard shortcuts refer to the end of this chapter.
Using the Console desktop shortcut The target of the MDM Console desktop shortcut can be appended with the full pathname of a specific .mcs file. The settings file will be opened every time you start the Console application from the desktop shortcut. The procedure is detailed next: 1. Create a desktop shortcut to the MDM Console application if it does not already exist. The shortcut should point to the Console.exe program placed in the directory path \SAP MDM 7.1\Console. For example, C:\Program Files\SAP MDM 7.1\Console\Console.exe. 2. Right-click on the shortcut and select Properties. A dialog box for the shortcut properties opens with the Shortcut tab selected. 3. In the Target field append the following text: -f
4. The argument after -f is the full pathname of the MDM Console Settings file. 5. Click on the OK button. Now when you start the MDM Console from the desktop shortcut it automatically mounts all the MDM server(s) saved in the .mcs file specified in the target field. If you have multiple .mcs files saved you can create multiple MDM Console desktop shortcuts to automatically mount the different sets of MDM servers.
Now, whenever you exit the MDM Console application without unmounting the server(s), MDM will prompt you to save the currently mounted server(s) to the settings file mentioned in the target field of the shortcut properties.
[ 37 ]
Getting to Know the MDM Console
Automatically saving the MDM Console settings file MDM allows you to automatically save the currently mounted server(s) to the .mcs settings file (opened using the -f argument in the target field) by appending -q to the target field under shortcut properties like this: -f -q Before exiting the MDM Console if you unmount all the MDM server(s), the console does not automatically save changes to the MDM Console settings file.
Using the command line When starting the Console application from the command line, you can append the full pathname of a specific .mcs file to the command line. For example, Console -f "C:\My Documents\SAP MDM Servers.mcs"
This opens the MDM Console application and automatically mounts the list of server(s) mentioned in the .mcs file. Command line arguments can be used for convenience when starting the MDM Console from the command line or a Windows shortcut. The available command line arguments are either "-" switches or arguments to a particular switch. Apart from loading the MDM Console Settings file there are various other command line parameters that can be used. We summarize all command-line arguments and a few others in a tabulated format as shown:
[ 38 ]
Chapter 2
Argument
Description
-f "filepath"
Starts the MDM Console and mounts the MDM Servers specified in the previously saved MDM Console Settings (.mcs) file. Example: Console -f "C:\My Documents\SAP MDM Servers.mcs"
Can be used with either -x or -q -m <Servername>
Mounts (and starts, if needed) the specified MDM Server. Example: Console -m MyMDM
If you provide the setting as AutoStart=True in the mds.ini file, along with starting the specified MDM server, MDM can also automatically load the mounted repositories. -q
Saves the MDM Console settings (.mcs) file without prompting when you exit the Console. Example: Console -f "C:\My Documents\SAP MDM Servers.mcs" -q
This argument works only with -f but it is superseded by -x -x
Does not save or prompt you to save the MDM Console Settings (.mcs) file when you exit the Console. Example Console -f "C:\My Documents\SAP MDM Servers.mcs" -x
This argument works only with -f and overrides -q option. -h
Displays and describes the available command-line arguments.
In the next session, we look at the MDM Console main window and understand what its graphical user interface has to offer.
[ 39 ]
Getting to Know the MDM Console
MDM Console main window On starting the Console, you see the main window which comprises of panes and tabs as illustrated next:
For understanding purposes, the panes and tabs have been labeled with numbers as follows: 1. Hierarchy pane 2. Objects pane 3. Object Detail pane 4. Functions tab 5. Tables and Fields tab 6. Status bar Next we discuss each of these listed panes and tabs in detail. [ 40 ]
Chapter 2
Hierarchy pane The hierarchy pane is the left-most pane in the Console main window. It displays a tree structure that represents the hierarchy of the MDM server(s), repositories, and tables. On expanding the tree fully you can view the currently mounted MDM server(s), mounted repositories, and the tables within each repository.
As you go deeper the Console hierarchy pane also displays administrative settings such as Users, Roles, Connections, and Change Tracking along with detailed reports.
[ 41 ]
Getting to Know the MDM Console
In the MDM Console, you can simultaneously mount multiple MDM servers wherein each server is capable of simultaneously accessing and mounting multiple MDM repositories.
Objects pane The objects pane is the top-right pane in the Console main window and adjacent to the hierarchy pane. It displays the MDM objects corresponding to the node selected in the tree of the hierarchy pane. The objects are displayed for root, server, repository, and table node selected within the hierarchy pane's tree structure. In this pane, you will see that every object is represented as a row consisting of columns that define the object property. Using the objects pane you can browse, sort, and select the objects for editing or deletion. The heading of the objects pane depends upon the type of node selected in the hierarchy pane's tree structure.
Object detail pane The object detail pane is the bottom-right pane of the Console main window located below the objects pane. For every object selected in the object pane, the object detail pane allows you to view and edit the object's properties. The pane comprises of a two column grid where the first column is the row header that lists object properties. The second column of the grid lists the corresponding object property values. The heading of the object detail pane changes dynamically to match the object type selected in the objects pane. We now list all the possible types of objects displayed in the objects pane for every selected node in the hierarchy pane and the corresponding details listed in the object detail pane:
[ 42 ]
Chapter 2
Selected node
Objects pane
Object detail pane
Root (SAP MDM Servers)
MDM Servers
MDM Server Detail
Any MDM Server
Repositories
Repository Detail
Any MDM repository
Tables
Table Detail
Any main table
Fields
Field Detail
Any subtable
Fields
Field Detail
Image Variants table
Variants
Variant Detail
Masks table
Fields
Field Detail
Families table
Fields
Field Detail
Relationships table
Relationships
Relationship Detail
Workflows table
Fields
Field Detail
Named Searches table
Fields
Field Detail
Tuples table
Tuples
Tuple Detail
Tuple
Member Fields
Member Field Detail
Admin
Empty
Empty
Roles table
Roles
Role Detail
Users table
Users
User Detail
Connections table
Connections
Connection Detail
Change Tracking
Empty
Change Tracking Detail
Remote Systems table
Remote Systems
Remote System Detail
Ports table
Ports
Port Detail
Links table
Links
Link Detail
XML Schemas table
XML Schemas
XML Schema Detail
Reports table
Reports
Report Detail
Logs table
Logs
Log Detail
Activities table
Activities
Activity Detail
Auxiliary Servers
MDM Auxiliary Servers
MDM Auxiliary Server Detail
Any Auxiliary Server
Repositories
Repository Detail
[ 43 ]
Getting to Know the MDM Console
Functions tab You can see the Functions tab within the object details pane only when the Roles node is selected in the hierarchy pane. In this tab, you can choose to restrict the privileges for any role (other than the Administrator role) such as restricting record creation in the main table, restricting modification of images, forbidding modification of multiple records, and so on. The layout of this tab contains a hierarchy of functions arranged in a grid format. You can choose whether or not a function can be executed by selecting the radio buttons available for each function. A sample view of the functions tab is illustrated next:
Tables and Fields tab Just like the Functions tab, you can see the Tables and Fields tab within the object details pane only when the Roles node is selected in the hierarchy pane. Using this tab, you can configure access constraints for any role (other than the Administrator role) such as allowing read-only access to the fields of a table. The layout of the tab consists of a grid with a hierarchy of tables and fields. On selecting the table or the field from the hierarchy you can set the Read-Only, Read/Write, or any additional constraints. A sample view of the Tables and Fields tab is illustrated next:
[ 44 ]
Chapter 2
Status bar The status bar appears at the bottom of the Console main window. Using the status bar you can see whether any of the Num Lock, Scroll Lock, Or Caps Lock keys are on. It also gives a count of the number of objects listed in the objects pane. Next let us see the types of configuration settings available in SAP NetWeaver MDM.
Configuration parameters We can configure the settings in MDM for the following: •
MDM Console
•
MDM server and auxiliary servers (MDIS, MDSS, MDLS)
•
MDM repositories
•
Backend database server
We will briefly learn about each of these in the following section.
[ 45 ]
Getting to Know the MDM Console
MDM Console settings These settings allow you to configure the look and feel of the MDM user interface and also define the list of mounted MDM servers saved in the MDM Console settings file. The Console settings file is always saved as a .mcs file and can be loaded from the main menu or startup. See the section on the MDM Console settings file. The graphical layout settings of the Console main window is found in the Windows registry in the path HKEY_CURRENT_USER>Software>SAP>MDM 7.1>Console. However, the registry settings should not be directly edited as any careless modification can cause irreversible damage.
MDM server settings MDM server settings need to be occasionally edited post the server installation. These settings define the MDM server behavior on the installed machine and are independent of the Console client where the server is mounted. The server settings also do not depend on any DBMS server that holds the MDM repository data. The configuration settings remain constant for an MDM server irrespective of the number or type of repository mounted or loaded on the MDM console. The file mds.ini that holds the server settings is saved in an operating system-independent format. For more information on editing this file, see the MDS Configuration section covered in Chapter 6, Server Administration.
MDM auxiliary server settings For each auxiliary server there exists a separate configuration settings file that governs its behavior. So we have the following three auxiliary settings files: •
MDM Import Server (MDIS) settings
•
MDM Syndication Server (MDSS) settings
•
MDM Layout Server (MDLS) settings
For detailed information on configuration settings for MDIS, refer to the section MDIS configuration covered in Chapter 7, Import Server Administration. More information on configuration settings for MDSS can be found in the section MDSS configuration covered in Chapter 8, Syndication Server Administration.
[ 46 ]
Chapter 2
Repository settings Repository settings vary for each MDM repository. These settings are neither dependent on the MDM server that mounts and loads the repository nor on the client that accesses the repository.
DBMS settings The DBMS settings are specific to a particular DBMS server. With these settings, you can configure parameters regarding DBMS server's use of the file system. These settings remain the same for a DBMS server regardless of any MDM server that accesses it and any repository mounted on the MDM server.
Keyboard shortcuts Here is a list of some more keyboard shortcuts for the SAP MDM Console: Keyboard shortcut
Description
Shift + Enter
Commit changes on current MDM repository such as adding/deleting/editing fields, tables, and so on.
Ctrl + Z
Undo the last edit operation on a property or field before committing the changes.
Ctrl + Y
Redo the last edit operation on a property or field before committing the changes.
Ctrl + X
Cut the highlighted text while performing an edit operation on a property or field of repository.
Ctrl + C
Copy the highlighted text while performing an edit operation on a property or field of repository.
Ctrl + V
Paste the text that was last cut or copied while performing an edit operation on an property or field of repository.
F5 (Function Key 5)
Refreshes the MDM Console view by communicating with the MDM server.
[ 47 ]
Getting to Know the MDM Console
Summary In the beginning of this chapter, we learned how to start and exit the MDM Console application. Then we discussed about saving the MDM server list to a Console settings file and loading this file in three different ways. Later on we analyzed the MDM Console main window and understood its GUI comprising of panes and tabs. Finally, we briefly talked about the various types of configuration settings available in MDM. In the next chapter, you can learn how to access and determine the behavior of MDM servers and underlying repositories.
[ 48 ]
Accessing the MDM System In this chapter, you can learn how to access and control the states of the MDM Servers and repositories using the MDM Console application. These Console operations enable you to maintain the MDM server and its underlying repositories. After going through this chapter, you will be able to: •
Mount and unmount an MDM server
•
Start and stop an MDM server
•
Mount and unmount a repository
•
Connect and disconnect to a repository
•
Load and unload a repository
Accessing the MDM servers Before we can access an MDM repository, we first need to have access to the MDM server that is hosting the repository. For this purpose we will first talk about accessing the MDM server. Accessing an MDM server involves mounting and unmounting operations which we discuss in the following section.
Mounting and unmounting an MDM server MDM server installations are accessible on the console only after they have been mounted. Multiple servers can be mounted within a single console session. We have a choice of mounting only those servers which need to be accessed. The server may or may not be in a running state when mounted in your console session. No password is required to mount a server in your console session even if it is password protected.
Accessing the MDM System
The MDM Console provides the option of saving the list of currently mounted servers to an MDM Console Settings file. We can load this settings file in the console session and automatically get the previously saved server(s) list mounted as a group. Refer to Chapter 2, Getting to Know the MDM Console for a detailed explanation under the topic the MDM Console Settings file. An MDM server can be mounted by multiple MDM Consoles. Once an MDM server is started from any console, it runs on the machine where it is installed and is seen as running by all MDM Consoles that have mounted it. We can mount an MDM server as follows: 1. Right-click on the root node (SAP MDM Servers) in the hierarchy pane tree and choose Mount MDM Server… from the context menu:
2. Alternatively you many select the root node (SAP MDM Servers) and choose MDM Servers | Mount MDM Server… from the main menu:
[ 50 ]
Chapter 3
3. MDM opens the Mount MDM Server dialog prompting for the MDM Server input as displayed next:
[ 51 ]
Accessing the MDM System
4. In the drop-down list input the region displaying the text Enter or select an MDM Server, type the name of the MDM server (typically the name of the machine on which the server is running) you want mounted or select it from the drop-down list. Alternatively (for non-Windows installations), type the name or IP address of any remote machine into the edit box in the Mount MDM Server dialog. 5. Click on the OK button: The drop-down list of MDM Servers shows only those servers that you have previously mounted. If a specific server is not in the list, click on … (Browse) button to open the Select MDM Server dialog (see next) and select the machine on which the MDM Server has been installed from the list of Windows machines visible on the local network.
On successful mounting of the MDM server, you will see a new server node added in the tree structure of the hierarchy pane. Depending on the state of the MDM server, the corresponding icon is displayed in the tree node. The different states and the respective icons of the server node are listed in the following table:
[ 52 ]
Chapter 3
Status icon
State of MDM server MDM server is stopped MDM server is running MDM server is in one of the following states*: •
Server Inaccessible
•
Communication Error
•
Start Server Failed
•
Invalid
If the MDM server is inaccessible via the console even after the server has been started, you can try unmounting and remounting the MDM server in the console to restore connectivity.
Next we see how to unmount an already mounted MDM server: 1. In the hierarchy tree, right-click on the MDM server that you want to unmount and choose Unmount MDM Server from the context menu. Alternatively, you may unmount the server by first selecting its node in the tree and then clicking on MDM Servers | Unmount MDM Server from the main menu. Unmounting an MDM server is also possible by using the MDM Servers pane (top-right) when the root node (SAP MDM Servers) is selected in the hierarchy tree. Then you can right-click on the MDM Server in the objects pane and select Unmount MDM Server from the context menu.
2. The MDM server node disappears from the tree in the hierarchy pane. Unmounting a running MDM server while it is still running keeps the MDM repositories mounted and loaded even while the unmounted server remains disconnected from the console session. Unmounting and again re-mounting an MDM server within the same MDM Console session requires the MDM server's password to be re-entered to perform any server-level operations (like starting and stopping the server).
[ 53 ]
Accessing the MDM System
Starting and stopping an MDM server Along with the MDM Server, other auxiliary servers like MDM Import Server, MDM Syndication Server, and MDM Layout Server can be started and stopped using the MDM Console tool. However, starting and stopping the servers requires an OS user and password to be entered in the Web Service Authentication dialog box. An MDM server in stopped state (red square) can be started by using the following steps: 1. Right-click on the stopped MDM server in the hierarchy pane and select Start MDM Server from the context menu. Alternatively, the server can also be started by selecting MDM Servers | Start MDM Server from the main menu. Starting a stopped MDM server is also possible by using the MDM Servers pane (top-right) when the root node (SAP MDM Servers) is selected in the hierarchy tree. You can simply right-click on the MDM server having the status Stopped in the objects pane and select Start MDM Server from the context menu.
2. The console application prompts you to enter the OS level User and Password in the Web Service Authentication dialog box:
3. Enter the credentials and click on OK. 4. The state of the MDM server changes to running with the server status icon changing from a red square to a green triangle (as shown):
[ 54 ]
Chapter 3
When starting an MDM server, a check is performed on each of its mounted repositories. This requires the underlying DBMS server to be up and running.
You can stop an MDM server when it is in running state (green triangle) as follows: 1. Stop the MDM server from the context menu by right-clicking on the server node in the hierarchy pane. Then click on the Stop MDM Server option in the context menu displayed:
[ 55 ]
Accessing the MDM System
2. Alternatively, you may also stop the currently selected MDM server by choosing MDM Servers | Stop MDM Server from the main menu:
Stopping a running MDM server is also possible by using the MDM Servers pane (top-right) when the root node (SAP MDM Servers) is selected in the hierarchy tree. You can simply right-click on the MDM server having the status Started in the objects pane and select Stop MDM Server from the context menu.
3. A pop-up SAP Instance Shutdown dialog box appears prompting for the type of shutdown. Select the shutdown type from the following choices: °
Hard (SIGINT)
°
Soft with timeout (SIGQUIT/SIGINT)
°
Soft without timeout (SIGQUIT)
[ 56 ]
Chapter 3
4. If you have selected Soft with timeout as the shutdown type then also provide the timeout period in seconds in the input textbox. 5. Click on the OK button. 6. MDM prompts you to enter the OS user name and password in the Web Service Authentication pop-up dialog box:
7. After entering the credentials click on OK. [ 57 ]
Accessing the MDM System
8. The server status icon changes from the green triangle to a red square (as shown) indicating that the server is now stopped:
You can start or stop the auxiliary servers using the following steps: 1. Mount the auxiliary server by right-clicking on the node in the console hierarchy Auxiliary Servers:
2. Select the desired auxiliary server from the context menu option Mount. 3. In the dialog box, select the auxiliary server from the drop-down menu:
[ 58 ]
Chapter 3
4. A new server node is appended below the Auxiliary Servers node:
5. To start the auxiliary server (for example, Import Server), right-click on it and select the context menu option Start Auxiliary Server:
[ 59 ]
Accessing the MDM System
Similarly, you can stop the auxiliary server by selecting the context menu option Stop Auxiliary Server. A pop-up SAP Instance Shutdown dialog box appears prompting for the type of shutdown. This is the same pop-up that appears while stopping the MDM server as discussed previously. In the next section, we will learn about the various properties of the MDM repositories and the DBMS server.
MDM repository properties Once the MDM server is started, we can see the repositories that are available in it. Every repository has a set of properties associated with it. In order to see the repositories, select the MDM server node in the hierarchy tree. The objects pane (top-right) having the title Repositories displays a list of mounted MDM repositories in a grid layout. Each repository in the list is a child of the corresponding MDM server node selected in the hierarchy pane. You can view the repository properties for every repository displayed in the objects pane titled Repositories. When you select a repository in the object pane list, the object details pane displays additional repository properties under the Repository Detail tab. These properties are summarized as shown: Property
Description
Name
The MDM repository name
Description
The MDM repository description
DBMS Server
The network ID of the DBMS server that is hosting the repository
DBMS Type
The DBMS brand:
•
SQL Server
•
Oracle
•
DB2
•
MaxDB
Login
The login name for the DBMS server
Password
The password for the DBMS server
Port
The TCP/IP port number on which to connect to the repository
[ 60 ]
Chapter 3
Property
Description
Type
The MDM repository type:
•
Normal
•
Master
•
Slave
•
Publication Slave
Languages
The languages supported by the MDM repository.
Status
The MDM repository status:
•
Disconnected
•
Unloaded
•
Loading
•
Loaded
•
Running Remotely
•
Outdated
•
Newer than MDM Server
•
Archiving
•
Unarchiving
•
Duplicating
•
Invalid
•
Busy
The Type and Port property is hidden by default in the Repositories pane; unhide to display. The Password property is not visible in either the Repositories or Repository Detail panes. The Status property is not visible in the Repository Detail pane.
A repository having the status Disconnected may only show values for the Name, DBMS Server, and DBMS Type properties. In order to see additional property values you must connect to the repository (See Connecting to and disconnecting from an MDM repository under the section Accessing MDM repository of this chapter). We now discuss in detail the DBMS server and the repository port properties listed in the previous table.
[ 61 ]
Accessing the MDM System
DBMS server The DBMS Server property defines the network identification string of the DBMS instance/machine/server that is used by the DBMS-specific client on the MDM server machine to connect to the DBMS. The DBMS Type property displays the brand of the DBMS server on which the repository is running. When two repositories with the same name, but located in different DBMS servers, are mounted on the same MDM server, MDM identifies them in the hierarchy pane of the console by appending the name of the DBMS server in angular brackets to the repository name (for example, Test Repository ).
Repository port numbers The port property defines TCP/IP port numbers that the various MDM client applications, MDM APIs, and OCI connections use to connect to the repository. MDM uses three consecutive port numbers starting from the value specified. So if you have given the port value as 2400, MDM will actually be using the ports 2400, 2401, and 2402. The starting port value can be chosen as any value in the range 2000 to 9999 as per your requirements, but be aware of the three consecutive port values actually used by MDM. It is recommended to provide at least a gap of 3 values while assigning port numbers to two or more repositories. It is recommended that each repository be assigned a unique port number as only one repository can be loaded on a port at a time. You can assign or edit TCP/IP port numbers using the object details pane titled Repository Detail during any of the following operations: •
Mounting a repository
•
Creating a repository
•
Repository duplication
•
Unarchiving a repository
[ 62 ]
Chapter 3
CAUTION Even though MDM allows you to mount two repositories on the same port, it doesn't allow you to load them on the same port simultaneously. Hence, unique port numbers should be assigned to repositories. Users should be notified promptly about any change in the port numbers.
Now that the MDM server has been mounted, let us move on to accessing the MDM repository.
Accessing the MDM repository You can access the MDM repository in your console session by first mounting it. After mounting the repository you need to connect to it in order to view the repository's current type and state. Then you can perform various administrative functions on it. The MDM server must be mounted in your console session in the running state before we can mount any repositories under it.
When you select the MDM server node in the hierarchy tree, the objects pane titled Repositories shows the list of mounted repositories. It displays both the type and state of only connected repositories. Let us see how we can mount, unmount, connect, disconnect, load, and unload repositories in the following sections.
Mounting and unmounting an MDM repository Multiple repositories can be mounted within a single console session. It is not necessary to mount all repositories; instead we can mount only those repositories which are of interest to us. When mounting an MDM repository you are required to enter the user name and password of the underlying DBMS server in the pop-up dialog box.
[ 63 ]
Accessing the MDM System
Follow the steps given in order to mount an existing MDM repository: 1. Right-click on the MDM server node in the tree of the hierarchy pane and choose Mount Repository from the context menu:
2. Alternatively, you can select the server node and choose Repositories | Mount… from the main menu:
[ 64 ]
Chapter 3
3. In the Mount MDM Repository dialog box, you are prompted to enter the DBMS server, User name, and Password:
[ 65 ]
Accessing the MDM System
4. In the DBMS server drop-down list, select the server of the DBMS you want to connect:
If the DBMS server is not available in the drop-down list, you can add a new DBMS server by clicking on the … button. MDM displays the Select DBMS Server pop-up as illustrated with the buttons Add, Remove, OK, and Cancel. By clicking on the Add… button, you can add a DBMS server and its corresponding DBMS type in the Add DBMS Server dialog box (see next). The newly added server henceforth appears in the DBMS Server drop-down list of the Mount MDM Repository dialog box.
5. After choosing the DBMS server, enter the DBMS User name having the system administrator privileges on the selected server and the corresponding user password. Then click on the Next button. 6. If the credentials for the DBMS server are correct, MDM disables the DBMS server, User name, and Password fields, and enables the Repository name and Port fields: [ 66 ]
Chapter 3
7. You can select the MDM repository you want to mount from the Repository name drop-down list. 8. Enter the TCP/IP port number in the Port textbox. 9. Click on the Finish button to mount the MDM repository. 10. A new node for the MDM repository gets added to the hierarchy tree as a child of the MDM server node. The repository is added in a disconnected state with a gray lock (as shown) in the status icon in the hierarchy pane:
Next, let us see the reverse process that is unmounting an MDM repository. In order to unmount a repository, it must be in the unloaded state. Follow the steps to unmount a mounted repository: 1. In the hierarchy tree, right-click on the MDM repository, and choose Unmount Repository from the context menu. Alternatively, you can also select the tree node and choose Repositories | Unmount from the main menu. 2. MDM removes the repository node from the hierarchy tree. Once you unmount a repository, the port on which it was mounted is freed and can be used to mount other repositories.
[ 67 ]
Accessing the MDM System
Connecting to and disconnecting from an MDM repository Once the MDM repository is mounted, you must connect to it for any further repository operations. To connect to a disconnected MDM repository (gray lock): 1. Right-click on the MDM repository node in the hierarchy tree and choose Connect to Repository from the context menu:
2. Alternatively, you can first select the repository tree node and choose Repositories | Connect from the main menu:
[ 68 ]
Chapter 3
Connecting to an MDM repository is also possible by using the Repositories pane (top-right) when the server node is selected in the hierarchy tree. You can simply right-click on the repository having the status Disconnected in the objects pane and select Connect to Repository from the context menu.
3. You are prompted to enter the repository User and Password credentials in the Connect to MDM Repository dialog box:
[ 69 ]
Accessing the MDM System
4. If the user and password are correct, the status icon of the MDM repository in the hierarchy tree changes to reflect its current type and state. 5. The Tables and Table Detail panes are populated with table information for the connected MDM repository. To disconnect from an MDM repository: 1. In the hierarchy tree, right-click on the MDM repository and choose Disconnect from Repository from the context menu:
[ 70 ]
Chapter 3
2. Alternatively, you may select the tree node and choose Repositories | Disconnect from the main menu:
3. The repository status icon changes to a gray lock indicating that the repository is now disconnected from the Console:
[ 71 ]
Accessing the MDM System
Loading and unloading an MDM repository After an MDM repository has been mounted and connected, the next step is to load the repository before performing data entry activities by the clients on the network. An MDM repository can be simultaneously mounted by multiple MDM servers. But once a repository has been loaded on a particular MDM server, it cannot be loaded on any other MDM server having the same repository mounted.
Only a single repository can be loaded on a TCP/IP port at a time. For instance, if Repository A has been loaded on port 2400, no other repository can be loaded on the same 2400 port. After an MDM repository has been loaded, its structure cannot be modified through the MDM Console. In order to do so it has to be first unloaded. In order to modify the structure of an MDM repository while preserving access to a current version, you can duplicate the repository and give it a new name, or use the same name and move it to another DBMS machine.
Follow the steps given to load an unloaded MDM repository (red square): 1. Right-click on the repository you want to load in the hierarchy tree and choose Load Repository from the context menu:
[ 72 ]
Chapter 3
2. Alternatively, you may select the repository node in the hierarchy tree and choose Repository | Load from the main menu:
[ 73 ]
Accessing the MDM System
3. There are two options to load the repository—Immediate or Update Indices. When you choose to load the repository using the Immediate option, MDM automatically updates the out of date indices as a result of changes made to the repository via the MDM Data Manager. On the other hand, if the structure of the repository has been modified through the MDM Console, MDM cannot know precisely which indices need to be updated. In such situations, the Update Indices method for loading the repository should be used and not the load Immediate option.
4. While MDM loads the MDM repository, the load progress is displayed in the Status field for the repository in the Repositories pane and the repository status icon changes to a blue arrow as illustrated:
5. After the loading process is completed the repository status icon changes to a green triangle. This process can take somewhere between five minutes to five hours depending upon the data stored in the repository:
Follow the steps given to unload a loaded MDM repository (green triangle):
[ 74 ]
Chapter 3
1. Right-click on the MDM repository node in the hierarchy tree and choose Unload Repository from the context menu:
[ 75 ]
Accessing the MDM System
2. Alternatively, you may select the tree node and choose Repositories | Unload from the main menu:
3. You can choose the time out before unloading the MDM repository from the cascading menu: °
Immediate
°
1 Minute
°
2 Minutes
°
5 Minutes
[ 76 ]
Chapter 3
4. With the delayed unload option, the repository state changes to Unload scheduled:
