ABAP Push Channel (APC) is the ABAP framework for supporting WebSockets in the ABAP engine. This framework is part of the ABAP Channels infrastructure, which is 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.0) 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 figure 1.0 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 figure 1.0 the documents tagged with letter "M" mark the ABAP Messaging Channels communication paths.
Figure 1.0: ABAP Channels supports eventing in ABAP
Most ABAP applications use polling techniques to achieve an even-driven communication. For pushing an event from an ABAP backend to a browser based user-agent like Web Dynpro, Business Server Pages (BSP) or WebGUI, a polling in multi-seconds interval against the ICM cacheis frequentlyused.This is a quitesystem resource consuming technique. In SAPGUI usually the timer control is used to detect an event in the back-end. One of the the main goals of the ABAP Channel technology is to replace such inefficient eventing based on polling techniques.
The ABAP Channels supports the following use-cases:
- ABAP Push Channel(APC): The WebSocket integration in ABAP.
- ABAP Messaging Channel(AMC): Eventing framework for messages exchange between different ABAP sessions based on publish/subscribe channels.
- Collaboration scenario: UsingAPCandAMCto push messages from ABAP sessions to WebSocket clients by binding publish/subscribe channels to a WebSocket connection.
In this article we focus on the exchange of messages between WebSocket clients and ABAP sessions called Collaboration scenario using AMC and APC (see figure1.1).
Figure1.1: Message Flow in ABAP Channel Components
Collaboration of ABAP Messaging and Push Channels
The collaboration scenario (see figure 2.0) provides the possibility on the basis of publish/subscribe pattern of ABAP Messaging Channels to push messages from an ABAP session or from a WebSocket client (using ABAP Push Channel) to from publisher to subscribers of channels.
Figure 2.0: Simple interaction model of collaboration scenario.
One of the goals for the collaboration scenario is to overcome the manual refresh for an object list in the user-interfaces by introducing an “auto-update” or alternatively by using a notification pattern. This goalcan easily be reached by notifying the user-agent having a WebSocket connection to the ABAP system about the changes on objects displayed in the user-agent.
Figure 2.1 illustrates the technical interaction model for pushing messages between a WebSocket
In order to pass an event from an ABAP session to a WebSocket client and vice-versa the publish/subscribe infrastructure of the ABAP Messaging Channels is used. As in the figure 2.1 depicted the APC frame with the binding manager interface offers the possibility to bind an AMC channel to the underlying WebSocket connection to act as message consumer (receiver) for the corresponding channel. After a successful binding to an AMC channel, here <application>/<channel>, any messages published to the channel will
be forwarded by the AMC broker to the WebSocket client using corresponding WebSocket connection.
Creating an ABAP Push and Messaging Channel Application for Collaboration Scenario
This section outlines the additional steps required to extend the existing APC application (see ABAP Channels Part 1: WebSocket Communication Using ABAP Push Channels [1]) and AMC application (see ABAP Channels Part 2: Publish/Subscribe Messaging Using ABAP Messaging Channels[2]) to create the collaboration scenario.
First, the APC applicationwill be extended:
- In the existing APC application YCL_APC_WS_EXT_YAPC_WS_TESTthe coding of methodON_START (Figure 2.12 in [1]) will be replaced with coding to bind the
WebSocket connection to the AMC application YAMC_TESTand channel“/ping”.
METHOD if_apc_ws_extension~on_start.
TRY.
* bind the WebSocket connection to the AMC channel
DATA(lo_binding) = i_context->get_binding_manager( ).
lo_binding->bind_amc_message_consumer( i_application_id = 'YAMC_TEST'
i_channel_id = '/ping' ).
CATCH cx_apc_error INTO DATA(lx_apc_error).
DATA(lv_message) = lx_apc_error->get_text( ).
MESSAGE lx_apc_error->get_text( ) TYPE 'E'.
ENDTRY.
ENDMETHOD.
- Same for methodON_MESSAGE (figure 2.15 in [1]). Here the received messages from WebSocket client are forwarded to the AMC application YAMC_TESTand channel“/ping”.
METHOD if_apc_ws_extension~on_message.
DATA: lo_producer TYPE REF TO if_amc_message_producer_text.
TRY.
* retrieve the text message
DATA(lv_text) = i_message->get_text( ).
lo_producer ?= cl_amc_channel_manager=>create_message_producer(
i_application_id = 'YAMC_TEST'
i_channel_id = '/ping' ).
lo_producer->send( i_message = lv_text ).
CATCH cx_amc_error INTO DATA(lx_amc_error).
MESSAGE lx_amc_error->get_text( ) TYPE 'E'.
CATCH cx_apc_error INTO DATA(lx_apc_error).
MESSAGE lx_apc_error->get_text( ) TYPE 'E'.
ENDTRY.
ENDMETHOD.
- In the next step the access rights will be maintained. For the AMC application YAMC_TEST and channel “ping” the activities “Receive via APC WebSocket” and Send”are referencing the implementation class YCL_APC_WS_EXT_YAPC_WS_TEST of APC application YAPC_WS_TEST. This is done in the AMC design time, transaction SAMC (figure 3.20 in [2]).
Open the definition of application YAMC_TEST and click Insert line (see figure 3.1).
Figure 3.1
Open the value help in the Authorized Program field (see figure 3.2).
Figure 3.2
Insert the class YCL_APC_WS_EXT_YAPC_WS_TESTand click Accept (see figure 3.3).
Figure 3.3
Select the entry C Receive via APC WebSocket (see figure 3.4).
Figure 3.4
Insert additional line as above and select the entry S Send (see figure 3.5).
Figure 3.5
Optionally a Virus Scan ID (outgoing) can be specified (see figure 3.6).
Figure 3.6
Click Save (see figure 3.7).
Figure 3.7
And Activate. (see figure 3.8).
Figure 3.8
Click Continue .(see figure 3.9)..
Figure 3.9
To test the application just press the Test icon (see figure 3.10).
Figure 3.10
This action launches the Web Dynpro application WDR_TEST_APCin a browser (see figure 3.11) which supports the WebSocket protocol (RFC 6455) (e.g. Chrome version >= 16, Firefox version >= 11, Internet Explorer version >= 10 and Safari on iOS version >= 6). If it does not launch, double check the Web Dynpro service path /sap/bc/webdynpro/sap/wdr_test_apc" in the transaction SICFis active.
Figure 3.11
Just starts a second time the Web Dynpro test application for APC application YAMC_TEST in browser (see figure 3.12).After a successful connection setup any messages send in a browser will be received also by the second browser.
Figure 3.12
Furthermore any report which apply any actions on the AMC application YAMC_TESTand channel“/ping” will be involved in the collaboration interaction. In other words the execution of the AMC send report YRS_AMC_SEND_MESSAGE(refer [2] figure 3.15) will lead to receiving the send message by the browser(see figure 3.13)
Figure 3.13
And the execution of the AMC receive report YRS_AMC_RECEIVE_MESSAGE (refer blog [2]figure 3.25) will lead to receiving the send message by the browser(see figure 3.14).
Figure 3.14
Collaboration Scenario Security
The security of collaboration scenario is handled by the underlying APC and ac frameworks.
Collaboration Scenario Supportability
Whereas for AMC channels with the transaction SMAMC(refer blog [2] figure 4.0) canthe subscribed channels be monitored also here a navigation to the bound WebSocket connection in SMWS(see [1] ) transaction. The transaction SMWS provides also the total number of bound AMC channels per WebSocket connection (see figure 4.0).
Figure 4.0
The transaction SMAMC (see figure 4.1) shows the list of the AMC channels which are registered in sessions (Type “Session”) or in case of “Collaboration scenario” the WebSocket connections (Type is “WebSocket”) in the system as AMC consumers.
Figure 4.1
Conclusion and outlook
This article showed the collaboration scenario based on AMC and APC for exchange of messages between different WebSocket clients. Currently the message exchange based on best/effort strategy and no guaranteed delivery is available. In a future article best practices will be outlined.