SAP NetWeaver MDM 7.1 Administrator's Guide

Masterdata consolidation utilizes the following SAP NetWeaver components:

In the following diagram, we illustrate Master Data Consolidation:

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.

MasterData Harmonization utilizes the following SAP NetWeaver components:

In the following diagram, we illustrate Master Data Harmonization:

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 utilizes the following SAP NetWeaver components:

In the following diagram, we illustrate Central Master Data Management:

In SAP NetWeaver's incremental approach, Master Data Consolidation is a prerequisite for subsequent Central Master Data Management.

This business scenario includes the following processes:

The following section discusses each of these processes in detail.

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Validations in MDM are similar to formulas in Excel that return a Boolean result to denote success or failure. Validations include the following capabilities:

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.