Life Cycle- CRUD cycle
Master data can be described by the way that it is created, read, updated, deleted, and searched. This life cycle is called the CRUD cycle.
Customer
Product
Asset
Employee
Create
Customer visit such as to Web site or facility; account
Product purchased or manufactured; SCM involvement
Unit acquired by opening a PO; approval process necessary
HR hires, numerous forms, orientation, benefits selection, asset allocations, office assignments
Read
Contextualized views based on credentials of viewer
Periodic inventory catalogues
Periodic reporting purposes, figuring depreciation, verification
Office access, reviews, insurance-claims, immigration
Update
Address, discounts, phone number, preferences, credit accounts
Packaging changes, raw materials changes
Packaging changes, raw materials changes
Immigration status, marriage status, level increase, raises, transfers
Destroy
Death, bankruptcy, liquidation, do-not-call.
Canceled, replaced, no longer available
Obsolete, sold, destroyed, stolen, scrapped
Termination, death
Search
CRM system, call-center system, contact-management system
ERP system, orders-processing system
GL tracking, asset DB management
HR LOB system
Data to be Managed
o Behavior
o Life Cycle
o Cardinality
o Lifetime
o Complexity
o Value
o Volatility
MDM project plan
An MDM project plan will be influenced by requirements, priorities, resource availability, time frame, and the size of the problem. Most MDM projects include at least these phases,
· Identify sources of master data.
· Identify the producers and consumers of the master data
Collect and analyze metadata about for your master data
· Appoint data stewards
· Implement a data-governance program and data-governance council.
· Develop the master-data model
· Choose a toolset
· Design the infrastructure
· Generate and test the master data
· Modify the producing and consuming systems
· Implement the maintenance processes.
MDM is a complex process that can go on for a long time. Like most things in software, the key to success is to implement MDM incrementally, so that the business realizes a series of short-term benefits while the complete project is a long-term process. No MDM project can be successful without the support and participation of the business users. IT professionals do not have the domain knowledge to create and maintain high-quality master data. Any MDM project that does not include changes to the processes that create, maintain, and validate master data is likely to fail. The rest of this paper will cover the details of the technology and processes for creating and maintaining master data.
Ads by Google
Visual Data Integration
Easy to use Data Integration environment. Try now! www.ecrion.com
Mastering Data Management
Proven expertise in Master data management , for Free Consultation global-value-web.com/
Creating a Master List
Whether you buy a tool or decide to roll your own, there are two basic steps to creating master data: clean and standardize the data, and match data from all the sources to consolidate duplicates. Before you can start cleaning and normalizing your data, you must understand the data model for the master data. As part of the modeling process, the contents of each attribute were defined, and a mapping was defined from each source system to the master-data model. This information is used to define the transformations necessary to clean your source data.
Cleaning the data and transforming it into the master data model is very similar to the Extract, Transform, and Load (ETL) processes used to populate a data warehouse. If you already have ETL tools and transformation defined, it might be easier just to modify these as required for the master data, instead of learning a new tool. Here are some typical data-cleansing functions:
Normalize data formats. Make all the phone numbers look the same, transform addresses (and so on) to a common format.
Replace missing values. Insert defaults, look up ZIP codes from the address, look up the Dun & Bradstreet number.
Standardize values. Convert all measurements to metric, convert prices to a common currency, change part numbers to an industry standard.
Map attributes. Parse the first name and last name out of a contact-name field, move Part# and partno to the PartNumber field.
Most tools will cleanse the data that they can, and put the rest into an error table for hand processing. Depending on how the matching tool works, the cleansed data will be put into a master table or a series of staging tables. As each source is cleansed, the output should be examined to ensure the cleansing process is working correctly.
Matching master-data records to eliminate duplicates is both the hardest and most important step in creating master data. False matches can actually lose data (two Acme Corporations become one, for example) and missed matches reduce the value of maintaining a common list. The matching accuracy of MDM tools is one of the most important purchase criteria. Some matches are pretty trivial to do. If you have Social Security numbers for all your customers, or if all your products use a common numbering scheme, a database JOIN will find most of the matches. This hardly ever happens in the real world, however, so matching algorithms are normally very complex and sophisticated. Customers can be matched on name, maiden name, nickname, address, phone number, credit-card number, and so on, while products are matched on name, description, part number, specifications, and price. The more attribute matches and the closer the match, the higher degree of confidence the MDM system has in the match. This confidence factor is computed for each match, and if it surpasses a threshold, the records match. The threshold is normally adjusted depending on the consequences of a false match. For example, you might specify that if the confidence level is over 95 percent, the records are merged automatically, and if the confidence is between 80 percent and 95 percent, a data steward should approve the match before they are merged.
Most merge tools merge one set of input into the master list, so the best procedure is to start the list with the data in which you have the most confidence, and then merge the other sources in one at a time. If you have a lot of data and a lot of problems with it, this process can take a long time. You might want to start with the data from which you expect to get the most benefit having consolidated; run a pilot project with that data, to ensure your processes work and you are seeing the business benefits you expect; and then start adding other sources, as time and resources permit. This approach means your project will take longer and possibly cost more, but the risk is lower. This approach also lets you start with a few organizations and add more as the project demonstrates success, instead of trying to get everybody on board from the start.
Another factor to consider when merging your source data into the master list is privacy. When customers become part of the customer master, their information might be visible to any of the applications that have access to the customer master. If the customer data was obtained under a privacy policy that limited its use to a particular application, you might not be able to merge it into the customer master. You might want to add a lawyer to your MDM planning team.
At this point, if your goal was to produce a list of master data, you are done. Print it out or burn it to a CD, and move on. If you want your master data to stay current as data is added and changed, you will have to develop infrastructure and processes to manage the master data over time. The next section provides some options on how to do just that.
Master data management best practices
When considering a new discipline like master data management (MDM), it's only natural to seek out people who have been there and done that.
But MDM best practices are still emerging and it's not easy to get organizations to talk about their MDM experiences. Kalido Inc., a Burlington, Mass.-based MDM technology vendor, admits that it has a hard time getting customers to talk to the press.
All this secrecy around successful MDM programs doesn't help companies looking for best practices, which is partly why Kalido sponsored a customer audit and MDM best practices study by San Mateo, Calif.-based analyst firm Ventana Research. Its researchers examined the best practices of five anonymous Kalido customers to reach their conclusions. The Ventana study, an experienced consultant, and a European telecom maker finally shed some light on the best (and worst) practices for MDM success.
1. Get business involved -- or in charge.
"MDM has to be driven by business needs, otherwise it may turn out to be just another database that must be synchronized with all the other ones," said David Loshin, president of Knowledge Integrity Inc., a Silver Spring, Md.-based consultancy that provides an MDM strategy development service and has worked on enterprise-scale initiatives.
Similarly, the Ventana study found that businesspeople, rather than IT, should drive the process. Support ranging from C-level executives to senior managers to business end users was critical for success, Ventana found. It's often hard to motivate an organization to get behind the dry prospect of MDM, but early enterprise-wide support is important in the long run, users said. If key corporate goals are tied to the project through a solid business case, it should be a straightforward task to demonstrate benefits and generate excitement.
2. Allow ample time for evaluation and planning.
Plan at least three months for evaluation, talk to reference customers, and do a proof-of-value project with samples of real company data, Kalido users told Ventana researchers. Don't underestimate the time and expertise needed to develop foundational data models, users said.
"It's more complex than people realize -- and that requires starting early and using real data for planning," said David Waddington, a Ventana vice president and research director who worked on the study.
IT's cooperation was an area of concern, as some companies have experienced delays in projects waiting for permission and access rights, Ventana found.
3. Have a big vision, but take small steps.
Consider the ultimate goal, but limit the scope of the initial deployment, users told Ventana. Once MDM is working in one place, extend it step by step, they advised. Business processes, rather than technology, are often the mitigating factor, they said, so it's important to get end-user input early in the process.
"If you're just interested in getting consistent customer data, it's very important to do that against the bigger background of 'how am I going to manage all of my master data longer term?'" Waddington explained. "Then you don't end up in the situation [of] having to link together a whole lot of different solutions."
4. Consider potential performance problems.
Performance is the 800-pound gorilla quietly lurking in the MDM discussion, Loshin cautioned.
Different architectures can mean different performance penalties. For example, if a company uses the master hub style of MDM, record creation flows through a single point, which can become a bottleneck. Also, with many applications relying on MDM, the workflow, system priorities and order of operations become critical issues to consider up front. How companies solve this potential performance problem varies, Loshin said, because it's inherently related to their unique architectures.
5. Institute data governance policies and processes.
Allow time and money for people and process change management, and don't underestimate the size of the job, experts agreed. Swedish telecom equipment maker Ericsson learned that the politics of data governance can be quite difficult, according to Roderick Hall, senior project manager. Long before deploying SAP MDM, the Stockholm-based company instituted a master data group to manage critical data assets. It's a "shared services" group that provides services to both IT and business. The group started as part of the finance department, but the function changed with the realization that master data management was a company-wide concern, Hall said. Their job isn't always easy.
Although some departments, such as finance, saw the value of centralizing master data management, Hall said, other groups were reluctant to give up data ownership.
"To get acceptance of the fact that people have got to give up the freedom to correct their own master data to some faceless group in Stockholm [where the master data group is located] has been a pretty hard battle," Hall said.
6. Carefully plan deployment.
MDM is still relatively new, so training of business and technical people is more important than ever, Ventana found. Using untrained or semi-trained systems integrators and outsourcing attempts caused major problems and project delays for MDM users, Waddington said.
Then, there's the prospect of rolling out a program that has an impact on many critical processes and systems -- no trivial concern. Loshin recommended that companies should plan an MDM transition strategy that allows for static and dynamic data synchronization.
"Trying to adjust the underlying infrastructure without affecting day-to-day operations can be as challenging as fixing potholes in the highway without disrupting traffic," Loshin said.
MDM Architecture
There are three basic styles of architecture used for MDM hubs: the registry, the repository, and the hybrid approach. The hybrid approach is really a continuum of approaches between the two extremes of registry and repository.
While master data management solutions may take many forms, most of them share similar architecture. This architecture is what allows for the accurate, consistent management of data and data processes by maintaining a structured environment under which MDM tools can operate. At the core of these systems is the MDM hub, a database in which master data is cleaned, collected and stored. MDM solutions may use multiple hubs to govern different sets of data, such as product information, customer data and site data, and each hub generally utilizes one of three common models: transaction/repository, registry, or hybrid.
In a transaction/repository-style hub, all relevant data is stored and accessed from a single database, and the database must contain all of the information needed by the different applications which access it. All data is consolidated and centralized, and published to the individual data sources after it has been linked and matched. This style of hub allows for a single source of data to be created, minimizing duplication by making it easier to detect as data is collected and cleaned. However, the transaction/repository style has drawbacks as well. Existing applications may have to be modified to use the master data, and in some cases this is not possible. Different applications and services which serve as an interim interface between the MDM software and the data-dependent applications may be needed and this can add to costs. Also, data models need to be complex enough to include all relevant information for the applications that utilize them, but not so large that they become overly large.
Registry style hubs, in contrast, do not store master data in the hub, but rather master data is maintained within native application databases. The hub instead stores lists of keys with which to access all relevant attributes for a specific master data entity, linking these attributes between application databases. The registry style hub allows for applications to remain fairly intact as all data is managed within native databases. However, when requests are made to access master data, data must be located, a query must be distributed between numerous databases, then a list of the requested data must be formed all in real time, and as the number of source databases grows, this can become increasingly inefficient. In addition, duplicate data entities can reside on different databases, or even within the same database, and while consolidation and cleaning of individual databases would be ideal, it is not always practical. Another disadvantage is that when new databases are to be included in the hub registry, new keys must be added to the existing tables, which may also require altering how queries are generated.
Read more: http://www.articlesbase.com/databases-articles/the-perception-of-master-data-management-3830837.html#ixzz1ZuSjbCqk
Under Creative Commons License: Attribution No Derivatives
Continued....
Showing posts with label erp mdm. Show all posts
Showing posts with label erp mdm. Show all posts
SRM and MDM Episode #1: SRM-MDM Catalog v2.0 is generally available! David Marchand
SRM and MDM Episode #1: SRM-MDM Catalog v2.0 is generally available! David Marchand
Hi all,
For the first episode of the inaugural "SRM and MDM" series, I like to share a good news: SRM-MDM Catalog v2.0 is made available today (actually on August 20th 2007) to all SAP customers (SRM, ERP) running procurement scenarios.
This means any customer who has the right license of SRM or ERP willing to upgrade to SRM-MDM Catalog v2.0 can do it today. The software is available for download on the SAP Service Marketplace: http://service.sap.com/swdc then browse to Download / Installations and Upgrades / Entry by Application Group / Installations and Upgrades / SAP Application Components / SAP SRM Catalog / SRM-MDM CATALOG / SRM-MDM CATALOG 2.0
Before you download the software, you may wish to learn what's new in it and which issues it could solve. But as the Zip file is 678 Mb big, I would suggest to launch the download process anyway and read the rest of this post in the meantime....
There are so many good reasons to adopt SRM-MDM Catalog v2.0 that I run the risk to turn this post into a boring marketing white paper. So I'll just focus on the top 10 reasons:
10- Robust Netweaver MDM Core: v2.0 SP1 relies on MDM 5.5 SP5, which has been proven to be robust and stable
9- Easy migration from v1.0 made possible by a built-in repository converter: check for more details on the dedicated Component Upgrade Guide located on http://service.sap.com/instguides / Installations and Upgrade Guides / SAP Business Suite Applications / SAP SRM / Using SAP SRM Server 6.0. By the way, at the same location, find a number of very interesting documents such as the functional documentation or the business scenario description.
8- Support of relationships between catalog items: Bill of Materials, Sales Kits, Substitutes and Related Items can be modeled now. This is an important step in the direction of direct material management and support of more advanced procurement processes. The concept is to bundle items together, either as parent - children (for BOM and kits) or as siblings (for substitutes and related items). The spectrum of different variants proposed covers the most important business use cases found in procurement scenarios.
7- End-User interface has been upgraded: not only to support the additional functionalities, but also to propose better usability in the search experience.
6- All in one screen: the initial page of the search engine user interface has been divided in 3 parts: Control panel with folders and keyword search / category browsing with a pick list / results with found items. The results of the search (ie: the list of items) are now displayed on the first screen. No need of an additional click now.
5- New Context display of search results: in addition to the traditional list of items in a form of a table, a new display is possible. Items are presented with an image on the left side and selected fields listed next to it.
4- More flexible configuration of the user interface: many changes to support more flexibility have been implemented. As an example, the Open Catalog Interface mapping can be configured per user now, as opposed to per repository in v1.0
3- Shopping Lists: Each user logging to the search engine can create, edit and share shopping lists. A shopping list is a static list of items which are purchased on a regular basis. Using shopping list avoids repetitive search for the items again and again. On a side note, shopping lists are stored in the MDM server as masks, so that a content manager may create them on behalf of the end-users.
2- Catalog Exploring mode for search purpose only: End-user has the possibility to search and browse the catalog but will not be able to order any items.
1- Roadmap of functionalities to be delivered soon: With the v2.0 SP2 planned for the end of the year (mid December), we will deliver a couple of additional functionalities that I am sure you will like a lot:
- Connectivity to electronic forms: it will be possible to call an external electronic form by clicking on an item in the catalog (using the OCI). For example, by clicking on the item "business card", an e-form to configure that business card will be called. Once the user has completed the requested input fields on the e-form, the necessary information are sent back to the SRM-MDM Catalog shopping cart preview.
- Web-based approval cockpit: most of the workflow functions enabled on the MDM Data Manager will be put on a light web-based user interface. Approvers and power-users will not need to have the MDM Data Manager installed on their desktop anymore. They will be able to make decisions (approve, reject) online, just by using their internet Browser.
There will be more again coming up on the SP2 and with SP3 later next year. We will have the opportunity to discuss with more details.
With that, I like to end this first episode of the "SRM and MDM" saga. As always, I like to receive your feedback and suggestions.
The SRM team wishes you a successful implementation of SRM-MDM Catalog v2.0. As we speak, there are 12 customers live with SRM-MDM Catalog. If we can count 20 by the end of the year, I will earn a full bonus. So thanks a lot for your support J
All the best
David.
David Marchand Solution Management for Procurement
Hi all,
For the first episode of the inaugural "SRM and MDM" series, I like to share a good news: SRM-MDM Catalog v2.0 is made available today (actually on August 20th 2007) to all SAP customers (SRM, ERP) running procurement scenarios.
This means any customer who has the right license of SRM or ERP willing to upgrade to SRM-MDM Catalog v2.0 can do it today. The software is available for download on the SAP Service Marketplace: http://service.sap.com/swdc then browse to Download / Installations and Upgrades / Entry by Application Group / Installations and Upgrades / SAP Application Components / SAP SRM Catalog / SRM-MDM CATALOG / SRM-MDM CATALOG 2.0
Before you download the software, you may wish to learn what's new in it and which issues it could solve. But as the Zip file is 678 Mb big, I would suggest to launch the download process anyway and read the rest of this post in the meantime....
There are so many good reasons to adopt SRM-MDM Catalog v2.0 that I run the risk to turn this post into a boring marketing white paper. So I'll just focus on the top 10 reasons:
10- Robust Netweaver MDM Core: v2.0 SP1 relies on MDM 5.5 SP5, which has been proven to be robust and stable
9- Easy migration from v1.0 made possible by a built-in repository converter: check for more details on the dedicated Component Upgrade Guide located on http://service.sap.com/instguides / Installations and Upgrade Guides / SAP Business Suite Applications / SAP SRM / Using SAP SRM Server 6.0. By the way, at the same location, find a number of very interesting documents such as the functional documentation or the business scenario description.
8- Support of relationships between catalog items: Bill of Materials, Sales Kits, Substitutes and Related Items can be modeled now. This is an important step in the direction of direct material management and support of more advanced procurement processes. The concept is to bundle items together, either as parent - children (for BOM and kits) or as siblings (for substitutes and related items). The spectrum of different variants proposed covers the most important business use cases found in procurement scenarios.
7- End-User interface has been upgraded: not only to support the additional functionalities, but also to propose better usability in the search experience.
6- All in one screen: the initial page of the search engine user interface has been divided in 3 parts: Control panel with folders and keyword search / category browsing with a pick list / results with found items. The results of the search (ie: the list of items) are now displayed on the first screen. No need of an additional click now.
5- New Context display of search results: in addition to the traditional list of items in a form of a table, a new display is possible. Items are presented with an image on the left side and selected fields listed next to it.
4- More flexible configuration of the user interface: many changes to support more flexibility have been implemented. As an example, the Open Catalog Interface mapping can be configured per user now, as opposed to per repository in v1.0
3- Shopping Lists: Each user logging to the search engine can create, edit and share shopping lists. A shopping list is a static list of items which are purchased on a regular basis. Using shopping list avoids repetitive search for the items again and again. On a side note, shopping lists are stored in the MDM server as masks, so that a content manager may create them on behalf of the end-users.
2- Catalog Exploring mode for search purpose only: End-user has the possibility to search and browse the catalog but will not be able to order any items.
1- Roadmap of functionalities to be delivered soon: With the v2.0 SP2 planned for the end of the year (mid December), we will deliver a couple of additional functionalities that I am sure you will like a lot:
- Connectivity to electronic forms: it will be possible to call an external electronic form by clicking on an item in the catalog (using the OCI). For example, by clicking on the item "business card", an e-form to configure that business card will be called. Once the user has completed the requested input fields on the e-form, the necessary information are sent back to the SRM-MDM Catalog shopping cart preview.
- Web-based approval cockpit: most of the workflow functions enabled on the MDM Data Manager will be put on a light web-based user interface. Approvers and power-users will not need to have the MDM Data Manager installed on their desktop anymore. They will be able to make decisions (approve, reject) online, just by using their internet Browser.
There will be more again coming up on the SP2 and with SP3 later next year. We will have the opportunity to discuss with more details.
With that, I like to end this first episode of the "SRM and MDM" saga. As always, I like to receive your feedback and suggestions.
The SRM team wishes you a successful implementation of SRM-MDM Catalog v2.0. As we speak, there are 12 customers live with SRM-MDM Catalog. If we can count 20 by the end of the year, I will earn a full bonus. So thanks a lot for your support J
All the best
David.
David Marchand Solution Management for Procurement
How to use the test environment of the MDM Enrichment Controller Andreas Seifried
How to use the test environment of the MDM Enrichment Controller
Andreas Seifried
The MDM Enrichment Controller makes use of 3rd party or custom developed adapters to integrate information from external services into an MDM master data repository.
Through the administrative user interface of the controller, it is possible to test such adapters and their connectivity to the external service. This offers the advantage to
* Perform initial smoke tests of a recently installed 3rd party adapter based on standardized test data, which may be delivered by the provider.
* Test the adapter during development including and its communication with the controller and the external service without the actual need of having the complete MDM stack installed on the developer's workplace
* Manually test the availability of the external service in production without touching live data in the MDM repository
Besides this test environment, SAP additionally delivers a simulation environment that consists of
* An MDM repository containing example workflows and prepared configuration settings
* Sample adapters for testing and education
* Source code of the adapter implementations
* XML documents and schemas
* MDM import and syndication maps
You can use the simulation environment to study the complete request and response cycle form end to end, including the call to a Web service. Since the source code of the adapters is also included, you can use it for education or as a starting point for your own adapter development.
The remainder of this blog briefly explains how to setup the simulation environment and use the test environment with the contained adapters. It is assumed, that you already have deployed the MDM Enrichment Controller on the application server.
The complete procedure is described in the documentation on the SAP Help Portal at http://help.sap.com/saphelp_mdm550/helpdata/en/index.htm
-> MDM Enrichment Architecture
-> Configuring the MDM Enrichment Architecture
-> Setting up an Enrichment Simulation Environment.
Since the sample adapters and the respective Web service are deployed together with the MDM Enrichment Controller, there are basically only two things to do in order to use them in the test environment:
* Using the J2EE Visual Administrator, configure the Web service destination to point to the server where the MDM test Web service was deployed. This is typically the local server or "localhost".
* Include the reference to the adapters in the configuration file of the MDM Enrichment Controller. Since this can only be done within a configuration section of a repository, it makes sense to use the values for the delivery example repository, even if you do not have MDM installed right now. In such a case just use arbitrary settings for the connection details to the MDM server, such as localhost for the host names as in the example below. (Note: Most of it can be copied out of the documentation.)
Destination service in visual admin
Both steps are described in the previously mentioned documentation.
Now you are ready to access the test environment via the admin UI of the MDM Enrichment Controller. See my other blog on the MDM Enrichment Controller Admin UI on how to open this.
MDM Enrichment Controller Admin UI
The link Test Enrichment Provider System brings you to the test environment, where you can now select out of the example adapters (AddressEnrichmentSimulator on the screenshot below) and select an XML file that is fed into the adapter. Together with the MDM Enrichment Controller, SAP ships a file named EC_Simulator.zip. In this file you find XML schemas and example files that are accepted by the example adapters. For instance, you need to feed the file AddressSimulatorOutSample.xml into the chosen adapter as shown in the screenshot.
MDM Enrichment Controller - Test Environment
Content of the sample XML:
13
Bob
Young
GBR
LONDON
23
Glendale Avenue
14
Bob
Young
ZZZ
LONDON
23
Glendale Avenue
After clicking on Test, you can download the XML response of the adapter.
Test result
Content of the response:
13
Bob
Young
GBR
LONDON
23
Glendale Avenue (simulator reply)
DEMO 99
true
14
Bob
Young
ZZZ
LONDON
23
Glendale Avenue
false
ZZZ Country not supported
As you see it is possible to perform this test without initiating the enrichment process from the MDM Data Manager and even without having actually the MDM Server installed. This makes the test environment very valuable during the development phase of an enrichment adapter.
SAP TechEd '07: Come see me speak!
If you are interested in more details about the MDM Enrichment Architecture: I will speak at SAP TechEd in Munich. You can attend there my session MDM350, which explains in detail how to develop and integrate an enrichment adapter.
Cheers,
Andreas
Andreas Seifried is a Product Manager for SAP NetWeaver Master Data Management.
How to use the test environment of the MDM Enrichment Controller
Andreas Seifried
Andreas Seifried
The MDM Enrichment Controller makes use of 3rd party or custom developed adapters to integrate information from external services into an MDM master data repository.
Through the administrative user interface of the controller, it is possible to test such adapters and their connectivity to the external service. This offers the advantage to
* Perform initial smoke tests of a recently installed 3rd party adapter based on standardized test data, which may be delivered by the provider.
* Test the adapter during development including and its communication with the controller and the external service without the actual need of having the complete MDM stack installed on the developer's workplace
* Manually test the availability of the external service in production without touching live data in the MDM repository
Besides this test environment, SAP additionally delivers a simulation environment that consists of
* An MDM repository containing example workflows and prepared configuration settings
* Sample adapters for testing and education
* Source code of the adapter implementations
* XML documents and schemas
* MDM import and syndication maps
You can use the simulation environment to study the complete request and response cycle form end to end, including the call to a Web service. Since the source code of the adapters is also included, you can use it for education or as a starting point for your own adapter development.
The remainder of this blog briefly explains how to setup the simulation environment and use the test environment with the contained adapters. It is assumed, that you already have deployed the MDM Enrichment Controller on the application server.
The complete procedure is described in the documentation on the SAP Help Portal at http://help.sap.com/saphelp_mdm550/helpdata/en/index.htm
-> MDM Enrichment Architecture
-> Configuring the MDM Enrichment Architecture
-> Setting up an Enrichment Simulation Environment.
Since the sample adapters and the respective Web service are deployed together with the MDM Enrichment Controller, there are basically only two things to do in order to use them in the test environment:
* Using the J2EE Visual Administrator, configure the Web service destination to point to the server where the MDM test Web service was deployed. This is typically the local server or "localhost".
* Include the reference to the adapters in the configuration file of the MDM Enrichment Controller. Since this can only be done within a configuration section of a repository, it makes sense to use the values for the delivery example repository, even if you do not have MDM installed right now. In such a case just use arbitrary settings for the connection details to the MDM server, such as localhost for the host names as in the example below. (Note: Most of it can be copied out of the documentation.)
Destination service in visual admin
Both steps are described in the previously mentioned documentation.
Now you are ready to access the test environment via the admin UI of the MDM Enrichment Controller. See my other blog on the MDM Enrichment Controller Admin UI on how to open this.
MDM Enrichment Controller Admin UI
The link Test Enrichment Provider System brings you to the test environment, where you can now select out of the example adapters (AddressEnrichmentSimulator on the screenshot below) and select an XML file that is fed into the adapter. Together with the MDM Enrichment Controller, SAP ships a file named EC_Simulator.zip. In this file you find XML schemas and example files that are accepted by the example adapters. For instance, you need to feed the file AddressSimulatorOutSample.xml into the chosen adapter as shown in the screenshot.
MDM Enrichment Controller - Test Environment
Content of the sample XML:
After clicking on Test, you can download the XML response of the adapter.
Test result
Content of the response:
As you see it is possible to perform this test without initiating the enrichment process from the MDM Data Manager and even without having actually the MDM Server installed. This makes the test environment very valuable during the development phase of an enrichment adapter.
SAP TechEd '07: Come see me speak!
If you are interested in more details about the MDM Enrichment Architecture: I will speak at SAP TechEd in Munich. You can attend there my session MDM350, which explains in detail how to develop and integrate an enrichment adapter.
Cheers,
Andreas
Andreas Seifried is a Product Manager for SAP NetWeaver Master Data Management.
How to use the test environment of the MDM Enrichment Controller
Andreas Seifried
Calculating Dates in MDM-Kristin Patterson
Calculating Dates in MDM
Kristin Patterson
Hi, MDM Users,
I have been asked many a times about the formulas used in the MDM Expression Editors. There are examples throughout the MDM Data Manager Guides but even with these it takes some interpretation to figure out what is happening behind the scenes. As there are millions of expressions, I decided to write an article using just Dates as this seems to be a common field used within MDM and the expression editor.
Calculating Dates in SAP NetWeaver MDM
Even though the examples in the article are related to Dates, the formulas can be applied to other fields. Also, these formulas are used in Calculated Fields, Assignments, and Validations. These being important components of the MDM Workflow.
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b025fab3-b3e9-2910-d999-a27b7a075a16
I hope this leads you to the exploration of even more MDM formulas.
Kristin Patterson
Kristin Patterson is a member of the SAP NetWeaver Solution Office.
Kristin Patterson
Hi, MDM Users,
I have been asked many a times about the formulas used in the MDM Expression Editors. There are examples throughout the MDM Data Manager Guides but even with these it takes some interpretation to figure out what is happening behind the scenes. As there are millions of expressions, I decided to write an article using just Dates as this seems to be a common field used within MDM and the expression editor.
Calculating Dates in SAP NetWeaver MDM
Even though the examples in the article are related to Dates, the formulas can be applied to other fields. Also, these formulas are used in Calculated Fields, Assignments, and Validations. These being important components of the MDM Workflow.
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b025fab3-b3e9-2910-d999-a27b7a075a16
I hope this leads you to the exploration of even more MDM formulas.
Kristin Patterson
Kristin Patterson is a member of the SAP NetWeaver Solution Office.
How to work with Command in the new MDM Java API Vijendra Singh Bhanot
How to work with Command in the new MDM Java API
Vijendra Singh Bhanot
I am new to the MDM Java API. For one of the existing project I was asked to explore the new MDM Java API. I do not have any experience with the earlier MDM4J but still I was able to understand and explore the new MDM Java API. I think this API is excellent and I am almost fallen in love with it. The best part I like about this API is the Commands. Initially it took me time to understand the concept but very soon it was all clear. With this blog I would like to share my knowledge about how to work with Commands. Also in this blog you will see an example of Validation Command.
Why you need a Command? What is a Command?
I command the MDM Java API to get me the list of Validations …..
Well, that’s what the idea is.
Command is a special class that instructs MDM Java API to perform some action. All actions like managing repository content, searching records, managing repository schema and etc, have dedicated commands.
All these commands are logically organized in packages. You can always refer Java Doc to identify which Command you need to use. (https://help.sap.com/javadocs/MDM/current/index.html)
How to Use a Command?
All Command’s are used in the following way:
1 RetrieveValidationsCommand objRetrieveValidationsCommand = new RetrieveValidationsCommand();
2 objRetrieveValidationsCommand.setSession();
3 objRetrieveValidationsCommand.setTableId(<>); // Required
try {
4 objRetrieveValidationsCommand.execute();
} catch (CommandException e) {
e.printStackTrace();
return;
}
(1) You create a new instance of a particular command by passing it the ConnectionAccessor object.
(2) The very second step is mostly the setSession(). Here it is important that you use the right type of session (Server Session, Repository Session or User Session). For Example, you may not be able to get list of validations if you use a Repository Session instead of User Session.
As I already mentioned that setSession() is not always the second step. Actually the commands responsible for creation of session are the ones that do not require a session. Thus these commands (CreateServerSessionCommand, CreateRepositorySessionCommand and CreateUserSessionCommand) do not require setSession().
(3) Some commands require specific setter method to be set before it is used. These setter methods are marked as “Required” in the Java Dock. There are few which are marked optional.
(4) Inside a try block you execute the command. If there is an error then CommandException is thrown.
Here is a sample of RetrieveValidationsCommand in action…
/*
* Created on Feb 7, 2008
*
* To change the template for this generated file go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
package demo.validation;
import com.sap.mdm.commands.AuthenticateUserSessionCommand;
import com.sap.mdm.commands.CommandException;
import com.sap.mdm.commands.CreateUserSessionCommand;
import com.sap.mdm.commands.GetRepositoryRegionListCommand;
import com.sap.mdm.data.RegionProperties;
import com.sap.mdm.ids.TableId;
import com.sap.mdm.net.ConnectionException;
import com.sap.mdm.net.ConnectionPool;
import com.sap.mdm.net.ConnectionPoolFactory;
import com.sap.mdm.server.DBMSType;
import com.sap.mdm.server.RepositoryIdentifier;
import com.sap.mdm.validation.ValidationProperties;
import com.sap.mdm.validation.ValidationPropertiesResult;
import com.sap.mdm.validation.commands.RetrieveValidationsCommand;
/**
*
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
public class GetListOfValidations {
public static void main(String[] args) {
// create connection pool to a MDM server
String serverName = "LOCALHOST";
ConnectionPool connections = null;
try {
connections = ConnectionPoolFactory.getInstance(serverName);
} catch (ConnectionException e) {
e.printStackTrace();
return;
}
// specify the repository to use
// alternatively, a repository identifier can be obtain from the GetMountedRepositoryListCommand
String repositoryName = "INQDemo";
String dbmsName = "localhost";
RepositoryIdentifier reposId =
new RepositoryIdentifier(repositoryName, dbmsName, DBMSType.ORACLE);
// get list of available regions for the repository
GetRepositoryRegionListCommand regionListCommand =
new GetRepositoryRegionListCommand(connections);
regionListCommand.setRepositoryIdentifier(reposId);
try {
regionListCommand.execute();
} catch (CommandException e) {
e.printStackTrace();
return;
}
RegionProperties[] regions = regionListCommand.getRegions();
// create a user session
CreateUserSessionCommand sessionCommand =
new CreateUserSessionCommand(connections);
sessionCommand.setRepositoryIdentifier(reposId);
sessionCommand.setDataRegion(regions[0]); // use the first region
try {
sessionCommand.execute();
} catch (CommandException e) {
e.printStackTrace();
return;
}
String sessionId = sessionCommand.getUserSession();
// authenticate the user session
String userName = "admin";
String userPassword = "admin";
AuthenticateUserSessionCommand authCommand =
new AuthenticateUserSessionCommand(connections);
authCommand.setSession(sessionId);
authCommand.setUserName(userName);
authCommand.setUserPassword(userPassword);
try {
authCommand.execute();
} catch (CommandException e) {
e.printStackTrace();
return;
}
// the main table, hard-coded
TableId mainTableId = new TableId(1);
// Get the list of validations
RetrieveValidationsCommand objRtvVldCmd =
new RetrieveValidationsCommand(connections);
// set the user session
objRtvVldCmd.setSession(sessionId);
// get validation for the following tables.
objRtvVldCmd.setTableId(mainTableId);
try {
objRtvVldCmd.execute();
} catch (CommandException e) {
e.printStackTrace();
return;
}
ValidationPropertiesResult objVldPropRslt =
objRtvVldCmd.getValidationPropertiesResult();
ValidationProperties[] validations = objVldPropRslt.getValidations();
//disply --> Validation ID | error/warning message | Validation Name
for (int i = 0; i < validations.length; i++) {
System.out.println(
validations[i].getId()
+ " | "
+ validations[i].getMessage()
+ " | "
+ validations[i].getName());
}
}
}
Vijendra Singh Bhanot is a certified XI Consultant
SAP MDM Training
SAP MDM Training
Vijendra Singh Bhanot
I am new to the MDM Java API. For one of the existing project I was asked to explore the new MDM Java API. I do not have any experience with the earlier MDM4J but still I was able to understand and explore the new MDM Java API. I think this API is excellent and I am almost fallen in love with it. The best part I like about this API is the Commands. Initially it took me time to understand the concept but very soon it was all clear. With this blog I would like to share my knowledge about how to work with Commands. Also in this blog you will see an example of Validation Command.
Why you need a Command? What is a Command?
I command the MDM Java API to get me the list of Validations …..
Well, that’s what the idea is.
Command is a special class that instructs MDM Java API to perform some action. All actions like managing repository content, searching records, managing repository schema and etc, have dedicated commands.
All these commands are logically organized in packages. You can always refer Java Doc to identify which Command you need to use. (https://help.sap.com/javadocs/MDM/current/index.html)
How to Use a Command?
All Command’s are used in the following way:
1 RetrieveValidationsCommand objRetrieveValidationsCommand = new RetrieveValidationsCommand(
2 objRetrieveValidationsCommand.setSession(
3 objRetrieveValidationsCommand.setTableId(<>); // Required
try {
4 objRetrieveValidationsCommand.execute();
} catch (CommandException e) {
e.printStackTrace();
return;
}
(1) You create a new instance of a particular command by passing it the ConnectionAccessor object.
(2) The very second step is mostly the setSession(
As I already mentioned that setSession(
(3) Some commands require specific setter method to be set before it is used. These setter methods are marked as “Required” in the Java Dock. There are few which are marked optional.
(4) Inside a try block you execute the command. If there is an error then CommandException is thrown.
Here is a sample of RetrieveValidationsCommand in action…
/*
* Created on Feb 7, 2008
*
* To change the template for this generated file go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
package demo.validation;
import com.sap.mdm.commands.AuthenticateUserSessionCommand;
import com.sap.mdm.commands.CommandException;
import com.sap.mdm.commands.CreateUserSessionCommand;
import com.sap.mdm.commands.GetRepositoryRegionListCommand;
import com.sap.mdm.data.RegionProperties;
import com.sap.mdm.ids.TableId;
import com.sap.mdm.net.ConnectionException;
import com.sap.mdm.net.ConnectionPool;
import com.sap.mdm.net.ConnectionPoolFactory;
import com.sap.mdm.server.DBMSType;
import com.sap.mdm.server.RepositoryIdentifier;
import com.sap.mdm.validation.ValidationProperties;
import com.sap.mdm.validation.ValidationPropertiesResult;
import com.sap.mdm.validation.commands.RetrieveValidationsCommand;
/**
*
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
public class GetListOfValidations {
public static void main(String[] args) {
// create connection pool to a MDM server
String serverName = "LOCALHOST";
ConnectionPool connections = null;
try {
connections = ConnectionPoolFactory.getInstance(serverName);
} catch (ConnectionException e) {
e.printStackTrace();
return;
}
// specify the repository to use
// alternatively, a repository identifier can be obtain from the GetMountedRepositoryListCommand
String repositoryName = "INQDemo";
String dbmsName = "localhost";
RepositoryIdentifier reposId =
new RepositoryIdentifier(repositoryName, dbmsName, DBMSType.ORACLE);
// get list of available regions for the repository
GetRepositoryRegionListCommand regionListCommand =
new GetRepositoryRegionListCommand(connections);
regionListCommand.setRepositoryIdentifier(reposId);
try {
regionListCommand.execute();
} catch (CommandException e) {
e.printStackTrace();
return;
}
RegionProperties[] regions = regionListCommand.getRegions();
// create a user session
CreateUserSessionCommand sessionCommand =
new CreateUserSessionCommand(connections);
sessionCommand.setRepositoryIdentifier(reposId);
sessionCommand.setDataRegion(regions[0]); // use the first region
try {
sessionCommand.execute();
} catch (CommandException e) {
e.printStackTrace();
return;
}
String sessionId = sessionCommand.getUserSession();
// authenticate the user session
String userName = "admin";
String userPassword = "admin";
AuthenticateUserSessionCommand authCommand =
new AuthenticateUserSessionCommand(connections);
authCommand.setSession(sessionId);
authCommand.setUserName(userName);
authCommand.setUserPassword(userPassword);
try {
authCommand.execute();
} catch (CommandException e) {
e.printStackTrace();
return;
}
// the main table, hard-coded
TableId mainTableId = new TableId(1);
// Get the list of validations
RetrieveValidationsCommand objRtvVldCmd =
new RetrieveValidationsCommand(connections);
// set the user session
objRtvVldCmd.setSession(sessionId);
// get validation for the following tables.
objRtvVldCmd.setTableId(mainTableId);
try {
objRtvVldCmd.execute();
} catch (CommandException e) {
e.printStackTrace();
return;
}
ValidationPropertiesResult objVldPropRslt =
objRtvVldCmd.getValidationPropertiesResult();
ValidationProperties[] validations = objVldPropRslt.getValidations();
//disply --> Validation ID | error/warning message | Validation Name
for (int i = 0; i < validations.length; i++) {
System.out.println(
validations[i].getId()
+ " | "
+ validations[i].getMessage()
+ " | "
+ validations[i].getName());
}
}
}
Vijendra Singh Bhanot is a certified XI Consultant
SAP MDM Training
SAP MDM Training
Using MDM WEB UI for tracking changes with Oracle Faycal CHRAIBI
The MDM Change tracking feature allows you to monitor any modification made to your master data repository and get useful information regarding this alteration such as the old value, the person who made the change or the modification date.
Although the activation of this feature is made through the MDM console, you will need to deploy the MDM WEB UI (delivered as a portal content) in order to visualize these information.
Unlike other portal contents, the Change tracking UI queries the database in order to get the information. The MDM RKT documents contains an excellent how-to deploy and configure this webdynpro but it doesn't cover the Oracle implementation which requires a specific configuration for the JDBC connector.
Make sure you have the latest support package of MDM (MDM 5.5 SP05 at the time being, the SP06 will be soon released to public). You will also need an SAP Web Application Server with a Java stack.
If you want to use this within a portal iView, deploy the Portal software units on the J2EE engine (note 883948).
As a pre-requisite, download the Oracle JDBC driver from Oracle website. Note 867176 may help you choose the appropriate driver.
First of all, download the MDM WEB UI latest build from the SAP Marketplace Software Distribution Center. Navigate to Support Packages and Patches -> SAP NetWeaver -> SAP MDM -> SAP MDM 5.5 -> Portal Content -> OS Independent, download the .sca file and deploy it through SDM.
The next step will consist in configuring your JDBC connection.
Open Visual Administrator, navigate to Cluster -> Server
Select drivers and click on the Create button.
Name your driver (ex: Oracle_JDBC)
Load the JDBC driver file you had downloaded
You should then see your new driver in the list
Select then DataSources, create a new datasource.
Provide an application name (this one should be unique), create an alias for this datasource (it will be used later in the webdynpro configuration).
Fill the information according to your database settings.
Click on the "Additional" tab and fill these information :
- applicationName: this can be set to any name as long as it hasn't been used previously.
- databaseName: this needs to be set to
_Z000 . In our case, the repository is called CATALOGRECETTE. You may find its name thanks to the following SQL query: SELECT table_name from all_tables where table_name LIKE ‘%Z000';
- user: this should be set to the owner of your A2i_CM_History table (this where MDM stores the change tracking information). You may get the owner name through the SQL query: SELECT owner from all_tables where table_name = ‘A2i_CM_History';
- password: this is your user's password for Oracle
- portNumber: fill it according to your tnsnames or listener configuration.
- serverName: refers to the host of the Oracle instance
- url: this is the connection string that will be used by the JDBC driver to connect to Oracle. It is of form jdbc:oracle:thin:@
: .:
You may keep the default information for connection pooling.
And select "Vendor SQL" for the SQL engine.
Further information, on JDBC configuration, can be found on the SAP NetWeaver Library at the following address: http://help.sap.com/saphelp_nw70/helpdata/en/ab/082484173ae045ab8dad8a41d33da3/frameset.htm
Make sure you have enabled tracking changes in the MDM console (Repository -> Admin -> Change Tracking), and make few changes to your master data in order to have few entries in your A2i_CM_History table.
Access your webdynpro through http://
In our case the Alias was : CATALOGRECETTE.
You may refer to the MDM Tracking changes RKT (available under Enhanced Generic Capabilities) which provides information on how to use this webdynpro with SAP MDM Data Manager or within an iView.
Faycal CHRAIBI is a NetWeaver Technical Architect at SAP and has been dealing with SOA and Enterprise SOA for a few years. He is highly interested by end to end process integration, agility and efficient model driven architectures.
Using MDM WEB UI for tracking changes with Oracle
Faycal CHRAIBI
MDM - Road Ahead Ketan Phanse
MDM - Road Ahead
Ketan Phanse
The road ahead for MDM seems bright and shiny... atleast as per a recent survey published by MDM Institute!http://www.tcdii.com/0809milestonesonmdmroadmap.html
So as SAP MDM continues to be rated as one of the most valued SAP skills, MDM's market would continue to mature and grow in 2008-09. What does that mean for all of us?
- As more verticals/industries would move into MDM we will see more niche master data objects being mastered. Some of them can be Patients for Healthcare, Well for Oil & Gas, MRO for Manufacturing, Fixed Assets for Service industry etc. This would mean that the limited repositories provided by SAP would not be sufficient. More functional knowledge and expertise would be required to model such niche repositories.
- One of the strong business case for MDM is M&A and in 2007-08 we saw lot of M&A within the MDM space itself! The SAP-BO, Microsoft-Siperian, Oracle-Cognos etc would enhance the functionalities of these core MDM products. This means a fast continuous skills upgrade for us and to keep pace with the technology. It started with SAP ERP, then to BI, SRM and now Business Objects. To learn all these new technologies as they begin to integrate with SAP MDM would be a task we all need to be upto for.
- As mentioned in the roadmap, throughout 2009-10, skill shortages will greatly inflame project costs as demand for data stewards, enterprise data architects, & individuals with data governance experience outstrip market supply. Hence SAP MDM Consultants on the SI side must try to build an identity for themselves on their skill set and experience.
These are some of the learning’s/outlooks we must look forward in MDM trends in up-coming years. The roadmap also throws light on SOA, data governance for MDM etc. Given all this speculation & competition, one can hope that SAP MDM continues to mature and out-pace and out-perform its competitors in technology, capability and functionalities!
Ketan Phanse is a SAP MDM Business Analyst in Wipro Technologies
MDM - Road Ahead
Ketan Phanse
Strategic Data Services for SAP NetWeaver MDM Markus Ganser
Strategic Data Services for SAP NetWeaver MDM
Markus Ganser
On behalf of the SAP field services and SAP development teams involved with SAP NetWeaver Master Data Management (MDM) I'd like to announce the availability of SAP Strategic Data Services (SDS) for SAP NetWeaver MDM. This offering comprises complementary high-quality customer services all along the life cycle of an MDM implementation project. SDS is staffed with MDM architects and SAP experts from consulting and development.
End-to-end implementation acticvities include:
- Data-quality analysis
- Project scoping, planning and estimation
- Master-data modeling and taxonomy creation
- Implementation of business rules and matching strategies to enable data consolidation
- Development and roll-out of data, data-process governance and methodologies
- Services in data cleansing, validation, enrichment and classification, including certified third party data-quality services
- Definition, design and configuration of MDM system architecture
- Tuning and optimization of MDM performance
- Custom API and SOA development services
If you are interested in SAP NetWeaver MDM or have already purchased it and like to move to the next steps, SDS could be a great opportunity to engage. The SDS front-office is staffed with MDM-experienced consultants from SAP field services, while the SDS back-office is part of the MDM development team. This combined approach makes SDS a service provider with vast and first hand experience with MDM and data issues. In addition, SDS enables you to directly engage with MDM-certified business information providers and data quality partners. The team is ready to help you make your MDM and data projects a sustained success.
See also the SDS overview graphic:
For detailed information, send an email to Ronen.Liper@SAP.com and Hermann.Reiter@sap.com.
Markus Ganser joins the product management team of SAP Master Data Management
Integrating MDM Item-Details-iView into a WebDynpro Application Steffen Ulmer
Integrating MDM Item-Details-iView into a WebDynpro Application
Steffen Ulmer
You want to access the MDM ItemDetails iView directly without the MDM Search capabilities?
Or do you want to write your own MDM-WebDynpro iView and want to use the existing ItemDetails iView within this WebDynpro?
If so you should read this weblog.
The referred article will show you how to integrate the SAP MDM 5.5 Business Package- iView functionality into a SAP WebDynpro. With SAP MDM 5.5 SP4 there is a very good possibility to position the ItemDetails IView on a WebDynpro View via the iFrames-UI element. The result is that you have the capacity to use existing and configurable iView within your self-programmed WebDynpro application. This procedure will save you a lot of costs and time during the implementation phase. The integration of the HTMLB-based IView and the WebDynpro based outer-View is transparent and the user will feel like it is only one application.
Please open this article: Integrating MDM Item-Details-iView into a WebDynpro Application
Or do you want to write your own MDM-WebDynpro iView and want to use the existing ItemDetails iView within this WebDynpro?
If so you should read this weblog.
The referred article will show you how to integrate the SAP MDM 5.5 Business Package- iView functionality into a SAP WebDynpro. With SAP MDM 5.5 SP4 there is a very good possibility to position the ItemDetails IView on a WebDynpro View via the iFrames-UI element. The result is that you have the capacity to use existing and configurable iView within your self-programmed WebDynpro application. This procedure will save you a lot of costs and time during the implementation phase. The integration of the HTMLB-based IView and the WebDynpro based outer-View is transparent and the user will feel like it is only one application.
Please open this article: Integrating MDM Item-Details-iView into a WebDynpro Application
Steffen Ulmer is a SAP NetWeaver Technology Consultant.
Contextual overview of SAP NetWeaver MDM Markus Ganser SAP Employee
Contextual overview of SAP NetWeaver MDM
Markus Ganser 
|
SDN features a new article on SAP NetWeaver Master Data Management (MDM) emphasizing the business strategy and business implications involved.
So, this rather non-technical article sheds light on the overall business strategy followed when implementing MDM, it gives clear insight into the scenario approach, verticalization and extensibility of the product, and finally stresses the importance of MDM as a pillar for companies seeking to operate on the basis of an enterprise service-oriented architecture.
Check it out by clicking the URL above, it's also worthwile reading for techies.
Best wishes,
MarkusMarkus Ganser joins the product management team of SAP Master Data Management
SAP MDM - One bite at a time Dattatreya Kulkarni
SAP MDM - One bite at a time
Dattatreya Kulkarni
SAP MDM: One bite at a time!
“We have a very complex way of managing master data that is spread over multiple systems. We have developed this solution long back and it has evolved over years. When we implemented it first, we did want to establish data governance models and the associated processes, in addition to making the IT solution available. However, reasons – good or bad, made us postpone this for future since the implementation deadline was around the corner and we did not want the business to wait. We have been growing rapidly over last 7 years and have acquired 3 companies in the process. Most of our energy & resources have been spent on integrating the new companies with us. We never got the time to go back to the pending matter of data governance model. Today there are many users who can create and change data as per their priority in their system. We have no control on who is changing what and we are not sure where and how to correct it”
These are the words of some customers, who want to implement a complete master data management solution but are unable to visualize how they would manage to do that while keeping the business running in the given scenario.
While we all know that SAP MDM allows an incremental approach in terms of implementing the IT scenarios, it is also useful to know that one can break this up further and choose to start off with just one master data object. For example, one can choose to focus only on material/product master and follow the incremental approach from content consolidation to central master data management. Further, one can choose to go Business Unit (BU) wise & so on.
By staying focused on one master data object,
a. You can manage the data owners (especially when you are a global company) better
b.You can manage the change associated with the new solution effectively
c.You can implement the new processes/practices in a smaller group more easily
d.You can plan to spend the required time and resources to establish the data governance model, even while keeping the overall project timeline and cost under control (as against a large big bang, all-objects-together approach)
e.You can leverage on the success of this object to get a faster buy in from other data owners and senior management
f.You can make project management a less complex matter & rather focus on the solution
g.You lower the risk (of failure) associated with the initiative
The question to be answered next: “which master data object to start with?” I can think of two options.
Option one, is to choose an object that is the least complex has lowest volumes and is the least spread across many IT systems. The chances that you complete a project initiative around this object fast and smooth are high. You could then leverage this success to get the required resources to take up others. The flip side of this is that you will may find it difficult to make a business case for investing in this initiative, since benefits gets postponed.
Option two, is to take up an object that poses immediate & critical challenges to your business (irrespective of the complexities involved around that object). This approach will help you deliver tangible business benefits quicker. Also, the chances that you get excellent support from business are high since they have high stakes in the project, owing its potential of creating an immediate-n-positive impact!
An approach that works at one company may not work at other. This has to be arrived at after deliberations within the company under the guidance of an experienced external partner. SAP MDM enables you to adopt this approach with its flexibility as you can choose to go object by object and focus on one repository at a time (from design to Go Live). The ease with which you can integrate it in your IT landscape makes the case stronger. In SAP MDM lies a workable solution to address the concerns like the one that I shared at the beginning of this note. Hence, you take a bite at a time; chew what you bit before taking the next bite, using SAP MDM.
I wanted to bring up this thought since many large companies do face this challenge. However, it does not mean that a company can not adopt a big bang approach using SAP MDM. If business and IT are committed to make it successful and if the business scale and market environment allows adoption of a big bang approach, it will work & will have its own benefits.
Dattatreya Kulkarni is the head of SAP Logistics and Supply Chain Management Practice in Wipro Technologies.
Testing and Monitoring an Interface Between MDM & XI Harrison Holland
Testing and Monitoring an Interface Between MDM & XI
Harrison Holland
1. MDM
First we'll start with the syndication process in MDM, and making sure our settings are correct.
1.1 Check Configuration
1.1.1 Client-Side Settings
- Open the MDM Console
- Navigate to Ports in the repository to which your map is located.
- Verify that you have selected the correct map (built in Part I)
- Select your processing mode as Automatic
- Open the MDM Syndicator (Select the repository and press OK)
- Select File->Open
- Select the remote system representing ECC
- Select your map and press OK
- Select the Map Properties tab
- Check Suppress Unchanged Records so we automatically update only changed records.
- Close and save your map
1.1.2 Server-Side Settings
- Open your mdss.ini file on the MDM server
- Verify that Auto Syndication Task Enabled=True
- For testing purposes, change the Auto Syndication Task Delay (seconds) to something rather small, such as 30 or less. This way you don't have to wait a long time for syndication when testing.
- Verify that the service is started.
- UNIX systems: ps -ef | grep mdss
- WINDOWS systems: open services, and look for entry regarding syndication server
- If service is not running, run command ./mdss (UNIX) or rightclick->start service (WINDOWS)
1.2 Important Locations
I'd like to go over some of the important locations (directories) on your server that will come in handy when troubleshooting and testing. One of the trickiest parts of working with MDM is figuring out where things go and where to look. Because it's so different from the SAP software that we are all used to, navigating the system is not as easy as running a transaction code. Also, MDM reacts to certain situations differently that you may expect, so it's important to know where to look when things aren't working properly. I'm working with MDM installed on HP-UX, however I will try to address each topic as it would appear in Windows to the best of my knowledge.
1.2.1 Home
Log onto your MDM server and navigate to the home directory for the MDM application server. On the server I am working with (sandbox) it happens to be located on the opt filesystem, and the path looks like /opt/MDM. In this directory take note of several important directories:
- /opt/MDM/Distributions
/opt/MDM/Logs
/opt/MDM/bin
The Distributions folder is very important because this is where the port directories get created. When you create a port in the MDM Console for a particular repository, it creates a subset of folders in the Distributions directory based on which repository the port was created in, and whether the port is inbound or outbound. For example, in our particular scenario we may navigate to the path /opt/MDM/Distributions/install_specific_directory/Material/Outbound/. Here we will notice a folder entitled ECC which (if you followed the fist part of this series) corresponds to the port that we created earlier. This directory was created as soon as the port was created in the MDM Console. We will focus more on the contents of our port directory shortly.
The Logs folder contains several important log files, however most of them will not apply to our particular scenario, because the logs that we will want to look at are going to be specific to the syndication process, and are located within the port directory. Neverless, I thought it was important to mention that in certain troubleshooting scenarios, don't forget that these log files also exist.
The Bin directory is critical because that is where the files that start the app servers are located. The programs mds, mdss, and mdis are critical files.
1.2.2 Port
Your port directory is going to have the following format:
/MDM_HOME_DIRECTORY/Distributions/MDM_NAME/REPOSITORY/Outbound/REMOTE_SYSTEM/CODE/
For example the we created looks like this:
/opt/MDM/SID.WORLD_ORCL/Material/Outbound/ECC/Out_ECC/
Here you should see the following directories:
- /Archive
/Exception
/Log
/Ready
/Status
The Archive directory is not as important during the process of syndication as it is with the process of importing data into MDM. This directory contains the processed data. For example, if you were to import an XML document containing material master data, a message would get placed in the archive directory for reference later if you ever needed to check.
The Exception directory is very important because often times when an error occurs you can find a file has been generated in the Exceptions folder that should look similar to that file that either the import server or the syndication server are attempting to import or syndicate. In other words, lets say you were attempting to import an XML document that contained material master data, but the map that was built in MDM has a logic error, the document will instead get passed to the Exceptions folder and the status of the port will be changed in the MDM Console program to "blocked".
The Log directory is important for the obvious reason. Logs are created each time the syndication server runs. So if your interval is 30 seconds, then a log will be generated in this folder every 30 seconds. It will give you the details of the syndication process which ultimately can be critical in the troubleshooting process.
The Ready folder is the most important folder in our scenario. When the Syndication Server polls during it's interval and performs the syndication, the generated XML message will appear in the Ready folder. So in the case of our scenario, we are going to have material master data exported to this directory and ultimately Exchange Infraustructure is going to pick up the data and process it to ECC.
The Status directory contains XML files that hold certain information pertaining to the import / export of data. This information includes processing codes and timestamps.
1.3 Testing
Now are going to test out our scenario and make sure that the export of materials works correctly. First things first, we need to create a new material in the MDM Data Manager. Make sure that your MDM syndication server is turned on! Remember on UNIX we can start it by running ./mdss in the /bin directory, and on Windows by simply starting the service.
1.3.1 MDM Data Manager
- Start MDM Data Manager
- Connect to Material repository.
- Add a new material by "right-click".
- Fill in required fields to satisfy the map built in Part I.
- Verify the new product is saved by clicking elsewhere in the Records screen, and then back to the new Material.
1.3.2 Check Syndication
We are now going go verify that the syndication process is taking place as it should based on the settings in your mdss.ini file. If you have set the MDM Syndication Server to perform the syndication process every 30 seconds, as I set it for testing purposes, then by the time you log into your server the syndication should have already occured. Lets check by logging onto the server and navigating to the Ready folder in our Port directory.
/opt/MDMSID.WORLD_ORCL/Material/Outbound/ECC/Out_ECC/
If all went as planned your Ready folder may look something like this:
Those files are XML files that contain the data for each material in your repository that has changed. In this case the only materials in my repository are the two that I just added, so the MDM Syndication Server updated the Ready folder with both new materials. Now they are waiting for XI to pick them up and process them. Before we move over to the XI part lets take a look at one of these files and verify that the data in them is correct. Keep in mind that if you have already configured XI to pick up the files from this directory and process them, it's possible you won't see them here because they have already been deleted by XI (based on the settings in your communication channel).
1.3.3 Verify Data
Lets go ahead and open one of these files. I copied the file from the server to my local Windows running computer to examine the file, but of course you can read the file straight from the server if you prefer. If your mapping was done similar to mine, your file should look like a MATMAS05 IDoc in XML structure. This is to make it easier for XI to process since we can export in this format from MDM without much difficulty.
2. Exchange Infrastructure
Now we'll take a look at the second half of this scenario and test out our XI interface.
2.1 Check Configuration
The only configuration we are going to check is the outbound communication channel. This is what tells Exchange Infrastructure where to pick up what file (location, filename) and do what after it's processed by the inbound communication channel (processing mode, ie: delete).
- Start your Integration Directory (Integration Builder: Configuration).
- Navigate to your outbound communication channel.
- Examine your File Access Parameters.
In my case, because this is a test scenario, I have a bash script picking up the file from the port directory and dropping it onto a drive that all of the SAP systems have access to; this being the /depot filesystem. As you can see I made a temporary folder on that filesystem for the files for this interface to be stored while waiting to be processed. Of course, the simplest way to do this would be to mount the Port directory from your MDM machine to your XI machine. Next take a look at your Processing Parameters and change the settings accordingly. For this particular scenario I have set the poll interval to 5 seconds for testing purposes. Also, notice that I am using delete as the processing parameter. This is so that I can verify that the file was processed, and so the folder doesn't get cluttered up with files.
If everything is the way you want it, lets go ahead and take a look at some important locations that will come in handy for testing and debugging the interface.
2.2 Important Locations
2.2.1 Integration Repository - Map Testing
Start the Integration Repository (Integration Builder: Design) and navigate to the map that we built in Part II. Select the Test tab.
To test our map, we can actually use the XML document that MDM generated via the Syndication Server. Lets go ahead and try this.
- Press the "Load Test Instance" button.
- Select the XML file MDM generated.
- Press the "Start Transformation" button.
If everything went smooth then you should see a pop up screen that says "Executed successfully". Otherwise you will recieve an error to which you can begin your debugging process.
2.2.2 Runtime Workbench - Component Monitoring
The runtime workbench is one of the most powerful and useful features of Exchange Infrastructure. Here we can get very detailed descriptions of errors that may occur with each component of XI. The component that we will want to pay particular attention to is the Adapter Engine.
- Log into your runtime workbench and select Component Monitoring -> Display.
- Click the Adapter Engine link.
Here you can view the status of the adapter. If there is an error in your configuration of a particular adapter it will show up here.
2.2.3 Runtime Workbench - Message Monitoring
Follow a similar procedure to display that Message Monitoring.
- Select your time filter, in this case I will select the last hour.
- Press Start.
You can now see the list of messages that have been processed by the Adapter Engine over the last hour. On my system only one message has been processed in the last hour. You can press either Details or Versions to view more information about any particular message that was processed.
2.2.4 Integration Engine - Monitoring
This is a particularly useful component of Exchange Infrastructure that allows us to view various aspects of the messages that get processed. Lets start by logging into the XI system and taking a look.
- Run transaction SXMB_MONI.
- Double-click Monitor for Processed XML Messages.
- Press F8 or the Execute button.
- Select a message and press Display.
You may notice that I have selected a message that coantains an error and did not actually reach it's destination. In Call Adapter -> SOAP Header take a look at Error. If you double click that button a screen will appear on the right hand side that shows the details of the error.
This error tells us that something is wrong with the IDoc Adapter. It tells us that transaction IDX1 contains errors, but in this case the error is actually in the configuration of our communication channel, in which we have made reference to the wrong Port. If you select Call Adapter -> Payloads you can see the content of the XML message that came from MDM.
If you go back to SXMB_MONI you may want to also take a look at the Processing Statistics program that will show a good overview which can be helpful when testing your interface with thousands of materials.
3. Testing
Now we're going to go ahead and test out the interface from end to end. I'm assuming that by now you have turned on the MDM Syndication Server and your XI interface is activated in the Integration Directory. Lets log into the MDM Data Manager and create a new material for testing purposes.
- Right click -> Add
- Enter enough data to satisfy your interface requirements (ie: which fields must be populated?)
- Click on another material to save changes
- Close the MDM Data Manager
- Turn on your MDM Syndication Server (if it's not already turned on)
If the runtime workbench shows the message transferred successfully then lets log ino ECC and see if the IDoc was posted.
- Log into ECC system
- Run transaction WE02
- Press F8
- In the left hand pane, select Inbound IDocs -> MATMAS
- In the right hand pane, select the IDoc that just transferred and double click on it
- In the IDoc display, on the left hand side expand E1MARAM and select E1MAKTM
- Verify that the material data is correct
- Expand Status Records -> 53 and double click the only record available
- In the pop up window, copy the message number that was issued to the IDoc
- Press Proceed
- Paste the message number that you copied
- Press F8
You may notice that my image says material 11696 created. This is because a modification was made to an ABAP program to create a material when an IDoc is processed with a certain code. In this blog, the ABAP modification is out of scope, but I'm assuming if you are familiar with ALE then this process should be familiar as well. In any case, this is not a permanent solution, just a temporary solution to finish our prototype. If we take that newly generated material number and run transaction MM02 we should be able to pull up the details on that material.
Press Select Views and select Basic Data and continue.
Hopefully if all went as planned, the material should have transferred smoothly, with no loss in data. This concludes the three part series on MDM and XI. Thanks for reading, hopefully it helps!
Harrison Holland is a systems integration and basis specialist.
Subscribe to:
Posts (Atom)
