In Interaction Center (IC) scenarios, the integration between the IC agent’s browser session and the external communications management software (CMS) relies on the communication session located on the SAP CRM server. The communication session (formerly known as “worker session”) sometimes gets in trouble when either the browser session connection or the CMS connection is not responding any more. This can happen when for some reason the agent’s PC or browser session crashes or also due to latency effects etc. in the network. To avoid phone calls from customers still being forwarded to the agent in such cases, the communication session can be enabled to check for the availability of both the browser session and the CMS connection.
In SAP CRM 7.0, the “Heartbeat and Watchdog” concept was implemented for the Interaction Center to monitor the connection between the agent’s “communication session” and the agent’s web browser. Now the watchdog concept has been extended to also monitor the connection between the communication session and the CMS (see SAP Note 1564979).
There are different ways of implementing this concept:
Checking the browser session availability
This check utilizes the following process: If the IC agent’s browser session is active, the browser keeps sending pings (configurable interval) to the communication session (formerly “worker session”). The communication session acknowledges these pings and logs the timestamps.
CMS-event-triggered timestamp comparison (heartbeat without watchdog): As soon as a CMS-event (such as a new phone call) comes in, the CMS transfers it to the communication session and the session then compares the timestamps of the last browser ping with the timestamp of the incoming communication event.
What happens next?
- If the time between the compared timestamps is too long (longer than the tolerance specified in Customizing), the browser session is considered unavailable and the communication session rejects the incoming call and logs the IC agent off from the CMS. The CMS will then route the call to another agent.
- If the last browser ping falls within the allowed tolerance, the CMS transfers the call to the agent, because the browser session is still considered to be available.
Watchdog-triggered timestamp comparison (heartbeat and watchdog): All users have their own watchdog sessions monitoring the browser availability by “waking up” at regular intervals (specified in Customizing) and checking for the last acknowledged browser ping logged in the shared memory.
What happens next?
- If the last acknowledged browser ping falls within the specified time, the watchdog goes back to sleep, because it assumes that the browser session is available.
- If more than the specified time has passed, the watchdog assumes that the browser is unavailable and logs the user off from the CMS and terminates itself.
What is the advantage of the watchdog monitoring the time stamps, compared to the CMS-event-triggered timestamp comparison?
The CMS-event-triggered check only starts when a new CMS event comes in. So if the agent’s browser already crashed a while ago, the CMS would still have to forward one more call to the agent, only to find out that they are not active any more. This call would then have to be rerouted by the CMS to another agent, which leads to waiting time for the caller. This can be avoided by letting the watchdog proactively check the browser session availability at regular intervals.
Checking the CMS session availability
All users have their own watchdog sessions, but all watchdog sessions share a memory to log timestamps. At specified intervals, each watchdog session wakes up and first checks the last acknowledged ping in the shared memory. If the last ping is older than specified in Customizing, it sends a new ping to the CMS.
What happens next?
- If the ping is acknowledged by the CMS, the watchdog session writes the timestamp of the ping into the shared memory and goes back to sleep.
- If the ping is not acknowledged by the CMS, the watchdog sends an error message to the browser session with the information that the CMS is not available at the moment. Furthermore, the watchdog session enters the information that the CMS is not available into the shared memory, to inform all the other watchdog sessions that will wake up next. The subsequent watchdog sessions will carry on checking for the CMS availability.