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.
Showing results for 
Search instead for 
Did you mean: 
Active Participant

After hearing all about websocket technology at Tech-ed last year, I’ve been extremely eager to try it out. I found there were a few great blogs already written about ABAP Push Channels and how to create your own. I recommend reading the following useful blogs and documents to get a good understanding of ABAP Push Channels:

and the following series of blogs by masoud.aghadavoodijolfaei

So in this blog I'm not going to go into detail about what ABAP Push Channels are all about, I'd recommend reading the blogs and documents above for that.
I’m rather going to demonstrate a real-life possible use case for ABAP Push Channels (websockets).  As entertaining as it is seeing it being used for ping pong games, thats unlikely to be very useful in an enterprise environment.

After writing this, I realised that it would be way too large to post as 1 blog. So I have divided it into several parts and each part will be posted in the appropriate space on SCN. See links below:

Please Note that this was all done on an ABAP 740 SP06 backend. Much of this is really new and may not be available or the same in prior versions.

The idea is to build a small UI5 or Web Dynpro ABAP Application to display the users Workflow Inbox. This application can either be run standalone or could even be used as a Side Panel Application in the NWBC client, which would possibly be the most appropriate use since it will always be open and be in the users sight while they are busy with other transactions.

Although I am using workflow as the use case to demo this, truthfully, this can be applied to any application in a very similar manner. These notifications are not only being used to display a message in the application, but also to inform the application that there has been a change and a refresh is necessary, therefore the application can reload the data. A push to pull type scenario. This prevents the need for periodic refreshes or for the user to constantly be pressing the refresh button to see if there have been changes.

Step 1 – Create the ABAP Push Channel

Got transaction SAPC (ABAP Push Channels). Right click on “ABAP Push Channels” and click Create.

Enter the name, in this case ZAPC_WF_NOTIFY. Then save to transport or as local object.

Enter a description then press the Generate Class and Service button.

Once generation is complete you will see the following message:

Navigate into the new generated class ZCL_APC_WS_EXT_ZAPC_WF_NOTIFY. Select IF_APC_WS_EXTENSION~ON_START and press the Redefine button . Then do the same for IF_APC_WS_EXTENSION~ON_MESSAGE.

For now leave the implementations of these methods blank, as we will return to enter the code in here after creating the AMC (ABAP Messaging Channel). Activate the class. Then Save and Activate the ABAP Push Channel.

Step 2 – Create the ABAP Messaging Channel

Goto transaction SAMC and right click on “ABAP Messaging Channels” and press Create.

Enter the name ZAMC_WF_NOTIFY. Then save to transport or as local object.

Enter a Description. Put /workflow_notify in Channels and set Message Type ID to TEXT and Activity Scope to System (User will not allow messages to be sent from one user to another). In order to make the messages user specific, we use the channel extension in bind_message_amc_consumer method call and the create_message_producer calls.

Then add the following entry to list of Authorised Programs:

Authorised Program: ZCL_APC_WS_EXT_ZAPC_WF_NOTIFY (class was created in the previous  step)
Prog. Type: CLAS
Activity: Receive via APC WebSocket

In subsequent steps we will add in an additional entry in Authorised programs to allow the program broadcasting the message to use the ABAP Messaging Channel.

Save and Activate the AMC (ABAP Messaging Channel)

Step 3 - Implement the code for the Messaging Channel in the APC

Go back to the APC class we created in step 1 and now implement the following code in the IF_APC_WS_EXTENSION~ON_START method. We are going to leave the IF_APC_WS_EXTENSION~ON_MESSAGE method blank as in this use case the client won't be sending any messages back to the ABAP backend. However, if it were to do so, we would need to add code into this method to handle it.

METHOD if_apc_ws_extension~on_start .
DATA: lv_channel_ext TYPE amc_channel_extension_id.

* Set the Channel extension to the user who is connecting,

* this is to ensure the user in a specific client only receives their own messages   

      lv_channel_ext = sy-mandt && sy-uname.

* Bind the APC (Websocket) we created in step 1 to the AMC ABAP Messagin Channel we created in step 2   

      DATA(lo_binding)= i_context->get_binding_manager( ).
      lo_binding->bind_amc_message_consumer( i_application_id  = 'ZAMC_WF_NOTIFY'

                                             i_channel_id      = '/workflow_notify'

                                             i_channel_extension_id = lv_channel_ext ).

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


In the next part we will create the work item exits which will broadcast the message via the ABAP Messaging Channel.

See Real-time notifications and workflow using ABAP Push Channels (websockets) Part 2: Broadcasting the ...

Labels in this area