This document tries to answer the most important questions about the ABAP Push Channels (APC) and ABAP Messaging Channels (AMC). ABAP Channels support real-time events and interactive collaborative event-driven scenarios in ABAP by means of integration of WebSocket in ABAP (ABAP Push Channel) and publish/subscribe infrastructure for message exchange across boundaries of ABAP application server (ABAP Messaging Channel).
For more information about ABAP Channels please take a look at the Introduction to ABAP Channels. If you have common questions, which should be answered in this collection, you can propose them here, in case you are interested to discuss more specific topics please take part at the forum/discussions.
Frequently Asked Questions
Which release is the minimum requirement for ABAP Channels? Which features are available in which release?
- NetWeaver AS ABAP 7.40 SP5/SP8:
The first version of the ABAP Channels infrastructure has been released with AS ABAP 7.40 SP5. This includes AMC and APC WebSocket. We highly recommend to use at least release 7.40 SP8, as this is the prerequisite for the recommended Push Channel Protocol (PCP).
- NetWeaver AS ABAP 7.50:
Support for APC TCP Socket. Also, the application server can open APC client connections and supports a stateful ABAP session handling model for APC connections.
- NetWeaver AS ABAP 7.51:
Support for large messages (see questions regarding message size limits). Additional functionalities for the WebSocket PCP subprotocol, e.g., connection health checks and multiplexing.
Can I use ABAP Channels to update SAP GUI frontends directly?
No, the ABAP Channel technology works only with Web frontends.
We did experiment with a prototype for a “SAP GUI Push Channel”, but it never left the experimental state and is not suitable for productive use. We do not plan any further development on this prototype because of technical issues. For this reasons, the prototype is deactivated and may be removed completely in the future. It is already removed for SNC-enabled SAP GUI connections as of kernel version 7.49.
Note that a SAP GUI session can receive AMC messages, but updates have to be pulled by a user interaction from the server. In order to push events directly to the frontend, the recommendation is to use SAP’s HTML5-based UI technologies like SAPUI5/Fiori.
ABAP Push Channel (APC)
My APC WebSocket connection to the ABAP application server does not work. Are there known pitfalls? What are the first steps for troubleshooting?
First of all you should ensure that you connect to the ABAP server via an SSL/TLS-encrypted connection. For a web applications that opens WebSocket connection this is usually the case when you call the web application via HTTPS. Besides security aspects, the reason to use SSL/TLS is that the encryption hides the WebSocket protocol to intermediaries, which possibly do not handle the WebSocket protocol correctly. Also check the question “What about security aspects?” below.
Then, you can test connecting via WebSockets to a particular ABAP server. Details and further steps of error analysis are described in SAP note 2353453.
Often, APC WebSocket connections work when connected directly to the application server ABAP, but WebSocket connections via a reverse proxy or load balancer fail. In this case, please refer to SAP note 2261212.
Web infrastructure components known for WebSocket issues include:
- If Apache is used as a reverse proxy, it must be configured according to SAP note 2261212 to enable WebSocket communication with the ABAP server.
- Citrix NetScaler has WebSocket Support disabled by default. How to enable WebSocket Support is described in the Citrix NetScaler documentation, e.g., for NetScaler 10.1: https://docs.citrix.com/en-us/netscaler/10-1/ns-system-wrapper-10-con/ns-http-con.html.
What about security aspects?
Each APC application has a path entry in the transaction SICF. With a new installation this entry is inactive per default. For an active usage of an APC application the associated APC path in SICF transaction has to be activated before. The path to an APC application is /sap/bc/apc/<name space>/<application name>. For each APC application you can maintain a dedicated virus/content scan ID for outgoing and incoming messages.
Furthermore, we recommend to use the existing escape methods in ABAP, e.g. the ESCAPE statement, to escape the WebSocket content that is exchanged between client and server. Finally, we highly recommend to use the secure variant of WebSocket, i.e. wss instead of ws.
For cross-origin-access to an APC application the APC framework also supports some aspects of the “The Web Origin Concept”, i.e. RFC 6454. In order to allow access to an APC application from an external server the white list maintenance via transaction SAPC_CROSS_ORIGIN has to be done accordingly.
How many connections are supported per ABAP application server and system?
In the lab we reached approximately 20000 WebSocket connections on a Linux application server. For an entire system consisting of multiple application servers, the limit of the Web Dispatcher as load balancer comes into play. The Web Dispatcher supports approximately 32000 connections depending on the underlying operating system. These limits are described in detail in SAP note 2007212.
The default configuration of an application server allows approximately 500 WebSocket connections. To allow more WebSocket connections and/or scenarios with high load (i.e., a high number of incoming WebSocket messages), the profiles of the application servers and Web Dispatcher have to be adjusted accordingly; see the following SAP Notes:
- 2007212: “Tuning SAP Web Dispatcher and ICM for high load”
- 2349642: “Configuration for high load on inbound WebSocket connections for ABAP Push Channel applications”
Also note that the memory footprint of a WebSocket connection without an attached ABAP session is very low compared to an ABAP handling incoming messages. If the applications executed in the ABAP sessions have high resource requirements (e.g., memory, CPU, connections, etc.), the maximum number of feasible WebSocket connections per application server may be much lower than the limits mentioned above. In this case, the profile parameters have to be adjusted according to the above mentioned notes and (if this is not sufficient) the load may be distributed to multiple application servers. Our load tests using LoadRunner show that the number of WebSocket connections and incoming messages scales well with server and system sizing.
How can I protect APC WebSocket and TCP Socket connections against (D)DoS attacks?
The ABAP application server provides an out-of-box protection against over-flooding of messages. Besides the limitation of APC connections to each ABAP application server (see question “How many connections are supported per ABAP application server and system?”), the ABAP application server suspends data reception from the network connection as long as the work processes are unable to handle the incoming messages (see the documentation of the profile parameter “rdisp/websocket/receive_threshold” for details).
Additional mechanisms to mitigate DoS attacks are available in SAP NetWeaver AS ABAP 7.52 / SAP Web Dispatcher 7.53 and later releases. These are described in the related documentation for Mitigating Denial of Service (DoS) Attacks and Limiting Application Server ABAP Resources per User.
Is there a size limit for APC messages?
The maximum message size depends on the NetWeaver release of the ABAP server.
- NetWeaver 7.50 and earlier:
- incoming and outgoing messages are limited to 64 KB.
- messages sent via system-wide access (i.e., using the connection attach handle) or AMC are limited to 31 KB.
- NetWaver 7.51 and later:
- incoming messages are limited to 100 MB (this limit is configurable via profile parameter); there is no size limit for outgoing messages.
- messages sent via system-wide access (i.e., using the connection attach handle) or AMC are limited to 1 MB.
All size limits refer to the binary message size, i.e., for text messages, this is the size after conversion to UTF-8.
What is the meaning of the WebSocket status/error codes?
WebSocket status codes are defined in the WebSocket protocol specification; refer to The WebSocket Protocol (RFC6455).
Error codes with special meaning:
- Error code 1005 means a close message is received without status code. Status code 1005 is never sent over the network from one peer to another.
- Error code 1006 is always a locally detected error. All locally detected errors have error code 1006. Status code 1006 is never sent over the network from one peer to another.
Why is sometimes the ON_ERROR handler called when closing the web browser?
Unfortunately, this depends on the web browser. We observed that Firefox simply closes the network connection when closing the browser. This leads to the call of ON_ERROR with following reason:
ICMENICLOSE:WebSocket connection closed by client
Chrome and Internet Explorer do not simply close the network connection, but instead send a WebSocket close message.Therefore, the ON_ERROR handler is not called; only the ON_CLOSE handler is called.
How can I load balance WebSocket connections?
It is possible to use Web Dispatcher for load balancing WebSocket connections. No additional configuration is required.
It is also possible to use 3rd party load balancers if they support WebSockets. But there are load balances that require additional configuration to support WebSockets (SAP Note 2261212).
How can I load balance TCP connections?
Load balancing TCP connections is available in SAP Web Dispatcher version 7.53 and higher. Refer to the TCP Socket Load Balancing documentation.
Since SAP Web Dispatcher is downward compatible, it is recommended to use SAP Web Dispatcher version 7.53 or higher for TCP load balancing, even if the version of the backend system is lower. For the currently recommended version of SAP Web Dispatcher refer to SAP note 908097.
It is also possible to use 3rd party load balancers if they support TCP load balancing.
How does connection health checking work for WebSockets?
For WebSocket connections, ICM sends ping messages and expects pong messages within a given time. The time can be configured with parameter icm/WS/ping_interval. Default is 60 seconds. Refer to the RZ11 parameter documentation for details.
How does connection health checking work for TCP?
Modern web protocols using persistent connections offer connection health checking on the protocol layer. This is true e.g. for WebSocket protocol and HTTP/2. Connection health checking is typically done by sending ping messages and expecting pong messages in reply within a defined time.
The TCP support in AS ABAP does not enforce connection health checking on the protocol level. However, it is possible and recommended for ABAP applications using TCP support to perform connection health checking, if this is offered by the protocol.
In case the protocol does not provide a mechanism to perform connection health checking, it is possible to configure health checking using the TCP “keep alive” mechanism by setting profile parameter icm/TCP/enable_keep_alive=TRUE. When the parameter is set to TRUE, the socket option SO_KEEPALIVE will be set. Details of the TCP keep-alive configuration are operating system specific and need to be configured directly in the operating system.
What happens if the TCP data does not match the TCP framing?
The used protocol is defined in the ABAP TCP APIs in a parameter of type APC_TCP_FRAME. The purpose of the framing is to detect the message boundaries. The framing is validated both for incoming and outgoing messages.
When reading data from the network it can happen that data is received which is not a complete message as defined by the framing. In this case an error message
“Connection to partner timed out after …s. Reason: incoming data package not finished”
is received and written to the TCP log (if TCP logging is configured).
Is there logging of TCP data?
It is possible to configure TCP logging using profile parameter icm/TCP/logging. By default it is not configured. Refer to the documentation for details. Displaying the log entries can be done using function module READ_TCP_LOG. For availability refer to SAP note 2258103. Starting with SAP NetWeaver release 7.51, report RS_READ_TCP_LOG can be used to display log entries also.
How can I secure TCP communication between different network location?
Secure TCP Socket connection (TCPS) supports an end to end SSL/TLS connection between ABAP and end devices.
If your end devices do not support SSL/TLS, you can use SAP Web Dispatcher as SSL/TLS endpoint in the in the local network of the end devices. This allows you to communicate with SSL/TLS between ABAP system and SAP Web Dispatcher, termination of the SSL/TLS connection there, and communicate with clear text TCP between SAP Web Dispatcher and the end devices.
As an alternative, TCP connections can be configured to use a chain of SAProuters by entering a SAProuter string as destination hostname. If you use two SAProuters, you can encrypt the traffic between them using SNC.
ABAP Messaging Channel (AMC)
Do I have to use WAIT FOR MESSAGING CHANNELS… statement in my application to “pull” for events?
No. In order to push or process events, an ABAP session, which acts as subscriber/consumer of a channel, must be in an interrupted state and not busy. There are ABAP statements, which provide an implicit interruption (e.g. Dynpro and List processing (PBO-PAI phases) or COMMIT WORK, etc.) and ABAP statements, which provide an explicit interruption (e.g. WAIT UP TO statement). It depends on the logic of the application to decide, which kind of interruption and which ABAP statement should be used.
When should I use WAIT FOR MESSAGING CHANNELS UNTIL <logical expression> UP TO <seconds> statement?
You can use this statement, if you want to detect and process the queued AMC messages for the session. You can then use WAIT FOR MESSAGING CHANNELS UNTIL <logical expression> UP TO 0 SECONDS.
Note that the statement can handle the optional timing in milliseconds, e.g., WAIT FOR MESSAGING CHANNELS UNTIL <logical expression> UP TO ‘0.5’ SECONDS.
Is there a size limit for AMC messages?
The maximum message size depends on the NetWeaver release of the ABAP server.
- NetWeaver 7.50 and earlier: AMC messages are limited to 31 KB.
- NetWaver 7.51 and later: AMC messages are limited to 1 MB.
The size limits refer to the binary message size, i.e., for text messages, this is the size after conversion to UTF-8.
Are ABAP Messaging Channels case-sensitive?
The channel is converted to lower case on registration/binding. Hence ABAP Messaging Channels are case-insensitive.