Revision as of 12:26, September 26, 2019 by Mgionet (talk | contribs) (Update with the copy of version: DRAFT)
Jump to: navigation, search

push_notification_include_payload

Section: chat.service-name
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately
Introduced: 8.5.201.04

If true, the chat event payload is included in customhttp notifications the same as with CometD notifications. Note: Applicable to Chat V2 with CometD and customhttp only. Not applicable to FCM and iOS push events.

Push notifications via GMS to HTTP server

Starting with version 8.5.306.03, the Chat solution allows you to request push (in other words, unsolicited) notifications through Genesys Mobile Server (GMS) to an HTTP server even when a customer-facing chat web application (Chat Widget) communicates with GMS via "Chat API Version 2". Previously, this was only possible with "Chat API Version 2 with CometD".

To enable this functionality, do the following:

Application Instructions
GMS
  1. Deploy GMS using Cluster Application
  2. Configure GMS for Custom HTTP notification
  3. Configure GMS with push_notification_include_payload (optional)
Chat Server

Introduced in version 8.5.305.XX(TBD)

  1. Add new configuration option flex-push-on-join in the settings section with value "true". This forces Chat Server to acknowledge the push notification subscription during the creation of a chat session.
  2. Ensure that option flex-push-enabled is set to "true", and option flex-push-timeout is set with a larger value (for example, "86400 seconds"). For more information, see Async Requirements.
  3. Review the schedule for resending push notifications defined by the configuration options, flex-push-resend-attempts and flex-push-resend-delay.
Customer-facing chat web application
  1. The web application must supply a set of mandatory key-value pairs in the userdata for the "Request Chat" HTTP method (using a userData[key-name] notation):
    • GCTI_Chat_PushSubscribe with the value "true". This enables push notifications in Chat Server when “Chat API Version 2” is used ./li>
    • GCTI_GMS_NodeGroup with the GMS cluster name. If the GMS version is 8.5.213.03 or greater, this key-value pair is not required, as it is automatically provided by GMS to Chat Server.
    • GCTI_GMS_PushDeviceId with a unique device ID. This ID is returned in the push notifications as “deviceId”.
    • GCTI_GMS_PushDeviceType with the value "customhttp". This defines the type of push notification used.
    • GCTI_GMS_NotifyRequestor with value "true". This forces Chat Server to send push notifications to GMS about the customer's own activity.
    • GCTI_GMS_PushIncludePayload with value "true". This forces GMS to include the payload (in other words, the chat transcript event content) with a custom-http push notification. Without providing this key-value pair, GMS sends only the deviceId (provided in GCTI_GMS_PushDeviceId) in the push notification, which can prevent the distribution of sensitive content. When reliable delivery is requested by GCTI_GMS_PushResend, this key-value pair must be provided.
  2. Starting with version 8.5.308.06, Chat Server provides the ability to request a reliable delivery of push notifications. For that, the web application must additionally supply the GCTI_GMS_PushResend key-value pair with value true in the userdata. This forces Chat Server to activate the mechanism of resending push notifications according to a schedule defined in the configuration. Chat Server will start resending push notifications if no "refresh" (in other words "pull transcript update") request is being received within the amount of time specified by option flex-push-resend-delay. See below for more information about reliable push notifications delivery.
  3. The web application can additionally supply a set of key-value pairs in the userdata:
    • GCTI_GMS_PushProvider
      Must be provided if you specified the configuration for the non-default provider in GMS.
    • GCTI_GMS_PushDebug
      Must be provided if you specified the debug mode for the configured provider in GMS.

Additional notes

  • If push notifications are enabled, Chat Server tries to find the GMS node in the GMS cluster (specified by "GCTI_GMS_NodeGroup") and to associate that found node for further notifications (until the node is disconnected). If no GMS node is available (in other words, registered in Chat Server), Chat Server attempts to find a node from the cluster the next time an activity is generated in the chat session or upon chat session restoration in HA mode.
  • If reliable delivery of a push notification is not requested by sending GCTI_GMS_PushResend, no attempts to resubmit the same push notification will be made in case of a delivery failure between the GMS and HTTP server, and between Chat Server and GMS. The following log messages are provided:
    • In GMS: "Dbg 09900 [com.genesyslab.PCT.invoker.default] DC Chat Server Persistent Listener: Event 17 was not (GMS is not running in full mode or incompatible Chat Server version) pushed for delivery to customhttp for device..."
    • In Chat Server: "Trc 59758 push-flex: could not send notification - no gms node found in group=..."

Sample configuration for custom HTTP notifications in GMS

[chat]
enable_notification_mode=true
push_notification_include_payload=true
  
[push]
customhttp.message=dummy message
customhttp.url=http://<hostname>:<port>
debug.customhttp.message=dummy message
debug.customhttp.url=http://<hostname>:<port>
pushEnabled=comet,customhttp

Reliable push notifications delivery

When reliable delivery for push notification is requested, GMS delivers the following JSON in the HTTP request:

{
  "message":{
    "secureKey":"G1xBGx9aTUYVBEECD0UZAVwTQEQDFgRZFVJTXEI3QSFFIShAHyVcRUI2GUJXXUEeAikkNSNTJFddQRc=",
    "chatId":"deprecated",
    "nextPosition":17,
    "messages":[
      {
        "from":{
          "nickname":"",
          "participantId":0,
          "type":"Client"
        },
        "index":0,
        "text":"PUSH-NOTIFICATION",
        "type":"PushUrl",
        "utcTime":1568662361000,
        "userData":{
          "notify-attempt":"0",
          "notify-position":"16",
          "user-id":"007D5D7FE31F001B",
          "session-id":"00020aEQFW6V0029"
        }
      }
    ],
    "alias":"0",
    "chatEnded":false,
    "userId":"deprecated",
    "statusCode":0,
    "monitored":false
  },
  "deviceId":"a1a23456789123456789"
}

Important field descriptions

Field Description
participantId Always 0 and must be ignored.
notify-position Contains the starting position of content not retrieved. It can have a value of -1 meaning that chat participant has been removed from the chat session.
notify-attempt Contains the number of attempts to deliver the push notification.
user-id Used to communicate with Chat Server.
session-id Used to communicate with Chat Server.
chatEnded If the value is true it means the chat session is finished.
Warning
The secure key is not provided for security reasons; it must be stored by the web application
Comments or questions about this documentation? Contact us for support!