WebSocket RFC – RFC For the Internet

thomas_weiss · ‎2021 Jul 19

Introduction, Overview, and Availability

By using WebSocket as an alternative transport layer for Remote Function Call (RFC), WebSocket RFC, the new web-enabled flavor of RFC, combines the benefits of a standardized transport layer with the well-known advantages of RFC and the benefits of RFC's fast serialization. WebSocket RFC is easy to administrate and is secure by default.

Profit from a New Standardized Transport Layer for RFC

You no longer need a VPN tunnel for RFC connections across network borders, avoid the time-consuming process of setting up a VPN tunnel and the costs entailed by this in terms of time and money required for the respective certificates.

Hybrid scenarios are possible without an intermediate SAP Cloud Connector (in this weblog further on, for reasons of simplicity named "Cloud Connector" ).

You can use standard HTTPS ports (443) - the normal HTTP port (80) should not be used because TLS is mandatory for WebSocket RFC as described below -, standard HTTP network infrastructure and tools since WebSocket uses an upgraded HTTPS connection.

In a nutshell, you avoid the disadvantages of the proprietary CPIC protocol so far underlying all RFC communication, and, instead, benefit from a standardized, web-enabled transport layer.

Well-known Strengths of RFC

High performance,
Tight coupling by usage of a continuously open connection,
RFC’s close integration into the ABAP programming model, which is the reason why
Exposing a function module for calls from another system or calling a remote-enabled function module (RFM) in another system requires hardly any special knowledge about RFC connectivity on the part of the ABAP developer – no matter if you use RFC over CPIC or over WebSocket.

Advantages due to Automatic Use of Fast Serialization

Faster by factors than classic serialization and basXML.

Transmission speed is equally high for all data and parameter types so that

No expert knowledge is required for developing, configuring, and extending high-performing fast RFC scenarios via WebSocket RFC. With fast serialization it is easy to achieve high RFC performance.

Fast serialization’s S/4 HANA mode mitigates problems in the RFC transmission caused by incompatible changes of DDIC types with every S/4HANA release.
(Find more on RFC's fast serialization in my weblog How to Profit from FAST RFC Serialization)

Secure by Default

All WebSocket-RFC-connections are TLS-encrypted: WebSocket RFC always uses HTTPS.

UCON protection for WebSocket RFC is mandatory and by default active on-premise and in the cloud: You can have different allowlists for the RFMs you expose via CPIC and via WebSocket RFC, which means that you can expose one subset of your system's remote enabled function modules (RFMs) for external access by RFC over CPIC and another subset for external access via WebSocket RFC.

Supported Authentication Methods

Basic authentication - user/password

x.509 - mutual TLS authentication

Trusted-trusting (only on-premise)

Full Support of Queued RFC

WebSocket RFC works fine with t/q/bgRFC.

Availability of WebSocket RFC

Delivered as part of SAP S/4HANA 1909 with its underlying ABAP Platform and
Also available in S/4HANA Cloud and SAP BTP ABAP environment: In SAP BTP ABAP environment, you can create RFMs that can be called from outside (inbound scenario) and you can call RFMs in other systems (outbound scenario). In S/4HANA Cloud inbound and outbound WebSocket RFC scenarios are also possible, if the respective RFMs are part of a Communication Scenario delivered by SAP. As for further details of WebSocket RFC scenarios in the cloud, have a look at the boxed paragraph below "Integration via WebSocket RFC in the cloud".
Support by RFC-based connectors: So far supported on the client side as of SAP Java Connector 3.1 and on the server side as of SAP Java Connector 3.1.3 and as of NetWeaver RFC SDK 7.50 on client and server side. The implementation of WebSocket RFC is also planned for .NET Connector on client- and server side. So far there is no support for WebSocket RFC in the Cloud Connector.

Scenarios in Which You Profit Most from WebSocket RFC

You want to call RFMs across the borders of your company network, e.g. between on-premise systems in different data centers or between your system and the one of your supplier without the tedious process of setting up a VPN tunnel, or you want to expose one group of RFMs to calls from outside of your company network (via WebSocket RFC) and a different group of RFMs to calls from within this network (for which, in general, CPIC-based RFC is used).
As for hybrid connectivity scenarios between an ABAP-based cloud solution and your on-premise system, you can call RFMs in an
- ABAP-based Cloud solution from an on-premise system via WebSocket RFC without an intermediate Cloud Connector.
- On-premise system from an ABAP-based cloud solution without Cloud Connector, but this is only possible, if the respective on-premise system is exposed to the internet. If your on-premise system cannot be reached from the internet, you need Cloud Connector to call RFMs in this system from the cloud. Since the CPIC-based RFC is tunneled via TLS between Cloud Connector and the respective ABAP system in the cloud, CPIC-based RFC suffices for hybrid RFC-scenarios with Cloud Connector. For this reason, Cloud Connector does not support WebSocket RFC in any direction.
Cloud-cloud scenarios: In the cloud, WebSocket RFC enables you to expose RFMs to other SAP cloud products via WebSocket RFC.

Compatibility of WebSocket RFC and Its Limits

Compatibility: WebSocket RFC is mainly compatible with CPIC RFC - with the exception of these minor restrictions: WebSocket RFC does not support

RFC callback/the usage of “DESTINATION BACK”,

Communication with RFMs that open SAP GUI-based UI/Web GUI (and

Forward debugging.

Configuration and Test Costs for a WebSocket RFC Scenario

Creating or maintaining a destination for a WebSocket-RFC-connection is little work in itself – both on-premise and in the cloud – for a new scenario, but requires some more effort - mainly in terms of testing -, if you want to use WebSocket RFC in an existing RFC scenario: You need a suitable destination, have to make sure that the RFMs belonging to the respective scenario are on the relevant allowlist of UCON for WebSocket RFC (also cf. section “How to Set up and Maintain UCON Allowlists for WebSocket RFC in More Detail” below) and have to preclude that the RFMs called in your scenario call “DESTINATION 'BACK'” or open an SAP GUI-based UI.

Creation and Configuration of a WebSocket RFC Connection

This is how you get a suitable destination to make an RFC connection over CPIC into a WebSocket RFC scenario or to create a new WebSocket RFC scenario:

On-premise: An administrator creates and configures a destination for WebSocket RFC – as usual – in transaction SM59. You just need the new type "W". Using a destination of this type in the “CALL FUNCTION” statement you get a WebSocket RFC connection.
In the cloud instead of using transaction SM59, creation and maintenance of destinations is done

In the Communication System in S/4HANA Cloud.

In SAP BTP ABAP environment: In the Communication System or in the SAP BTP Destination Service

In SAP BTP ABAP environment, just choose proxy-type “Internet", in S/4 HANA Cloud “Cloud Connector off”.

Get the Relevant RFM(s) on the UCON Allowlist for WebSocket RFC

The effort to set up the mandatory allowlists for a WebSocket RFC scenario depends on whether the respective RFMs are in the cloud or on-premise and – in on-premise systems – whether it is a new or an existing scenario:

Exposing an RFM to be called via WebSocket RFC in the cloud requires no additional test effort because all RFMs in the respective Communication Scenario are automatically added to the respective allowlist (cf. below: “Integration via WebSocket RFC in the Cloud”.)
In on-premise systems due to mandatory and active-by-default UCON protection for RFMs exposed via WebSocket RFC:
- New RFC Scenarios require little effort in this regard because, in these scenarios, it should be known which RFMs need to be exposed.
- Switching existing RFC scenarios to WebSocket, in general, requires extensive testing because, usually, it will take some time to find out which RFMs need to be exposed in a particular scenario and therefore to be added to the respective UCON allowlist.

Ensure the Relevant RFMs do Not Use Features Incompatible with WebSocket RFC

Again, less effort is needed, if you want to use WebSocket RFC in a new RFC scenario: In this case, you know the RFMs called by the scenario and it should not be too much work to preclude that the respective RFMs make callbacks or open an SAP-GUI or WEB-GUI-based UI.

As for existing RFC scenarios between different on-premise systems, more testing may be needed before you know which RFMs are called via the respective WebSocket destination and whether these RFMs make callbacks or open an SAP-GUI or WEB-GUI-based UI. Using WebSocket RFC in cases in which hybrid RFC scenarios (between Cloud and on-premise) via Cloud Connector have been used so far, should require less testing because these incompatible features are also not supported by Cloud Connector.

In general, it is a good idea to test things thoroughly if you use WebSocket RFC for an already existing RFC scenario.

Note: Keep in mind that as with all connectivity features, WebSocket RFC can only be used, if it is supported on the client and server side of a connection.

No Code Changes Required for Calls via WebSocket RFC

The code to create an RFC-call is the same no matter whether WebSocket or CPIC is the underlying transport layer. Just use the good old “CALL FUNCTION” statement also for WebSocket RFC: In all supported RFC scenarios – that is all scenarios except for those using RFC callback or opening an SAP-GUI or WEB-GUI-based UI – you can use WebSocket RFC instead of RFC over CPIC. No need not change the “CALL FUNCTION” statement in any way: All you need is a destination of type “W”. And, of course, you should make sure that the RFMs called via WebSocket RFC do not use "DESTINATION BACK" or open an SAP-GUI or WEB-GUI-based UI.

No Particular Connectivity Knowledge Required by Developers for WebSocket-RFC-Calls

While usage of other HTTP-based connectivity technologies may require a developer to have some complex knowledge of the respective technology, developers using WebSocket RFC get along with the limited knowledge required to set up an RFC call. WebSocket RFC does not require the creation of a particular proxy or a detailed understanding of how things are serialized. The complete WebSocket handling is transparent in a lower layer and developers and administrators need not care about it.

Integration via WebSocket RFC in the cloud

As for all connections with other systems in ABAP-based clouds,

(1) Inbound WebSocket RFC scenarios need:

A dedicated Communication scenario that defines all RFMs to be called on the server side (inbound scenario) and

The Instantiation of this Communication Scenario in form of a Communication Arrangement with a Communication System and a Communication User (cf. related documentation and tutorial for SAP BTP ABAP environment).

(2) Outbound WebSocket RFC scenarios offer two options. You can

Instantiate the respective Communication Scenario (as described above under item 1) or

Make do without a Communication Scenario and simply use a reference to the respective destination in the SAP BTP Destination Service in your ABAP Code. (cf. related documentation)

All this, by and large, is the same for all types of communication in the cloud between different systems: WebSocket RFC scenarios do not differ in any principal way from scenarios based on RFC via CPIC or HTTP in the cloud. But there is a basic difference as to

Whether a business or technical scenario is delivered by SAP, in which case SAP develops the respective Communication Scenario and you as customer only configure/instantiate it,

or

Whether something is developed by the customer, in which case the customer first needs to create the relevant Communication Scenario (if one is needed) before configuring it.

Important Note: Before enabling a WebSocket RFC scenario, make sure that all RFMs to be called over WebSocket do not open any SAP-GUI or WEB-GUI-based UIs or make callbacks. Often, this will require extensive testing.

The Different Layers of WebSocket RFC and CPIC RFC

Basically, WebSocket RFC differs from CPIC RFC by having a different transport layer and mandatory fast serialization, while you call an RFM via WebSocket RFC just the way you are used to as an ABAP developer:

WebSocket RFC in More Detail

High Performance and Compression

WebSocket-RFC’s permanent use of fast serialization achieves a much higher data compression than classic serialization and basXML, which is partially due to it using different compressions for LAN and WAN scenarios:

In WAN, a high compression rate is most important to reach a high performance and to minimize network bandwidth costs. This is why, in WAN scenarios, fast serialization uses a compression algorithm with a high compression rate and, to some degree, ignores the time needed for the data compression.
In LAN, fast serialization uses a compression with a good balance between payload reduction and the time needed to process the compression algorithm – because in LAN compression speed and compression rate are equally important.

WebSocket RFC automatically selects the best compression for your RFC scenario because it measures the latency of the respective connection during the TLS handshake and, based on this measurement, decides, if LAN or WAN compression is better. Still, you can override this automatic selection and chose to always use the high WAN compression, if – for example – you primarily want to save bandwidth because you are in a cloud scenario and may have to pay for bandwidth

Note: Automatic selection of the best compression is only available for connections between two ABAP servers and not supported by the RFC-based connectors.

Note: By default, the line between LAN and WAN is 110 ms, but you can adapt this to your specific needs.

Latest Supported Version of WebSocket RFC Used Automatically

The WebSocket handshake exchanges protocol information so that always the highest version of WebSocket RFC is used that is supported both by client and server. There is no need to select and maintain this version manually in transaction SM59.

Extensibility of RFC Parameters and Incompatibilities Due to Field-Extensions in S/4

Due to WebSocket RFC's use of fast serialization, incompatibilities between structures on the client side and structures on the server side are detected. If possible without data loss, the data is automatically transferred to the server-side structures, otherwise - if data loss within a particular component cannot be avoided due to incompatibility between parameter-types on client- and server-side - an error message is thrown: This mitigates many of the problems caused by incompatible changes of DDIC types with every new S/4 release. Fast serialization allows for field extensions or the introduction of new fields at all positions in structures used in interfaces of existing function modules, which has the consequence that fields that do not exist on both sides are omitted in the data transmission, and no error message is thrown in this case.

Web Socket RFC's Flavor of Fast Serialization Supports Transparence and Maximal Parameter Extensibility

Just as ABAP Objects – compared to procedural ABAP – offers more and less at the same time, namely more powerful object-oriented features and a stricter syntax check, which forbids many old statements, WebSocket RFC’s mandatory use of fast serialization’s future-proof interface contract for new scenarios is more powerful in terms of parameter extensibility and, also at the same time, forbids non-transparent parameter mapping mechanisms used in exceptional situations - most times in scenarios connecting newer with very old releases - by the other RFC serializations. WebSocket RFC’s flavor of fast serialization

Offers you maximal extensibility of structures and tables, namely at all positions, not only at the end, and

Strictly forbids extreme differences in technical properties of the same RFC parameter between client- and server side, which often are tolerated by classic serialization or basXML and handled by unexpected exceptional mapping mechanisms. While fast serialization for CPIC-based RFC also has these modes that, to a large degree, emulate these exceptional mapping mechanisms of the other RFC serializations, WebSocket RFC does not offer fast serialization's emulation/compatibility modes for basXML and classic serialization. Instead WebSocket RFC's mandatory usage of fast serialization's future-proof interface contract for new scenarios enforces a transparent and consistent behavior as to which differences in the same RFC parameter between client- and server side are tolerated, and which differences lead to an error. (Find out more on fast serializations different flavors or modes in my weblog How to Profit from FAST RFC Serialization in the section on configuration.)

Support for Multiplexing and Load Balancing

Multiplexing for WebSocket RFC means that a physical WebSocket connection/tunnel is only created once between two points and can be re-used for other RFC connections via WebSocket between these two points. Given this re-use of a WebSocket tunnel, the fact that WebSocket protocol and TLS need several handshakes to setup a connection only has a small impact on the performance of WebSocket RFC. There is also support for load balancing by Web Socket RFC.
Still, multiplexing and load balancing have some restrictions and presuppositions as explained in the table below:

	ABAP System – ABAP System	ABAP-based Connector/NW RFClib – ABAP System
Load Balancing	Only with SAP Web Dispatcher.	Standard HTTP(S) load balancer will also do.
Multiplexing	Only with Web Dispatcher and if HTTP/2 is supported by all infrastructure in between client and server.	Not possible due to missing HTTP/2 support by connectors, but this is remedied by connectors' pooling of unused RFC connections (both for RFC over CPIC and WebSocket) that enables re-use of RFC connections.

How to Set up and Maintain UCON Allowlists for WebSocket RFC in More Detail

As you already know, in the cloud, all RFMs to be exposed by WebSocket RFC (inbound scenario) need to be listed in a Communication Scenario. Then all these RFMs are automatically added to the UCON allowlist for WebSocket RFC once the respective Communication Scenario is activated. (The same is true for RFMs to be called via CPIC RFC: The respective UCON allowlist is automatically maintained based on the RFMs listed in the relevant Communication Scenarios.)

On-premise, for the usage of WebSocket RFC, there is a new UCON scenario that is mandatory and active by default. Now you have UCON RFC basic (for calls via CPIC) and UCON for WebSocket RFC with different allowlists for RFMs to be exposed via CPIC and via WebSocket. In on-premise systems, you must fill the respective allowlists manually, while – as you know by now - in the Cloud, all called RFMs for incoming calls (inbound scenarios) are defined in the Communication Scenario, and then automatically added to the respective UCON allowlist.

Exposing RFMs to calls via CPIC from within your company’s network is less risky than exposing RFM to calls over WebSocket from the internet. Therefore, you should keep the numbers of RFMs exposed to calls via WebSocket RFC as small as possible, and this is why UCON for WebSocket RFC has a dedicated allowlist of its own that you should maintain carefully: It would be very insecure, if you exposed all RFMs you need to access in your CPIC-based RFC scenarios also for external calls over WebSocket – as it would be the case if you had a shared allowlist for RFC over CPIC and WebSocket RFC. For security reasons, you should have an allowlist of its own for WebSocket-RFC-scenarios, if your ABAP onPremise system is exposed to the internet

It is, however, possible to select an option in UCON for WebSocket RFC that automatically exposes the same RFMs via WebSocket RFC and via RFC over CPIC. This option is mainly meant for those customers who can or want to invest as little time as possible in the UCON protection of their server-side WebSocket RFC communication and, still, want to profit from UCON protection of WebSocket RFC. But of course, having distinct allowlists for WebSocket RFC and CPIC RFC respectively, is more secure.

Important Note: No matter whether you chose to have the same or different allowlists for RFMs to be called over WebSocket and over CPIC, - as already stated above - you should only enable WebSocket RFC for a particular destination based on an intentional decision and after extensive testing:
Before you have to make sure that no SAP-/WEBGUIs and no callbacks are used in the RFMs called via the respective destination: Since these features are not supported in WebSocket RFC, calling RFMs that open SAP-/WEBGUI-based UIs or use callbacks over WebSocket will cause a dump, which should be prevented by testing.

Administration of UCON for WebSocket requires little effort because - in contrast to UCON RFC basis for CPIC-based RFC - there is no dedicated logging and there are no phases in UCON for WebSocket RFC. You simply do not need this: Due to the extensive testing that is required for WebSocket RFC scenarios, you know exactly which RFMs to expose. Still, if you chose to have the same allowlist for both RFC flavors, accordingly, the UCON phase tool of the UCON RFC basic scenario shows all RFC calls in the same way no matter if they are WebSocket- or CPIC-based.

Summary

Gone are the days, when you had to choose between RFC and a connectivity technology with a standardized web-enabled transport layer. With WebSocket RFC you have it all: The advantages of a standardized transport layer and the well-known advantages of RFC. Calling RFMs via WebSocket RFC you can use standard internet infrastructure and no longer need VPN tunnels for calls across the borders of your business network. Still you get RFC’s high performance, a continuously open connection and RFC’s close integration into the ABAP programming model plus all the improvements that come with RFC’s fast serialization - such as its equally high transmission speed for all data and parameter types as well as for all permitted parameter extensions and fast serialization’s S/4HANA mode that mitigates problems in the RFC transmission caused by incompatible changes of DDIC types with every S/4HANA release.

The RFC statement you need for calls via Web Socket RFC is the same as it ever was. But at any rate, you should take into account that WebSocket RFC does not support SAP-/WEBGUI-based UIs or RFC callbacks.

WebSocket RFC is secure by default because of mandatory TLS-encryption and mandatory and active-by-default UCON protection on-premise and in the cloud. The test effort needed to setup the respective allowlist with all relevant RFMs varies depending on whether the RFMs to be exposed are known or not: No additional effort to fill the UCON list is required in the cloud and for new on-premise scenarios. Using WebSocket RFC for existing on-premise scenarios may need extensive testing to find out the respective RFMs you need to expose.

All in all, with WebSocket RFC you get a lot of advantages with comparatively little effort.