Introduction to ABAP Channels

Overview

ABAP Channels infrastructure was delivered with SAP NetWeaver AS ABAP 7.40 support package 2 (SP2) for simple tests and prototyping and released with 7.40 support package 5 (SP5).

The basic idea of the ABAP Channels (see Figure 1) is the native support of interactive and collaborative scenarios based on event-driven architecture. The scope of ABAP Channels consists of the following communication channels:

• ABAP Push Channel for bi-directional communication with user agents via WebSockets in ABAP. In the Figure 1 the documents tagged with letter "P" mark the ABAP Push Channel communication paths.
• Publish/subscribe infrastructure for exchange of messages between either user sessions (Session C => Session A) or user session and user agents

(Session C => User Agent B) residing on different application servers via ABAP Messaging Channels. In the Figure 1 the documents tagged with letter
"M" mark the ABAP Messaging Channels communication paths

Figure1: ABAP Channels support real-time eventing in ABAP

The ABAP Channels support the following use cases:

• ABAP Push Channel (APC) The WebSocket integration in ABAP.
• ABAP Messaging Channel (AMC): Eventing framework for message exchange between different ABAP sessions based on publish/subscribe channels.
• Collaboration scenario: Using APC and AMC to push messages from ABAP sessions to WebSocket clients by binding publish/subscribe channels to a WebSocket connection.

Figure 2: ABAP Channels use cases in ABAP

General recommendations for usage of ABAP Channels

SAP recommendations for a common programming model for use of ABAP channels are:

1. Use one WebSocket connection for collaboration scenario
2. Use SAP Push Channel Protocol (PCP) messaging protocol                                           

Use one WebSocket connection for collaboration

For collaboration scenarios which take use of WebSocket (ABAP Push Channel), it is recommended to share - whenever possible - a single WebSocket connection per client (e.g. browsertab/UI application) for consumption of different types of frequently updated content (feed): e.g. changes applied to a business object, or notification regarding incoming external information (news, weather, sport, chat, activation/deactivation of logs, traces, debugging, etc.).

This is because:

• This will avoid the unnecessary creation of parallel WebSocket connections for each feed, which is a limited resource at the both communication sides i.e. at the client and the server.
• Any additional WebSocket connection leads to performance degradation due to WebSocket protocol specific network traffic (e.g. due to keeping alive ping-pongs packages). Furthermore the lifecycle handling of the WebSockets leads to additional complexity at both communication sides.
• Moreover the situation will worsen when in the UI dependencies between different feeds exist, e.g. because a UI area contains an aggregation of information provided by different feed providers.

Figure 3 shows roughly how the messages are exchanged between an UI application running in a browser and using WebSocket connection (ABAP Push Channel) to ABAP sessions. The ABAP Messaging Channels (AMC 1… 4) are bound to the ABAP Push Chanel (APC). Either the UI Client can act as feed producer sending notifications about business object changes on UI to the subscribed WebSocket clients (Sessions 1…4) or vice versa: ABAP Sessions can publish messages about business object changes to their respective AMCs and they will be pushed by APC to the subscribed WebSocket clients (UI areas of business objects BO 1…4)

Figure 3: One WebSocket Connection (APC) for collaboration scenario

Use common messaging protocol Push Channel Protocol (PCP)

Starting with AS ABAP 7.40, SP05 it is recommended to send and receive messages in ABAP Channels in format of SAP's own Push Channel Protocol (PCP).

The Push Channel Protocol (PCP) is a message based protocol with message format similar to a HTTP message format.

The proposal of having a common messaging protocol is also valid for most of well-known service oriented infrastructures, e.g. SOA, REST or OData based services. This enables an application developer to publish and consume the services in the same way. Furthermore with this strategy an extension of the provided services is possible, as additional optional fields/metadata can be added to the existing message without breaking the downport compatibility rules.

In context of ABAP Channels the consumption of different feeds by a single WebSocket connection requires a common higher protocol and message type on top of WebSocket for those feeds which are pushed from server. This is necessary because in the WebSocket message handling at the UI client side should be a unique and reliable way to identify the different message types and to assign the appropriate consumer UI area. In worst case if the feeds do not

share the same protocol and each feed provider sends different message type, e.g. feed <f1> sends its messages as a kind of custom XML document, feed <f2> as JSON and feed <f3> as binary, it would be hardly possible to process the messages in a simple and reliable way in the WebSocket message handling.