Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Most ABAP applications use polling techniques to achieve an event-driven communication.For pushing an event from an ABAP backend to a browser based user agent like SAPUI5, Web Dynpro, Business Server Pages (BSP) or WebGUI, a polling in multi-seconds interval is frequently used. This is a quite system resource consuming technique. In SAPGUI usually the timer control is used to detect an event in the ABAP backend system. ABAP Channels technology targets to replace such inefficient eventing based on polling techniques through push notifications based on publish-subscribe infrastructure and WebSockets in ABAP.
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 Messaging Channel(AMC😞 Eventing framework for message exchange between different ABAP sessions based on publish/subscribe channels.
Collaboration scenario: UsingAPCand AMCto 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:
Use one WebSocket connection for collaboration scenario
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.
More about how to exchange messages in ABAP Channels with PCP will be published soon on SCN.
Using ABAP Channels
More detailed information about how to use ABAP Channels in the following series of blogs bymasoud.aghadavoodijolfaei