Say Goodbye to Polling: Real-time events in ABAP w...
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.
The new technologies like Cloud, Mobility, and In-Memory open new opportunities and lead the industries to the real-time business. Become real-time business means react immediately to the market changes, provide higher responsiveness, accelerate business processes, adjust responses in real-time based on changed business conditions, deliver fast and personalized service for customers, or exploit new business chances not possible before.
But what does real-time mean for the running business? From the business user point of view, one of the most important definitions is low latency, meaning how fast the application responds to a click or other user interaction (independent on a computer or a mobile device). Ideally users expect that the input data is processed within milliseconds and they receive immediate responses.
Real-time means also always having the latest up-to-date information about application data and state (e.g. the current stock market prices, airline seat availability, latest deadlines for delivery, accurate information on inventory – value, status, receipt, location and disposition), and react in real-time to incoming events. The events can be of various nature and span from the simple notification (e.g. the vacation request was approved in the system), broadcasting (e.g. new repurchase prices are available and must be distributed to the users), process control information (e.g. delivery of sales orders took place, the billing process for customers can start) to events, which require immediate reaction (e.g. illegal trade pattern is detected). Another aspect of real-time is best support for collaborative scenarios (e.g. business users work on the same data records, collaboration platforms, interaction centers).
All in all developing real-time applications in ABAP is about the fast, event-driven, highly interactive and collaborative scenarios, which must be supported in ABAP applications.
How is it implemented in ABAP? ABAP development for SAP HANA enables real-time processing for huge amounts of business data by exploiting the strengths of In-Memory technology. Using SAPUI5/SAP Fiori on top of AS ABAP offers real-time UI experience and simplified business interactions by means of intuitive highly-responsive consistent UIs across multiple devices. The ABAP channels complete this real-time offering by supporting interactive and collaborative scenarios based on event-driven paradigm independent of database (yes, not only on HANA!) and UI (yes, it works also 'as prototype' for Dynpros!). ABAP Channels infrastructure is general available with SAP NetWeaver AS ABAP 7.40 Support Package 5 (SP05).
Real-time UI access to ABAP data with ABAP Push Channel (APC)
As described above, one of the important real-time characteristics is immediate access of users to the frequently changing business information and data in ABAP backend, which will support timely business insights, decision making and productivity.
The examples for this can be for instance bringing the irregularly and often changing product information and sale conditions to browser UI (SAPUI5, Web Dynpro ABAP, BSP) as soon as data change takes place in the ABAP backend, pushing short-lived financial data relevant for trades to the browser UI, statistics, process information (sales figures in different areas, financial statistics, manufacturing process status). In all these cases the data presentation on UI (charts, diagrams, text and numbers) must be updated immediately accordingly to the modified data in the ABAP backend.
In such situations in order to present the latest up-to-date information from the ABAP backend in real-time on the browser based UI most ABAP applications used polling techniques with multi-seconds intervals or refresh button periodically to get newest updates to UI. These approaches are quite resource consuming result in insufficient performance and poor user experience. The availability of real-time data in ABAP backend is unpredictable and it is unnecessary effort to make requests and open and close HTTP connections.
The ABAP Push Channel (APC) technology replaces such inefficient polling approach through WebSockets. ABAP Push Channel is bi-directional message based communication channel representing the WebSocket integration in ABAP, allowing e.g.to push notification to the UI as soon as data change in ABAP backend happens. This is a sign for a user to request the changed data from ABAP backend and update UI.
More details about ABAP Push Channel and step-by-step guidance how to implement it in ABAP in Masoud’s Blog:
Real-timecommunication between ABAP sessions with ABAP Messaging Channel (AMC)
Other aspect of the real-time behavior is reacting immediately to the events. Event-driven communication between ABAP sessions across the boundaries of ABAP application servers will streamline the business process workflow, speed up performance and reduce the rate of consumption of database resources. An ABAP application might need to identify and react to certain events in the other ABAP session as soon as they occur. Moreover an ABAP application might involve data processing in order to provide some output to be delivered to another application, running in another ABAP session and therefore has to send notification. Traditionally to realize such real-time event-driven behavior ABAP applications often poll periodically for the state information on the database. Bottleneck problems on the database may occur with numerous active polling from many ABAP applications simultaneously.
One of the examples of such real life situations can be long running calculations (sales statistics, loan calculations). A user may initiate a loan calculation (via asynchronous RFC) and it is running so long, that he is not any more interested in the status of calculations and the results and may want to proceed with another actions. In such case the running session (initiated e.g. by RFC) only consumes resources and the calculation must be stopped. In current implementations the ABAP application polls for the status of the calculation on the database. Another example is long running batch jobs (mass data changes, create deliveries from open sales orders, create invoices) which process data gradually. To simulate the real-time behavior, the calling ABAP session polls in short time intervals on the database for the status in order to request already processed data or get updated information.
Another example is the business workflow e.g. the manufacturing process, which consists of several productions steps (e.g. manufacturing of components), which are initiated in parallel by the central process (e.g. assembling) on different application servers and must report back their status as soon as they get accomplished. The central process would need to poll on the database periodically in order to get the status of the productions steps. All these situations result either in heavily loaded database by batch jobs, bottlenecks, or by resource- and time-intensive applications reducing database performance.
Instead of using periodically polling technique, a publish/subscribe mechanism can be used for prompt notification which can eliminate unnecessary database load. The ABAP Messaging Channel (AMC) infrastructure replaces the polling through publish/subscribe mechanism and acts as a broker for the messages exchange between different ABAP sessions, which can reside on different ABAP application servers. After ABAP sessions act as publisher and receiver respectively, as soon as an ABAP session publishes notification to AMC, all subscriber ABAP sessions get notified.
More details about AMC and step-by-step guidance how to implement it in ABAP in Masoud’s Blog:
Real-time collaboration with ABAP Push Channel (APC) and ABAP Messaging Channel (AMC)
Another essential element of the real-time business are real-time collaboration scenarios, which allow multiple users in different locations in internet to communicate instantly or work on the same business objects simultaneously sharing the same backend resources and even allowing collaborative real-time editing. Applying this to ABAP would mean for example SAPUI5 users in different ABAP sessions which reside on different ABAP application servers can communicate (send messages) and work together on the same ABAP business data records.
One of the business scenarios would be broadcasting and distributing of the irregularly and frequently changing business data in ABAP backend to the browser UIs of multiple users across the boundaries of the ABAP application servers (see APC use examples above)
Another real-time scenario would be collecting the data from any kind of hardware device (e.g. traffic control tool, medical equipment, RFID scanner, vehicle tracking control, multimedia system, etc.) in the ABAP system and display them on the UI, or react to event (robot reached its destination in the warehouse,telephone call/chat arrived in the interaction center) in ABAP system with subsequent UI update with latest data without having to poll for the data changes.
In situations when multiple users work with the same data (e.g. customers or suppliers information) in the browser UI, and one user changes several data records, they must be updated immediately on all other user UIs.
If one goes a step further there are also scenarios of collaborative real-time editing of business object data in which multiple browser UI users have to edit jointly the data of the same ABAP object and modified data should be displayed on UI of other users in the real-time without having to lock the whole object.
For all these scenarios the collaboration of ABAP Push and Messaging Channels is the best choice. The publish/subscribe infrastructure of the ABAP Messaging Channels can be used with ABAP Push Channel to enable WebSocket UI clients to act as subscriber. This allows WebSocket UI clients either to receive notifications about data changes or to publish notifications requesting WebSocket UI clients to reload the data from source.
More details about using AMC/APC for collaboration and step-by-step guidance how to implement it in ABAP in Masoud’s Blog:
in the ABAP application server release 740 SP08 you will find one of my test reports RS_APC_SOHBAT_SLIDER which takes use of ABAP LIST processing and asynchronous RFC with the AMC to update the screen any time a message is received via AMC. The technology works as follow:
In the main report <report> an asynchronous RFC (aRFC) with response and keeping task for remote enabled function module <func> is initiated. In the function module <func> is also the subscription to an AMC channel implemented. The function module <func> returns to the main report <report> (via method rfc_callback) as soon as an AMC message is received. After handling of the response an update event is raised to the main report <report> and to the AT USER-COMMAND event handling block, respectively, which takes care of the screen updates. Following pseudo ABAP code will show the processing steps:
REPORT <report>.
CLASS lcl_myclass DEFINITION. PUBLIC SECTION. CLASS-METHODS: … rfc_callback IMPORTING p_task TYPE c. ENDCLASS.
CLASS lcl_myclass IMPLEMENTATION.
…
METHOD rfc_callback. RECEIVE RESULTS FROM FUNCTION <func> KEEPING TASK EXCEPTIONS communication_failure = 1 system_failure = 2.
… SET USER-COMMAND 'OKCD'. ENDMETHOD.
ENDCLASS.
…
START-OF-SELECTION.
…
CALL FUNCTION <func> DESTINATION 'NONE' STARTING NEW TASK 'ALARM' CALLING rfc_callback ON END OF TASK EXCEPTIONS communication_failure = 1 system_failure = 2.
…
* create screen
…
AT USER-COMMAND.
* update screen
Implementation of the remote function would be like:
FUNCTION <func>. …
* create message consumer
* start message delivery
* WAIT FOR MESSAGING CHANNELS UNTIL <log. expression> …
My understanding of "publish and subscibe" inside ABAP has always been something like SAP Business Workflow.
You create, say, a sales order, and this raises an event. Earlier a workflow had been defined which reacted to this event. In the car example above, when the engine was installed it would raise an event which started a workflow to update some sort of central table, and the same for wheels etc etc.
You would then have some sort of report which you would have to run and keep refreshing to see the current state of affairs. What you would really want was a report which you ran once and it sat on your screen and when something changed somehow the report got notified and refreshed itself, rather than having to constantly query a database table which may not have changed.
When I first heard about the ABAP messaging channels which sent messages between application servers I thought that SAP had magically solved this problem somehow, and was wondering what the mechanics of this were.
I was really puzzled that in all the examples the receiving program had code like WAIT FOR MESSAGING CHANNELS UNTIL (logical expression) UP TO 60 SECONDS.
Pausing for 60 seconds is like polling surely? you are doing one big 60 second poll to see if you get a message in that period, presumably holding open a work process for those 60 seconds, rather like CIC0 holds open a work process until a phone call comes in. And then if after 60 seconds if a message comes in your program has moved on and so cannot react to it.
How is that "subsrcibing" to the message? The configuration says what programs can recieve messages sent from certain other programs, that is a bit like publish and subscribe, but real subscription is when you don't have to "pull" in the messages as in WAIT FOR MESSAGING CHANNELS but rather the message is "pushed" to the consuming program.
I asked Thomas Jung about this at the SAP Technology conference last week, and he confirmed my suspicion that on the internet the ABAP Push channels can work in a true publish and subscribe fashion, due to the asynchronous nature of the technology, but inside ABAP you still had to do the WAIT UP UNTIL.
In my mind that means this technology is not a publish and subscribe type replacement for polling at all, at least within the ABAP stack.
If someone wants to tell me I am wrong, and wants to show me how to set up one program to listen for messages from another without having to "pull" such messages, then please feel free.
first of all thanks for sharing your thoughts with us. In ABAP engine I personally have heard the term “publish subscribe” in different contexts two of them is in Workflow and SOA (Service oriented Architecture). In those cases is the situation from ABAP session handling perspective a little bit different than in ABAP Messaging Channel. In the existing technologies the processing of the “events” are handled via initiation of (asynchronous) RFCs or HTTPs whereas in case of ABAP Messaging Channels the aim is to consume the “event” (message) in an active session. As you mentioned in order to exchange events between sessions often a pooling against a shared entity, e.g. database table, shared objects and the like are used, which is with AMC not necessary anymore. In order to push or to process an event in an active ABAP session which act as consumer/subscriber of a channel must the session be in an interrupted state and not be busy. There exist a number of ABAP statements which provide an implicit interruption, e.g. dynpro and List processing (PBO-PAI phases) or COMMIT WORK, etc. and some statement which provide an explicit interruption, i.e. WAIT statement. This is now depends on the logic of the application to decide which kind of interruption should be used for processing of the events. By the way the new established WAIT statement, i.e. WAIT FOR MESSAGING CHANNELS UNTIL <logical expression> UP TO <seconds>, can handle the optional timing in milliseconds. The timing part is only than necessary if you would like to detect and process the queued events for the session and here you could use WAIT FOR MESSAGING CHANNELS UNTIL <logical expression> UP To ‘0.0’ SECONDS., but you do not need the timing part and can just use the expression part to detect an incoming event to initiate the post processing of the event after WAIT statement. The only aspect of AMC is the exchange of events between active session that means you have to keep the consumer session up and running and the WAIT statement can help you to reach this goal. Furthermore the execution of a WAIT statement leads to an interruption, i.e. the ABAP session is rolled-out of the work process (this is valid for dialog work process type), and do not keep work process busy !
You can just verify the facts with my test reports for exchange of messages based on AMC. First execute the report RS_AMC_ RECEIVE _MESSAGE and choose “List processing” option for handling of incoming events. Additionally execute the report RS_AMC_SEND_MESSAGE in a second SAPGUI session. Now by double clicking the list output in the RS_AMC_RECEIVE_MESSAGE you will see the processed message.
If it would be at all possible for you to tell me how to put some code in a progarm to receive an AMC message without the WAIT FOR addition i.e. in a true "pull" fashion I would dance around the room with joy.
A method is fine, I can work around almost anything, but the concept of a running program getting notified about a message seems like black magic thus far.
I think it is my job - and indeed all of our jobs - to use such black magic as and when it becomes available to help our businesses / goverment departments. I just hope this is not magic but reality.
I now have a log in to the CAL demonstration system of a 740 ABAP system, and I ran the two programs you described staring with RS_AMC_ and everything worked as you said. The program that receied the message did not hold a work process open in SM66 in the way that CIC0 does.
The question still remains, inside an SAP GUI could a program that is in a dormant state - i.e. just showing an ALV screen to the user - refresh itself when receiving such a message?
The scenario is - a delivery has just been created by user X. Meanwhile user Y has a screen open showing a list of deliveries. When the delivery is created by user X can the screen being viewed by user Y automatically update itself with the new delivery whilst user Y is in the toilet so they can see it when they come back?
Do I need to use something like the timer class to check every so often for recived messages and if a message has been recieved since the last time it checked then update the screen or is there a better way?
we have also established as PROTOTYPE the SAPGUI Push Channel (SPC) as push capability to SAPGUI similar to ABAP Push Channel for the push capabilities to WebSocket (HTML5) enabled browsers. The SPC is available only for tests and NOT RELEASED for productive usage with the ABAP Application Server 740 SP8 under the usage of SAPGUI version 740. For installation and support strategy of SAPGUI refer to note "147519 - Maintenance strategy / deadlines for SAP GUI".
With SPC it is possible to update SAPGUI controls or the whole SAPGUI screen as well, e.g. after receiving notifications via SPC from different back-end sessions. Furthermore there is a user-specific switch which is off by default to avoid the productive usage by developers and customers. We provided also in the 740 SP8 a simple test report for SPC. If your test environment fulfills the above-mentioned requirements, i.e. using ABAP Application Server 740 SP8 and SAPGUI 740, then you can activate the switch by maintaining the user specific SET/GET parameter “SAPGUI_PUSH_CHANNEL = X” in the own user profile. For running a test report with SPC just carries out the following instructions:
Activation the SAPGUI Push Channel switch for tests: Choose in the menu bar of a SAPGUI mode the entry “System -> User Profile -> Own Data”. Than enter in the created SAPGUI alternative session the tab “Parameters” and enter the table column “Set/Get parameter ID” the value “SAPGUI_PUSH_CHANNEL” and under “Parameter value” the value “X”, i.e. “SAPGUI_PUSH_CHANNEL = X”.
Now run the test report RS_AMC_RECEIVE_MESSAGE (which acts as a SPC consumer) with the following parameter values:
Application ID: ECHO
Channel ID: /sapgui/ping
Checkbox SAPGUI as consumer: activate
Choose “List processing” option
Additionally execute the report RS_AMC_SEND_MESSAGE in a second SAPGUI session (to send a message to the SPC session) with the following parameters:
Application ID: ECHO
Channel ID: /sapgui/ping
Message content: whatever you want as text, e.g. Hi there !
After execution of the RS_AMC_SEND_MESSAGE report you will get a popup prompted on the first SAPGUI session executing the report RS_AMC_RECEIVE_MESSAGE without any interaction, i.e. without double clicking the list. This shows how the SAPGUI screen gets updated automatically with the content of the received data using SPC!
I wish you merry Christmas and Happy New Year 2015 !
If the user using the application is not online then will the notification sent automatically to the device once they turn online ? Or this notification is missed. Thanks
the ABAP Push Channel does not provide any "offline push" capability as this is available for mobile devices, e.g with Apple Push Notification Service. The ABAP Push Channel can be used to push information via an active WebSocket connection from ABAP engine to an active user agent, e.g. chrome browser. As soon as the user agent terminates its WebSocket connection the messages published in ABAP engine, e.g. based on ABAP Messaging Channels, cannot be delivered to that side and will be dropped.
Got it. Thanks for your insights to help me understand. SAP Gateway is providing us a similar functionality like this. Do you know whats the difference between these 2 (APC & Gateway push notifications) ?
you should contact the Gateway colleagues (insert your question in that blog). Gateway provide different notification infrastructures (refer to documentation). We have already successfully done a PoC using ABAP Channels as a further notification possibilities in Gateway. If you like to now when this possibility will be available you have to ask the Gateway team or add this question into the proper Gateway blogs.
yes. In a side-by-side deployment of SAP Gateway the events occuredi n a backend system have to be transffered to the fontedn server, i.e. Gateway, and additionally pushed to the UI5 applications.
You should contact the Gateway colleagues (insert your question in that blog regarding the support (timeline ?) of ABAP Push Channels (WebSockets) in Gateway.
Hi Masoud, This is great blog. I have one question, We ar using the Gateway hub7.4 SP9 and ECC 7.31 SP6 with add-on IW_BEP SP9. so we are developing the ODATA services on SAP Gateway hub and regestering the same server itself. Buiding the UI5 applications some in portal server and some UI5 applications are running Gateway server itself. since it is supports from 7.4 relasease, to implement this APC, I think we need to upgrade our ECC from 7.3 to 7.4, then it is possible. But i have one qustion, if we are using the Gateway system , do we need to have two websockets. Like one is in ECC to push the messages to Gateway and another web socket to push the messages to UI5 application, if ui5 running in Portal server or UI5 running in Gateway itself. Can you tell me how to implement at high level. Thanks
That worked fine and I have just got around to experimenting with my own copy of the program.
First off, almost a year has gone by - is this technology still classed as a prototype not for productive use?
Secondly, in the example program the receiving report is "magically" responds to an incoming message by reacting as if the user had done something that fired the "AT USER COMMAND / AT LINE SELECTION" events, i.e. what you expect to happen in a report which uses WRITE statements.
Is there a specific ALV equivalent of this, or do I just add the "AT USER COMMAND" event into the executable program that controls the ALV instance, and tell it to call the REFRESH method of the running instance?
for transffering of a event raised in a backend/hub system to the (frontend) Gateway system you need a kind of notifcation infrastructure, which may based on APC WebSocket client available with the ABAP Application Server 750 or an RFC/HTTP or using Gateway notification (?).
As I proposed to Prabaharan Asokan (see above) you may contact the Gateway colleagues (insert your question in the Gateway specific blogs).
there is up now no plan for productization of the SAP GUI Push Channel (SPC). But you can address this development requirement with the reference to the business case accordingly to SAP development organisation.
we think that it would be very valuable to use SPC in production. Do you have any news on this? How can we exactly address our requirement to SAP development organization?
I'm concerning the performance impact on system. As setup of websocket between frontend and backend server will more or less consume resource of backend system. Is there a statistic that how many websocket can be set up in backend server?
please also refer to the FAQ – ABAP Channels, section “Can I use ABAP Channels to update SAP GUI frontends directly?“ regarding push message to SAP GUI.
You said it was going, and clearly, going it is. A great pity, one of the best ideas SAP ever had in my opinion. However I understand the politics - SAP get more money by moving people onto higher releases.
Improving the SAP GUI experience would encourage people to keep using the SAP GUI. That is the last thing that SAP wants.
This political/money-driven/marketing aspect is the "technical reason" for getting rid of the massive improvement, as mentioned in the explanation of why it is going. Not that it did not work, because it did, but that it worked too well.
Still, it was good while it lasted.... My company will still be on the SAP GUI for another nine years (until ECC 6.0 goes out of support) so it would have been very handy, but oh well, business value for the customer is always last on the list when it comes to making decisions. To be fair SAP is only behaving like its competition in this regard.
we think that it would be very valuable to use SPC in production. Do you have any news on this? How can we exactly address our requirement to SAP development organization?
Hi,
are there any news on this question? I am facing the same problem: The user cannot continue working because the session is locked by the WAIT statement.