Introduction: In this blog, I will explain how to generate and expose a WSDL/SOAP API in SAP Process Orchestration (SAP PO) 7.5 Single Stack and how it can be consumed as part of an integration scenario.
The integration scenario covered in this blog is:
Azure → SAP PO → SAP S/4HANA
The objective is to expose a SOAP-based API from SAP PO, generate the corresponding WSDL, and make the service available for consumption from Azure.
The complete process can be divided into two major areas:
- Enterprise Services Repository (ESR) – where the required design-time objects are created.
- Integration Directory (ID) – where the integration configuration and SOAP service exposure are configured.
Prerequisite: Before configuring the SOAP API in the Integration Directory, the required ESR objects should be completed.
The ESR development typically includes the required:
- Data Types
- Message Types
- Service Interfaces
- Other required design-time objects
Once the ESR development is completed and activated, we can proceed with the corresponding configuration in the Integration Directory (ID).
End-to-End Integration Flow:
The high-level flow used in this scenario is:
Azure → SOAP API → SAP PO → S/4HANA
Azure acts as the source system and sends the SOAP request to the SOAP endpoint exposed by SAP PO.SAP PO receives the request, processes it according to the configured integration scenario, and then sends the required message to SAP S/4HANA.
The WSDL generated/exposed through the SAP PO configuration provides the contract that the consuming application can use to understand the SOAP service, including the available operations and message structures.
ESR Development:
The first step is to complete the required interface development in the Enterprise Services Repository (ESR).
The required objects should be created according to the integration requirement. Once the ESR development is completed, the objects should be activated and made available for the Integration Directory configuration.
It is important to complete the ESR development before proceeding with the corresponding Integration Directory configuration because the ID configuration uses the interfaces and other objects defined in ESR.
Integration Directory Configuration:
After completing the ESR development, we can move to the Integration Directory (ID).
Here, we configure the integration scenario and the required communication channels.
For the SOAP API exposure, the relevant SOAP configuration is maintained on the sender side. Based on this configuration, SAP PO can expose the required SOAP endpoint and provide the corresponding WSDL information.
The detailed configuration steps, including how to generate/access the WSDL and configure the SOAP endpoint, will be covered step by step in the following sections.
STEPS:
Below is the Channel Created for SOAP Sender since the Scenario is Asynchronous, we are using the quality of service as Exactly once.
After Creating the Sender Channel, we are proceeding with the creation of Integrated Configuration. We are selecting the Service Interface created in ESR while creating the ICO.
After Creating the ICO we are assigning the sender and receiver channels and using Operation mapping which is created in ESR and activate the ICO.
Now right click on the Integration Configuration and select Display WSDL option
Below WSDL screen will appear and we will save the WSDL.
We are using the SOAP UI for Providing the API. Click on the SOAP tile and then upload the saved WSDL through browse.
After clicking on the Ok then the WSDL is loaded and expand the section
After selecting the request, we will get endpoint
Depending on the environment and security requirements, the service may be accessed through HTTP or HTTPS.
Once the SOAP service is configured, the endpoint can be tested with necessary credentials so that we can know it is hitting our SAP PO system. In below we have successfully sent the request to the SAP PO system.
In SAP PO we have successfully received the request and delivered to the SAP PO.We can see the same request which was sent from SOAP UI and SAP PO has received the request and processed the same to S4 Hana.
Now we can conclude that the endpoint is valid and we can share the same endpoint to Source (Azure) with necessary credentials so that they can establish the connection with SAP PO.
For production integrations, HTTPS is generally preferred because it provides encryption for the communication between the consumer and the SAP PO endpoint.
Note:
Since the required connectivity between the internal Azure environment and SAP PO is already established and the network/firewall rules permit the required traffic, no additional IP whitelisting is required for this integration.
Conclusion:
This blog demonstrated an end-to-end approach for exposing a SOAP API using SAP PO 7.5 Single Stack. It covered the key configuration and integration steps required to establish communication between SAP PO and Azure, providing a practical reference for implementing similar integration scenarios.
Happy Learning!!
#abap