Revision as of 17:34, May 20, 2020 by Mgionet (talk | contribs)
Jump to: navigation, search

Async chat through GMS REST API

Entire page is new

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 or "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. [MG: I'll link this option properly when it becomes available]

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 Chat Server, which have 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.
Comments or questions about this documentation? Contact us for support!