In this series of Blog Posts I have published my learnings from setting up various scenarios connecting OnPrem and the Cloud via RFC and BAPI Calls. At one point a requirement from a customer came back to my mind: Use SAP Cloud Platform Integration as a Middleware to receive data from an external system, map it to a BAPI structure and then make a call into SAP S/4HANA Public Cloud. It turned out that direct RFC calls in the SAP Cloud do not work. The workaround is to go via a SAP Cloud Connector located somewhere on premise.
I have mentioned multiple times that this scenario is not supported and hence not suited for productive environments or, let’s put it in this words:
“You can do it. But if you die, please die quietly.”.
Calling a BAPI in the SAP S/4HANA Cloud from the Cloud
We build on the scenario from the previous Blog Post. What we want to achieve is this:
Remember SAP Note 2447593:
- This setup is not officially supported, meaning, although it may work now and for a while, there is no guarantee that changes in e.g. the Cloud Connector or something else can render it inoperational with no warning at all.
- Going from Cloud to OnPrem back to the Cloud involves a lot of overhead and hence tends to be slow..
I got it to work, though.
What I used
- A functional SAP Cloud Connector Instance + user with administrative privileges
- An SAP Cloud Platform Integration tenant + user with administrative privileges
- An SAP S/4 HANA Public Cloud Tenant + user with administrative privileges
- The previous test case
- Postman on my Desktop
What I did
- Copy the IFlow from the previous test case
- Settings in the Cloud Connector
- Maintain a Destination in the Cloud Cockpit Subaccount
- Test the connection and the BAPI from Postman
Setting everything up
First step is to copy the IFlow. It can be left untouched, only two settings need to be adjusted:
- The endpoint to call the IFlow
- The RFC Destination in the RFC Receiver adapter. Before we can change the RFC Destination
We have to make the necessary configurations in the SAP Cloud Connector and in the SAP Cloud Platform Cockpit Destinations.
Setting up the Channel in SAP Cloud Connector
Set up a channel pointing to the SAP On-Premise System and using RFC, just like before. But as target host specify the Cloud Connector URL (in my case the name of the system url resembles the name of SAP Cloud Connector url, but in fact they are different. I had to blur the important details because of data protection reasons):
Like in the previous scenario, you will use the Virtual Host Name in the destination.
Don’t forget to add the proper resource, so the BAPI can be called! We are using the Equipment Details BAPI from the very beginning of the series.
Next, maintain the destination in the SAP Cloud Platform Subaccount. Check the available SAP Cloud Connectors first:
If your setup was correct, the Virtual Host you just maintained is available!
In the destination, maintain the fields accordingly:
jco.client.ashost is the Virtual Server you maintained, Client, Lang and Sysnr are those of the SAP S/4HANA Public Cloud.
The user “API” is the same as in the earlier examples and is the CommUser in the Cloud System. The name of the destination will be used in the IFlow in SAP Cloud Platform Integration.
Next, change settings in the copied IFlow. Set a new endpoint for the https Sender Adapter:
And use the new RFC Destination in the RFC Receiver Adapter:
Save & Deploy. You will notice that the deployment takes quite some time. After that you can call the IFlow from Postman with this Payload (use an Equinumber that is in use in your system!):
<?xml version="1.0" encoding="UTF-8"?> <ns1:BAPI_EQUI_GETDETAIL xmlns:ns1="urn:sap-com:document:sap:rfc:functions"> <EQUIPMENT>000000000010000000</EQUIPMENT> </ns1:BAPI_EQUI_GETDETAIL>
In our example it reads the data of the equipment just fine!
If you change the Destination in SCP, you need to redeploy the IFlow!
I actually wanted to find out how this scenario can work. The only connection I see is the Local Instance Number in the OnPrem to Cloud RFC Channel:
This may seem silly but I changed it in SCC it to 02 and got this very nice error:
An internal server error occured: <?xml version="1.0" encoding="UTF-8" standalone="no"?><rfc:BAPI_EQUI_GETDETAIL.Exception xmlns:rfc="urn:sap-com:document:sap:rfc:functions"><Name>Opening connection to backend failed:LOCATION CPIC (TCP/IP) on local hostERROR partner '10.97.yy.xxx:sapgw00' not reachedTIME Tue Feb 5 17:46:14 2019RELEASE 749COMPONENT NI (network interface)VERSION 40RC -10MODULE /bas/749_REL/src/base/ni/nixxi.cppLINE 3428DETAIL NiPConnect2: 10.97.65.119:3300SYSTEM CALL connectERRNO 111ERRNO TEXT Connection refusedCOUNTER 3</Name><Text>Opening connection to backend failed:LOCATION CPIC (TCP/IP) on local hostERROR partner '10.97.yy.xxx:sapgw00' not reachedTIME Tue Feb 5 17:46:14 2019RELEASE 749COMPONENT NI (network interface)VERSION 40RC -10MODULE /bas/749_REL/src/base/ni/nixxi.cppLINE 3428DETAIL NiPConnect2: 10.97.yy.xxx:3300SYSTEM CALL connectERRNO 111ERRNO TEXT Connection refusedCOUNTER 3</Text><Message> <ID/> <Number/> </Message><Attributes> </Attributes></rfc:BAPI_EQUI_GETDETAIL.Exception>.The MPL ID for the failed message is : AFxZy-V5D-kCePJtF3A_1NWRWzMyFor more details please check tail log.
When I check the destination in SAP Cloud Platform, this error occurs:
So I change the Cloud to OnPrem Channel accordingly to SAPGW02:
That done, it works again!
The local instance number determines the port:
My explanation: OnPrem to Cloud channel is listening on the SCC machine on port 3302. The Cloud to OnPrem Channel is sending to port 3302 on the same machine.
This concludes my blog about BAPI Calls in the age of cloud. Over time the white-listed BAPIs will be replaced by SOAP and OData-APIs and the cases described here (at least those which are supported!) will lose their purpose. In general I assume there will be only rare occasions when they can be used at all. But with setting them up I learned a lot and once again felt the joy of making integration work.
Thanks for following my Blog!
Please let me know if the description was helpful and you were able to set up the same test case. Any feedback how to improve this blog post is welcomed! Please put it in the comment section.
Special thanks go to
Marco Matha and Andreas Muno from SAP Product Management for supporting me in this, especially Marco for the positioning document!
Hoang Vu for contributing Test Case 2 and all the technical help he provided.