SAP MDM Modeling

SAP MDM Modeling

Data Management Strategy
Formal architecture toward a common context for data to be viewed and managed as any other asset within the enterprise




MDM Repository Stucture
- Main table – One for each repository. In product repository, be the product including a field for each general valid piece of information
- Sub-tables – Lookup tables (value/customizing)
- Object tables – Images/text blocks and PDFs
- Special tables – Masks, families, image variants, relationships, roles, users, data groups

Main Table (flat table)
- A repository must only have one main table
- All other tables support it (directly-flat lookup or qualified lookup; / indirectly-tables linked to qualifier table & qualifier table linked to main T)
- Main table fields reference tables:
-- Flat lookup
-- Qualified lookup
-- Hierarchy
-- Taxonomy
-- Image, sound, video, PDF, and external binary object
-- Text block, copy blocks, and text HTML
-- Special tables

Flat & Qualified Lookup Table
- Flat tables (sub-table) can be multi-valued
- Qualified tables- Stores lookup records; Supports qualifiers; Is always multi-valued. Can be used for search

Hierarchy and Taxonomy Tables
- Hierarchy - sub-table orgainzing infor in a hierarchy (record related to parent/sibling record; contains lookup info for fields in main T; ordered sequence)
- Taxonomy- classification scheme that defines categories and subcategories.

Special Tables
- Families – Further partition records in taxonomy into smaller groups based upon values of other fields and/or attributes
- Relationships – Define different product-level relationships

Keep in mind...
- Many table and fields properties cannot be changed after creation (Table type; field type; multilingual option; Lookup table)
- Null values are not blank values
- Maintainable properties: (Name, code, Description, Display fields; Unique fields; Key mapping)

Repository Objects
- Taxonomies - general term classification scheme (hierarchy table, special lookup table) – created and managed using MDM Data Manager in Taxonomy mode.
- Attributes – characteristics in category (is a field applied to a subset of the records in a table)
- Product is assigned to category - Typical categorization of products is reflected in a taxonomy

- Flat / hierarchy lookup tables
- Taxonomy Lookup tables
- Qualified link tables – larger number of records
- Non-lookup sub-table = Relationship functionality (used for one-to-many relationship between main table records and sub table records

Relationship in Data Manager
- Parent/Child Relationship – Relates a group of records that are not equivalent (eg. Assembly)
- Sibling relationship – Relates a group of main table product records that are equivalent (eg. Cross sells)

Field Types & Properties
- Each table must have at least one Display Field (Display Field - value used as lookup field value; node name for the record; name of record in Product Relationships dialog box)
- Multiple Display Fields value is combination values separated by a comma
- Each field name must be unique within a table
- Items can be re-ordered

Field Details
- Variety of compond and structured data type (table types) specifically suited for managing info in a product repository
- Text Normalized – stores the actual text value, but uses normalized value for sorting and searching (upper-case with non-alphanumeric removed)


 


 


 

SOA for Business Developer

SOA for Business
•Open Standards
•Structure of a SOA Application – composed largely of services (Integration Services, Business Services, Data-Access Services)
•Web and Binary-Exchange Services – WSDL, SOAP, HTTP
•Presentation Services – Portlet, HTML,
•Runtime Products – security, service allocation, service composition, logging

•Loose Coupling
•Service Registry
•Service Level Agreements

Service Aspects
•Service Implementation - Logic
•Elementary access details – Location, binding, protocol, formatting
•Contract – interface and Quality of Service

Message Exchange Patterns
•One-way pattern – (fire-and-forget)
•Request-response pattern – (in-out)
•Notification pattern – (out-only)
•Solicit-response pattern – (out-in)
•Synchronous and Asynchronous Communication
•Callbacks – (Request and callback)

Quality of Service
•Reliability guarantees- availability, throughput, response time and probability, assured message
•Security mechanisms – Authentication, authorization, confidentiality, integrity, non-repudiation, attack protection
•Service coordination, including transaction control – Orchestration, Choreography
•Runtime update of address, binding, and message content – flow of traffic change, message reformat, send message to destination other than the requester

Process Steps
•Analyzing a Business Process
•Identifying Problems with current Process
•Communicating the Assumptions in Writing
•Isolating Services
•Creating the application

XML Schema
•Data Type – primitive, derived, simple, complex
•Purposes – data exchange, validation rules
•Groups, Sequencing,

SOA Standards
•WSDL
•SOAP
•UDDI



Introduction to BPEL
•BPEL process fulfills a workflow by accessing one service after another (partner service)
•BPEL activity is equivalent to a function call
•Running time can be far longer than other kinds of software
•Mechanisms for fault handling, compensation, correlation
•BPEL abstract process – subset of BPEL executable process (no implementation)

Additional language used by BPEL
•Query Language – XPath
•Expression language – XPath, Java
•doXslTransform
•Can use WSDL as source of data types
•PartnerLinkType (WSDL) – runtime conversation to partner service

BPEL Basics
•Activities– assign,compensate,compensateScope, empty, exit, extensionActivity, invoke, receive, reply, rethrow, throw, validate, wait
• An XML-base language for creating a process
•1. Accept a request for an insurance quote
•2. If the submitted details are appropriate, calculate the quote and include it in the response
•3. Otherwise, say "No" and include a justfication




BPEL - Partner Links
•Give details on the relationship between the BPEL process and each partner service
<partnerlinks>
<partnerlink name="ProcessQuote" partnerlinktype="ProcessQuotePLT" myrole="ProcessQuoteRole">
<partnerlink name="mainframeQuoteMgr" partnerrole="partnerRole" partnerlinktype="PartnerLinkPLT">
</partnerlinks>

BPEL - Variables
•assigns variables, which are memory areas that are each described by a Web Services Description Language (WSDL) message but could have been described by an XML Schema element or type

<variables>
<variable name="quoteRequest" messageType="placeQuoteRequestMsg" />
<variable name="highlightQuote" messageType="placeQuoteResponseMsg" />
<variable name="buildQuoteReq" messageType="buildQuoteRequestMsg" />
<variable name="newHighlightQuote" messageType="buildQuoteResponseMsg" />
</variables>

BPEL - Quote Request
receives a quote request
<receive name="processQuoteRequest" createInstance="yes" operation="placeQuote" partnerLink="ProcessQuote"
portType="ProcessQuote" variable="quoteRequest">
</receive>

BPEL - Copy Data
uses XPath syntax to copy data from the received message to a variable that is used for invoking another service
<assign name="AssignQuoteReq"> <copy>
<from variable="quoteRequest" part="placeQuoteParameters"> <query>/quoteInformation</query> </from>
<to variable="buildQuoteReq" part="buildQuoteParameters"> <query>/customerQuoteInfo</query></to>
</copy> </assign>

BPEL - Other Service
•invokes the other service, which calculates and returns a quote
<invoke name="CalculateQuote" inputVariable="buildQuoteReq" operation="buildQuote" outputVariable="newHighlightQuote" partnerLink="mainframeQuoteMgr" portType="QuoteManagement" />

BPEL - Copy to response
copies the quote details to another variable and in this way formats the response message
<assign name="AssignQuoteRes"> <copy>
<from variable="newHighlightQuote" part="buildQuoteResult"> <query>/quote</query> </from>
<to variable="highlightQuote" part="placeQuoteResult" > <query>/quote</query> </to>
</copy> </assign>

BPEL - Reply
•replies to the invoker, which may have been a Web application or a service

<reply name="processQuoteResponse" operation="placeQuote" partnerLink="ProcessQuote" portType="ProcessQuote" variable="highlightQuote" />

BPEL – General activities
•Run in a preset sequence
•Run in a loop
•Run on condition that a Boolean expression evaluates to true
•Run immediately or wait for some period of time, even years
•Run in response to an event that occurs after the process starts (specifically, in response to an inbound message, a calendar date and clock time, or the passing of time)
•Run in an order that differs for different instances of the same process

BPEL – Processes
•BPEL executable process – a Web service and acts as the hub in a service orchestration
•Software that runs an executable process is called a BPEL engine
•BPEL abstract process – similar to BPEL executable process but includes a subset of the information. It is a description of business logic, it omits implementation details in most cases

BPEL – WSDL
•PartnerLinkType – specifies the roles between the BPEL process and a partner service. (BPEL, WSDL)

•Port Type – WSDL
•Operations – WSDL
•Data types – XSD

BPEL – WSDL-based constructs
•Properties and property aliases benefits
•Use same name to access the same data in differently structured variables
•Name's position change doesn't necessarily change the logic in BPEL process
•BPEL correlation set (constants). Help direct an inbound message to the correct instance of BPEL process

BPEL – Process Elements
<process>
<import> </import>
<partnerLinks> </partnerLinks>
<messageExchanges> </messageExchanges>
<variables> </variables>
<correlationSets> </correlationSets>
<faultHandlers> </faultHandlers>
<eventHandlers> </eventHandlers>
<!— The previous two elements include activities, as does the subsequent content of the process element. Activities can be enclosed in scopes, as described later. —>
</process>

BPEL – File Structure
•Import - provides access to a WSDL definition or an XML Schema
•Partner link - is a kind of specialized variable that describes the relationship between the BPEL process and a partner service
•Message exchange - is an idnetifier that is used to avoid an ambiguous case in a complex usiness scenario – specifically, to pair a BPEL activity that receives a message with the activity that issues a reply
•Variable - contains business data (message, process logic)
•Correlation set – listing of properties used to correlate service instances
•Fault handler – a set of activities that run in response to a fault (failure in the process)
•Event handler – a set of activities that run concurrently with other activities, in response either to the passage of time or to receipt of a message




BPEL – Partner Link
•myRole – enacted by the BPEL process
•Operations are described in port type that is related to the role.
•partnerRole – enacted by the partner service
•Multiple partner links can be based on the same partner link type.

BPEL – Correlation Sets
•Maintain data integrity
•A list of propertirs whose values are expected to remain constant throughout a process or throughout a specific scope
•Reference only in activities that receive or transmit data
•Inbound activity – BPEL engine to direct msg
•Outbound activity – verify property values
•Inboundor outbound – initiates the correlation set

BPEL – Fault Handling
•Purpose – minimize the effect of an error
•Composed of a catch or optional catchAll
•Each fault handler hasselection criteria, which include (optionally) the fault name and the type of data
•BPEL engine selects the fault handler whose selection criteria most closely mirror the fault
•If the fault has a name but no data, BPEL engine selects the fault handler whose selection criteria match exactly
•If no catchAll, BPEL provides default:
<catchAll>
<sequence>
<compensate/>
<rethrow/>
</sequence>
</catchAll>

BPEL – Compensation Handling
•Compensation for a successfully completed scope occurs under the guidance of a compensation handler
•Invocation always comes from a parent scope
•The compensateScope activity invodes the compensation handler of a specific nested scope
•A failure in scope A causes invocation of the compensation handler in scope B:
<scope name="A">
<compensationHandler>
<compensateScope target="B">
</compensationHandler>
<scope name="B">
<compensationHandler>
<!— a basic or structured activity is here —>
</compensationHandler>
</scope>
</scope>

BPEL – Termination Handling
•Set of activities that are issues when a running scope is being forced to terminate
•Default
<terminationHandler >
<compensate/>
</terminationHandler>

BPEL - Concurrency
Synchronized - Activities run concurrently and one activity is forced to wait for another

BPEL Activity – Start
•First activity (other than flow, scope or sequence)
•1. a receive activity
•2. a pick activity that contains only onMessage events


 

SAP NetWeaver Master Data Management 7.1

SAP NetWeaver Master Data Management 7.1 is in ramp-up shipment since November 2008. This release features significant enhancements and improvements in the area of data modeling, data inbound and outbound processing, integration with SAP Business Objects Data Services, SOA support through Web Services generator, and administration and lifecycle management.



 

There are two main approaches to integrate MDM with EP

  • Customized approach
  • Standard approach


In the customized way you can create your own Webdynpro screens and use the MDM Java API to integrate with MDM. You need to deploy the MDM_JAVA_API sca files on WAS as matching with your MDM version. Then you can use these API to call your MDM functions through portal.

In the standard way :SAP has some pre-delivered content to integrate with MDM .so you can use the MDM std IViews to integrate MDM with EP. In this standard approach you need to deploy the std business packages sca files that are available with the MDM version. On doing this you can use the std archives on portal to call MDM functionalities from EP, so you can have for eg an MDM search IView or MDM result set IView etc.

The Deployments that are needed on portal for integrating with MDM are:

  • MDM_JAVA_API 70 SP2 .sca for search and configuration UI
  • BPMDMTECHN06_2.sca
  • BPMDMAPPL06_2.sca

As you have finished the deployment, there are few configuration needed to be set so that you can start using MDM components on Portal.

Lauch Go.bat i.e. Visual Administrator and logon using your administrator credentials.

Go to services –> Connection container –> MDM Factory

Select the Porperties Tab and set the server details and maximum allowed connection i.e. pooling properties.

Now Go to Services –> Monitoring, here you can see the up-to-date information on MDM deployed components. You can also see the errors in the deployments if any.

With this your MDM deployment on portal is completed. In the next article we will see portal side configurations to connect to MDM repositories.

The Business content provided by SAP, for integration of EP MDM.
The landscape could be EP as a front end with MDM acts as a backend for it. Using the standard IViews the fields in the MDM can be displayed in EP side. Depending on the type of fields, you can customise the display of fields at the EP side.
Using the concepts of MDM Workflow or UWL or Guided procedures, you can implement the CMDM scenario. In this case you dont need PI.

SRM MDM Catalog:

  • BP_SRM 7.1 SP2
  • SRM_MDM_CAT 3.0 SP2
  • MDM_JAVA_API 7.1 SP1

R/3-XI-MDM (Outbound Scenario)

This article will show you how to integrate SAP R/3 and Master Data Management (MDM) using PI in short framework. We will be discussing Outbound process i.e. Outbound to the SAP R/3

Figure Outbound to R/3


MDM Configuration Steps:
Step One-->Create Client System
Follow the same steps to create client system. Also we can use the same client system.
Step Two-->Create Port for Client System
Follow the same steps to create inbound port.
The Port Name is SIEBEL_IB_CUS_SIEBELCUS01, Code SIEBEL_IB_CUS_SIEBELCUS01, and Type as Inbound. See the figures below.

Figure Port for Inbound


MDM Server Side Configuration
In the SAP MDM Server, Look at the server folder structure for the Inbound folder which we have created in the MDM Console.

Figure MDM Server Folder


FTP Server Side Configuration
Step Three-->FTP Server Configuration
Configure/Specify the file folder path for pulling the file in FTP Server. This is screen refers the FTP server configuration (WS_FTP server)

Figure FTP Server


SAP XI / PI Side Configuration
Step Four --> SAP PI Receiver Communication Channel

Figure Receiver CC


Outbound Process Flow:

Figure Outbound Process Flow


>>>Here, I will be discussing Outbound process, the above figure shows the entire process
Process step in R/3
In this IDoc triggers to outbound port.
Process step in PI
The IDoc Communication Channel picks up in the PI System and starts the PI Process. In the PI, transformation and conversion happens and sends to the File Adaptor. The file adaptor pushes the file to the specified path in MDM server folder.
Process step in MDM
The Import Manager picks up the file which the file placed in server folder and imports the file to MDM repository main table.


 

New MDM Matching

The MDM matching functionality exposed in the MDM Data Manager supports interactive, strategy-based matching allowing identification of duplicate master data records. Coupled with the existing MDM merging functionality, MDM provides powerful capabilities for the deduplication process in a single environment.

In this blog, you will learn how easy it is to define matching rules, to compose matching strategies, and to run these matching strategies as an essential part of the deduplication process.

MDM Matching is Record-Centric

What this means is that each record has its own matching group of zero or more potential matches. When an MDM matching strategy is applied to a set of selected records, the strategy is applied individually to each selected record, and the potential matches are placed in the matching group for each record.

MDM Matching Occurs in a New Mode


Matching mode allows you to define matching strategies (design time), apply these strategies to a set of records, and view the matching results (runtime).

  • Interactive matching in matching mode is like searching: fully interactive, ad hoc, and without any form of persistence.
  • Automated matching occurs as part of the MDM Data Management Workflow, using a match/merge step that applies a matching strategy to the records in the workflow job (either on the records in the job or all records in the repository). Matching results are persistent during the execution of the workflow.

Matching mode is very similar to record mode and features the familiar three-pane layout including
(1) Search pane on the left
(2) Records pane on the top-right containing a grid with the search results and
(3) Matching pane on the bottom-right containing the following tabs:


The Matches tab shows the matching group of potential matches for the selected record:


The Merge tab contains an embedded version of the merge dialog for record mode, allowing you to merge the marked records in the matching group:


The Matches and Merge tabs together comprise the Runtime of matching mode.

Define a Matching Strategy

A matching strategy, the core of MDM matching, can be applied to selected records, to search results or to all records in the repository.

The Transformation tab (incl. substitution and synonym lists) allows you to create a virtual field that is a transformed version of a field in the repository, so that you can apply rules to the transformed values rather than to the original source values.


The Rules tab (with which you can specify a score for the success, failure and undefined conditions) allows you to define matching rules that are for comparing field values of record pairs. The matching functions include Equals (exact match) and Token Equals (match on one or more tokens). The set of functions will increase over time, making MDM matching highly extensible.


The Strategies tab allows you to define matching strategies consisting of matching rules. Each matching strategy is defined by the following properties: a name, lower & upper threshold, and one or more matching rules. The Min and Max Score is automatically calculated by MDM based on the selected rules.


The Design Time of matching mode comprises the Transformations, Rules and Strategies tabs.

Apply a Matching Strategy

You can use a menu command to execute a matching strategy on any subset of selected records against the subset (Selected vs. Selected), against the current search results (Selected vs. Results) or against the entire set of records in the repository (Selected vs. All):


You can also match the search results against search results (Results vs. Results) or against all records in the repository (Results vs. All).

After executing the matching, you can review the matching results by selecting a record in the Record pane and investigating potential matches for the selected record in the Matches tab. You can see the scores for every matching rule, the sum for each record, and the match class. Based on this information and the record data, you can decide if two records are identical.

If you have identified duplicates, you can merge them on the Merge tab, which provides the Merge dialog known from record mode.


New MDM Match/Merge Workflow Step

An sample workflow could look like the following:


The properties of the match/merge step include Name, Description, Matching Strategy and Match Records Scope (Records vs. Records or Records vs. All) as well as generic workflow step information like assigned users or roles.

The Workflows tab in Matching mode is the same as the Workflows tab in record mode. There you can find all the workflows that require attention by the user. Whereas Record mode lists all of the workflows available for a particular user, matching mode lists only those workflows which processed the match/merge step and are waiting for user interaction.



 

This is an initial preview of MDM matching, Details will follow ;-)

SAP Developer Network Latest Updates