Intégration des messages MAX POST

Utiliser les messages POST pour l'intégration IFrame

Pour faciliter les intégrations avancées sur les postes de travail, le client agent MAX (My Agent eXperience) prend en charge l'abonnement d'événements par des pages Web intégrées personnalisées. MAX peut intégrer des pages Web (IFrame) à l'aide de panneaux de contact (qui s'ouvrent et se ferment conjointement avec leur contact associé) ou d'espaces de travail personnalisés (toujours ouverts et disponibles, quels que soient les contacts). Un cas d'utilisation courant pour les panneaux de contact serait une page Web CRM spécifique à un client ouverte comme une fenêtre contextuelle lors d'un appel téléphonique (puis fermée une fois l'appel terminé). Un cas d'utilisation courant pour les espaces de travail personnalisés serait une page de base de connaissances ou un autre site qui n'est pas directement associé à un contact ou à une interaction client.

Dans les deux cas (Panneau de contact ou Espace de travail personnalisé), la page Web intégrée « enfant » peut s'abonner aux événements système reçus par la fenêtre MAX « parent » via des messages POST. MAX reçoit régulièrement des informations de la plateforme ACD avec des détails sur l'état de l'agent ou sur des contacts individuels. En s'abonnant à ces événements, la page Web IFramed peut implémenter une logique personnalisée qui répond au comportement dans MAX. Par exemple, lorsque l'agent passe de l'état disponible à l'état actif et de l'état actif à l'état indisponible, la page Web intégrée personnalisée peut choisir de répondre en fonction de règles commerciales. Ou, lors de la réception d'un nouvel appel, la page Web peut être avertie du nouvel appel et y répondre en conséquence. Pour plus d'informations, voir la documentation supplémentaire à : https://developer.niceincontact.com/API, https://developer.niceincontact.com/Documentation/AgentSessionEvents, et https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage.

Variables d'objet de données

MAX est configuré pour recevoir un message de publication du client dans un objet de données contenant les valeurs suivantes. Toutes les clés de propriété sont sensibles à la casse. Si spécifié, les valeurs sont également sensibles à la casse.

• contactCardData : Il s'agit de l'objet de données contenant le nom du client et l'image du contact téléphonique. Il a deux clés, name (nom) et userImg (image de l'utilisateur). Elle est sensible à la casse.
• contactId : Ceci est un entier facultatif. Si vous connaissez l'identifiant du contact, vous pouvez le fournir ici. Si vous n'avez pas l'ID de contact et qu'il est chargé dans un panneau de contacts, nous localiserons l'ID de contact du panneau associé. Les espaces de travail personnalisés généraux n'auront pas d'ID de contact pouvant être localisé de cette manière. Ils devront donc être fournis si une entrée spécifique à un contact est souhaitée.
• issuer : (émetteur) Ceci est une chaîne facultative. Cela fonctionne comme un identifiant pour l'expéditeur, bien qu'il ne doive pas nécessaire être unique. Cette chaîne facilite la journalisation pour ajouter un contexte aux journaux de la console. Lors des tests, il se peut que votre auditeur de message Post récupère le message d’enregistrement que vous avez envoyé. Vous pouvez utiliser ce champ pour vérifier si le message vient de vous. MAX enverra les événements de réponse avec « MAX » comme émetteur.
• messageType : Ceci est une chaîne requise. Elle est sensible à la casse. Il y a deux entrées valides :

  Valeur d'entrée	Résultat
  "RegisterForClientEvents"	C'est ainsi que MAX sait que vous cherchez à configurer un abonnement à un événement client.
  "UnregisterFromClientEvents"	Cela déconnectera votre référence de fenêtre de MAX et mettra fin à l'envoi de l'événement client. Si vous souhaitez modifier les types d'abonnement ou contactId, vous devrez l'appeler avant de vous réinscrire. Ne pas faire cela et utiliser la même fenêtre avec un nouvel enregistrement dans contactPanel entraînera des bogues.
  "ContactCardData"	C’est ainsi que MAX sait qu’il obtient le nom du client et l’image du contact téléphonique.

• subscriptionTypes : Ceci est un tableau obligatoire de chaînes. Il n’est pas sensible à la casse, car tout le contenu du tableau sera normalisé en minuscule. Les valeurs du tableau sont additives. Chaque option spécifie un type de message que vous recevrez. Il existe quelques entrées valides possibles :

  Valeur d'entrée	Résultat
  "all"	Cela retournera tout.
  "agent"	Cela renverra tout ce qui n'a pas d'identifiant de contact.
  "contact"	Cela renverra des événements limités soit par l'ID de contact demandé, soit par l'ID de contact pour le panneau associé si l'IFrame est connecté à une compétence ou à un contact.
  "contacts"	Cela renverra tous les événements qui ont un ID de contact. Si vous êtes dans un panneau de contacts et souhaitez des informations supplémentaires sur le contact du panneau, ajoutez ce champ.
  "sessioninfo"	Cela renverra le jeton de session d'un agent. Si vous souhaitez effectuer des appels API spécifiques à une session d’agent, inscrivez-vous à cet événement.

Lorsque MAX reçoit l'abonnement, avec le message d'accusé de réception, nous enverrons les états actuels des types d'abonnement demandés pour aider à configurer correctement l'espace de travail. Ces événements sont garantis au départ.

Valeur d'entrée	États actuels
"all"	Renvoie l'AgentState (l'état actuel de l'agent) et tous les contacts actuels qui sont dans le champ d'application de MAX.
"agent"	Retournera l'AgentState actuel. Cela n'inclut pas le jeton de session de l'agent.
"contact"	Renvoie l'état actuel du contact si le contact existe dans le cadre de MAX.
"contacts"	Renvoie tous les contacts actuels qui existent dans le cadre de MAX.

Il est possible que l'enregistrement reçoive parfois plus que l'AgentState de base et contacts à l'initialisation. Ces événements peuvent inclure AgentLegEvent, AgentSessionStart et MchAgentSettingsChangeEvent. Vous verrez ces événements supplémentaires si votre demande d'abonnement arrive avant que nous ayons établi nos références locales à ces données. Si cela se produit, nous stockerons et passerons en revue tous les événements envoyés à MAX via l'événement get-next-event comme vous le feriez normalement pendant l'utilisation. La seule différence est que nous ne sommes pas en mesure de sélectionner les événements principaux sélectionnés pour une initialisation de base. Les mêmes filtres s'appliqueront aux données pour lesquelles vous êtes enregistré, ainsi aucun résultat anormal ne devrait en découler.

Commandes d'appel

Si MAX est dans un état valide pour accepter la commande donnée, il appellera cette action dans l'application. Ces commandes s'alignent étroitement avec les boutons principaux utilisés pour la gestion des contacts. Elles ne renvoient pas de messages.

Valeur d'entrée	Résultat
AnswerEvent et RefuseEvent	A lieu lorsqu'il y a un appel entrant affichant la boîte de dialogue d'acceptation / de rejet.
HoldEvent, MuteEvent et MaskEvent	Traités comme des touches à bascule. Par exemple, appelez Hold une fois et l'appel est mis en attente, appelez-le à nouveau et l'appel est rétabli.
RecordEvent	Une action ponctuelle. Par exemple, une fois Record est appelé, il ne peut pas être arrêté.
HangupEvent	L'appel est immédiatement terminé sans boîte de dialogue de confirmation.

Exemple d'appel (seul messageType nécessaire)

opener.postMessage({ messageType: 'MuteEvent' }, '');*

Exemple d'implémentation

// Trouver la fenêtre parente (MAX) à enregistrer pour les événements

var opener = window.opener || window.parent;

// Configurez vos abonnements

var subscriptionTypes = ['agent', 'contacts'];

 

// Commencer à écouter les messages de réponse

var doSomething = function (events) {

spacevar event = null;

space var eventIndex = null;

space for(eventIndex in events){

Space space if (events.hasOwnProperty(eventIndex)){

spacespacespaceevent = events[eventIndex];

Space space }

space }

};

var listenForPostMessage = function (event) {

if (event.data && event.data.events && event.data.issuer === 'MAX') {

logToConsole('=== a reçu un message avec [' + event.data.events.length + '] events ===');

doSomething(event.data.events);

}

};

// Ajoute l'écouteur pour les événements clients MAX.

window.addEventListener('message', listenForPostMessage);

// Envoyer le message d'inscription à MAX

opener.postMessage({ contactId: contactId, issuer: 'MyTestSite', messageType: 'Register-ForClientEvents', subscriptionTypes: subscriptionTypes }, '*');

L'objet de réponse

L'OBJET DE RÉPONSE (THE RESPONSE OBJECT)

{

issuer: 'MAX',

contactId: int (Nullable) - l'ID de contact qui a été trouvé comme panneau persistant ou qui a été transmis. Il sera nul si aucun contactId n'a été transmis ou trouvé.

events: [objet, objet, objet ...] - Tous les événements renvoyés dans cet ensemble d'événements qui correspondent aux types d'abonnement ou au filtre de contact.

}

Réponse pour la forme du message de l'abonnement "SessionInfo":

{

messageType: "SessionInfo"

sessionToken: "mysessiontoken=="

}

L'ÉVÉNEMENT DE RECONNAISSANCE D'ABONNEMENT

S'il y a au moins un subscriptionType, l'abonnement est autorisé. S'il n'y a pas de subscriptionType valide, un avertissement de la console indiquant le type non valide est consigné. Le premier événement de l'ensemble des événements renvoyés sera un événement du type de message ClientEventSubscriptionAcknowledge. Cet événement a la structure suivante :

{

contactId: (int) - Si null, cela signifie qu'aucun contactId n'est associé à l'abonnement. Cela permet au client de voir si son abonnement « contact » a fonctionné.

messageType: ClientEventSubscriptionAcknowledge - (chaîne). C'est leur type de message d'événement d'accusé de réception spécifique.

reason: "Succès" | "Id de contact non valide" | "Types d'abonnement non valides" - S'il répond avec la raison du code d'état ERREUR. Ce ne sera pas très détaillé pour ne pas ajouter trop de complexité. Il ne retouternera qu'une raison d'échec. Nous vérifions d'abord la validité de l'ID de contact (pas ZERO ou une chaîne non entière). Si cela échoue mais qu'il existe également des types d'abonnement non valides, nous ne montrerons pas les erreurs d'abonnement tant qu'ils n'auront pas réessayé après avoir corrigé l'ID du contact. Cela signifie que nous n'avons pas gardé de référence à la fenêtre, l'abonnement a donc échoué.

status: "OK" ou "ERROR" - Si cela renvoie une erreur, cela signifie que nous n'avons pas réussi à créer la connexion d'abonnement aux messages postés. Ils devront corriger ces erreurs et réessayer.

}

Dans certains cas, aucun accusé de réception d'abonnement n'est envoyé. Lorsque la même fenêtre demande un deuxième abonnement, sans supprimer d'abord l'abonnement existant, aucune réponse ne sera envoyée et aucun autre abonnement ne sera reconnu. Nous allons imprimer un avertissement de console ayant la structure suivante :

{

console.warn('Erreur lors du traitement de l'abonnement client même. Émetteur : [' + subscriberObject.data.issuer + '] est déjà abonné. ')

}