Async chat through GMS REST API

The Async Requirements state that async chat must only operate through "GMS using Chat API V2 with CometD". This is because:

• Initially it was not possible to send push notifications while using GMS REST API V2. This feature was introduced in a later release and is described on the page, Push notifications via GMS to HTTP server.
• Running too many async chat sessions with a periodic short polling imposes an unreasonably high load onto GMS and Chat Server components. With the approach described below, this can be avoided by applying special logic for a custom web chat application.

Approach

In order to implement async chat with GMS REST API V2, a custom web chat client application (let's call it custom-chat-app) must be developed as it is important to implement a special processing logic which does not exist in the Genesys Chat Widget. This custom web chat client application can be implemented in two ways:

• By using mid-layer architecture (in other words, inserting a special web server application between a client software and GMS).
• By allowing a client device/computer to communicate directly with GMS. Note: Here, the custom web chat client must have the ability to receive push notifications (either mobile or custom).

In both cases, a customer needs to develop and deploy a special web application (let's call it notification-receiver-app) which can:

• Receive custom http push notifications from GMS. For reliability it is important that the “resending” these notifications is enabled by sending GCTI_GMS_PushResend.
• Communicate with GMS for push notification acknowledgement, required for re-sending logic for notifications and for high availability mode support. See the "High availability support" section below, for more details.

Note: custom-chat-app and notification-receiver-app can be separate parts of one single application.

The following solution-wide logic must be implemented:

• The custom-chat-app must not use short polling to receive chat session updates. This will prevent producing an unreasonably high load onto GMS and Chat Server. Instead, it:
  • Must send "Refresh" requests upon receiving a push notification through notification-receiver-app.
  • Optionally, it can send a rare or periodic “Refresh” request (so called, "ping"), in case some unsolicited notifications were missed. For example, with a ping timeout of 30 minutes, 100K chat sessions will produce an average of 55 ping requests per second which is a reasonable load.
• If a reliable delivery is enabled by GCTI_GMS_PushResend (this is highly recommended in order to not loose push notifications), then upon receiving an unsolicited notification (which will be always of type push-url when resending is enabled), the notification-receiver-app must either send or ask the custom-chat-app to send a ping Refresh request to Chat Server to acknowledge the delivery (which then stops the resending logic in Chat Server). It can be requested that all necessary tokens be received in a notification from Chat Server through the configuration option flex-push-content.

High availability support

Chat Server high availability is based on a chat session restoration which can only be triggered from a client chat application side (not from an agent desktop or workflow side). This means that a request—such as a ping Refresh request—must be sent from a client chat application as soon as possible after Chat Server (which was handling a given chat session) was stopped. This request is delivered by GMS to one of the available Chat Server instances and triggers a chat session restoration. Since regular chat includes frequent ping requests through the use of short polling, this is a non-issue. For async chat however, where no activity is generated by the client application for long intervals, either notification-receiver-app or custom-chat must:

• Cache access tokens (alias, secure-key, session-id, user-id) for all running chat sessions.
• Send a ping request to GMS for all chat sessions running on the Chat Server instance, which has stopped or restarted. It can be detected by the following:
  • Monitor the Chat Server health metrics through the REST API (see, Key Performance Indicator counters for more information) and keep the map of Chat Server (app_dbid, process_os_pid) pairs. If an application cannot access the Chat Server health port with a few failed attempts, or if the value of process_os_pid changes for the provided app_dbid (which is the same as alias in GMS REST API), this means that Chat Server has been restarted.
  • Additionally, if Chat Server is stopped intentionally through a solution control layer (for example, for maintenance), Chat Server sends a push notification with type=ParticipantLeft, participantId=1 and quit-reason-advice=reconnect. This functionality is enabled through the configuration option shutdown-notify-flex-push with a value of 1.