Dépannage de la connexion et de la disponibilité des agents dans la conversation et la messagerie électronique d'entreprise

Introduction

Ce document décrit comment Enterprise Chat and Email(ECE) identifie l'état de disponibilité de l'agent lorsque les clients lancent des sessions de discussion.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Clavardage et messagerie pour entreprises
• Outils de développement des navigateurs Web
• Unified Intelligent Contact Management Enterprise

Components Used

Les informations contenues dans ce document sont basées sur la version logicielle ECE 11.6.

Les informations de ce document ont été créées à partir des périphériques d'un environnement de travaux pratiques spécifique. All of the devices used in this document started with a cleared (default) configuration. 

Présentation fonctionnelle

Pour que Cisco Unified Intelligent Contact Management Enterprise (ICM) gère les activités des agents et achemine correctement les tâches, ICM doit surveiller tous les agents connectés à ICM. Les instances d'application, comme ECE, signalent les activités et l'état des agents via l'interface CTI/ARM ICM étendue (Agent Report and Management).

Le service ARM repose sur la fonctionnalité CTI Server actuelle et permet à une application cliente de surveiller les agents d'application et l'activité des tâches. L'interface ARM permet à une application cliente de surveiller un ensemble spécifié d'agents (mode station de travail) ou tous les agents (mode pont) associés à une application.

L'image montre plus de détails sur les interfaces ARM.  Une instance d'application utilise l'interface ARM pour gérer les agents sur un ou plusieurs groupes de terminaux d'agent (les connecter et les déconnecter du support, etc.) et pour générer des rapports sur leur activité de tâche (Tâche de début, Tâche de fin, etc.). 

Flux de connexion de l'agent

La disponibilité de l'agent est identifiée du côté du serveur CTI. Lorsqu'un agent se connecte à la console de l'agent, le processus d'écoute ECE envoie la demande au serveur CTI. La demande indique que l'agent est connecté et qu'il s'est marqué comme disponible.

Voici les indicateurs qui sont envoyés par l'application CEE au serveur CTI :

Chaque fois qu'un agent est connecté, un écouteur envoie un MEDIA_LOGIN_REQ. MEDIA_LOGIN_REQ connecte l'agent spécifié à un domaine de routage média (MRD) (connecte l'agent à toutes les compétences configurées pour ce MRD et cet agent). Lorsqu'un agent se marque comme étant disponible, l'écouteur envoie deux autres requêtes indiquant que l'agent est ROUTABLE ou NON ROUTABLE et PRÊT ou NON PRÊT, et fournit des informations d'agent définies par le client. Le client CTI doit avoir spécifié le chemin d'application pour la paire de périphériques MRD associée dans le message de demande ouverte ou la connexion est rejetée. Pour que la connexion réussisse, l'agent doit également être configuré pour appartenir à au moins un groupe de compétences (SG) appartenant au MRD indiqué.

L'image montre le diagramme de flux des messages pour la demande de connexion :

Journal de l'écouteur avec le niveau de trace INFO :

2019-07-20 18:27:31.749 GMT+0000 <@> INFO <@> [14285:listener-event-pool-priority-arm-request-executor::-0] <@> ProcessId:4584 
<@> PID:1 <@> UID:1005 <@> HttpSessionId:IrltMMd3T0prrkbhAwK8wkL5 <@> com.ipcc.listener.arm.ARMLogger <@>  
<@> Sending MEDIA_LOGIN_REQ  -> 0 0 0 27 0 0 0 -105 0 2 8 1 0 0 19 -120 0 0 19 -87 0 0 0 0 0 0 0 1 107 5 49 48 48 53 0   <@>


2019-07-20 18:27:32.037 GMT+0000 <@> INFO <@> [71:Thread-9] <@> ProcessId:4584 <@> PID:1 <@> UID:12 <@> HttpSessionId:  
<@> com.ipcc.listener.arm.ARMLogger <@>  <@> Received MEDIA_LOGIN_RESP  ->  0 0 0 8 0 0 0 -104 0 2 8 1 0 0 0 0   <@>

 Journal CTIsvr avec le niveau de suivi par défaut :

20:27:32:466 cg1A-ctisvr Trace: ProcessMediaLoginReq - sessionID 4
20:27:32:466 cg1A-ctisvr Trace: SendARMMsg -- InvokeID = 591309094, MRDID = 5000, ICMAgentID = 5033, AgentMode = 0
IsAvailable = 0, MaxTaskLimit = 1, AgentInfo = 1005, ApplicationPathID = 5001, PeripheralID = 0, AgentID =
20:27:32:607 cg1A-ctisvr Trace: ProcessARMMediaLoginRespMsg -- InvokeID = 591309094, Status = 0, AgentSkillTargetID = 5033

Status 0 signifie qu'aucune erreur n'a été détectée du côté du serveur CTI.

Flux de disponibilité des agents

Si l'agent est associé au SG de conversation et que ce SG est associé à la file d'attente CEE dans le point d'entrée de conversation, lorsque l'agent se marque disponible, vous voyez 2 demandes, MAKE_AGENT_ROUTABLE_IND et MAKE_AGENT_READY_IND.

L'indication Routable Agent indique à ICM que l'agent spécifié a été défini sur un mode ROUTABLE pour le MRD spécifié.

Note: Le message d'indication Routable de l'agent peut être envoyé pendant qu'il attend une réponse Routable de l'agent et annule la demande Routable de l'agent en attente.

Une fois que la demande Make Agent Ready Indication est reçue par l'écouteur à partir du serveur d'applications, l'écouteur transmet la demande au serveur CTI et, à ce moment, l'agent considéré comme disponible pour ECE. Dans ce cas, si le chat est lancé en même temps, le système permet de démarrer et de créer l'activité de chat pour ce chat.

Le journal de l'écouteur affiche ces demandes si la trace INFO est activée : 

2019-08-19 13:34:09.773 GMT+0000 <@> INFO <@> [8938:listener-event-pool-priority-arm-request-executor::-441] <@> ProcessId:5436 <@> PID:1 <@> UID:12 <@> HttpSessionId: <@> com.ipcc.listener.AgentAvailabilityStatusHandler <@> <@> AgentAvailabilityStatusHandler:agentIsAvailable() MAKE_AGENT_ROUTABLE_IND to ARM armLoginDataArraySize= ARMAgentData ==================================================================
2019-08-19 13:34:09.773 GMT+0000 <@> INFO <@> [8938:listener-event-pool-priority-arm-request-executor::-441] <@> ProcessId:5436 <@> PID:1 <@> UID:12 <@> HttpSessionId: <@> com.ipcc.listener.arm.ARMLogger <@> <@> Sending MAKE_AGENT_ROUTABLE_IND -> 0 0 0 16 0 0 0 -102 0 1 57 43 0 0 19 -120 0 0 25 20 0 0 0 2 <@>
2019-08-19 13:34:09.774 GMT+0000 <@> INFO <@> [8938:listener-event-pool-priority-arm-request-executor::-441] <@> ProcessId:5436 <@> PID:1 <@> UID:12 <@> HttpSessionId: <@> com.ipcc.listener.arm.ARMLogger <@> <@> Sending MAKE_AGENT_READY_IND -> 0 0 0 14 0 0 0 -99 0 1 57 44 0 0 19 -120 0 0 25 20 0 1 <@>
2019-08-19 13:34:09.774 GMT+0000 <@> INFO <@> [8938:listener-event-pool-priority-arm-request-executor::-441] <@> ProcessId:5436 <@> PID:1 <@> UID:12 <@> HttpSessionId: <@> com.ipcc.listener.AgentAvailabilityStatusHandler <@> <@> PRINT_STATE after sending MAKE_AGENT_READY_IND to ARM:

Le résultat des journaux des processus CTI Server et OPC :

### CTI Server
15:34:09:841 cg1A-ctisvr Trace: ProcessMakeAgentRoutableInd - sessionID 6
15:34:09:841 cg1A-ctisvr Trace: SendARMMsg -- InvokeID = 80171, MRDID = 5000, ICMAgentID = 6420, MaxTasks = 2, SessionID = 6
15:34:09:841 cg1A-ctisvr Trace: ProcessMakeAgentReadyInd - sessionID 6
15:34:09:841 cg1A-ctisvr Trace: SendARMMsg -- InvokeID = 80172, MRDID = 5000, ICMAgentID = 6420, MakeRoutable = 1, SessionID = 6

### OPC
15:34:09:841 PG1A-opc Trace: MakeAgentRoutableInd - InvokeID = 80171, MRDID = 5000, ICMAgentID = 6420, MaxTasks = 2, SessionID = 6
15:34:09:841 PG1A-opc Trace: MakeAgentReadyInd - InvokeID = 80172, MRDID = 5000, ICMAgentID = 6420, MakeRoutable = 1, SessionID = 6

En conséquence, le processus OPC supprime l'agent de l'état AS_NOT_READY et passe à l'état AS_NOT_ACTIVE. NewState=AS_NOT_ACTIVE est en fait l'état Prêt pour la conversation/l'e-mail.

15:34:09:841 PG1A-opc Trace: SetAgentState: ASTID=6420 Periph#=15003 MRDomainID=5000 SGSTID=6928 SG#=70518(0x11376) OldState=AS_NOT_READY NewState=AS_NOT_ACTIVE Duration=0 CurLine=-1 ReasonCode=0 AgentObj=0x44535b8

À ce stade, l'agent est routable et disponible du point de vue du routeur. La meilleure façon de vérifier ceci est d'utiliser l'utilitaire rttest :

rttest: agent_status /agent 6420

### 6520 is ICMAgtID

Agent CUCM.Agent_test (6420, periph# 15003)

  domain: Cisco_Voice (1), state = [nr-0:1,R], 411 secs

    CL nr   TEST_SG (6274, periph# 70520)

     L nr   CUCM_PIM1.Cisco_Voice.defa.88025 (5000, periph# 31858)

  domain: ECE_Chat (5000), state = [na-0:2,RA], 383 secs

    CL na   TEST_Chat (6928, periph# 70518)

     L na   CUCM.ECE_Chat.default.11006 (6909, periph# 54839)

na - NonActif

0:2 - TâchesAcites : LimiteTâchesConcurrentes

RA - R est routable (si défini), A indique que le routeur considère l'agent disponible pour de nouveaux travaux dans ce domaine

Attention : Dans ICM 11.5, 11.6 et 12.0, vous pouvez frapper le défaut CSCvq11852 Chat et les e-mails ne sont pas affectés aux agents même s'ils sont disponibles. Dans de tels scénarios, vous voyez dans la sortie du test [na-0:2, RD], où D signifie domaine indisponible (tel que signalé par le chemin d'application).

Au-delà de cela, vous pouvez vérifier l'état de l'agent à partir des utilitaires de procmon OPCtest et Agent PG.

Exemples:

opctest /cust <inst> /node PG1A

opctest: dump_agent 5000 15003


C:\icm\pcc12\ra\logfiles>procmon <inst> PG1A pim1
11:38:40 Trace: EMT Creating Mutex Global\IMTConnect_DisconnectLock
>>>>dagent 15003

Où 5000 est l'ID de périphérique où l'agent est créé, et 15003 est le numéro de périphérique de l'agent.

Disponibilité requise dans le point d'entrée de conversation

Dans les initialisations de chat, vos clients peuvent voir le message « Merci pour votre demande. Nos heures de service sont de 9h à 17h (heure normale du Pacifique), du lundi au vendredi. » Un tel message peut s'afficher même lorsqu'un agent est à l'état Prêt pour une conversation. Pour identifier la disponibilité de l'agent, le système envoie l'appel API lorsque les clients exécutent l'URL du point d'entrée. La demande d'API passe par le serveur Web de la CEE au serveur d'applications de la CEE. Cette disponibilité est déterminée par les sessions créées sur le serveur d'applications.

Dans la section ECE 11.6, l'option Disponibilité requise examine la disponibilité du MRD et, s'il existe un agent disponible dans le MRD, la conversation est disponible. Le problème ici est que si vous avez 2 SG dans CHAT MRD, alors s'il y a un agent disponible dans l'un des SG, votre MRD devient actif et CHAT est offert. Ce problème est résolu dans les versions CEE 12.0 et ultérieures. L'amélioration a été réalisée par l'utilisation du SG dans la configuration. Dans ce cas, le système comptabilise également les groupes de compétences des agents qui se marquent disponibles pour le MRD spécifique.

Requête API :

http://<ECE_WEB_Server_IP>/system/egain/chat/entrypoint/initialize/1001

où 1001 est l'ID de point d'entrée.

Réponse de l'API :

{"checkEligibility":{"responseType":0},"maskingPatterns":{"maskingPattern":[]},"isVideoChatLicensed":false,"isVideoChatEnabled":false,"videoChatMaxEscalation":5,"isDirectAudioChatEnabled":true,"isChatAttachmentEnabled":false,"maxChatAttachmentSize":3,"isBlackListType":false,"isOffRecordEnabled":false,"htmlTagMatcherRegEx":"((?:[\\r\\n|\\n]*(?:<[^>]*>)*[\\r\\n|\\n]*)*)","htmlTagMatcherIncr":1,"isOneTagOff":true}

Il existe deux options permettant de définir la disponibilité de l'agent par le système. Soit l'agent est disponible pour une discussion, soit il y a une Profondeur de file d'attente qui permet de faire ceci. La configuration de la profondeur de la file d'attente permet le nombre de clients qui peuvent être mis en file d'attente lorsque tous les agents sont occupés.

Dans la réponse de l'API, prêtez attention à checkEligibility : valeur responseType. Il indique la disponibilité d'un agent à ce moment-là.

• S'il s'agit de 0, cela signifie que l'agent est disponible pour prendre la conversation ou que la profondeur de la file d'attente n'est pas atteinte.
• S'il est 1, il indique qu'il n'y a aucun agent disponible.
• 2 signifie que la profondeur maximale de la file d'attente a été atteinte.

Note: Il n'y a aucune option ici pour voir combien d'agents sont disponibles à l'heure spécifique.

Si un agent est disponible, les autres fichiers .js sont reçus par le navigateur Web. Par conséquent, un client voit la page initiale avec le nom de connexion et les paramètres d'objet du point d'entrée.

Collecte de journaux

Les réponses de l'API sont disponibles soit du côté client (à partir du navigateur Web Network trace), soit du serveur d'applications CEE avec le niveau de débogage ou de trace qui n'est pas recommandé pour longtemps en raison de l'E/S élevée consommée.