WebSocket RFC – RFC For the Internet
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:
(2) Outbound WebSocket RFC scenarios offer two options. You can
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
|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.
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.
cool, is there a description of the new protocol, or is it proprietary?
In fact, it is not really a new protocol, but an RFC with fast serialization (also available for RFC via CPIC) only and WebSocket as the transport layer.
The WebSocket layer is standard compliant to the degree that you can use HTTP infrastructure - but with the limitations on multiplexing and load balancing as sketched in the respective section of the weblog above. Authentication, serialization layer with fast serialization (also usable in RFC over CPIC) and API layer (the way you create RFC calls in your program - is proprietary. Since these layers are mainly RFC-compliant, in general, you can use WebSocket RFC for existing RFC scenarios without code changes in the program that make the respective RFC call(s)- unless the remote-enabled Function Modules (RFMs) open a SAP/WEBGUI or make a callback. And - of course - in on-premise systems you should make sure that you allowlist the relevant RFMs in UCON for WebSocket RFC because UCON is active by default for WebSocket RFC.
Since you ask for a description, the most comprehensive systematic description of WebSocket RFC features is available in this weblog. In case you miss some information, it will be best to ask concrete questions in a further comment and I will try to answer your questions in a reply.
Hi Thomas, lots to like indeed, especially better security with less network change, however I'm curious to know when RFC W will be given the same use cases as RFC 3, which RFC H is not?
For example in ATC the RFC Object Providers that need to be setup for Central checks / Remote checks only work with RFC 3 so that SAP Router is required in the Customer DMZ to enable remote quality services. For Customers that are comfortable with Web Dispatcher and the AV / InfoSec tools of their choice, allowing SAP Router to enable 'native' access to SAP Backends is frightening, apparently. So they have a strong preference for Web Dispatcher and trusted InfoSec tools over SAP Router, despite being shown the SAP Router controls on traffic.
Despite that quirky use case, I'd be grateful for your view on RFC W == RFC 3?
Concerning the port: I guess in SM59 you have to enter the port which is defined by this profile parameter icm/server_port_* in the target system which defines the settings for PROT=HTTPS. (This is not necessarily port 443.)
Thank you Thomas Weiss for this comprehensive blogpost!
I appreciate the decision to enable UCON for WebSocket RFC by default.
Another very nice feature, which is outlined in your blogpost but maybe did not got the attention it deserved, is the support of X.509 certificate based authentication, which is not supported in RFC via CPIC.
This is not just a security benefit as it is considered a stronger authenticaction method than username + password. This also renders perfectly timed credential renewals on both sides of the interface a thing of the past. From my feeling this was the top reason why so many interfaces refrained from regular password changes, while the natural fluctuation in companies should make them indispensable. Organizational measures like ‘do not store interface passwords, rather reset them if necessary’ were hardly ever in place on both sides and do not sound effective to prevent insider driven attacks either.
One thing I wondered about is the missing support for RFC callbacks. While from a security perspective this is very welcome it seems to contradict the principle of WebSockets. One main difference between WebSocket and HTTP streaming is WebSockets allow bi-directional communication. Or did I miss understood that?
On my testing callback was working just fine for me
Hi Marco Hammel, in the todays talk of Markus Tolksdorf at DSAG Technologie Tage 2022 it was outlined once again that DESTINATION BACK is no longer functional by design.
Hi Thomas Weiss ,
Thanks for the blog. I find the approach of using WebSocket as a transport layer for RFC communication quite interesting. It can ease up the pain of many customers where the need to develop, run, and maintain a PO, or using CPI (which does not support CPIC) as a messaging middleware when there is actually no need for any message transformation.
What I'm more concerned of and would like to ask for your advise is the support of RFC via WebSocket for the SAP cloud offerings as a WebSocket server like like S/4HANA public/private cloud. Due to the nature of WebSocket proxies need to behave accordingly like:
- doing the HTTP to WebSocket connection upgrade
- modifying HTTP header information on the routing for example not falsely adding the HTTP CONNECT to the first WebSocket client frame
Even though WebSocket is a firewall and routing friendly protocol, the devil is in the details and SAP would need to guarantee that their cloud infrastructure supports this approach. Do you have any further information regarding the support for such setup in the relevant SAP cloud products?
What I don't get is the callback restriction you mentioned. I think the restriction only applies when DIAG should be tunnelled via WebSocket. Otherwise in my local testing setup callbacks do just work fine. Am I wrong with something here?
you are correct, the involved proxies, like the SAP Webdispatcher need to be configured so that WebSocket connections to the ABAP server are allowed to the new /sap/bc/rfc endpoint.
WebSocket RFC can be used without restrictions in all ABAP based public cloud products (e.g. S/4HANA Public Cloud, IBP and BTP ABAP environment). It is also possible to configure S/4HANA Private Cloud so that WebSocket RFC can be used.
Regarding the "callback restriction": this only refers to the destination "BACK" feature. See e.g. RFC Callback Whitelist | SAP Blogs for details of this legacy feature.
Hi Thomas, First of all thanks a lot for such a wonderful and descriptive blog.
Just wanted to clarify the usage scenario for websocket RFC:
Instance that Customer has : Transactional ECC (ECC 6.0 Ehp7) running on-prem and SAP IBP running in SAP's cloud env. So now to make use of this websocket RFC based communication between these two systems (i.e. Customer's On-Prem ECC & SAP's Cloud), the customer's on-Prem ECC has to be exposed to internet ? But if customer's policy says that they dont expose the on-Prem ECCs on internet then we have to make use of SAP Cloud connector and then can use websocket RFC. Is this a right understanding ?
your understanding is not completely right, as you need to take one more point into consideration:
ECC 6.0 is pretty old, and the underlying SAP Kernel & ABAP Platform do not yet support WebSocket RFC.
Exposing the ECC to the internet is not necessary and in fact would not even help, as the ECC system cannot receive WebSocket RFC calls anyway...
SAP BC will receive the "classic" RFC call from ECC, convert it to WebSocket RFC and send it on to the Cloud (IBP) via your standard HTTP Proxy/Firewall.
SAP BC is quite lightweight and can for example be installed on the ECC hardware, or on a small Linux/Windows/AIX server in the same LAN.
Best Regards, Ulrich
Hi Thomas Weiss, my company is using SAP DI to extract data from S/4 and I want the SAP DI requests to only use some of the available Application Server instances in production.
With classic RFC I would create a logon group, assign the relevant instances and connect via message server. How can I achive the same with the websockets setup? *There is a Web Dispatcher between DI and S/4.