Deploying a High-Availability Chat Solution

Chat Server provides the possibility to run in high availability (HA) mode where in case of failure of any Chat Server instances – chat sessions could be continued on any other running Chat Server instances. To facilitate this mode Genesys recommends to run Chat Server in so called load-balancing (sometimes called “N+1”) mode – where all running instances run in primary, i.e. active mode (no backup applications are configured). Primary/backup mode is still supported, but not recommended(unless there are specific requirements). When running in HA mode:

• web chat application (i.e. GMS) is selecting any active Chat Server instances to start a new chat session, and if this Chat Server instance will be broken during the course of chat session, web chat application will select another active Chat Server instance, where chat session will be restored and continued. At the moment of session restoration, Chat Server updates the interaction in Interaction Server with information how to connect to chat session at new location.
• Agent Desktop is watching for interaction properties updates, and upon such notification will reconnect to chat session at specified Chat Server instance.

For Chat Server to be able to restore chat session when requested, Chat Server stores the intermediate version of chat session transcript in persistent storage. Configuration allows to use for this purpose either of:

• UCS – more simple configuration, however implies additional load unto UCS and its database.
• Cassandra – require special configuration, but removes the load from UCS which could be essential for deployments with high load.

Configure Chat Server for HA

Configure as follows:

1. Configure Primary and Backup Chat Server instances. Specify Warm Standby mode for the backup instance.
2. Connect Web API Server to the Primary Chat Server only. Web API Server reads the information about the backup Chat Server automatically.
3. Connect Interaction Server to the Primary Chat Server only.
4. Set the following values for options in the settings section for both Chat Server applications:
   • session-restoration-mode = simple

     This enables Chat Server's session restoration functionality.

   • transcript-auto-save = 1

     This makes Chat Server update the transcript in UCS after each submitted message. You may also set this option to 2 (notify clients when the transcript is updated), however that would be effective only if the agent desktop can process special notifications from Chat Server (in particular, the notice ucs-save-fail/save). From the standpoint of resources, using the value 2 will slightly increase CPU usage; also Genesys Interaction Workspace does not currently support this functionality.

   • transcript-save-on-error = close

     This makes Chat Server close the chat session (without a final update in UCS) if, during the session, UCS sends a non-recoverable error message in response to one of Chat Server's periodic transcript updates.

5. Review the values for the following options (see eServices 8.1 Reference Manual for full descriptions):
   • transcript-resend-attempts
   • transcript-resend-delay
   • transcript-save-on-error
   • transcript-save-notices

   The default values are acceptable for HA functionality; however you may wish to evaluate whether those values produce the behavior that you expect.

Run a Test

A properly configured solution with HA mode must work without any additional configuration for other components. This section describes a simple test.

Requirements:

• The Chat HA sample included in Web API Server
• Interaction Workspace (agent desktop)
• A primary/backup pair of Chat Servers

Conduct the test as follows:

1. Start a chat session using the Chat HA web sample.
2. Send a message to verify that the chat session is active.
3. Then do either of the following:
   • Kill the primary Chat Server process, using Task Manager on Windows or kill -9 on UNIX (if you then restart Chat Server it should start in backup mode).
   • Switch the primary Chat Server over from primary to backup using SCI.
4. Send a message to verify that the web sample is continuing the chat session. You will see messages showing that a user was disconnected and connected again. It is up to chat web application and/or agent desktop to decide if to show these messages.
5. Optionally, examine the Chat Server logs to see what actions were performed by the server to restore the chat session.