Classically there were limited options to integrate PI with SAP MDM. All the integrations had to go through standard file adapters with standard file adapter based polling mechanism. However for quite few years now – this has changed. With MDM 7.1 the MDM PI Adapters are available on SAP PI. This is quite a selling point for PI in MDM integrations as well since most the implementations want to move away from a file polling based approach and to my knowledge SAP PI is the only middleware that is seamlessly integrated with SAP MDM out of the box. Also PI provides a standard platform to expose MDM data for CRUD operations. This assumes great significance in designing synchronous communications. If you have SAP MDM installed, it probably doesn’t make a lot of sense to not use SAP PI as a middleware application.
The MDM-PI adapter fits into the Application Server – Java stack and hence also compatible with AEX. Installation is quite simple. The MDM-PI adapter code is packaged as a SCA file. The SCA file needs to be deployed on the PI server which can be done using JSPM. Additionally MDM PI adapter content must also be downloaded and imported into the ESR. These MDM PI adapter content is different than the out of the box content that SAP delivers for MDM Business Content. Requires no additional installation on the MDM server.
Once installed, the adapter can be used for both inbound and outbound communications. MDM-PI adapter supports Exactly Once (EO) and Exactly Once in Order (EOIO) communication protocol. Monitoring the adapter is done in the exact same as any other adapter.
The MDM adapter uses the following internal mechanism of data transfer:
The PI’s receiver MDM adapter sends the data as a XML file to the ready folder (folder exists in MDM file system). This file is time-stamped. This file is then processed in MDIS and the data is persisted in the SAP MDM server. On the reverse end, the data is spit out from MDSS again in the ready folder as a time-stamped XML file. MDSS follows this up with an event to the PI’s MDM adapter. Once receiving this event PI reads the file from the MDM folder and processes its further. MDM and PI share the same schema, and there is no chance of the file being out of sync with either of this system.
Many hate polling and this event based mechanism eliminates any need for polling.
During support one of the most common reasons for the middleware team getting involved with the connecting system is to identify where the data was lost. The MDM PI adapter provides two levels of acknowledgement. One when the file is actually delivered to MDIS and is imported into MDIS and two, when the file is correctly uploaded into SAP MDM server providing PI a full perspective of what happens to the data in MDM. Off course, like any of other adapter, acknowledgment needs to be requested.
In case the MDM – PI connection is down for reasons of downtime, or network failure, the data is not dropped. When the connection is back up again, PI processes the data in exactly the same order in which MDIS spit it out making sure that there is no data loss. Interestingly, in case the MDM server is bounced, the PI adapter provides real time status of the MDM server such as ‘repository mounting’, ‘loading schema’ etc.
Detailed information is available at – How MDM PI adapter works.
This is not a new feature and has been used with NetWeaver Portal based integration for a long time. However there are many cases where you would like do MDM lookups within PI especially in landscapes where you don’t have NetWeaver Portal or have NetWeaver Portal but don’t want to have an additional hop. On use case where I came across was where MDM would not pass PI enough information as part of the MDM syndication and PI had to go back into MDM to look for additional fields. As we all know, MDM is not a relational database. In the absence of workflows, MDM cannot syndicate data that joins two tables. Many implementations take a conscious architecture decision of not using MDM work flows. In such situation the data that gets syndicated out of MDM may not contain all hierarchical information and mandate a requirement on the middleware to look up some fields in MDM during at runtime.
MDM comes with its own API libraries, connectors and a component called the Web Service Generator all packed as SDA files. However these components require SAP’s Java runtime which is not part of MDM installation. PI’s Java stack is a good place to deploy these files. The deployment of these files is quite standard and details are available on the SAP help site. Once deployed, the username and password that these services (on PI servers) use to connect to the MDM repository (MDM server) must be set in the MDM server. Also the exact same username password must be created in PI. So in essence these services use PI’s runtime, but get the data from MDM on a real-time basis.
Once the installation and authentication details are set up, we need create services. Using the browser you can navigate to http://<PI Servers IP Address>:<HTTP port>/mdm/wsgenerator. To log into the generator your name should be assigned to role MDM_WS_Generator. After logging in, you will see a wizard that will enable you to create CRUD operations on any given MDM table.
Source: SAP Help
Moving further, this wizard will also let you generate a service (as an EAR file) and also deploy the service in PI. More details on using the wizard can be found at the SAP Help site.
Once these services are deployed, the next step is to consume the data. Before you go ahead developing a mapping program on these services a good idea is to test it using PI’s WS Navigator. You can search on the operation name and then provide input data in XML format and checking the response.
Once all this completed the service is ready to be called programmatically. The blog Webservice Calls From a User Defined Function provides you an easy way of doing this. This proves the potential of MDM as a true SOA platform and a real time service provider. Using this approach PI can make synchronous calls to fetch data from MDM.
SAP PI is the only middleware application that enables you to deploy these services and then test them out before actually running them. If any other middleware except PI needs to do the same, either they would have to enter through another SAP application which has SAP’s Java stack or force MDM to send additional feeds some file system through which the data can be collated into a single stream in which case chances are that the data is not real-time and one may be working with stale data.
After having analyzed many middleware, none works with SAP MDM like the way PI does and wherever there is a SAP MDM implementation PI must be the de facto choice of ESB.