Skip to Content
Technical Articles
Author's profile photo Jens Neumann

Calling a BAPI in the SAP S/4HANA Cloud from the Cloud


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:

  1. 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.
  2. 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> 

In our example it reads the data of the equipment just fine!


Some Observations

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 '' 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: CALL connectERRNO       111ERRNO TEXT  Connection refusedCOUNTER     3</Name><Text>Opening connection to backend failed:LOCATION    CPIC (TCP/IP) on local hostERROR       partner '' 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: 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.

Your Feedback

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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Pedro Redondo Garcia
      Pedro Redondo Garcia

      Thanks again Jens, this is what we actually need to do!

      Concerning the internal host name you have been blurring all over the pictures...Is there any rule we could apply to get it by our own ways or should we contact SAP to get it? If we just concatenate mo-<hostid> is not working for us.

      Note: By <hostid> I mean that part on the url string of the S/4 Hana Cloud host name. [https://my<hostid>]


      Thanks in advance!


      Author's profile photo Jens Neumann
      Jens Neumann
      Blog Post Author

      Hi Pedro,

      in this example you have to give the url of the SAP Cloud Connector but keep the backend type ABAP System. The settings are like you were calling an on-premise system but actually you are pointing to a Cloud Connector Service Channel. Your Cloud Connector url will of course be different from mine.

      Hope this helps!