Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

FAQ - ABAP Channels

OlgaDolinskaja
Product and Topic Expert
Product and Topic Expert
‎10-13-2016 2:08 PM
This document tries to answer the most important questions about the ABAP Push Channels (APC), ABAP Messaging Channels (AMC) and ABAP Daemons.

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

ABAP Daemons are used to handle events in a reliable way by running in sessions with unlimited lifetime. ABAP programs can communicate with ABAP Daemons by sending messages to them. You can find more information in ABAP Daemons – Always available ABAP sessions to handle events. You can also try create an ABAP Daemon application yourself by completing the Create a Simple Daemon tutorial.

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

ABAP Channels (general questions)

 

ABAP Push Channel

 

ABAP Messaging Channel

 

ABAP Daemons

________________________________________________________________________________

 

Frequently Asked Questions


ABAP Channels (general questions)


 

What are the typical ABAP Channels use cases?

  • Using WebSocket protocol to send push notifications to web UIs. This facilitates applications with a real-time user experience where the UI is updated as soon as the data in the backend changes. Examples are progress indicators and user notifications without polling.

  • Using WebSocket protocol and the publish/subscribe capabilities of ABAP Channels to facilitate the collaborative real-time editing of business objects and group chats.

  • Sending business events from an ABAP system to extensions in the Cloud or vice versa using the WebSocket or the MQTT protocol.

  • Connecting sensors and machines on the shop floor via WebSocket, MQTT, AMQP or plain TCP/IP connectivity.

  • In banking, payment software that only offers a TCP/IP interface can be connected directly to an ABAP system to realize payment solutions.


 

Where does SAP itself use ABAP Channels?

  • WebGUI (progress indicator, system messages, front-end printing, etc.)

  • SAP Floorplan Manager for Web Dynpro ABAP (read blog ABAP Push Channel for FPM Events)

  • SAP Extended Warehouse Management (SAP EWM)

  • SAP Enterprise Messaging, Enterprise Event Enablement framework

  • SAP CRM Interaction Center (SAP CRM IC)


 

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.

  • NetWeaver AS ABAP 7.52:
    First version of the ABAP Daemons.

  • ABAP Platform 1809 (SAP_BASIS 7.53😞
    Support for MQTT v3.1.1 (MQTT client only). Automatic start-up configuration for the ABAP Daemons.

  • ABAP Platform 1909 (SAP_BASIS 7.54😞
    "WebSocket RFC", i.e., SAP Remote Function Call (RFC) via WebSocket. (Although WebSocket RFC is not an ABAP Channels feature, it is listed here, as it enhances the WebSocket protocol support of the ABAP Platform.)

  • ABAP Platform 2020 (SAP_BASIS 7.55😞
    Support for AMQP 1.0.0 (AMQP client only).


 

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

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.

 

Which tools can I use to monitor ABAP Channels?

You can use transaction SMWS to monitor APC connections and transaction SMAMC for AMC registrations.

 

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.

In the case that the connection test using the Web Dynpro test application (as described in step 1 of note 2353453) fails, please ensure that the JavaScript libraries of the Web Dynpro "Unified Rendering" engine are up to date; see SAP notes 2243993 and 2154957.

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:

 

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, Edge 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 locations?

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.

 

Why do I see statistic records for APC sessions with a high "roll wait time" in transaction STAD or STATS?

For stateless APC applications, APC sessions may be pooled for some time after message processing. Moreover, statistic records are not always completed when an APC session finished its processing and is put into the session pool. In the case that the statistic record is not completed, the time that the session was in the APC session pool is part of the "roll wait time". Hence, when the APC session is used to process the next incoming APC message, a statistic record might be written, which contains this idle time as "roll wait time". This behavior is a performance optimization, which can be fine-tuned using the profile parameters "stat/collect_records_for" and "stat/collect_interval".

This described symptom can be avoided by removing the string "APC" from the value of the profile parameter "stat/collect_records_for". Then, a statistic record is always written when an APC session is pooled. This empty value for profile parameter "stat/collect_records_for" is also the default as of ABAP Platform 2020 (SAP_BASIS 7.55).

However, please note that collecting statistics of multiple APC requests before writing the statistic record is a performance optimization. Hence, in cases where the ABAP server is used for scenarios where incoming APC requests are processed frequently, the parameter setting "stat/collect_records_for = APC" could be used to avoid a performance bottleneck of the statistics.

 

ABAP Messaging Channel (AMC)


 

Can I restrict the number of messages for an AMC application during the runtime? Is there a filter mechanism?

Yes, you can. Note that an ABAP Messaging Channel is composed of three parts: application id, channels id, and an optional channel extension id. As the first two parts are development objects, it hinders you to specify them dynamically as a filter in your application. However, the channel extension id is a string specified at the runtime. Usually this suffices to filter messages according to your needs.

Since NetWeaver AS ABAP 7.52 we’ve also provided so-called “AMC Filters”. They are useful if you have combinations of criteria that you have to filter for. An example are the WebGUI system messages. System messages can be sent to user session of a certain application server, client, or language. Hence, each user session has to register to all combination of its attributes. This can be realized using AMC Filters with a single registration.

To learn more about "AMC Filters", see Attributes of ABAP Messaging Channels.

 

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.

  • NetWeaver 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 attributes of an ABAP Messaging Channel (application id, channel id, channel extension id) are converted to lower case on registration/binding. Hence, ABAP Messaging Channels are not case-sensitive.

 

Some AMC messages that are sent to an ABAP session or to the front end (browser) via WebSocket get lost. Why?

AMC must be considered as an unreliable, best effort communication channel. The reason lies in the publish/subscribe communication model of AMC. A sender of an AMC message usually does not know the number of receivers and therefore cannot notice whether the sent message reached all intended receivers. (An exception to this are the synchronous message transfer mechanisms, which has been introduced with NetWeaver 7.50; see below.)

More precisely, an AMC message might get lost because of the following reasons:

  • The intended receiver, i.e., the registered ABAP session or the bound WebSocket connection, has been unregistered/unbound.

  • The WebSocket connection bound to AMC has already been closed (or has never been established).

  • The queue of the registered ABAP session is overloaded (see profile parameter "rdisp/amc/task_limit") or the outbound queue of the bound WebSocket connection is overloaded.


NetWeaver 7.50 and later releases offer APIs to realize a reliable point-to-point communication:

  • The synchronous send option for AMC Point-To-Point Communication allows a reliable transfer AMC message transfer to a dedicated ABAP session of the same SAP system. (This is the method of choice for reliable, system-internal communication scenarios.)

  • The System-Wide Access to APC Connections allows a reliable communication from an arbitrary ABAP session in the SAP system to a WebSocket connection (using the connection attach handle). (This is the method of choice for a reliable communication with external devices.)


In both of these point-to-point scenarios, the sender gets an exception if the ABAP method call for sending the message fails.

 

Why do I see many "APC Streaming Sessions" in transaction SM04, although the corresponding APC connections are stateless?

An APC connection needs an APC streaming session for sending messages via the connection from a foreign ABAP session, either using AMC or using the "System-Wide Access for APC Connections"; see SAP Help Portal documentation. Therefore, the APC streaming session is created for an APC WebSocket connection when the WebSocket is bound to AMC or when the APC system-wide access is used for the first time. APC streaming sessions are technical sessions that do not run any ABAP code. Hence, they have a very low memory footage and usually do not need significant server resources except additional users sessions (which are restricted by profile parameter "rdisp/tm_max_no").

Transaction SM04 also supports you to find the associated APC connection. For this purpose, SM04 offers the additional column "WebSocket Handle", which shows the key of the connection entry in transaction SMWS. The WebSocket Handle in SM04 allows forward navigation to its SMWS entry. Transaction SMWS also shows the "ICM Connection Handle", which can be used in turn to identify this WebSocket or TCP Socket connection in transaction SMICM.

ABAP Daemons


 

Can I use ABAP Daemons as an alternative to batch jobs? Which should I use in which cases?

It depends. For heavy-weighted periodic tasks that run at most once a day, we recommend batch jobs. ABAP Daemons could be an alternative for light-weighted, very frequent periodic tasks, e.g., health checks that run every minute or so. The advantages of ABAP Daemons are: You do not need to create a new ABAP session for each execution; no batch work process is needed.

Note that behavior of ABAP Daemons differs from batch jobs, as they run in dialog work processes, e.g., the LUW / DB commit handling is different.


Are ABAP Daemons client-specific or are they available in the entire system?

Each ABAP daemon runs under a given user. Hence, they are client-specific. The API that enables message sending via an ABAP daemon is also restricted to the same client. However, you can implement a system-wide messaging to the ABAP daemon via ABAP Messaging Channel by using the AMC API.


Are ABAP daemons, which I have configured to start automatically, started per application server or per system?

Both is possible. During the configuration, you need to specify the topology type, which can be either server or server group, and the number of daemons to be started. Server means that the number of configured daemons will be started on each active application server of the system. Server group means that the number of configured daemons will be started and distributed over active servers that belong to an RFC group. Empty server group ("SPACE") means that the number of daemons will be started and distributed over all active application servers of the system. The logic of distribution within a server group is to equally spread the configured number of daemons over the number of active servers. For both topology types, application servers in passive state are ignored.


How is automatic ABAP daemon start-up configuration is realized?

Each application server is connected to the message server (as it’s always been). The message server notices, when an application server is down, starting or active.This triggers the execution of a method on each application server (so-called “server startup procedure”) that compares the daemon start-up configuration with the currently running daemons and starts/stops daemons. The communication to start/stop daemons on other application servers is realized via Remote Function Call (RFC).

 

Which tools can I use to monitor ABAP Daemons?

You can use transaction SMDAEMON to get the list of running daemons as well to monitor the start-up configuration.
7 Comments
Labels in this area
Popular Blog Posts