The Perception of Master Data Management - Part 2 : V V Narendra Kumar
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....
The Perception of Master Data Management - VV Narendra Kumar
Abstract
Master data management (MDM) is a comprehensive method of enabling an enterprise to link all of its critical data to one file, called a master file, which provides a common point of reference. When properly done, MDM streamlines data sharing among personnel and departments. In addition, MDM can facilitate computing in multiple system architectures, platforms and applications. The benefits of the MDM paradigm increase as the number and diversity of organizational departments, worker roles and computing applications expand. For this reason, MDM is more likely to be of value to large or complex enterprises than to small, medium-sized or simple ones. When companies merge, the implementation of MDM can minimize confusion and optimize the efficiency of the new, larger organization. For MDM to function at its best, all personnel and departments must be taught how data is to be formatted, stored and accessed. Frequent, coordinated updates to the master data file are also essential.
Introduction
Master data management (MDM) is meant to deliver a near real-time, hub-based and synchronized master record of information to any seat or point of view in the organization. Master records are created with data that is defined, integrated and reconciled from multiple systems (customer relationship management, financial, supply chain, marketing etc.) and classified by type (e.g. product master, customer master, location master etc.). MDM is often pursued by data type through programs that address Customer data integration (CDI) or product information management (PIM), though many observers believe true MDM requires reconciliation of all data types. Critical to MDM are the notions of data quality and matching, which technology tools can help to automate.
Master Data
Most software systems have lists of data that are shared and used by several of the applications that make up the system. For example, a typical ERP system as a minimum will have a Customer Master, an Item Master, and an Account Master. This master data is often one of the key assets of a company. It's not unusual for a company to be acquired primarily for access to its Customer Master data.
Essential data types
There are essentially five types of data in corporations:
Unstructured—This is data found in e-mail, white papers like this, magazine articles, corporate intranet portals, product specifications, marketing collateral, and PDF files.
Transactional—This is data related to sales, deliveries, invoices, trouble tickets, claims, and other monetary and non-monetary interactions.
Metadata—This is data about other data and may reside in a formal repository or in various other forms such as XML documents, report definitions, column descriptions in a database, log files, connections, and configuration files.
Hierarchical—Hierarchical data stores the relationships between other data. It may be stored as part of an accounting system or separately as descriptions of real-world relationships, such as company organizational structures or product lines. Hierarchical data is sometimes considered a super MDM domain, because it is critical to understanding and sometimes discovering the relationships between master data.
Master—Master data are the critical nouns of a business and fall generally into four groupings: people, things, places, and concepts. Further categorizations within those groupings are called subject areas, domain areas, or entity types. For example, within people, there are customer, employee, and salesperson. Within things, there are product, part, store, and asset. Within concepts, there are things like contract, warrantee, and licenses. Finally, within places, there are office locations and geographic divisions. Some of these domain areas may be further divided. Customer may be further segmented, based on incentives and history. A company may have normal customers, as well as premiere and executive customers. Product may be further segmented by sector and industry. The requirements, life cycle, and CRUD cycle for a product in the Consumer Packaged Goods (CPG) sector is likely very different from those of the clothing industry. The granularity of domains is essentially determined by the magnitude of differences between the attributes of the entities within them
Read more: http://www.articlesbase.com/databases-articles/the-perception-of-master-data-management-3830837.html#ixzz1ZuSLxNyp
Under Creative Commons License: Attribution No Derivatives
continued...
Do you know the SAP Management Console (SAP MC)? Dirk Jenrich
Dirk Jenrich
If you are using windows, then you probably know the Microsoft Management Console (MMC), which provides a common framework for system management. SAP has developed the SAP Systems Manager snap-in which allows you to monitor, start or stop SAP systems centrally from the MMC, this simplifying system administration. Under Unix, however, for a long time no such tool was available.
But with SAP NetWeaver 7.0, things finally got moving:
* A new start service (sapstartsrv) is available on all platforms. It is offering web service interfaces to applications for centrally administering and monitoring SAP systems.
* With a similar UI to the SAP Systems Manager snap-in of the MMC, the SAP Management Console (SAP MC) was developed, which uses the web services mentioned above. The SAP MC is a browser-based, platform-independent user interface providing basic monitoring and administration of SAP systems.
* Within the development of SAP NetWeaver 7.1 the web service interfacs were further improved. These functions are already available to you in the SAP NetWeaver Composition Environment 7.1. To some degree, a downport of these functions to NW 7.0 is planned.
This weblog introduces the SAP MC. Technically, it's a Java applet running in a Java Runtime Environment on the front end host.
Summarized, the SAP MC allows you to monitor and perform basic administration tasks on SAP systems centrally, thus simplifying system administration. Among other things, it provides the following functions:
* Monitor and control (start, stop, or restart) SAP systems (ABAP and Java) and its instances with a single tool.
* Display SAP log and trace files, start profiles, instance parameters, the system environment, SAP environment, and so on.
* Display and control Java and ABAP processes.
* Monitor system alerts.
If you want to use the SAP MC, you need a Java Runtime Environment with a release as of release 1.4 on your front end. Besides, the corresponding Java Plug-In has to be active on your browser. To start the SAP MC, simply enter the following URL into your web browser:
http://
The URL is automatically forwarded to:
http://
Now, simply choose Start.
image
Depending on the patch level of the SAP system, the values of the system entered in the URL are shown. If not, you can always add instances manually, using the pushbutoon "Add new instance":
image
Now specify the host parameters of the SAP system you want to display:
image
As you can see, the UI is similar to the MMC:
image
I suggest that you click a little bit around to find out about the different functions. Don't worry! You have to confirm every potentially dangerous command (for example stopping an instance) by entering user and password in order to prevent misuse. Or - if you one of the rare breed, who prefer reading the documentation first - follow this link: http://help.sap.com/saphelp_nwce10/helpdata/en/44/c707c053550f2ce10000000a1553f7/frameset.htm.
Note
Remember that this the documentation of the SAP NetWeaver Composition Environment, so for your NW 7.0 system not all of the functions mentioned there are available.
Some remarks about the UI:
* Right click an instance or a system to get more commands on that level:
image
* Entries below instance levels often contains sub trees; the corresponding icons appear after you've chosen the corresponding entry. As an example, you can see the sub trees for system monitoring, which show the current status and open alerts reported to the CCMS monitoring segments of the corresponding instance.
image
One remark about monitoring of Java instances. In release SAP NetWeaver 7.0, there is the entry AS Java containing a process table with information about the Java processes:
image
In SAP NetWeaver 7.1 however, you can see much more. If you add a Composition Environment (CE) instance, you can see a whole bunch of extremely important monitoring values - representing one of the most complete and comprehensible collection of metrics about Java monitoring. In detail, it contains:
* information about the AS Java threads, sessions, caches, aliases, Enterprise JavaBeans (EJB) sessions, remote objects
* Java Virtual Machine garbage collection and heap memory information of the application server
image
Is there anything more that might be interesting to know?
* You can use the SAP MC for systems with release SAP NetWeaver 2004 as well; see SAP note 1014480.
* If you want, you can install the SAP MC locally; see SAP note 1014480 as well.
* You can use https for calling the SAP MC; for details see SAP note 1036107.
If the notes are not visible to you now, please have some patience - the notes will be released soon.
Dirk Jenrich is info developer for SAP and specializes in central monitoring.
SAP NetWeaver MDM Java API - What's new in SP06 Richard LeBlanc
Since MDM SP6 Patch1 was recently released for all customers, i thought it would be a good idea to point you to some resources that describe the new features that were introduced in the MDM Java API.
The first one is a Know How Network Call (KHNC) that was given back in December. The presentation and the recording can be found here.
The second one is the How To Use the MDM Java API for MDM SP06 Patch 1 how to guide. It contains code samples to perform all kinds of tasks in MDM e.g. search, insert, update, delete, check-out/check-in, etc... and it uses some of the new features that were introduced in SP06 Patch1 so you'll be able to run these code samples and see for yourself how it works!
Richard LeBlanc is a Senior Consultant for SAP and a member or the SAP NetWeaver Regional Implementation Group(RIG).
MDM Java API 2 an introductive series part IV Tobias Grunow
Tobias Grunow
Introduction
In my last Blog I showed you how to get an authenticated user session using a trusted connection. In this part I want to show you how to gather MDM system information from a SAP Portal system object.
After that I will introduce the basic concept behind working with MDM and the Java API 2, showing you how the system works (RecordID, Lookup Values, Display Fields...).
If you build a solution based on MDM you will sooner or later face a two or three tier MDM system landscape. Meaning that there will be a development system (D-System) and there might be a quality assurance system (Q-System) and there will be a productive system (P-System). This scenario can include multiple MDM Server or maybe only different Repositories on the same server and in addition maybe (D-, Q-, P-Clients). So now you face the problem how to address the different repositories from your code without having to take care about addressing the right one dependant on which landscape you are in.
In case you are using a SAP Portal I want to point to a very useful thread I have found on SDN.
Hard-code credentials - any other solution exists?
This forum post shows you how to work with the SAP Portal system objects and how to retrieve information out of it. I have used this concept to address the problem I have just pointed out to you in addition with the trusted connection user session authentication and it worked fine for me.
Let us continue with the next topic...
MDM Java API 2 introducing the concept
First of all I want to give u a brief introduction into the concept of MDM to better understand my future coding. As a coder you need a much better understanding of the concept behind the MDM than anyone else. Simple GUI-Users (Graphical User Interface) don’t have the need to understand the technical details behind the data storage and operations like Java programmers. So at the beginning the most important task is to understand how MDM will store data and connect the data with each other.
So let’s start with the first graphic:
image
Figure 1: Table concept in MDM
The first graphic shows the table concept of MDM. The central table called “Main table” is the centre of the model. From the main table there will be references going towards any kind of sub tables. In the Main table will be fields. Those fields can hold values which are stored directly in the table or hold a reference to any record of a sub table. Sub tables can store data values or hold references to other sub tables.
To illustrate the possible layout of a main table take a look at figure 2.
[Click the picture to enlarge!]
image
Figure 2: Possible layout in main table (MDM Console view)
As you can see the main table stores e.g. text values directly as well as references to other sub tables (Lookup’s of different kinds). To find out where the lookup’s are pointing to, you can open up the MDM Console and click on an entry in the list of fields in the main table to see its details (Figure 3).
image
Figure 3: Main table field details (Bottom part of MDM Console)
If we look at the details we have to notice two important things.
First, figure 3 shows us a field detail named “CODE”. This code is very important for us because it is the name we will use in our code to address this field in the table. Second, we have to notice that the field is of “Type” Lookup [Flat]. This tells us, that the value we will find in this field will be of type RecordID.
A RecordID is the ID of the record in the sub table (e.g. Sales Product Key – Table [Detail: Lookup Table]). This means that we will not be able to access the value directly by accessing the field in the main table. We will only get the reference to the sub table which holds the actual value desired. In my future Blogs I will give more details on the concepts behind MDM and give examples of other techniques used.
So enough of MDM concepts and let’s get to the Java API and some examples.
Searching in MDM
Searching in MDM will be one of the most common used functionality there is.
Searching in a repository has some prerequisites. First we have to have a connection to the MDM Server and second we have to have an authenticated user session to a repository. In my Blogs published before I showed you how to setup those prerequisites. In the class provided I have combined all the necessary steps to get the connection and the user session. So now let’s get to the code.
package com.sap.sdn.examples;
import java.util.Locale;
import com.sap.mdm.commands.AuthenticateUserSessionCommand;
import com.sap.mdm.commands.CommandException;
import com.sap.mdm.commands.CreateUserSessionCommand;
import com.sap.mdm.commands.SetUnicodeNormalizationCommand;
import com.sap.mdm.commands.TrustedUserSessionCommand;
import com.sap.mdm.data.RecordResultSet;
import com.sap.mdm.data.RegionProperties;
import com.sap.mdm.data.ResultDefinition;
import com.sap.mdm.data.commands.RetrieveLimitedRecordsCommand;
import com.sap.mdm.ids.FieldId;
import com.sap.mdm.ids.TableId;
import com.sap.mdm.net.ConnectionAccessor;
import com.sap.mdm.net.ConnectionException;
import com.sap.mdm.net.SimpleConnectionFactory;
import com.sap.mdm.search.FieldSearchDimension;
import com.sap.mdm.search.Search;
import com.sap.mdm.search.TextSearchConstraint;
import com.sap.mdm.server.DBMSType;
import com.sap.mdm.server.RepositoryIdentifier;
public class SearchExamples {
// Instance variables needed for processing
private ConnectionAccessor mySimpleConnection;
// Name of the server that mdm runns on
private String serverName = "IBSOLUTI-D790B6";
// Name of the repository shown in the mdm console
private String RepositoryNameAsString = "SDN_Repository";
// Name of the DB-Server this could be an IP address only
private String DBServerNameAsString = "IBSOLUTI-D790B6\\SQLEXPRESS";
// Define the Database type (MS SQL Server)
private DBMSType DBMSTypeUsed = DBMSType.MS_SQL;
// Create a new data region
private RegionProperties dataRegion = new RegionProperties();
// Session which will be used for searching
private String userSession;
// Default user name
private String userName = "Admin";
// Password is empty on default setup
private String userPassword ="";
// result we will get from mdm
public RecordResultSet Result;
/**
* Constructor for class
*/
public SearchExamples(){
// Set the Data Region
dataRegion.setRegionCode("engUSA");
// Set the locale on data region
dataRegion.setLocale(new Locale("en", "US"));
// Set the name of data region
dataRegion.setName("US");
// get a connection to the server
this.getConnection();
// Authenticate a user session
try {
this.getAuthenticatedUserSession();
} catch (ConnectionException e) {
// Do something with exception
e.printStackTrace();
} catch (CommandException e) {
// Do something with exception
e.printStackTrace();
}
// Get resulting records
Result = this.SearchTypes();
}
// ResultDefinition Main Table declaration
private ResultDefinition rdMain;
/**
* Method that will search for all records in main table of a certain type
*
* @return RecordResultSet that holds all resulting records from search
*/
public RecordResultSet SearchTypes() {
/**
* 1. First we create the Result Definition. This result definition will
* tell the search which fields are of interest to us. The list could
* include all fields of the table or only the ones we are interested
* in.
*/
// Define which table should be represented by this ResultDefintion
// In my repository this is the table MAINTABLE
rdMain = new ResultDefinition(new TableId(1));
// Add the desired FieldId's to the result definition
// In my repository this is the field PRODUCT_NAME
rdMain.addSelectField(new FieldId(2));
// In my repository this is the field TYP
rdMain.addSelectField(new FieldId(27));
/**
* 2. Create the needed search parameters.
* Define what to search for and where.
*/
// Create the field search dimension [Where to search!?]
FieldSearchDimension fsdMaintableType = new FieldSearchDimension(new FieldId(27));
// Create the text search constraint [What to search for?! (Every record that contains ROOT)]
TextSearchConstraint tscTypeRoot = new TextSearchConstraint("ROOT", TextSearchConstraint.CONTAINS);
/**
* 3.
* Create the search object with the given search parameters.
*/
// Create the search
Search seSearchTypeRoot = new Search(new TableId(1));
// Add the parameters to the search
seSearchTypeRoot.addSearchItem(fsdMaintableType, tscTypeRoot);
/**
* 4.
* Create the command to search with and retrieve the result
*/
// Build the command
RetrieveLimitedRecordsCommand rlrcGetRecordsOfTypeRoot = new RetrieveLimitedRecordsCommand(mySimpleConnection);
// Set the search to use for command
rlrcGetRecordsOfTypeRoot.setSearch(seSearchTypeRoot);
// Set the session to use for command
rlrcGetRecordsOfTypeRoot.setSession(this.userSession);
// Set the result definition to use
rlrcGetRecordsOfTypeRoot.setResultDefinition(rdMain);
// Try to execute the command
try {
rlrcGetRecordsOfTypeRoot.execute();
} catch (CommandException e) {
// Do something with the exception
e.printStackTrace();
}
// Return the result
return rlrcGetRecordsOfTypeRoot.getRecords();
}
/**
* Create and authenticate a new user session to an MDM repository.
*
* @param mySimpleConnection
* The connection to the MDM Server
* @param RepositoryNameAsString
* name of the repository to connect to
* @param DBServerNameAsString
* name of DBServer
* @param DBMSType
* Type of DBMS that MDM works with
* @param dataRegion
* RegionProperties defining the language the repository should
* be connected with.
* @param userName
* Name of the user that should make the connection to repository
* @param userPassword
* password of user that should be used if connection is not trusted
* @throws ConnectionException
* is propagated from the API
* @throws CommandException
* is propagated from the API
*/
public String getAuthenticatedUserSession(
) throws ConnectionException, CommandException {
/*
* We need a RepositoryIdentifier to connect to the desired repository
* parameters for the constructor are: Repository name as string as read
* in the MDM Console in the "Name" field DB Server name as string as
* used while creating a repository DBMS Type as string - Valid types
* are: MSQL, ORCL, IDB2, IZOS, IIOS, MXDB
*/
RepositoryIdentifier repId = new RepositoryIdentifier(
RepositoryNameAsString, DBServerNameAsString, DBMSTypeUsed);
// Create the command to get the Session
CreateUserSessionCommand createUserSessionCommand = new CreateUserSessionCommand(
mySimpleConnection);
// Set the identifier
createUserSessionCommand.setRepositoryIdentifier(repId);
// Set the region to use for Session - (Language)
createUserSessionCommand.setDataRegion(dataRegion);
// Execute the command
createUserSessionCommand.execute();
// Get the session identifier
this.userSession = createUserSessionCommand.getUserSession();
// Authenticate the user session
try {
// Use command to authenticate user session on trusted connection
TrustedUserSessionCommand tuscTrustedUser = new TrustedUserSessionCommand(
mySimpleConnection);
// Set the user name to use
tuscTrustedUser.setUserName(userName);
tuscTrustedUser.setSession(this.userSession);
tuscTrustedUser.execute();
this.userSession = tuscTrustedUser.getSession();
} catch (com.sap.mdm.commands.CommandException e) {
/* In Case the Connection is not Trusted */
AuthenticateUserSessionCommand authenticateUserSessionCommand = new AuthenticateUserSessionCommand(
mySimpleConnection);
authenticateUserSessionCommand.setSession(this.userSession);
authenticateUserSessionCommand.setUserName(userName);
authenticateUserSessionCommand.setUserPassword(userPassword);
authenticateUserSessionCommand.execute();
}
// For further information see:
// http://help.sap.com/javadocs/MDM/current/com/sap/mdm/commands/SetUnicodeNormalizationCommand.html
// Create the normalization command
SetUnicodeNormalizationCommand setUnicodeNormalizationCommand = new SetUnicodeNormalizationCommand(
mySimpleConnection);
// Set the session to be used
setUnicodeNormalizationCommand.setSession(this.userSession);
// Set the normalization type
setUnicodeNormalizationCommand
.setNormalizationType(SetUnicodeNormalizationCommand.NORMALIZATION_COMPOSED);
// Execute the command
setUnicodeNormalizationCommand.execute();
// Return the session identifier as string value
return this.userSession;
}
/*
* The method will return a ConnectionAccessor which is needed every time
* you want to execute a Command like searching or as on any other Command
* there is. @return SimpleConnection to MDM Server
*/
public void getConnection() {
String sHostName = serverName;
// We need a try / catch statement or a throws for the method cause
try {
/*
* retrieve connection from Factory The hostname can be the name of
* the server if it is listening on the standard port 20005 or a
* combination of Servername:Portnumber eg. MDMSERVER:40000
*/
mySimpleConnection = SimpleConnectionFactory.getInstance(sHostName);
} catch (ConnectionException e) {
// Do some exception handling
e.printStackTrace();
}
}
}
To test the code we also need a simple test class that will instantiate the sample class and prints out the number of retrieved Records.
package com.sap.sdn.examples;
public class Test {
/**
* @param args
*/
public static void main(String[] args) {
// Create instance of search class
SearchExamples test = new SearchExamples();
// Print out the amount of found records
System.out.println("Total of " + test.Result.getCount() + " Records found that match criteria TYPE=ROOT");
}
}
I wrote a lot of comments in the code but I will give you some more details on what is happening there.
First of all there are some instance variables that hold the connection information to the MDM Server and the MDM Repository.
The constructor will set up some variables which are needed for the search.
A connection to the MDM server will be created.
A Session will be created and will be authenticated, if there is a trusted connection we will use it to authenticate and if we only have a normal connection to the server normal authentication will be used.
The search will be triggered and the result will be stored in instance variable.
The search needs some elements to work with.
At the beginning in the SearchTypes() method [Comment 1. in code] set up a ResultDefiniton which tells the search what fields are of interest to the program and should be accessible in the result. If this definition is not including some desired field and you want to access it later in your code, an exception will be thrown.
[Comment 2. in code] Define a search dimension and a search constraint to tell the search where to look at and what to look for. There are a lot of search constraints to work with.
All available constraints:
[Comment 3. in code] Define the search itself and use the dimension and constraint to set it up.
[Comment 4. in code] Build the command that is needed to execute the search.
More Details on command please see this link
So this is just a very simple example and I will give you more advanced codes in future Blogs.
If you have any questions on what the code does or need more detailed explanations please feel free to comment on this Blog. If this code helped you a little please feel free to comment as well.
So this will be the last Blog for this year since I am rebuilding my flat at the moment. The topic of the next Blog needs to be defined and I will update my agenda in my first Blog next year.
So I wish you a happy new year and as you would say in german: “ Einen guten Rutsch ins neue Jahr!”.
Best regards,
Tobi
Tobias Grunow is a Solution Consultant for IBSolution GmbH Heilbronn, Germany. He is a member of the research and development team.
Learning MDM -- A short guide for rookies Ketan Phanse
Learning MDM -- A short guide for rookies
Ketan Phanse
Since long, the MDM Forum has been flooded with threads with subjects as "Basics of MDM", "Learning MDM", "New to MDM" etc etc. As more and more people are joining the Team MDM, they are not able to find a systematic way of going about Learning MDM, and to be honest I faced the same problem an year back.So how do you go about get yourself well acquainted with SAP MDM assuming you have no previous experience/knowledge whatsoever about "Master Data Management" and have jumped in as its the new "in thing!". Here's how I think you should do it:
1. Understand MDM before SAP MDM
Don’t jump directly into the technology or the product without understanding what you are doing and why you are doing. One must first appreciate the need for managing master data, why is it that suddenly everyone is talking about it. Devote one week's time only in reading articles, whitepapers, case studies on MDM... let it be SAP or any other product for that matter. Some of the useful links/websites are:
http://www.b-eye-network.com/news/index.php?filter_topic=1160,1106,1041,1180
http://www.dmreview.com/channels/master_data_management.html
You can find many more on the net. Would suggest control your temptation to go to sdn as of now. ( But anyways you would have landed on this blog mostly via sdn! )
2. Its SAP MDM time !
Now that you have understood the concept of MDM, you can start of with knowing more about SAP MDM specifically. Again don’t jump into the product as yet. This time your focus should be on knowing the business offerings, scenarios, technology fit of SAP MDM with respect to its overall landscape. Things you should focus on this time would be:
a. What is SAP MDM?
b. How does SAP MDM fit into SAP NetWeaver landscape?
c. What are the IT scenarios of SAP MDM?
d. What are the business scenarios of SAP MDM?
e. What are the key components, GUI of SAP MDM?
f. Some case studies on success stories of SAP MDM
This time the best source would be sdn!
https://www.sdn.sap.com/irj/sdn/nw-mdm
https://www.sdn.sap.com/irj/sdn/nw-mdm?rid=/webcontent/uuid/c039d0df-0901-0010-16b4-8fdc4bf639e3
3. Getting hands-on SAP MDM
By now you would have well conceptualized SAP MDM and eager to open various MDM components. Here are few suggested readings:
a. SAP has provided detailed Reference Guides for each MDM component. These would be your bibles for time to come. They are available on service market place.
b. Reference guides are also available on help.sap.com at following link
http://help.sap.com/saphelp_mdm300/helpdata/EN/2d/ca9b835855804d9446044fd06f4484/frameset.htm
c. How-to Guides on sdn provide detailed step-by-step description on some important scenarios.
https://www.sdn.sap.com/irj/sdn/nw-mdm?rid=/webcontent/uuid/5024a59a-4276-2910-7580-f52eb789194b
d. We on sdn! You can always ask questions on sdn, but again requesting you to make sure that they do not already exist on the Forums and the SDN-MDM family will be more than happy to help you.
4. Execute your learning’s
Remember, SAP MDM is not a small product. It has 4 Reference guides, and they too don’t cover all the components. So if you think you can learn MDM by reading the Reference Guides as Agatha Christie & Sidney Sheldon then SAP MDM would surely look like all fiction to you! So take a step back, be patient and try to execute whatever you are learning. Find yourself a live MDM environment, better if its on the latest version, and try your hands on it. Develop simple scenarios to execute your learning’s like creating a small repository with fields and tables, importing data from excel, writing validation and assignments, developing simple workflows etc.
Hope this blog helps you in your way to becoming an MDM Guru!
Ketan Phanse is a SAP MDM Business Analyst in Wipro Technologies
Learning MDM -- A short guide for rookies
Ketan Phanse
Watch Master Data Management in Action Markus Ganser
Watch Master Data Management in Action
Markus Ganser
Watch this new flashbook on master data management to see how MDM promotes trust in enterprise information by extracting, consolidating, and enriching supplier master data from a remote system, that after this quality treatment is sent back to the source. Data enrichment, that is, address validation, is done using Business Objects services.
Additionally, the following presentations about MDM have been updated:
Stay up-to-date with MDM.
Markus Ganser joins the product management team of SAP Master Data Management