Overview

In order to enable async chat capabilities, the following must be provisioned:

• During a chat session creation, a special key-value pair GCTI_Chat_AsyncMode=true must be provided. It enables a special processing in Chat Server and Agent Desktop, and can also be used in workflow logic.
• Chat Server (version 8.5.202.xx and higher required) configuration must be reviewed for the following configuration options:
  • To prevent the chat session from being closed when a mobile application disconnects with GMS, set the value of the flex-push-timeout option to a larger value (for example, 86400 seconds). If there is no protocol activity from a mobile application for the duration of this timeout, Chat Server checks with GMS to see if a connection with a mobile application is still alive. If GMS does not confirm the liveness of a connection, Chat Server sets the timer again and, when the timeout expires, removes a customer from the chat session if no protocol activity is detected.
  • Consider adjusting (only if needed) async-idle-alert, async-idle-close, async-idle-notices. Default values of these options enable async inactivity control monitoring for async chat sessions. The value of option async-idle-notices also defines the condition when GCTI_Chat_AsyncStatus is updated to a value of "2".

  Notes:

  • Async inactivity control is different from regular inactivity control (specified in configuration of section [inactivity-control]) in a way that it does not require the presence of an agent in the chat session.
  • Activity in inactivity control means any activity in the chat session that is visible to all participants and that is not generated by bot participants.
  • It is not recommended you enable regular inactivity control (section [inactivity-control]) for Chat Server which handles async chat sessions, as it contradicts with the nature of long chat sessions.
  • async-idle-alert/close reuses the message-alert/close options from the section [inactivity-control] for the notification.
• Workflow with a special processing must be deployed (see the sample workflow provided in Deployment). It must evaluate the following interaction properties:
  • GCTI_Chat_AsyncStatus is an integer and any positive value must trigger the workflow to route an interaction to an agent. The following values are possible:

    Value	Description
    -2	set when chat session is placed on hold or into a dormant state (in other words, placed into the workbin/queue by an agent).
    -1	set when an agent is processing the chat session.
    0	undefined value (value is not used).
    1	signifies a newly created chat session.
    2	set when a customer posted a reply (sent a message) into a chat session while there were no agents in chat session.
    3	set when async inactivity control timeout expired (which means that chat session could be closed soon by Chat Server).
    4	set when agent desktop abnormally disconnects from Chat Server (in other words, in case of exits).

  • GCTI_Chat_AsyncCheckAt contains a timestamp when an interaction must be checked. This property must be used to detect "stuck" interactions in workflow which happens under abnormal situations (for example, in a case when Chat Server has stopped, and a chat session was never restored on another instance of Chat Server).
• Workspace Desktop Edition (version 8.5.122.08 and higher) provides:
  • Additional Place Chat On Hold button (configuration option chat.on-hold-queue) which allows an agent to return the chat session into the workflow (in other words, put into a dormant state) where it can await customer activity.
  • The possibility to open the active chat from the workbin and contact history windows.
• Mobile application (which implements a chat client for a customer) must operate with GMS using CometD and mobile push functionality (GMS version 8.5.114.09 or higher required). It keeps the chat session running for as long as it is needed.

Additional notes:

• Async chat sessions can be processed in the same way as non-async chat sessions. Async chat simply extends the functionality for chat session processing.
• In Async mode (in other words when CometD is used with GMS, and the rate of messages in a single chat session is low), a single instance of Chat Server is capable to support a greater number (up to 5000) of concurrent chat sessions. However, the Chat Server limitation of concurrent connections (4K on Windows and 32K on Linux) must be taken into account when planning your deployment. When calculating the number of total expected connections for web or mobile chat, consider the following:
  • Every agent desktop and every chat bot require a separate persistent connection to chat session. For agents, multiply it by the maximum possible capacity of agents.
  • Additionally, supervisor monitoring requires a separate persistent connection.
  • Client (in other words, consumer-facing) operations do not keep a persistent connection with Chat Server. The connection is only established when the consumer sends the request with a message or notice, or when Chat Widget requests periodic pull transcript updates (which is applicable only in non-CometD mode in GMS).Once the request is complete, the connection is immediately closed.