Extraction of data from MDM to SAP R/3 using CL_MDM_GENERIC_API
Applies to
SAP ECC 6.0. And further.
Summary
This article has distinctively been actualized to provide a simple concept towards extraction of data from MDM into the SAP R/3 system. This document briefly manifests each step, starting from the connection setup till the data extraction part, with all the likely screen-shots and chunks of code. A very simple approach to grab data stored in MDM has been displayed.
Author(s): Aastha Mehrotra
Company: Larsen & Toubro Infotech
Created on: 29th February, 2012
Author Bio
Aastha Mehrotra has been engaged with Larsen and Toubro Infotech for two years and three months, her acquaintance with the IT industry being the same.
The author has worked on various projects with different clients, in SAP as an ABAP Developer. She is also well versed in a couple of other ABAP technologies, for instance WebDynpro for ABAP, Workflows and Smart Forms. However, the Magnum Opus in her career has been her distinguished work in the field of Data Extraction from MDM to SAP R/3. Aastha did a major research on retrieving flat as well as lookup data from MDM into SAP R/3 system, using the MDM ABAP APIs. She also applied her know how on MDM ABAP APIs, in two implementation projects. She has also imparted trainings on Setting up connection between MDM and SAP R/3 as well as Extracting data from MDM to SAP R/3.
Introduction
To ensure consistency and command over the information in an organization the concept of MDM is vastly utilized. MDM provides various processes to manage the master data since it is a collection of all the activities like Data consolidation, Cleaning, Mapping, Merging with pre-existing data, making the data accessible & consistent across various systems etc.
Retrieving data from MDM into other systems, in our case, ensures zero redundancy and provides hundred percent consistent data.
This document would take you through all the steps involved in the extraction of the data from MDM to R/3. In addition, this would also assist setting up a connection between the two platforms to allow the data transfer.
Add-On MDM_TECH
Prior to, going ahead with the coding to retrieve the data, we need to check for all the necessary settings which are compulsory for the interaction of MDM and SAP R/3.
- We need to ensure that the Add-On MDM_TECH is installed in the system. We install it using the Transaction code SAINT.
- We can see the Add-Ons in the system using the transaction SAINT
Configuration settings
The configuration settings are to be done by the BASIS people. However, we must check if the appropriate configuration settings exist for the system which is being connecting with MDM.
· We need to confirm if proper connections have been setup between the SAP R/3 and the MDM systems.
- We can check this using the transaction code MDMAPIC
There are 5 parts to the settings:
1. MDM Repositories
We tie our entire configuration together by specifying for a repository what server, DBMS, and Provider it should use.
· Object Name: Object name is the logical name for the MDM repository. This object name would be used in ABAP code for the parameter lv_log_object_name.
· MDM Repository: MDM repository is the name of the repository available on the MDM Server.
Note: This field is case-sensitive. The repository name entered should be exactly as the repository name defined in MDM server.
· MDM Connection: This is the server connection configuration entry. There are 3 parameters defined under this
1. Connection Name: User-defined name.
2. Host Name: IP address or name of the MDM server.
3. IP Port: This value is generally 20005.
· MDM DBMS: Specifying the Database specific details.
1. Name: User-defined name.
2. DBMS Host Name: Host name of the DBMS Server.
3. Type of Server: Selecting the type of Database Server. This field is a drop-down field. Example: Oracle, IBM DB2, MaxDB etc
· MDM Provider: Specifying the version and patch level of current MDM Server.
NOTE: The Object name is arbitrary and only known to ABAP- although it is used as the key to read the entire configuration. And the MDM Repository must be real repository name as it is displayed from the MDM Console.
2. Server Connections
· Define the TCP/IP communication settings for connection to the MDM server
· Enter the Server Hostname and the Port for communication
· Typically the MDM server runs on Port 20005
· The name in the MDM Connection field is arbitrary and only known to SAP
NOTE:
· All access via MDM is always done for a particular repository
· The class based API is instantiated for a particular repository. You cannot switch to a different repository with an instance.
· In all calls to a function module based API, the repository must be based in through the mandatory parameter(iv_log_object_name)
· Therefore, the configuration In MDMAPIC really revolves around the repository as its central object.
3. DBMS Configuration
· Repositories may reside on a DBMS that is a different physical system than the MDM server itself
· The Drop down Box for DB Type will show all supported DBMS types.
· The name in the MDM DBMS field is arbitrary and only known to ABAP.
4. ABAP Implementation for MDM version
· Different releases of SAP NetWeaver MDM may require technical differences in the Low Level Provider Class.
· This configuration will allow you to assign a provider class to a set of repository configuration settings
5. MDM API Trace Configuration
Generally there are no values to be set here.
MDM ABAP APIs
· The MDM ABAP API provides an interface for accessing SAP MDM using ABAP
· The interface is easy to configure and convenient to use
· It is optimized for ABAP developers and available using ABAP Objects and function modules (partly remote enabled)
In addition to the core services performed on the records (create, retrieve, update, delete, query, etc), metadata (tables, fields, etc.) and administrative functions (such as repository) are delivered
Features of MDM ABAP APIs
· The MDM ABAP API empowers ABAP-based applications to control MDM Servers using most of the functions available in the MDM Console and MDM Data Manager applications.
· The API is provided with:
1. Interfaces and methods (ABAP objects)
2. Function groups and function modules)
Some function modules are remote enabled (Web services, RFC)
Class based GENERIC API
For class based access to MDM we only interact with CL_MDM_GENERIC_API
All access to the functionality of MDM is done through the instances of the main group of interfaces exposed by the GENERIC API.
Main programming interfaces of the class GENERIC API
· IF_MDM_ACCESSOR
This is the fundamental interface that controls the opening and closing of the connection to the particular repository in MDM. it's methods are used to connect and disconnect to the repository while coding to retrieve data from MDM. For most of the other API methods, a connection needs to be set up using this interface prior to using those.
· IF_MDM_ADMIN
This interface provides access to the admin functions similar to the ones available via the MDM Console. The functions include User creation, password creation, role setting and maintenance and Repository mount or loading.
· IF_MDM_CONFIG
This interface permits us to read the configuration entries from the transaction code MDMAPIC for a particular, or all the repositories. See the Data dictionary structures MDM_REPOSITORY, MDM_CONNECTION, MDM_DBMS, and MDM_PROVIDER for the data supplied by this interface.
· IF_MDM_CORE_SERVICES
This is the expert interface to manipulate the data within the repository, connected to. It includes Check in/out, Client System Keys, Update, Delete, Creation and Query of Data.
· IF_MDM_META
This provides certain methods which allow us to change the metadata of a repository. A couple of these methods require the repository to be unloaded before we go ahead with them.
Class Based connection example
Function Groups of the Generic API
There are function groups of the Generic API which correspond absolutely to the main interfaces of the provider class. The processing logic for these is the same as the class based interface since, the class based interface is called from within the function module. Several of these key functions are Remote enabled.
We can map the Function Groups to the Interfaces thus:
FG_MDM_ACCESSOR = IF_MDM_ACCESSOR
FG_MDM_ADMIN_API = IF_MDM_ADMIN
FG_MDM_CONFIG_MONITOR = IF_MDM_API_CONFIG
FG_MDM_CORE_SERVICE_API = IF_MDM_CORE_SERVICES
FG_MDM_META_API = IF_MDM_META
Hence, we can use the interface and the Function Groups interchangeably.
Function group based connection example
Coding towards the extraction of data from the repository in MDM
The main aspiration of this document is to let us code in order to retrieve data from MDM. For the same objective the entire process has been explained from the initial level.
Hence you would be acquainted with all the necessary data declarations and code snippets to confidently capture data from the required repository in MDM.
Inside any repository In MDM, there are various types’ of fields. There are flat fields, Date time fields and Lookup fields. The repository exists like a table with fields in it. We have to retrieve data from this table.
NOTE: We can fetch any number of fields, as per our requirement. Just that, a structure containing all those fields with the same type as that in MDM (or the corresponding type in R/3), has to be created in R/3. We can make a normal Z Structure in ABAP.
Let’s start with out sneak into the code snippets:
Data Declaration
Connecting with the Repository
We need to specify the Logon language, country and region for the server, prior to the connection. The logical connection name, as established in the transaction code MDMAPIC, is stated against the iv_log_object_name to create an instance of the API (here ‘MDM_DVH_DMH_CONNECTION’).
Finally, we connect to the repository by applying the particular Logon language info. We use the Method Connect(), to establish the connection.
The QUERY Method
With this method, we can perform various searches on a MDM repository. We need to specify:
Prameters:
· IV_OBJECT_TYPE_CODE: This is the Table code which is Character-based, non language-dependent unique table descriptor. E.g. ’Z_PEOPLE’, ‘Z_MATERIAL’ etc.
· IT_QUERY: query definition (optional)
The Query definition is stored in the table IT_QUERY.
IT_QUERY has the following structure:
· PARAMETER_CODE: This is the Field code as in MDM. It is Character-based, non language-dependent unique field descriptor. E.g.’ Z_USER_NAME’ can be a field code for the ‘user name’ in PEOPLE repository.
· DIMENSION_TYPE: This is the Search dimension. The various kinds of search dimensions are:
q Field search dimension (value = MDMIF_SEARCH_DIM_FIELD)
q Attribute search dimension (value = MDMIF_SEARCH_DIM_ATTR)
q Qualifier search dimension (value = MDMIF_SEARCH_DIM_QUAL)
q Masks search dimension (value = MDMIF_SEARCH_DIM_MASK)
q Keyword search dimension (value = MDMIF_SEARCH_DIM_KEYW)
· OPERATOR: Search operators help us compare the values
q Equal to (like standard select-options parameter) (value = 'EQ')
q Not equal to (like standard select-options parameter) (value = 'NE')
q Less than (like standard select-options parameter) (value = 'LT')
q Less than or equal to (like standard s-o parameter) (value = 'LE')
q Greater than (like standard select-options parameter) (value = 'GT')
q Greater than or equal to (like standard s-o parameter (value = 'GE')
q Starts with (MDM-specific parameter) (value = 'SW')
q Ends with (MDM-specific parameter) (value = 'EW')
q Contains (MDM-specific parameter) (value = 'CS')
q Not contained (MDM-specific parameter) (value = 'NC')
q Sounds like [phonetic] (MDM-specific parameter) (value = 'SL')
q Progressive search (MDM-specific parameter) (value = 'PS')
q Language layer search (MDM-specific parameter) (value = ' LL ')
q Inherited value search (MDM-specific parameter) (value = ' IV ')
q Unrelated value search (MDM-specific parameter) (value = ' UV ')
· CONSTRAINT_TYPE: This is the Search constraint. We need to specify the kind of search we need to perform.
q Boolean search constraint (value = MDMIF_SEARCH_CONSTR_BOOL)
q Lookup field search constraint (value = MDMIF_SEARCH_CONSTR_LOOK)
q Date time search constraint (value = MDMIF_SEARCH_CONSTR_DATE)
q Keyword search constraint (value = MDMIF_SEARCH_CONSTR_KEYW)
q Measurement search constraint (value = MDMIF_SEARCH_CONSTR_MEAS)
q Null search constraint (value = MDMIF_SEARCH_CONSTR_NULL)
q Numeric search constraint (value = MDMIF_SEARCH_CONSTR_NUM)
q Text search constraint (value = MDMIF_SEARCH_CONSTR_TEXT)
q Text attribute search constraint (value = MDMIF_SEARCH_CONSTR_ATTR_TEXT)
q Numeric attribute search constraint (value = MDMIF_SEARCH_CONSTR_ATTR_NUM)
q Coupled attribute search constraint (value = MDMIF_SEARCH_CONSTR_ATTR_C_ NUM)
· VALUE_LOW: Data reference set according to the search constraint type. Precisely this contains the value to be compared with.
q Constraint type (value = MDMIF_SEARCH_CONSTR_BOOL): [MDM_E_BOOLEAN | MDM_QUALIFIER_QUERY with MDM_QUALIFIER_QUERY-VALUE equals MDM_E_BOOLEAN (qualifier search dimension)]
q Constraint type (value = MDMIF_SEARCH_CONSTR_LOOK): [MDM_GDT_INTEGERVALUE_TABLE (record IDs) | MDM_QUALIFIER_QUERY with MDM_QUALIFIER_QUERY-VALUE equals MDM_GDT_INTEGERVALUE_TABLE (qualifier search dimension)]
q Constraint type (value = MDMIF_SEARCH_CONSTR_DATE): MDM_CDT_DATE_TIME
q Constraint type (value = MDMIF_SEARCH_CONSTR_KEYW): STRING
q Constraint type (value = MDMIF_SEARCH_CONSTR_MEAS): MDM_GDT_QUANTITY
q Constraint type (value = MDMIF_SEARCH_CONSTR_NULL): [MDM_E_BOOLEAN | MDM_QUALIFIER_QUERY with MDM_QUALIFIER_QUERY-VALUE equals MDM_E_BOOLEAN (qualifier search dimension)]
q Constraint type (value = MDMIF_SEARCH_CONSTR_NUM): MDM_GDT_DOUBLE
q Constraint type (value = MDMIF_SEARCH_CONSTR_TEXT): STRING
q Constraint type (value = MDMIF_SEARCH_CONSTR_ATTR_TEXT): MDM_ATTTRIBUTE_ QUERY with MDM_ATTTRIBUTE_QUERY-ATTRIBUTE_VALUE equals MDM_UNIQUE_ID_TABLE (text value identifier)
q Constraint type (value = MDMIF_SEARCH_CONSTR_ATTR_NUM): MDM_ATTTRIBUTE_QUERY with MDM_ATTTRIBUTE_QUERY-ATTRIBUTE_VALUE equals MDM_GDT_QUANTITY_TABLE
q Constraint type (value = MDMIF_SEARCH_CONSTR_ATTR_C_NUM): MDM_ATTTRIBUTE_QUERY with MDM_ATTTRIBUTE_QUERY-ATTRIBUTE_VALUE equals MDM_COUPLED_ATTR_VALUE_TABLE
· EXCEPTIONS
q CX_MDM_USAGE_ERROR: Incorrect use of interface, e.g. incorrect or insufficient input
q CX_MDM_PROVIDER: Error at provider level. Internal operation failed due to incorrect use of interface or internal error
q CX_MDM_KERNEL: Kernel level exception, e.g. connection timeout
q CX_MDM_SERVER_RC_CODE: MDM Server return code comes directly from the MDM Server and shows the error situation, e.g. incorrect parameter submitted by the user
q CX_MDM_NOT_SUPPORTED: API currently does not support the function
In the code snippet below we are laying the search criteria for MDM such that the Field name in MDM is ‘Z_UNAME’, the operator is ‘EQ’, we are performing Field search and the Constraint type is Text.
Hence, we will look for the names AASTHA and AKSHAY in the field Z_UNAME. The records with an exact match for these texts shall be fetched.
With the help of the query we designed we will search for the records as per the query in the Z_PEOPLE table in MDM.
The RETRIEVE_SIMPLE Method
This method helps us retrieve the records from the MDM tables in a simple way. It helps us retrieve the Attributes and the values. The qualifiers can also be retrieved, using this.
Simple in the Retrieve_Simple implies that we just need to prepare a structure in which the data is passed from the API. The API handles the structure.
NOTE: The assignment from the MDM result set to the provided structure has to conform to specific rules. The field names have to be the same as the codes of the MDM structure. For instance, if the MDM field code is "Name", the corresponding field in the structure has to be "Name" (case-sensitive). The field must have the required API type.
Through this comfortable approach, it is not possible to display the MDM NULL values for fields that are initial. In other words, an MDM NULL value becomes the default value of the underlying type. Use the generic methods to avoid this problem.
Parameters:
§ IV_OBJECT_TYPE_CODE: Table code; Same as the Query method.
§ IT_KEYS: List of internal record/attribute IDs, e.g. result of a query
§ ET_DDIC_STRUCTURE: Target structure where the API puts the retrieved data
§ EXCEPTIONS
q CX_MDM_USAGE_ERROR: Incorrect use of interface, e.g. incorrect or insufficient input
q CX_MDM_PROVIDER: Error at provider level. Internal operation failed due to incorrect use of interface or internal error
q CX_MDM_KERNEL: Kernel level exception, e.g. connection timeout
q CX_MDM_SERVER_RC_CODE: MDM Server return code comes directly from the MDM Server and shows the error situation, e.g. incorrect parameter submitted by the user
q CX_MDM_NOT_SUPPORTED: API currently does not support the function
The structure lt_result_ddic would contain the required fields or the fields which have been asked for.
For Example here we have:
As specified earlier, in case of SIMPLE APIs we need to use the same DDIC structure as the one in MDM.
The types MDM_CDT_AMOUNT and MDM_CDT_DATE_TIME are the MDM supported data types corresponding to the Currency and Literal date, respectively.
There are certain other supported types against the specific types in MDM.
Field | API type |
AutoID | MDM_GDT_INTEGERVALUE |
Boolean | MDM_E_BOOLEAN |
Create Stamp | MDM_CDT_DATE_TIME |
Currency | MDM_CDT_AMOUNT |
GM Time | MDM_CDT_DATE_TIME |
Integer | MDM_GDT_INTEGERVALUE |
Literal date | MDM_CDT_DATE_TIME |
Literal time | MDM_CDT_DATE_TIME |
Log | STRING |
Measurement | MDM_GDT_QUANTITY (single), MDM_GDT_QUANTITY_TABLE (multi) |
Name | MDM_PERSONNAME |
Text | STRING |
Text Large | STRING |
Text Normalized | STRING |
Time Stamp | MDM_CDT_DATE_TIME |
User Stamp | STRING |
Lookup flat | MDM_GDT_INTEGERVALUE, MDM_GDT_INTEGERVALUE_TABLE |
Lookup hierarchy | MDM_GDT_INTEGERVALUE, MDM_GDT_INTEGERVALUE_TABLE |
Lookup taxonomy | MDM_TAXONOMY_ENTRY |
Lookup Qualified flat | MDM_QUALIFIED_LINK_TABLE, |
Tuple | MDM_TUPLE_TABLE |
Text Value | MDM_EXT_ATTR_INFO_TABLE_SL (-ATTR_INFO-ATTR_FEATURE_DOMAIN) |
Numeric Value | MDM_EXT_ATTR_INFO_TABLE_SL (-CHARACTERISTICS), for multi-valued: (-MULTI_NUMERIC_ATTR_VALUES-ATTR_VALUES) |
Coupled Numeric | MDM_EXT_ATTR_INFO_TABLE_SL (-COUPLED_ATTRIBUTE_VALUES) |
This way we can retrieve any flat values against any selection criteria into SAP R/3.
NOTE: The code snippets mentioned are parts of the same continuous code.
This article helps us extract the simple fields from MDM. However, there is another complex kind of fields in MDM. THose are the LOOKUP fields.For the lookup fields the Keymapping technique is used to retrieve the data. In the first retrieve only a set display value is retrieved from MDM, the actual value is obtained by performing a lookup. For instance there is a field GENDER, in the first retrieve it would return 1 or 2. In the second lookup, we would search in, say table GENDERS(lookup table for GENDER) which would provide us with the values male and female. This means GENDER is a lookup field, while the GENDERS lookup table is a key mapped table.
The second version of this document would elaborate the process involved in retrieving the Lookup fields from MDM.
- SAP Managed Tags:
10 Comments
