Client-side processing, Polling and WebSockets (push)
Dear community,
By introducing my newest contributions to the DesignStudio community SDK repository I would like to show you guys what is possible in terms of SDK component communication and processing whereabouts. From a conceptual perspective we are going to talk about how to achieve data updates in a near real time manner and who is going to do the work. There are three options I would like to discuss: client-only processing, client based polling and permanent communication channels in between clients and servers using push messages. Each of these concepts will be covered by one of the SDK components presented in the next section.
Client-side Processing (WorldTime component)
This easy to use component enables a designer to display a localized time string. Portal-like dashboards often use it for convenience of the user.
Figure 1: WorldTime design view
You can define an UTC offset, use daylight saving if necessary and choose from a variety of different layout options regarding the time and date format.
Figure 2: WorldTime properties sheet
The update interval specifies how often (currently every 5 seconds) the update routine is triggered to refresh the displayed time string. Technically this is done by using the standard JavaScript method setInterval().
That way all of the workload resides on the client’s browser. There is no network load and no impact on the server at all.
Master of fast polling (TimeOut component)
But what if you need actual data feeds which can’t be derived by the client app? Usually web applications such as DesignStudio dashboards are build using technologies like AJAX and libraries like jQuery to optimize server calls and roundtrips. Those are standard JavaScript tools to implement fast and flexible web pages. Parts of your application only call for data input if they need to and the requested data packages can arrive piece by piece. Even better, only the affected web components are updated in the process and not the whole page. But on the bottom line the communication is client initiated utilizing HTTP and the TCP/IP protocol where the communication channel is closed once the receiver confirms data arrival. Every new call starts again with a typical protocol handshake.
So, if we want to implement periodic data feed updates, we have to call the server for new information (client poll) on a regular basis. That’s where the second new SDK component comes into play. Let’s say you have a file repository on the SAP BW and you want to monitor if a new file arrives. The TimeOut component enables you to start a timer and use its time out event to add time driven logic to your DesignStudio dashboard.
In order to realize the use case described before you can check the checkbox” is periodic?” and schedule a periodic call. That way the dashboard user will be notified about a new file automatically. In the given example worst case is after five seconds. The involved WebService component can be found on the community SDK repository too.
Figure 3: TimeOut properties sheet
This kind of approach impacts on the server depending on the frequency of calls and the number of users using the web application. In addition to that, many times, data updates happen less often than the client’s poll for new information. Especially if the request frequency is very high, for example in magnitudes of sub seconds. As a result there is constant traffic on the network and load on the server even if there is no new data to share.
For the sake of completeness, if the server delays its answer to the client’s poll request to increase the chance of an incoming data update instead of answering right away, that mechanism is called long polling.
Push messages at its best (WSPusher component)
To overcome the downsides of fast and long polling regarding the amount of dispensable poll requests and overhead of the handshaking mechanism, the obvious solution is to let the server decide when to send an update and keep the connection open. In order to do so it is necessary to establish a continuous full duplex connection between the client and the server. WebSockets (TCP/IP based protocol) are a popular solution to achieve just that. On such an open stream both partners can exchange messages on their behalf. Meaning the server can now push information to his clients.
My SDK component WSPusher implements the standard JavaScript API for WebSockets to enable the pushing mechanism. There are four event listener that handle the communication channel lifecycle on the browser (all current browsers support WebSockets😞
- onopen: Called when the communication channel is setup initially
- onmessage: Called when a message is received from the server
- onerror: Called when an error happens during the communication
- onclose: Called when the communication link closes
These are hooked accordingly into the DesignStudio SDK framework so that you can use my component to send and receive messages using WebSockets.
You only need to specify your WebSocket compatible server and you are good to go to get some data pushes from that server. The default URL points to a WebSocket server implementation that echoes your messages so that you can start using the component out of the box.
When a new message from the server arrives the event handler On Push Message Received is triggered. My component serves as a generic adapter that only passes the messages from one end to the other. It’s the developer’s task to ensure the web server handles messages and client connection management gracefully. On the other end the DesignStudio app designer needs to do something meaningful with the pushed messages of course.
I would suggest using JSON as data format for the messages and the community’s SDK component JSON Object to work with the JSON documents to increase component interoperability.
Figure 4: WSPusher properties sheet
The fun part starts when you try to implement WebSockets with ABAP on SAP. SAP calls it ABAP Push Channels (APC). I managed to get a WebSocket compatible service up and running using this blog entry: http://scn.sap.com/community/abap/connectivity/blog/2013/11/18/websocket-communication-using-abap-pu...
And this code snippet for the on_message handler:
method IF_APC_WSP_EXTENSION~ON_MESSAGE.
" Message has been received
TRY.
" Echo the message on WebSocket connection
DATA(lo_message) = I_MESSAGE_MANAGER->create_message( ).
lo_message->set_text( i_message->get_text( ) ).
" Send message
I_MESSAGE_MANAGER->send( lo_message ).
CATCH cx_apc_error INTO DATA(lx_apc_error).
MESSAGE lx_apc_error->get_text( ) TYPE 'E'.
ENDTRY.
endmethod.
Now your SAP backend can push around your DesignStudio dashboard :wink: isn’t it great?
Obviously there are not only upsides to the WebSocket approach. For example there is also permanent traffic on the network to keep up the continuous communication but with considerably less overhead than with plain old HTTP. And your server needs to be sufficiently equipped to handle several client connections at once in parallel.
There is a lot more around that whole topic like broadcasting mechanisms and the ABAP Messaging channel just to mention a few. But for now this shall be sufficient.
Final words
Using the DesignStudio SDK we can use the full range of types of communication channels and process data/tasks where they are best suited, at the client, at the server or a mixture of both.
The components mentioned today are generic in nature and can be used for all sorts of use cases other than described here. I’d like very much to hear about your ideas to make use of them and what problems you solved.
Find the code repository on GitHub: https://github.com/org-scn-design-studio-community/sdkpackage
You don’t know the SDK community? You haven’t downloaded our SDK components yet? Find us, our SDK repository installation link and all of the mentioned SDK components over here:
As always feel free to ask lots of follow up questions.
Yours
Martin
- SAP Managed Tags:
1 Comment
