SAP Build Apps and BAPIs: RFC meets Web

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