Ansicht
Dokumentation

CRMV_IC_HBTPROF - Define Heartbeat Profile

BAL Application Log Documentation   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
This documentation is copyright by SAP AG.

In this Customizing activity, you configure settings that check for continued communication between the communication session, the communication management software (CMS), and the Web browser.

For every browser session of an Interaction Center agent there are two sessions in the system: the communication session and the agent session. The communication session hosts communication functions such as telephony, whereas the agent session hosts generic functions such as account identification and the navigation bar.

You can choose between the following checking methods:

Checking the Browser Session Availability

• CMS-event-triggered timestamp comparison (heartbeat without watchdog)

This check is triggered by an external CMS event, such as an inbound call. For this call to reach the agent, the browser session has to be functioning. The browser of the interaction center (IC) agent sends pings to the communication session at regular intervals. The communication session acknowledges the ping and logs the last timestamp of the browser ping. When the CMS transfers an external event, for example an incoming call to the communication session, the communication session compares the timestamps of the last browser ping to the timestamp of the current communication event and does the following:

• If the time between the two timestamps is longer than specified in the Heartbeat Lag field, the browser session is regarded as no longer available. The communication session rejects the call and logs the IC agent off from the CMS.

• If the last browser ping falls within the specified tolerance, the communication session transfers the call to the agent.

• Watchdog-triggered timestamp comparison (heartbeat and watchdog)

All users have their own watchdog sessions that monitor the browser status. The browser of the IC agent sends pings to the communication session at regular intervals. The communication session acknowledges each browser ping and logs the timestamp in a shared memory. The watchdog sessions wake up at regular intervals (for example, every 120 seconds) as specified in the Watchdog Session Sleep Time field and check whether the most recent time stamp of the last acknowledged browser ping is within the time specified in the Heartbeat and Watchdog Lag field. The following happens next:

• If the last acknowledged browser ping falls within the specified time, the watchdog goes back to sleep.

• If more than the specified time has passed, the watchdog assumes that the browser is unavailable and logs the user off the CMS and terminates itself.

Checking the CMS Session Availability

All users have their own watchdog sessions. At a specified interval, the watchdog session of agent A sends a ping to the CMS. The CMS acknowledges the ping immediately and the watchdog session writes the timestamp into the shared memory.

The watchdog sessions wake up at regular intervals (for example, every 120 seconds) as specified in the Watchdog Session Sleep Time field and check whether the most recent time stamp of the last acknowledged CMS ping is within the interval configured in the CMS Ping Interval field (for example, every 30 seconds). If this is the case, the watchdog goes back to sleep.

The first watchdog of any user that wakes up at 30 seconds or more after the last acknowledged CMS ping sends a new ping to the CMS (for example, the watchdog of agent B). If the ping is not acknowledged by the CMS, the watchdog of agent B assumes that the CMS is not available anymore. The watchdog of agent B sends this information to the following places:

• The communication session of agent B

The communication session sends an error message to the browser to inform agent B about the unavailability of the CMS.

• The shared memory of all users

The last entry in the shared memory specifies that the CMS is not available. As soon as the next watchdog wakes up and reads this information, it sends a new ping to the CMS to check if it is available again.

If the ping is acknowledged, the watchdog updates the shared memory accordingly. If the ping is not acknowledged, the watchdog informs the communication session. The communication session sends an error message to the browser to inform the agent about the unavailability of the CMS.

Note: As soon as a watchdog sends a ping to the CMS, this locks the shared memory table. This indicates to other watchdogs that wake up that a ping has been sent and that they must not send an additional ping in parallel.

Note: All time periods entered in seconds.

Checking the Browser Session Availability

If you want to check if the agent's browser sessions are still active, you can do the following:

• Use heartbeat without watchdog:

The heartbeat check allows you to monitor whether the browser session is still active. To use the heartbeat check, you have to make settings in the following fields:

• Heartbeat Lag

• Browser Ping Interval

You have to assign the heartbeat profile to a business role using the Customizing activity Define Business Role. If you do not assign a heartbeat profile to your business role, the heartbeat profile DEFAULTis activated. If this profile is not available, the system falls back to SAP program logic to do the checking.

• Use heartbeat and watchdog:

The heartbeat and watchdog check allows you to monitor whether the browser session is still active: To use the heartbeat and watchdog check, you have to make settings in the following fields:

• Heartbeat and Watchdog Lag

• Browser Ping Interval

• Watchdog Session Sleep Time

• Watchdog Enabled

You have to assign the heartbeat profile to a business role using the Customizing activity Define Business Role. If you do not assign a heartbeat profile to your business role, the heartbeat profile DEFAULTis activated. If this profile is not available, the system falls back to SAP program logic to do the checking.

Checking the CMS Session Availability

If you want to check if the CMS session is still active, you have to make settings in the following fields:

• Watchdog Session Sleep Time

• CMS Ping Interval

• Watchdog Enabled

You do not need any lag settings, because if the ping sent to the CMS is not acknowledged immediately, the CMS is regarded as not available.

You have to assign the heartbeat profile to a business role using the Customizing activity Define Business Role. If you do not assign a heartbeat profile to your business role, the heartbeat profile Defaultis activated. If this profile is not available, the system falls back to SAP program logic to do the checking.

If you want to check the CMS session availability in a system landscape involving multiple CMS systems that are connected to Service with a 3rd party load balancer, you have to implement SAP Notes 1640673 and 1595224.

BAL_S_LOG - Application Log: Log header data   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.

Length: 9181 Date: 20240523 Time: 172132     sap01-206 ( 153 ms )