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.

SAP Developer Network Latest Updates