How to connect SAP PO running over netweaver 7.50 with OpenText XML Adapter
Category:Programming,SAP,SAP PI/POIntroduction
In today’s digital landscape, enterprises rely heavily on seamless integration between platforms to maintain agility, optimize operations, and enhance digital transformation initiatives. SAP Process Orchestration (SAP PO) is a comprehensive integration software that enables the synchronization of processes and data across numerous SAP and non-SAP applications. One such integration possibility involves connecting SAP PO with OpenText’s SOAP API to facilitate efficient document management capabilities.
OpenText is a leading enterprise information management company known for its robust solutions, including its SOAP API which provides functionalities for document management. Integrating SAP PO with OpenText’s SOAP API allows organizations to achieve a streamlined connection between their business processes and their document management systems, thereby enhancing access to vital information and documents.
Before embarking on this integration journey, several key considerations must be addressed, including authentication mechanisms, message format mapping, and error handling. Given that SOAP (Simple Object Access Protocol) relies on XML-based messaging protocols, mastering these elements is critical for a successful and secure integration. This article will guide you through the essential steps for establish a secure connection to OpenText’s SOAP API and offer insights into how to authenticate users and manage documents effectively.
Goal
The goal of this article is to guide enterprises on connecting a legacy system to OpenText using SAP PO, and to generate a single endpoint that encapsulates multiple requests to different services exposed by OpenText. By achieving this, organizations can streamline their document management processes, reduce complexity, and enhance the efficiency of their operations.
The first step in order to achieve the integration of both systems will be to Establishing a secure and reliable connection between SAP PO and OpenText’s SOAP API requires robust authentication mechanisms.
In this case we will delve into the basic authentication. Understanding this methodology is crucial for safeguarding your data and ensuring authorized access only.
Once authenticated, the core of the integration lies in the consumption of document management features offered by the OpenText SOAP API. This section offers a step-by-step guide on how to configure SAP PO to interact with OpenText’s document management functionalities.
To simplify, the basic architecture will be structured this way.
A single interface is presented to the legacy system, which is then divided within SAP PI to engage multiple interfaces based on a custom tag referred to as method.
Step 1.
Generate a single data type with a common structure for the services that will be consolidated on one.
The following Data Type will be used as the request
And this Data Type will be used for the response
Transformation process involve several use of graphical mapping and XSLT transformations in order to achieve the goal to get a single entry point for all the exposed services, with the graphical mappings allowing to include transformations and validations in order to detect the data type received
Step 2
Define the graphical message mappings for request and response, one for each inbound service interface defined.
Step 3
At the response graphical mapping, add custom java functions in order to identify and set the data type of the values that are returning, the custom functions must to be embedded inside the mapping and be called as custom functions.
This custom function receive 5 entry parameters that are returned by the opentext get node method, evaluate the data type of the value and return a single text with the description of the type, the goal of this is reduce the complexity of the logic at the legacy system.
Here is the Java code of the custom function
at also another custom function was developed to validate the data type of any value returned at the Values tag
Step 4
Build the XSLT transformations in order to adapt the structure to the opentext services, this will add the corresponding namespaces, eliminate non necessary tags and generate the parents when will be need it.
Step 5.
Build the operation mapping that will be in charge of call sequentially the graphical message mapping and the XSLT transformations, this operation mapping will have one step for request and another for response considering the process defined as Synchronous.
Request side will at first call the graphical mapping and at second will use the XSLT transformation
The response side will call the XSLT transformation that will adapt the structure, then add the namespace and at last use the graphical mapping where the custom java functions are located
Once all the steps are done and the iFlow is created and deployed the service could be tested using SOAP UI.
Conclusion
This approach allow to generate a single endpoint to consume some specific methods of the Opentext implementation, allowing to get an homogeneous structure at response, but will require some work if new methods will be implemented, at also the architecture could be considered slightly coupled since maintenance could be required as well but not frequently.
The current architecture could face several challenges to be migrated to SAP Integration Suite running over BTP