Before an organization implements SAP NetWeaver Master Data Management (SAP NetWeaver MDM), it must mitigate design challenges by employing strategic planning that is enhanced with best practices and lessons learned. A failed implementation does not necessarily mean that the product failed. Based on personal experience, it means tool challenges were not identified and addressed in advance to meet enterprise requirements.

Every product can manifest limitations without strategic plans for meeting present — and future — requirements. After implementing dozens of MDM solutions for enterprise across industries, I have found that out of the box SAP NetWeaver MDM is capable of achieving roughly 50 to 70 percent of every organization’s requirements. The successful and competitive enterprise, however, attains all requirements.

I’ll show you how to be such an enterprise, chiefly by tackling four key challenges that arise during SAP NetWeaver MDM project implementations:

1. Syndication
2. Data domain relationships
3. User interface
4. Business rules synchronization

This article is designed for solution architects and MDM architects.

Syndication Challenge

Organizations engage a variety of IT applications to manage business processes and each application has different master data requirements. The ideal MDM solution must generate a complex output structure to meet the needs of those IT applications that consume master data.

The standard SAP NetWeaver MDM syndicator is designed to trigger syndication only on a selected table. However, most companies require syndicated data when a change event is triggered at the parent table, its related child tables, or subchild tables. The standard SAP NetWeaver MDM syndicator capability does not support this type of scenario.

Consider this example: Vendor address data contains a country code field. This field is a lookup from the country table, which includes the country code and country name fields. In this model, the country table contains country code US and country name America (Figure 1). This means that all consuming systems should feature America as the country name for US vendors.

Figure 1

Vendor data in a main table: country code US and country name America

Later, enterprise data standardizations necessitate that the country name be United States of America (Figure 2). The user must apply the update.

Figure 2

The country name changes to United States of America

All vendor records in consuming systems with the US country code must be updated with the country name United States of America. If the syndication is defined at the vendor main table, a change event in the country table does not trigger the syndication event in the vendor main table. To update this information, a change event in the country table should trigger a change event in the vendor main table, and the same for all related lookup tables in the vendor repository.

Three options are available for mitigating SAP NetWeaver MDM syndication challenges:

1. Use a Java Application Programming Interface (API)
2. Use an SAP NetWeaver Process Integration (SAP NetWeaver PI) interface
3. Enable functionality in the user interface (UI)

Option 1. Use a Java API

Use a Java API to trigger a change event in the child table based on the event received from the parent table (Figure 3). Then follow this process:

• Add a new field to the vendor main table to maintain the syndication status
• Write API logic to listen for the change event in the country lookup table, search the corresponding vendors in the vendor main table, and update the syndication status field
• Develop a syndication map to syndicate the vendors with updated syndication statuses
• Enable the master data syndication server (MDSS) to automate the syndication process

Figure 3

Java API or Java Listener detects the changes at the country table and triggers the changes at the vendor table

Option 2. Use an SAP NetWeaver PI Interface

Use an SAP NetWeaver PI interface to trigger an inbound message in the child tables based on the outbound message received from the parent table (Figure 4). Then follow this process:

• Add a new field to the vendor main table, as this field is used to maintain syndication status
• Develop a syndication map to trigger changes in the country lookup table
• The MDSS drops the outbound file with changed country information
• Develop an SAP NetWeaver PI interface to pick up the file and update the corresponding vendors in the vendor main table
• Develop an import map to update the vendor syndication status
• Develop a syndication map to syndicate the vendors with updated statuses
• Enable the master data import server (MDIS) to automate the import process and the MDSS to automate the syndication process

Figure 4

SAP NetWeaver PI server receives the changes from the country table and triggers the changes at the vendor basic data table

Option 3. Enable Functionality in the UI

Enable functionality in the UI to trigger a change event in the child table based on the event received from the parent table, assuming the UI is developed using SAP NetWeaver Portal or SAP NetWeaver Composite Environment (SAP NetWeaver CE) (Figure 5). Then perform this process:

• Add a new field to the vendor main table. This field is used to maintain the syndication status.
• Develop a UI to trigger the API for updating the country name in the country lookup table, and the corresponding vendor syndication status in the vendor main table
• Write logic in the API to perform the above functionality
• Develop a syndication map to syndicate the vendors with the updated status
• Enable the MDSS to automate the syndication process

Figure 5

Java API updates both the country name in the country lookup table and the corresponding vendors in the vendor main table

Choosing one of these three options depends on each individual company’s requirements. However, if you are implementing a UI with SAP NetWeaver Portal or SAP NetWeaver CE, I recommend option 3. This choice requires less effort and produces better performance compared to options 1 and 2.

Data Domain Relationships

Almost all organizations require an established reference between various master data domains because an account can be assigned to a vendor, customer, or product. Similarly, a product might need a reference to a vendor or customer. SAP NetWeaver MDM 7.1 introduced the capability to establish master data domain relationships in a single repository with multiple main tables. However, this concept frequently leads to data redundancy in each repository, as well as additional interfaces to replicate and synchronize data between the related repositories.

In Figure 6, both the vendor master and account master repositories require account information. You can maintain this information in both repositories, or maintain it in one repository and replicate it in another repository using interfaces. Unfortunately, both situations lead to redundant account information.

Figure 6

Existence of account information in both vendor and account master data repositories leads to redundant information

Address this challenge by establishing the reference at the UI and not at the database. Only the account master repository manages and stores account information. When the vendor master needs account information from the account master repository, you can use the UI to retrieve the information. The complete set of vendor master data with vendor account information is saved into the vendor repository (Figure 7).

Figure 7

When the vendor master needs account information from the account master repository, the UI retrieves the information and the required accounting information goes only to the vendor repository

Alternatively, choose a common scenario that requires the vendor and customer accounts to use the same lookup tables such as Country or Region (Figure 8). Placing tables in both repositories leads to data redundancy and an enormous effort to synchronize data between both the repositories.

Figure 8

The vendor and customer accounts use the same lookup tables

This type of challenge must be addressed in architectural design decisions. I recommend placing the common reference data (i.e., lookup tables) in the repository that houses a high frequency of transactions, while another repository references this information via a Data Steward UI (Figure 9). This strategy helps reduce data redundancy, reduce the number of interfaces, and address the critical challenge of reference data synchronization across repositories.

Figure 9

Region and Country lookup tables are located only in the vendor repository

User Interface

For UI challenges, Data Manager is a valuable, standard feature in SAP NetWeaver MDM. It is designed for administrators and isn’t very user friendly, so I recommend that business users refrain from using it to maintain master data because they can easily create data inconsistencies if they do not use it properly.

As a best practice, I recommend you develop a Data Steward UI using either SAP NetWeaver Portal or SAP NetWeaver CE. Data Steward UI is an alternative to using Data Manager. It provides additional advantages, including user-friendly data maintenance forms that enable complex workflow governance processes. It also executes complex business rules either by remote function calls to SAP ERP systems, or internal business rules coded within SAP NetWeaver MDM.

Here are three recommendations for Data Steward UI design and development:

• Use the pre-delivered search forms that allow the user to search for available information in SAP NetWeaver MDM, before requesting it to create a new record
• The best practice is to categorize master data attributes into various functional areas, such as general data, financial data, or company code data (an example for vendor master data). This practice helps simplify the UI and also improves application performance.
• Use the pre-delivered APIs for performing create, read, update, and delete (CRUD) operations. In addition to the readily available APIs, you can develop additional services to meet your requirements

Business Rules Synchronization Challenge

It’s mandatory that you align business rules between SAP NetWeaver MDM and consuming systems such as SAP ERP Central Component (SAP ECC). Rebuilding all the SAP ECC-related business rules in SAP NetWeaver MDM is a challenge that leads to solution complexity, plus increased implementation and maintenance costs.

Some SAP ECC business rules can change over time. Not replicating the updated business rules in SAP NetWeaver MDM results in gaps due to human error. Data flowing from SAP NetWeaver MDM to SAP ECC fails if a variance exists in business rules, which is a common problem in organizations.

As a best practice, I recommend that you call either the remote-enabled function module (RFM) or the Business Application Programming Interface (BAPI) from SAP ECC. This practice executes required validations on the SAP NetWeaver MDM data steward UI before saving the data into SAP NetWeaver MDM.

This technique helps execute required validations without programming all the consuming system business rules into SAP NetWeaver MDM. It also eliminates the risk of a variance of business rules between SAP NetWeaver MDM and consuming systems such as SAP ECC.

Mohammad Assad Shaik

Mohammad Assad Shaik is a senior enterprise information management lead. He is an engineer with expertise in computers and IT architecture. Assad provides expertise to medium-sized and large organizations in diverse industries that include oil and gas, consumer goods and services, financial, manufacturing, chemical, high-tech, telecommunications, insurance, power and energy, and safety and security. Assad is the author of Enterprise Master Data Management Using SAP NetWeaver MDM, which is available in paperback from Amazon.com.

You may contact the author at assad.sm@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.