Dear community,
supporting my post about "Security Orchestration, Automation, and Response" for SAP, I am sharing a step by step guide to expose your legacy RFCs as enterprise services (SOAP) through configuration. No development needed! However, an ABAP developer key is required to activate the enterprise service 🤷🏽♀️🙃
This way the RFC capabilities may be handled by API Management, workflow engines like SAP Build Process Automation, SAP Cloud Integration or Azure Logic Apps without special runtimes.
Such an approach is still useful, because some nice SAP remote function modules just don't have a nice SOAP or OData interface today or maybe ever. S/4HANA Cloud anyone?
For this exercise we will be focusing on a remote function module that enables User locking.
Click Create -> Enterprise Service -> provide the name “ZWS_BAPI_USER_LOCK” or adapt the playbook http step “Block User via SOAP exposed BAPI” accordingly.
🛈Note: Ensure that your SAP system is properly configured regarding ABAP Web Service runtime using transaction SRT_ADMIN. Check SAP notes 2347013 and 3214850 for more details.
For a PoC or single stage setup, consider "user credentials", "no transport guarantee" and local object as shown below.
In production scenarios SAP guidelines for SOAP services with certificate and transport guarantee are recommended. See the API Management docs for more details on the certificate setup if needed.
Once created, don’t forget to click activate 🪄! Otherwise, you need to start over. Been there done that 😉Finish the exercise by creating the service binding via the transaction SOAMANAGER (/sap/bc/webdynpro/sap/appl_soap_management).
Export the SOAP web service description (WSDL) via the highlighted button above. There are multiple ways to grab the XML. I usually choose “View page source” or “inspect website” to get the raw XML without the pretty HTML artifacts. For mass WSDL downloads you may revert to scripting with URL construction based on your service naming convention.
Choose the 👓 to open the service binding and view the calculated SOAP access URL.
That is a more complex one. Learn more from the SAP docs about SAP WSRM, SAP RM etc.
For now I am describing here, how to disable RM and use "pure" SOAP.
See below the configuration for the enterprise service for RFC "TH_DELETE_USER" for ending active backend user sessions.
Test your new enterprise service with any SOAP client having "line-of-sight" to your SAP system. See below my example with SOAPUI as a reference:
See my blog post about Sentinel integration with SAP to see this approach in action with near real-time security threats as triggers.
Troubleshoot any issues with your SOAP request via SAP transaction codes like SRT_LOG to get detailed info. I ran into challenges with XML comments and the RETURN XML tag not being supplied properly on request.
Aaand that's it. You are all set to expose your RFCs to enable scenarios like locking SAP backend users via web service consumers, add them to your API Management solution and interact with them without special RFC libraries. Not too bad, huh?
Cheers
Martin
supporting my post about "Security Orchestration, Automation, and Response" for SAP, I am sharing a step by step guide to expose your legacy RFCs as enterprise services (SOAP) through configuration. No development needed! However, an ABAP developer key is required to activate the enterprise service 🤷🏽♀️🙃
This way the RFC capabilities may be handled by API Management, workflow engines like SAP Build Process Automation, SAP Cloud Integration or Azure Logic Apps without special runtimes.
Such an approach is still useful, because some nice SAP remote function modules just don't have a nice SOAP or OData interface today or maybe ever. S/4HANA Cloud anyone?
Speaking of SOAP, luckily any SAP function module can be exposed as enterprise service!
For this exercise we will be focusing on a remote function module that enables User locking.
Click Create -> Enterprise Service -> provide the name “ZWS_BAPI_USER_LOCK” or adapt the playbook http step “Block User via SOAP exposed BAPI” accordingly.
🛈Note: Ensure that your SAP system is properly configured regarding ABAP Web Service runtime using transaction SRT_ADMIN. Check SAP notes 2347013 and 3214850 for more details.
For a PoC or single stage setup, consider "user credentials", "no transport guarantee" and local object as shown below.
In production scenarios SAP guidelines for SOAP services with certificate and transport guarantee are recommended. See the API Management docs for more details on the certificate setup if needed.
Once created, don’t forget to click activate 🪄! Otherwise, you need to start over. Been there done that 😉Finish the exercise by creating the service binding via the transaction SOAMANAGER (/sap/bc/webdynpro/sap/appl_soap_management).
Export the web service description from SAP SOAMANAGER
Export the SOAP web service description (WSDL) via the highlighted button above. There are multiple ways to grab the XML. I usually choose “View page source” or “inspect website” to get the raw XML without the pretty HTML artifacts. For mass WSDL downloads you may revert to scripting with URL construction based on your service naming convention.
| 🛈Note: You might notice an import validation error for some of the legacy SAP WSDLs. They contain a value under the <portType> element that is not defined on the referenced schema. You may just drop the inconsistent <policy> element from the WSDL and continue your integration journey. |
Identify the calculated SOAP access URL from Transport Configuration
Choose the 👓 to open the service binding and view the calculated SOAP access URL.
What about SOAP reliable messaging?
That is a more complex one. Learn more from the SAP docs about SAP WSRM, SAP RM etc.
For now I am describing here, how to disable RM and use "pure" SOAP.
See below the configuration for the enterprise service for RFC "TH_DELETE_USER" for ending active backend user sessions.
Test your new enterprise service with any SOAP client having "line-of-sight" to your SAP system. See below my example with SOAPUI as a reference:
See my blog post about Sentinel integration with SAP to see this approach in action with near real-time security threats as triggers.
Troubleshoot any issues with your SOAP request via SAP transaction codes like SRT_LOG to get detailed info. I ran into challenges with XML comments and the RETURN XML tag not being supplied properly on request.
Configure API Management to front your SAP SOAP service
- Identify your Azure API Management instance with “line of sight” to your SAP system.
In many cases that requires Azure VNet integration, because the SAP systems are in private Azure networks. See here for RISE specific deployments. To reach on-premises from a spoke network on Azure you will need additional routing. A typical setup will have a routing device on the hub network with access to the ExpressRoute or VPN tunnel spanning to on-premises. To avoid the extra network hop checkout the mentioned blog by Amit using the on-premises data gateway instead.
- Create a new SOAP API from the WSDL you downloaded from SAP and choose import method “SOAP to REST“. That simplifies the usage from the playbook as it converts XML to JSON out-of-the-box. Supply the API URL suffix “lockme” or alter the HTTP step “Block User via SOAP exposed BAPI” on the playbook.
🛈Note: You might notice an import validation error for some of the legacy SAP WSDLs. They contain a value under the <portType> element that is not defined on the referenced schema. You may just drop the inconsistent <policy> element from the WSDL and continue your integration journey.
- Uncheck the “Subscription required” checkbox or provide the header “Ocp-Apim-Subscription-Key” including your key based on the API products chosen.
- Checkout the generated SOAP translation by navigating to the POST operation and opening the code view </>.
- Verify the generated liquid template.
I simplified it further for ease of use and dropped all unnecessary optional fields and qualified the namespace of the element <BAPI_USER_LOCK> with “urn”. See the outbound part of the policy translating the SOAP response to JSON in case the message was processed successfully. Your playbook is grateful for the ready to consume response payload 😊
- SSL handshake and certificate trust is taken care of on the API Management layer. See configuration details here. Alternatively, disable trust chain verification for PoC type implementations (APIs -> Backends -> Validate Certificat Chain).
- Note your API Management Gateway URL and combine with the SOAP path you collected earlier.
- Finish with a good old integration test using the API Management test pane, calling from Postman or using a Logic App like I did below 😎
Final Words
Aaand that's it. You are all set to expose your RFCs to enable scenarios like locking SAP backend users via web service consumers, add them to your API Management solution and interact with them without special RFC libraries. Not too bad, huh?
Cheers
Martin
- SAP Managed Tags:
