Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

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

former_member131481
Explorer
‎07-11-2019 1:13 PM

Introduction


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.

Preparation


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!

 

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 '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.


Conclusion


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#overview from SAP Product Management for supporting me in this, especially Marco for the positioning document!
hoang.vu3#overview for contributing Test Case 2 and all the technical help he provided.
2 Comments
Popular Blog Posts