SAP Build Apps and BAPIs: RFC meets Web

[Gunter]

"RFC meets Web"

Enable all your RFC functions for web consumption without development?

Today, I'm excited to share a new thing: A proxy on SAP BTP that translates from REST to SAP RFC calls, making it possible to use BAPIs and RFC-enabled function modules on older SAP ECC or S/4HANA systems.

This solution is particularly useful for SAP ERP users who are looking to integrate with systems that lack the new OData APIs that are only available on newer S/4HANA systems. With the REST-to-RFC proxy, RFC meets web, creating a seamless integration experience that unlocks the full potential of your SAP ecosystem.

Benefits:

• Protect your past investment: Use your function modules for the web


• RFC modules turned into synchronous REST APIs


• No further development work


• Secured communication through SAP BTP destinations

Image 1: Outline of solution - it works with any RFC function module (Y/Z-RFC modules included)

In this blog post, we'll take a closer look at how this proxy works, the benefits it provides, and the impact it can have on your SAP integration projects. So, let's dive in and discover the possibilities of web meets RFC!

Solution approach

SAP BTP offers the destination service to define ways to connect to systems. Keeping destinations separate from applications makes them reusable and easy to maintain. They come in several flavors like:

1. HTTP - for anything like REST, OData-REST, HTML and the like.


2. LDAP - Lightweight Directory Access Protocol to lookup information in a network. Often used for organizational data of entities and persons.


3. MAIL - to send emails to an SMTP server


4. RFC - Remote Function Call, this is what we look at for the cloud connector-facing side.

From here we define the first destination to the cloud connector (CC) as RFC. You need to white-list the function modules you plan to use in your cloud connector instance.

Image 2: Example of an RFC destination. The ashost is as defined in your CC.

I use this destination in the Java HTTPServlet. On the consumption side you'll need another destination that you can use for e.g. SAP Build Apps and which is provided by the HTTPServlet. If you secure it with OAuth2 the config could look like that.

Image 3: REST destination for consumption of BAPIs or RFC functions in general.

Since I use xsuaa for authentication and authorization I've defined 2 scopes to allow for display and change authorization.

Image 4: POST and GET related scopes to be assigned to relevant users for consumption.

The difference between the two is that the POST will trigger a BAPI.commit and therefore posts data in your S/4HANA or ECC system while the GET doesn't. Of course it depends on how you've designed your ABAP code - standard BAPIs will adhere to this approach.

SAP Build Apps demo: Change material master

Enough talk! Let's see a demo built with SAP Build Apps. It uses 3 BAPIs:

1. BAPI_MATERIAL_GETLIST - To search for materials and get them in a list


2. BAPI_MATERIAL_GETALL - To retrieve the details of a selected material


3. BAPI_MATERIAL_SAVEDATA - To change some fields in the material master

There is no development done on both backend and frontend.

1. Mobile application

2. SAP Build and S/4HANA Backend

Solution Architecture

Below are the schematics for using the REST to RFC proxy running on BTP Cloud Foundry.

Image 2: Solution architecture for REST-RFC proxy on SAP BTP Cloud Foundry

I'll explain the technical details in a second blog if you are interested to create such a proxy on BTP for yourself.

Conclusion

And there it is: A proxy that opens all your RFC developments to the web in a secured manner. Hope it is useful!

Check my second blog for the technical details on how you can design the proxy on SAP BTP.

[Antonio_leites]

The rejuvenation of SAP Visual Composer without Adobe SVG dependency almost 20 years later ...  nice post.
Congratulations,
Antonio

[Saurabh]

Nice post ! Can we use it to replicate some scenarios on free tier or with  trial account?>

[Summitt12]

Nice blog

how difficult is to consume this App in another cloud product like SAP service cloud

[Ulrich_Schmidt]

It confirms the old proverb from the Bible: "There is nothing new under the sun" (Koh 1,9) ... 🙂

"Enable all your RFC functions for web consumption without development?" -- Well, SAP Business Connector is doing exactly this since 1999... (Not via REST, which did not yet exist back then, but via "old-fashioned" XML documents and HTTP POST...)

[Ulrich_Schmidt]

You probably mean "trial account"?

"Trail" is something different... 🙂

[Gunter]

Yes - I set up beautiful UN/EDIFACT EDI flows with the SAP BC in 2002. Usability of that tool was great! Very easy to edit flows in that Java-Editor. Nostalgic!

[Gunter]

tiwaris2020 Yes, that should work from a services-perspective. Check my second blog for the tech details.

[Gunter]

Hi manish_b The proxy just provides a secured REST API, it doesn't require a certain environment, so you can use it with any SAP or Non-SAP product that understands REST and is able to authenticate through OAuth with User/Pw.

[Saurabh]

Thanks Ulrich , It was  typo 🙂

[Ulrich_Schmidt]

Wow, you used the BC back in the day? Great!

BTW: two years ago, we updated that Java Editor to support today's high-resolution displays... 🙂 So it is still alive and kicking...!

(Very nice for large complicated mappings...)

[Srdjan]

Nice blog Gunter,

using RFC API it is possible to build very powerful web and cloud applications, with the absolute minimum of "glue" code, as described in this blog

https://blogs.sap.com/2023/10/12/powerful-web-applications-with-old-and-new-abap-systems

Thank you for sharing this secure configuration

[Hariom]

Hi Gunter,

Really nice blog!!

Can you please share more details about the process of creating such an app using SAP Build Apps.

I was also not able to create the destination as shown in the second screenshot. Where can I find the URL, Client ID, Client Secret, and Token Service URL to create this destination?

Best Regards

[Gunter]

yadavhariom - thanks!

You get these details from the deployed application itself. Since we bind the xsuaa service into it, you do like shown below:

Within Build Apps you can simply call your proxy with the according URL. E.g. a GET:

https://jco-rfc-rest-server.cfapps.eu10.hana.ondemand.com/rfc/?fm=BAPI_PR_GETDETAIL&query={"NUMBER":"0010001133","ACCOUNT_ASSIGNMENT":"X"}

Or a POST:

https://jco-rfc-rest-server.cfapps.eu10.hana.ondemand.com/rfc/?fm=BAPI_PR_GETDETAIL

// Below is the body of the post

{

	"imports": {

		"NUMBER":"0010001133",

		"ACCOUNT_ASSIGNMENT":"X"

	}

}

Both will lead to the same result. However, if you want to commit data like creating a purchase requisition you must use a POST. Only that will do a BAPI commit (part of the simple authorizations I've built into it).