Showing posts with label SAP MDM ABAP API. Show all posts
Showing posts with label SAP MDM ABAP API. Show all posts

What is the MDM ABAP API?

What is the MDM ABAP API?

Historically most ERP based master data resides in existing ABAP Systems. Also the majority of the business logic in that is consuming the master data also resides in ABAP based systems.  Therefore it makes sense to extend the accessiblity of SAP NetWeaver MDM to allow for easy accessiblity from ABAP.

That is the goal of the MDM ABAP API (MDM4A).  MDM4A takes the same read, modify, search, and Administrative functionalities of the established COM and Java APIs (MDM4J) and brings them to the ABAP World.

By using MDM4A, ABAP developers do not have to learn the SAP NetWeaver MDM specific data types.  MDM4A does the job of mapping all the data types and structures for the developer. It translates the structures such as data arrays into ABAP constructs like Internal Tables.

MDM also takes a different approach to passing language specific data. It might be important to note that all the data is passed through MDM4A via Unicode (UTF-8) regardless of the settings in the AS-ABAP system (Unicode vs. Non-Unicode). The MDM4A layers also do all the work of translating this data into the code page of the current system. Even on Unicode systems, a translation from UTF-8 to UTF-16 must occur.

What is the Architecture of MDM4A?

What is the Architecture of MDM4A?

MDM4A is made up of three major parts:

  • Generic API
  • Provider Framework
  • C-Kernel

The Generic API is a release independent interface into the SAP NetWeaver MDM API.  It is the only layer that application developers should ever directly interact with.  It is comprised of publically available Function Modules and Classes.

The Provider Framework is the release specific implementation of the SAP NetWeaver MDM API.  As new releases or support packages of MDM are released, new matching version fo the provider framework will be created.

However the features of the provider framework are always abastracted by the Generic API, causing the least amount of changes to the consuming applications as possible.  This protects the application developer from changes within MDM breaking their applications. The Provider Framework is not intended for direct access by SAP's Customers or Partners.  The MDM 5.5 SP4 class for the provider framework is CL_MDM_PROVIDER_SP4_PL00.

The Generic API and the Provider Framework are both delivered as part of a SAINT Package (SAP Add-on installed into the system via transaction SAINT).

Finally there are new Kernel Libraries written in C that are an integrated part of the ABAP stack that provide the low level communication interface to MDM. The C-Kernel is an integrated part of the AS-ABAP Kernel. The file dw_mdm.dll is part of the core disp+work package of the Kernel and is installed into /usr/sap/<SID>/DVEBMGS<Instance Number>/exe just like the rest of the Kernel

What Codepage is used by MDM4A?

What Codepage is used by MDM4A?

MDM4A is always a Unicode based interface regardless of the codepage used by the ABAP system.  Althought a Unicode ABAP system is UTF-16, the MDM4A interface is UTF-8.  Therefore regardless of the ABAP system codepage, a codepage conversion must take place. The codepage conversion is done within the inner layers of the MDM4A.  However on non-Unicode ABAP systems if you attempt to process characters from MDM that are outside your current codepage, this will produce a CX_SY_CONVERSION_CODEPAGE shortdump.

In non-Unicode ABAP systems, the best way to avoid such errors is to match the logon langauge of the ABAP system to the langauge used to connect to MDM.

DATA ls_language TYPE mdm_cdt_language_code.
ls_language-language = 'eng'.
ls_language-country = 'US'.
ls_language-region = 'USA'.
lr_api->mo_accessor->connect( ls_language ).

What causes the CRC Check Error?

What does it mean when I receive the following error message:

  Server return code 0x8002000E: File failed a crc check

This probably means that there is a mismatch between the release/patch level of the MDM Server and the ABAP API Add-In or Java API add-in (e.g MDMJAVAAPI04_0.sca).

Although a single ABAP system with the MDM API Add-In could potentially interface with multiple MDM Servers on different release levels, the ABAP MDM API Add-In release level/patch level must always match at least that of the most release level of any MDM Server it connects to. In other words, the ABAP side the MDM APIs (provided via an ABAP Add-In) is backwards compatible, but not forwards compatible.

Lets say for instance that you are running the MDM Server at 5.5 SP4 Patch 0. This would show up as something like 5.5.32.56 in the release level dialog on the MDM Server Console. Your ABAP system should have installed at least the same patch level. If you update your MDM Server to 5.5 SP4 Patch 1 (version 5.5.33.13), then patch one of the MDM ABAP API Add-on must be applied as well. Patches for the MDM ABAP API Add-on can be downloaded from the Service Marketplace.

You also need to make sure that your have configured the correct MDM Provider for your particular repository in the MDM Configuration with the ABAP System (Transaction MDMAPIC).

How do you use the Function Module-Based version of MDM4A?

How do you use the Function Module-Based version of MDM4A?

There are function groups that map directly to the main Interfaces of the provider class. The processing logic is the same (the class-based interface is called from within the Function Modules). Several of the Key Function Modules are "Remote Enabled". Because they are remote enabled, they can also very quickly be generated into Web Services.

Function Group/Class Interface Mapping
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

How do you use the Class-Based version of MDM4A?

How do you use the Class-Based version of MDM4A?

For all class-based access to MDM4A you only interact with the object CL_MDM_GENERIC_API. Internally the Abstract Provider will be instantiated with the release specific provider. All access to the functionality of MDM4A is done through the instances of the main group of Interfaces exposed by the Generic API

The object CL_MDM_GENERIC_API has attributes that hold object references to the 5 major parts of the API:

IF_MDM_ACCESSOR
This interface controls the opening and closing of a connection to a repository.
For many of the other API Methods, you must first have created a connection to a repository via this interface.

IF_MDM_ADMIN
This interface provides access to Admin functions similar to those available via the MDM Console. It includes User (creation, password set, role maintenance) and Repository (Mount or Load Repositories) Administration.

The IF_MDM_ADMIN interface poses an interesting situation. Many of the functions here could be automated and then batch scheduled using the local ABAP Scheduler or the Netweaver Central Scheduler by Redwood. It would also be quite easy to use IF_MDM_ADMIN to batch create users (based upon their existence or role assignment in AS-ABAP) for the MDM Server.

IF_MDM_API_CONFIG
This interface allows you to read the configuration entries from Transaction MDMAPIC for one repository or all of them at once. 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 main interface to directly manipulate the data within a repository.
It includes Check In/Out, Client System Keys, Update, Delete, Creation, and Query of data.

Many of the Core Services have a second method that ends in _SIMPLE. For instance there is UPDATE and UPDATE_SIMPLE. The "Simple" methods accept data dictionary structures that match the format of the repository table that you want to manipulate. This provides an easier interface into the API but requires the creation of a matching structure in the ABAP Data Dictionary.

The field names in the ABAP Data Dictionary Structure must be the same as the Name in the MDM Repository (case-sensitive). You are also restricted to only using the MDM API Data Types. Keep in mind that in ABAP there is no NULL state for a value. Any NULL value from MDM will be returned through the simple data types using the initial value for the underlying Data Dictionary Domain. Use of the specific methods instead of the SIMPLE ones will avoid this issue.

IF_MDM_META
This interface provides methods that allow you to change the metadata of a repository. Many of these methods require that the repository be unloaded before they can be performed.

How do you configure the connection to MDM from ABAP?

How do you configure the connection to MDM from ABAP?

All Configuration is done from Transaction Code MDMAPIC and is broken into 5 main sections:

  • MDM Repositories
  • MDM Server Connections
  • MDM DBMS Hosts
  • ABAP Implementation for MDM Version Support
  • MDM API Trace Configuration

All access via MDM4A is always done for a particular repository. The class based API is instantiated for a particular repository. You can not switch to a different repository within an instance. You must create a separate instance to access a different repository.

In all calls to the function module based API, the repository must be passed in through the mandatory parameter IV_LOG_OBJECT_NAME. Therefore all the configuration in MDMAPIC really revolves around the repository as its central object. Although we will create Server and Database configuration entries it is the Repository entry that drives all configuration through the API.

Server Configuration

First define the TCP/IP communication settings for connection to the MDM Server. Then enter the Server Hostname and the Port for communications. Typically the MDM server runs on Port 20005. The name in the MDM Connection field is arbitrary and only know to the ABAP side of the interface.

Be careful when defining the host name for systems that may have more than one hostname alias. During the connection to the repository via MDM4A, a list of all repositories and their hostname according to the MDM Server will be retrieved. The local customizing will be checked against this list. If the hostnames do not match, then the connection will be rejected. Therefore the use of IP addresses for the hostname is technically possible, but will always lead to a configuration mismatch and rejection.

DBMS Configuration

Repositories may reside on a DBMS that is a different physical system than the MDM server itself, therefore it needs its own configuration entry. The Drop Down Box for DB Type will show all support DBMS types. The name in the MDM DBMS field is arbitrary and only know to ABAP, much like the server name field in the Server Configuration.

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. You must select a class that is derived from the Abstract class CL_MDM_ABSTRACT_PROVIDER. The class provided for SP04 is CL_MDM_PROVIDER_SP04_PL00.

Remember as a developer you should only program against the Generic API and not this lower level provider framework. Otherwise incompatible changes may be introduced by SAP during version changes that break your application coding. The Generic API will use this configuration in order to call the correct logic for the version of MDM that it must connect with.

MDM Repository

We tie all our config. together by specifying for a repository what server, DBMS, and Provider it should use. The Object name is arbitrary and only know to ABAP - although it is used as the key to read all the configuration. The MDM Repository must be the real repository name as it is displayed from the MDM Console.

How do I connect to a Repository using the Class-Based MDM4A?

How do I connect to a Repository using the Class-Based MDM4A?

This is a simple example that only focuses on a few things: Instantiating the MDM4A, making a connection to a repository and exception handling.

DATA api             TYPE REF TO cl_mdm_generic_api.
DATA log_object_name TYPE mdm_log_object_name.
DATA language TYPE mdm_cdt_language_code.
DATA exception TYPE REF TO cx_mdm_main_exception.

log_object_name = 'API_CRUD_1'.
language-language = 'eng'.
language-country = 'US'. language-region = 'USA'.

TRY.
CREATE OBJECT api
EXPORTING
iv_log_object_name = log_object_name.
api->mo_accessor->connect( language ).
****Do Something
api->mo_accessor->disconnect( ).

CATCH cx_mdm_usage_error INTO exception.
****Other Exceptions...
CLEANUP.
TRY.
api->mo_accessor->disconnect( ).
CATCH cx_root.
ENDTRY.
ENDTRY.

IF NOT exception IS INITIAL.
MESSAGE exception TYPE 'E'.
ENDIF.



LOG_OBJECT_NAME is initialized with the key for our repository customizing (from Transaction MDMAPIC). That is only value you have to specify. All the other connection information will be looked up for you by the MDM4A.



We create the instance of the MDM4A by calling the CREATE OBJECT for our instance of CL_MDM_GENERIC_API. We only must pass in the configuration key. You could still have configuration, authorization, or trusting errors; but these exceptions will not be thrown until we connect to the repository in the next step.



Through the API we have access to instances of all 5 of the major interfaces (MO_ACCESSOR=IF_MDM_ACCESSOR, MO_CORE_SERVICE=IF_MDM_CORE_SERVICE, MO_ADMIN=IF_MDM_ADMIN, MO_META=IF_MDM_META, and MO_API_CONFIG=IF_MDM_API_CONFIG). We use api->mo_accessor to establish a connection to our repository. It is this point where the first communication connection is made.



First a list of repositories is retrieved from the MDM Server. This list is matched against our configuration settings to make sure the configuration is correct. Next a connection to the repository is made. The current AS-ABAP User (SY-UNAME) is passed through the interface call without specifying a password. At this point the Trusted Status of the AS-ABAP Server is also checked against the MDM Server allow.ip/deny.ip configuration files.



All processing logic is left out of this example. At the point marked "Do Something" you would place the specific logic.

Once finished with processing, you should disconnect from the MDM server explicitly with a call to the Accessor method DISCONNECT. If you end your application without disconnecting, the connection will remain open until it is cleaned up after its timeout. This will tie up system resources on the MDM Server unnecessarily.



All of our logic is placed within a single TRY...ENDTRY block. That way all errors will trigger into a single exception block. Only one Exception is shown here to save space. There is one super exception that can be caught to get all possible MDM4A specific exceptions - CX_MDM_MAIN_EXCEPTION. Inheriting from this exception are 5 more specific exceptions: CX_MDM_KERNEL (Exceptions within the Kernel layer for the MDM4A), CX_MDM_NOT_SUPPORTED (Exceptions if a method is called that isn't supported by the current release-specific provider that you are using), CX_MDM_PROVIDER (Exceptions generated within the Provider Layer of MDM4A), CX_MDM_SERVER_RC_CODE (Exceptions generated on the MDM Server. The MDM Server specific Return Code and explanatory text are passed back through this exception), and CX_MDM_USAGE_ERROR (Exceptions produced by incorrect usage of an MDM4A interface).



It is important to note the use of the CLEANUP event within the TRY...CATCH Block. Regardless of what type of exception occurred, processing can not continue. However we still want to be sure to close the interface connection and free up the resources allocated to it. Therefore we also call the Accessor DISCONNECT here. This logic path only occurs if an exception is caught. If errors occur within this Disconnect, there isn't really anything that can be done about it therefore the logic catches all exceptions (CX_ROOT) and ignores them.



Finally we process an error message with the text from the exception with the last block of coding.

How does Authentication work in MDM4A?

How does Authentication work in MDM4A?

All authentication between the MDM server and the ABAP system via the MDM4A requires a Server Trust relationship. The SAP NetWeaver MDM Server(s) must trust their AS-ABAP counterparts. Trusting is configured via two files on the SAP NetWeaver MDM server - allow.ip and deny.ip This files contain the IP addresses of the AS-ABAP systems that you want to control access from.

The Files allow.ip and deny.ip should normally be placed directly into the same folder that holds your mds.ini (MDM Server Configuration) file. However if you need to place them in a different location (perhaps a centralized network share) you can configure their location in the mds.ini file. Use the entry TrustFiles Dir=<directory> to specify this location.

Allow.ip and deny.ip must be flat, text only files.

It is possible to wildcard the entries in allow.ip and deny.ip using the * character. You can NOT just specify * to allow all possible IP addresses. You must at least specify one subnet --ie. at least 10.*

Instead of listing each IP address directly, users will most likely take advantage of the wildcard. If you want to allow access from all but a few IP address you can combine the allow.ip and deny.ip entries. For instance you may wish to allow all servers from the 192.168.0.* range. However their may be a single "unsafe" machine in this subnet. You could then place the IP address of this "unsafe" machine within the deny.ip file. This can be useful to keep development or test servers from accidentally updating data in a production repository.

Any IP address not found in the allow.ip file (or if no allow.ip file can be read) will cause all requests will be refused.

Comments can be placed in the allow.ip and deny.ip files using the # character in the first column.

Once the server trust relationship is established, authentication is quite simple. Because there is a trusting relationship, no passwords must be passed through MDM4A. The AS-ABAP user identity (SY-UNAME) will automatically be passed through the MDM4A interface. A repository user with the same ID must exist on the SAP NetWeaver MDM server side for a role to be assigned to the request. Alternatively, User Mapping is possible using the LDAP Connectivity of the SAP NetWeaver MDM Server.

How can I change the timeout parameter?

You have exceeded the MDM ABAP API Communication timeout and recieved an error message, however your process does indeed take longer than the default time.

The timeout parameter is set and controlled by the ABAP side of the communication. The default value of the timeout is 30000 milliseconds. The timeout parameter is controlled by the ABAP Profile Parameter mdm/network_timeout. For more details see OSS Note 968804.

TIP ~ MDM ABAP-API ~ Things to Remember (for Starters)

This is something I found with MDM ABAP APIs and thought to share. It will be quite old and small thing for experts but I guess still a little good for starters.


1.  The *Table code* is case sensitive in MDM ABAP API. If you add *CUSTOMERS* in your console, please use *CUSTOMERS* only in the ABAP API program. Please do not use *Customers* or *customers. Another example is *Customer_MDM* , so dont use *Customer_mdm* etc.*


Works - Only Code of Table is case-sensitive: not Table Name.


Not Works  -  Code needs to be exact, its case-sensitive.


2.   The User-ID is always capital since ECC uses caps for user-Id. Please use *MDMUSER* as console and not *mdmuser. *mdmuser* will give exception that *User is not found.**


Works - Only Name of User is case-sensitive!

Not Works  -  Name needs to be in capital letters, its case-sensitive.


Same is true for Table Fields as well.

In the end, its also a tip that Please Use the ABAP API How to Guides provided. I must admit that they are really helpful and even helped me in solving a simple customer requirement. Cheers !

How can I change the timeout parameter?

You have exceeded the MDM ABAP API Communication timeout and recieved an error message, however your process does indeed take longer than the default time.

The timeout parameter is set and controlled by the ABAP side of the communication. The default value of the timeout is 30000 milliseconds. The timeout parameter is controlled by the ABAP Profile Parameter mdm/network_timeout. For more details see OSS Note 968804.

How can I change the timeout parameter?

You have exceeded the MDM ABAP API Communication timeout and recieved an error message, however your process does indeed take longer than the default time.

The timeout parameter is set and controlled by the ABAP side of the communication. The default value of the timeout is 30000 milliseconds. The timeout parameter is controlled by the ABAP Profile Parameter mdm/network_timeout. For more details see OSS Note 968804.

What causes the CRC Check Error?

What does it mean when I receive the following error message:

  Server return code 0x8002000E: File failed a crc check

This probably means that there is a mismatch between the release/patch level of the MDM Server and the ABAP API Add-In or Java API add-in (e.g MDMJAVAAPI04_0.sca).

Although a single ABAP system with the MDM API Add-In could potentially interface with multiple MDM Servers on different release levels, the ABAP MDM API Add-In release level/patch level must always match at least that of the most release level of any MDM Server it connects to. In other words, the ABAP side the MDM APIs (provided via an ABAP Add-In) is backwards compatible, but not forwards compatible.

Lets say for instance that you are running the MDM Server at 5.5 SP4 Patch 0. This would show up as something like 5.5.32.56 in the release level dialog on the MDM Server Console. Your ABAP system should have installed at least the same patch level. If you update your MDM Server to 5.5 SP4 Patch 1 (version 5.5.33.13), then patch one of the MDM ABAP API Add-on must be applied as well. Patches for the MDM ABAP API Add-on can be downloaded from the Service Marketplace.

You also need to make sure that your have configured the correct MDM Provider for your particular repository in the MDM Configuration with the ABAP System (Transaction MDMAPIC).

Why am I getting the Error in Repository Configuration message when I know my config is correct?

If you have verified your configuration is actually correct, yet you still receive this error message:
Error in repository configuration: <repository id> not found
you may have encountered an error in the system.

This error only occurs if your configuration uses the Oracle DBMS. Fixed value for Oracle is set to 0, yet it is used in an integeter field. Therefore when the MDM API Factory class tries to check the configuration settings, its check for initial on the DBMS_TYPE field produces an error for the Oracle value - 0.

This problem occurs in MDM 5.5 SP4 up till Patch Level 2. OSS note 995252 contains details on the problems and the advance corrections that can be applied.

How do I connect to a Repository using the Function Module-Based MDM4A?

How do I connect to a Repository using the Function Module-Based MDM4A?

This is the exact same logic as our earlier class-based example, just now implemented using the Function Groups.

DATA log_object_name TYPE mdm_log_object_name.
DATA language TYPE mdm_cdt_language_code.

log_object_name = 'LOCAL_MDM'.
language-language = 'eng'.
language-country = 'US'. language-region = 'USA'.

CALL FUNCTION 'MDM_ACCESSOR_CONNECT'
EXPORTING
is_repository_language = language
iv_log_object_name = log_object_name
EXCEPTIONS
ex_api_usage_error = 1
* ....
OTHERS = 6.
IF sy-subrc NE 0.
WRITE: / 'Error during connect: ', sy-subrc.
EXIT.
ENDIF.
****Do Something

CALL FUNCTION 'MDM_ACCESSOR_DISCONNECT'
EXPORTING
iv_log_object_name = log_object_name
EXCEPTIONS
ex_api_usage_error = 1
* ....
OTHERS = 6.
IF sy-subrc NE 0.
EXIT.
ENDIF.


One of the key differences is that now we have to pass the configuration key (the MDM Logical Object Name) into every function module call. Also the exception handling must be repeated and checked after each function module call. The functions don't throw exception classes, therefore TRY...CATCH blocks must be replaced with checks of SY-SUBRC.

How do you use the Function Module-Based version of MDM4A?

How do you use the Function Module-Based version of MDM4A?

There are function groups that map directly to the main Interfaces of the provider class. The processing logic is the same (the class-based interface is called from within the Function Modules). Several of the Key Function Modules are "Remote Enabled". Because they are remote enabled, they can also very quickly be generated into Web Services.

Function Group/Class Interface Mapping
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

How do I connect to a Repository using the Class-Based MDM4A?

How do I connect to a Repository using the Class-Based MDM4A?

This is a simple example that only focuses on a few things: Instantiating the MDM4A, making a connection to a repository and exception handling.

DATA api             TYPE REF TO cl_mdm_generic_api.
DATA log_object_name TYPE mdm_log_object_name.
DATA language TYPE mdm_cdt_language_code.
DATA exception TYPE REF TO cx_mdm_main_exception.

log_object_name = 'API_CRUD_1'.
language-language = 'eng'.
language-country = 'US'. language-region = 'USA'.

TRY.
CREATE OBJECT api
EXPORTING
iv_log_object_name = log_object_name.
api->mo_accessor->connect( language ).
****Do Something
api->mo_accessor->disconnect( ).

CATCH cx_mdm_usage_error INTO exception.
****Other Exceptions...
CLEANUP.
TRY.
api->mo_accessor->disconnect( ).
CATCH cx_root.
ENDTRY.
ENDTRY.

IF NOT exception IS INITIAL.
MESSAGE exception TYPE 'E'.
ENDIF.



LOG_OBJECT_NAME is initialized with the key for our repository customizing (from Transaction MDMAPIC). That is only value you have to specify. All the other connection information will be looked up for you by the MDM4A.



We create the instance of the MDM4A by calling the CREATE OBJECT for our instance of CL_MDM_GENERIC_API. We only must pass in the configuration key. You could still have configuration, authorization, or trusting errors; but these exceptions will not be thrown until we connect to the repository in the next step.



Through the API we have access to instances of all 5 of the major interfaces (MO_ACCESSOR=IF_MDM_ACCESSOR, MO_CORE_SERVICE=IF_MDM_CORE_SERVICE, MO_ADMIN=IF_MDM_ADMIN, MO_META=IF_MDM_META, and MO_API_CONFIG=IF_MDM_API_CONFIG). We use api->mo_accessor to establish a connection to our repository. It is this point where the first communication connection is made.



First a list of repositories is retrieved from the MDM Server. This list is matched against our configuration settings to make sure the configuration is correct. Next a connection to the repository is made. The current AS-ABAP User (SY-UNAME) is passed through the interface call without specifying a password. At this point the Trusted Status of the AS-ABAP Server is also checked against the MDM Server allow.ip/deny.ip configuration files.



All processing logic is left out of this example. At the point marked "Do Something" you would place the specific logic.

Once finished with processing, you should disconnect from the MDM server explicitly with a call to the Accessor method DISCONNECT. If you end your application without disconnecting, the connection will remain open until it is cleaned up after its timeout. This will tie up system resources on the MDM Server unnecessarily.



All of our logic is placed within a single TRY...ENDTRY block. That way all errors will trigger into a single exception block. Only one Exception is shown here to save space. There is one super exception that can be caught to get all possible MDM4A specific exceptions - CX_MDM_MAIN_EXCEPTION. Inheriting from this exception are 5 more specific exceptions: CX_MDM_KERNEL (Exceptions within the Kernel layer for the MDM4A), CX_MDM_NOT_SUPPORTED (Exceptions if a method is called that isn't supported by the current release-specific provider that you are using), CX_MDM_PROVIDER (Exceptions generated within the Provider Layer of MDM4A), CX_MDM_SERVER_RC_CODE (Exceptions generated on the MDM Server. The MDM Server specific Return Code and explanatory text are passed back through this exception), and CX_MDM_USAGE_ERROR (Exceptions produced by incorrect usage of an MDM4A interface).



It is important to note the use of the CLEANUP event within the TRY...CATCH Block. Regardless of what type of exception occurred, processing can not continue. However we still want to be sure to close the interface connection and free up the resources allocated to it. Therefore we also call the Accessor DISCONNECT here. This logic path only occurs if an exception is caught. If errors occur within this Disconnect, there isn't really anything that can be done about it therefore the logic catches all exceptions (CX_ROOT) and ignores them.



Finally we process an error message with the text from the exception with the last block of coding.

How do you use the Class-Based version of MDM4A?

How do you use the Class-Based version of MDM4A?

For all class-based access to MDM4A you only interact with the object CL_MDM_GENERIC_API. Internally the Abstract Provider will be instantiated with the release specific provider. All access to the functionality of MDM4A is done through the instances of the main group of Interfaces exposed by the Generic API

The object CL_MDM_GENERIC_API has attributes that hold object references to the 5 major parts of the API:

IF_MDM_ACCESSOR
This interface controls the opening and closing of a connection to a repository.
For many of the other API Methods, you must first have created a connection to a repository via this interface.

IF_MDM_ADMIN
This interface provides access to Admin functions similar to those available via the MDM Console. It includes User (creation, password set, role maintenance) and Repository (Mount or Load Repositories) Administration.

The IF_MDM_ADMIN interface poses an interesting situation. Many of the functions here could be automated and then batch scheduled using the local ABAP Scheduler or the Netweaver Central Scheduler by Redwood. It would also be quite easy to use IF_MDM_ADMIN to batch create users (based upon their existence or role assignment in AS-ABAP) for the MDM Server.

IF_MDM_API_CONFIG
This interface allows you to read the configuration entries from Transaction MDMAPIC for one repository or all of them at once. 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 main interface to directly manipulate the data within a repository.
It includes Check In/Out, Client System Keys, Update, Delete, Creation, and Query of data.

Many of the Core Services have a second method that ends in _SIMPLE. For instance there is UPDATE and UPDATE_SIMPLE. The "Simple" methods accept data dictionary structures that match the format of the repository table that you want to manipulate. This provides an easier interface into the API but requires the creation of a matching structure in the ABAP Data Dictionary.

The field names in the ABAP Data Dictionary Structure must be the same as the Name in the MDM Repository (case-sensitive). You are also restricted to only using the MDM API Data Types. Keep in mind that in ABAP there is no NULL state for a value. Any NULL value from MDM will be returned through the simple data types using the initial value for the underlying Data Dictionary Domain. Use of the specific methods instead of the SIMPLE ones will avoid this issue.

IF_MDM_META
This interface provides methods that allow you to change the metadata of a repository. Many of these methods require that the repository be unloaded before they can be performed.

How do you configure the connection to MDM from ABAP?

How do you configure the connection to MDM from ABAP?

All Configuration is done from Transaction Code MDMAPIC and is broken into 5 main sections:

  • MDM Repositories
  • MDM Server Connections
  • MDM DBMS Hosts
  • ABAP Implementation for MDM Version Support
  • MDM API Trace Configuration

All access via MDM4A is always done for a particular repository. The class based API is instantiated for a particular repository. You can not switch to a different repository within an instance. You must create a separate instance to access a different repository.

In all calls to the function module based API, the repository must be passed in through the mandatory parameter IV_LOG_OBJECT_NAME. Therefore all the configuration in MDMAPIC really revolves around the repository as its central object. Although we will create Server and Database configuration entries it is the Repository entry that drives all configuration through the API.

Server Configuration

First define the TCP/IP communication settings for connection to the MDM Server. Then enter the Server Hostname and the Port for communications. Typically the MDM server runs on Port 20005. The name in the MDM Connection field is arbitrary and only know to the ABAP side of the interface.

Be careful when defining the host name for systems that may have more than one hostname alias. During the connection to the repository via MDM4A, a list of all repositories and their hostname according to the MDM Server will be retrieved. The local customizing will be checked against this list. If the hostnames do not match, then the connection will be rejected. Therefore the use of IP addresses for the hostname is technically possible, but will always lead to a configuration mismatch and rejection.

DBMS Configuration

Repositories may reside on a DBMS that is a different physical system than the MDM server itself, therefore it needs its own configuration entry. The Drop Down Box for DB Type will show all support DBMS types. The name in the MDM DBMS field is arbitrary and only know to ABAP, much like the server name field in the Server Configuration.

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. You must select a class that is derived from the Abstract class CL_MDM_ABSTRACT_PROVIDER. The class provided for SP04 is CL_MDM_PROVIDER_SP04_PL00.

Remember as a developer you should only program against the Generic API and not this lower level provider framework. Otherwise incompatible changes may be introduced by SAP during version changes that break your application coding. The Generic API will use this configuration in order to call the correct logic for the version of MDM that it must connect with.

MDM Repository

We tie all our config. together by specifying for a repository what server, DBMS, and Provider it should use. The Object name is arbitrary and only know to ABAP - although it is used as the key to read all the configuration. The MDM Repository must be the real repository name as it is displayed from the MDM Console.

SAP Developer Network Latest Updates