Replace polling in CRM Interaction Center by ABAP Push Channel
As of SAP enhancement package 3 (SP03) for SAP CRM 7.0, the Interaction Center (IC) utilizes ABAP Push Channel (APC) for
detail information on APC refer to blog http://scn.sap.com/community/abap/connectivity/blog/2013/11/18/websocket-communication-using-abap-push-channels. When the APC is active, the server informs the Web browser about events like an incoming phone call immediately and directly – using a permanent WebSocket connection. This way APC provides an alternative to the polling mechanism of the IC context area.
Example: A communication event like “new phone call is altering” arrives on the CRM server. Now it has to be transferred to the IC Session in the Web browser of the respective agent. In the past, this was done by a polling mechanism (“SAM polling”): the browser polls at regular intervals (typically once per second) to the server and will thus get the information that the new event (alerting phone call) has occurred. With APC there will be no need for polling: the CRM server can directly push the information that there is a new communication event to the Web browser. This way the CRM server, the network and the browser session are freed up from the permanent polling traffic. And also the agent benefits from the better response times: the event (alerting phone call) will – on average – arrive faster on the agent’s UI because the polling interval (e.g. 1 second) is avoided.
It is by the way not only the communication events that benefit from the new push mechanism. Also Alerting and Broadcast Messaging rely on the new push channel as soon as you switch on the APC option in the context area profile.
As prerequisite you need a Web browser that supports WebSockets (e.g. IE10). If temporary network connection problems occur, or if the Web browser used by an agent does not support WebSockets, the system launches the classic polling mechanism instead.
If you are interested, you can activate the APC in the Customizing activity Define Context Area Profile and check out SAP note 1962301 for more technical details.
For further information check the RKT material of SAP enhancement package 3 or the release information.
Hello Henning,
thanks for this post. I am thinking of any risks - please, do you know, are there any issues reported by customers who went from polling to to APC?
Are there also any statistics from real environments available - like decrease of network load, decrease of ICM load (if any)?
Thanks and regards,
Dawood Hla Shwe.
Hello Dawood,
thanks for the feedback!
We are not aware of any risk based first customer feedback. Generally risks (namely security) where analyzed carefully by our colleagues from SAP NetWeaver who provide the APC technology (for details also see blog http://scn.sap.com/community/abap/connectivity/blog/2013/11/18/websocket-communication-using-abap-push-channels)
In the area of Callback URLs an port handling in combination with Web dispatchers / Load balancers we found that the settings described in note 2095906 - CRM-IC: APC usage with WebDispatcher / Load Balancer and standard protocol port (80 or 443) have to be considered (not a risk, just prerequisite to get the connection established).
With regards to performance: avoiding the polling cycles (typically 1 poll per second and agent) reduces the number of messages that have to be handled by the network. However due to the very small payload of the polling messages this does not reduce the overall volume of the network traffic dramatically. The reduction of open http connections and http requests however proved helpful e.g. in large installation (several 1000 agents). Here some of the network components can have a limit e.g. of supported http connections. In such cases avoiding the polling can help to reduce the number of parallel network components.
An Advantage that we could observe is the improved responsiveness of communication related roundtrips (e.g. alerting phone call, accepting a phone call, …). Here the response time is reduced by an average of at least 500 msec. This is obviously and advantage from an agent productivity point of view. And it also an
advantage regarding stability of the communication integration infrastructure:
as we avoid the delay caused by the polling cycles - the integration with the
communication management software is more direct / real time. This reduces the
risk of racing condition (“bad timing”) like “customer hangs up and at the same
time agent initiates transfer”.
Best regards,
Henning
Hello Henning,
this is really useful addendum to your blog,thanks! I really appreciate that you have shared real experience from customers.
Apparently, we cannot expect that this feature will come later also into CRM Ehp2 with some SP, since basis 7.40 SP05 is a prerequisite. One more reason to upgrade to EhP3 🙂 .
Looks like that one of the CRM CMS related core classes, CL_CRM_MCM_SESSION, is still used and has been extended to use APC. We have developed ABAP based progressive dialer by enhancing this class and using polling. I was just wondering whether it will survive whether it will survive switch to APC and it looks safe...
Best regards and please, keep on blogging 😉 ..
Dawood.
Hi Dawood,
yes, our intention was to provide APC integration as a generic alternative to the polling into the ICM cache. This should generically serve all processes that made use of the polling based SAM messaging.
best regards,
Henning
Interesting! Thanks for sharing.