Previous Post: ABAP Freak Show – May 20th – NetWeaver Business Client 3.0 Preview Next Post: ABAP Freak Show – June 17th – Large Database Objects in 7.02
ABAP Freak Show – June 3rd – Web Dynpro ABAP Notification Service
by Thomas Jung on June 3, 2009 at 12:13 pm
This episode of the ABAP Freak Show looks in detail at the new Web Dynpro ABAP Notification Service that will ship later this year as part of NetWeaver 7.0 Enhancement Package 2. This technology goes by many names – Long Polling, Reverse AJAX, Comet – but regardless the name the idea is to allow data and updates to appear to be pushed from the server to the client. In this eLearning we look at the infrastructure in ABAP that has been built to support such push without putting too much load on either the client or the server. We also look at implementations of this technology for long calculations, inter-session communication, and asynchronous external communication. We also show a real world example using the ESME application for a real time messaging service built into a business transaction.
For more information on ESME: http://blog.esme.us/ or http://cwiki.apache.org/confluence/display/ESME/Index
You can download a high resolution version MP4 version of the video here:
http://blip.tv/file/get/Thomas_jung-AFSJune3rd2009ABAP702NotificationService991.mp4
You can also download an iPod/iPhone version:
http://blip.tv/file/get/Thomas_jung-AFSJune3rd2009ABAP702NotificationService474.mp4
Tags: ABAP, ABAP Freak Show, EnhP2, ESME, Long Polling, NetWeaver, Web Dynpro ABAP
Amazing features and easy to work with… Just blew away my OLTP reporting nightmare in Web Dynpro… Thanks!!!
When using CL_WD_NOTIFICATION_SERVICE (eg. from the demo application WDR_TEST_NOTIFICATION), the browser sends each second a request to /sap/public/bc/webdynpro/Polling which is answered immediatly (from ICM cache).
IMHO this hardly counts as “long polling”, “comet”-equivalent or the like since the idea there is that the browser opens one connection which the server keeps open until a result needs to be communicated.
The problem with the current approach is that this transmitts about 300bytes each second which would make it 1 MegaByte in a hour!
Does anybody have an idea how to circumvent this problem?
@Wolfgang: there is a balance here between network usage and impact on the server side. The requests are processed by the ICM Cache, as you say, and therefore don’t need to drop in to the ABAP layer for processing. Without extensive new development in the ICM to sleep the server thread or dropping into an ABAP work process and sleeping; this was our workaround. Development felt that the network impact of the ICM check was small enough, but it is something you can consider when using this feature. One thing planned for the future is the ability for the application to set the polling interval and therefore perhaps set a timing of several seconds. A small change in the interval might not even be noticeable to the end user, but could have a significant impact to the network traffic.