Solución de problemas de inicio de sesión y disponibilidad de agentes en chat empresarial y correo electrónico
Contenido
Introducción
Este documento describe cómo Enterprise Chat and Email (ECE) identifica el estado de disponibilidad del agente cuando los clientes inician sesiones de chat.
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- Correo electrónico y chat empresarial
- Herramientas para desarrolladores de exploradores web
- Unified Intelligent Contact Management Enterprise
Componentes Utilizados
La información contenida en este documento se basa en la versión de software ECE 11.6.
La información de este documento se creó a partir de los dispositivos en un entorno de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration.
Información general funcional
Para que Cisco Unified Intelligent Contact Management Enterprise (ICM) administre las actividades de los agentes y enrute correctamente las tareas, ICM debe supervisar todos los agentes que están conectados a ICM. Las instancias de la aplicación, como CEPE, informan de las actividades del agente y del estado del agente a través de la interfaz ICM CTI/ARM (Agent Report and Management) ampliada.
El servicio ARM se basa en la funcionalidad actual del servidor CTI y permite a una aplicación cliente supervisar los agentes de aplicación y la actividad de tareas. La interfaz ARM permite que una aplicación cliente monitoree un conjunto especificado de agentes (modo estación de trabajo) o todos los agentes (modo puente) asociados a una aplicación.
La imagen muestra más detalles de las interfaces ARM. Una instancia de aplicación utiliza la interfaz ARM para administrar agentes en uno o más PG de agente (conectarlos y desconectarse de medios, etc.) y para informar sobre su actividad de tarea (tarea inicial, tarea final, etc.).
Flujo de inicio de sesión del agente
La disponibilidad del agente se identifica desde el lado del servidor CTI. Cuando un agente inicia sesión en la consola de agente, el proceso de receptor de CEPE envía la solicitud al servidor CTI. La solicitud indica que el agente ha iniciado sesión y se ha marcado como disponible.
Estos son los indicadores que se envían por aplicación ECE al servidor CTI:
Siempre que un agente está conectado, un receptor envía una MEDIA_LOGIN_REQ. MEDIA_LOGIN_REQ registra al agente especificado en un dominio de ruta de medios (MRD) (registra al agente en todas las habilidades configuradas para ese MRD y agente). Cuando un agente se marca como disponible, el receptor envía dos solicitudes más que indican que el agente es ROUTABLE o NO ROUTABLE y PREPARADO o NO PREPARADO, y proporciona información del agente definida por el cliente. El cliente CTI debe haber especificado la ruta de aplicación para el par de periféricos MRD relacionado en el mensaje Open Request o se rechaza el inicio de sesión. Para que el inicio de sesión se realice correctamente, el agente también debe configurarse para que pertenezca al menos a un grupo de habilidades (SG) que pertenezca al MRD indicado.
La imagen muestra el diagrama de flujo de mensajes para la solicitud de inicio de sesión:
Registro del receptor con el nivel de seguimiento 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 <@>
registro CTIsvr con el nivel de seguimiento predeterminado:
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
Estado 0 significa que no se han producido errores en el lado del servidor CTI.
Flujo de disponibilidad del agente
Si el agente está asociado al SG de chat y este SG está asociado a la cola ECE en el punto de entrada de chat, cuando el agente se marca a sí mismo disponible verá 2 solicitudes, MAKE_AGENT_ROUTABLE_IND y MAKE_AGENT_READY_IND.
Make Agent Routable Indication indica al ICM que el agente especificado se ha configurado en modo ROUTABLE para el MRD especificado.
Una vez que el receptor recibe la solicitud de indicación Make Agent Ready del servidor de aplicaciones, el receptor reenvía la solicitud al servidor CTI y en ese momento el agente se considera disponible para ECE. En ese caso, si se inicia el chat al mismo tiempo, el sistema permite iniciar y crear la actividad de chat para ese chat.
El registro del receptor muestra esas solicitudes si el seguimiento de la información está habilitado:
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:
El resultado de los registros de procesos de servidor CTI y 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
Como resultado, el proceso OPC quita al agente del estado AS_NOT_READY y lo pone al estado AS_NOT_ACTIVE. NewState=AS_NOT_ACTIVE es en realidad el estado Preparado para el chat/correo electrónico.
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
En este momento, el agente es enrutable y disponible desde la perspectiva del router. La mejor manera de verificar esto es usar la utilidad 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 -No activo
0:2 - TareasActivas:LímiteTareaConcurrente
RA - R es enrutable (si se establece), A indica que el router considera que el agente está disponible para un nuevo trabajo en este dominio
Además, puede comprobar el estado del agente desde las utilidades OPCtest y Agent PG procmon.
Examples:
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
Donde 5000 es ID de periférico donde se crea el agente, y 15003 es el número de periférico del agente.
Disponibilidad necesaria en el punto de entrada del chat
En las inicializaciones de chat, los clientes pueden ver el mensaje "Gracias por su consulta. Nuestro horario de servicio es de 9:00 a 17:00 PST, de lunes a viernes". Este mensaje puede aparecer incluso cuando hay un agente en estado Preparado para un chat. Para identificar la disponibilidad del agente, el sistema envía la llamada API cuando los clientes ejecutan la URL del punto de entrada. La solicitud de API pasa a través del servidor Web ECE al servidor de aplicaciones ECE. Esta disponibilidad viene determinada por las sesiones creadas en el servidor de aplicaciones.
En ECE 11.6, Availability Require examina la disponibilidad de MRD y si hay algún agente disponible en MRD, entonces Chat está disponible. El problema aquí es que si tiene 2 SG en CHAT MRD, entonces si hay un agente disponible en uno de los SG, su MRD se activará y se ofrecerá CHAT. Este problema se resuelve en ECE 12.0 y versiones posteriores. La mejora se realizó mediante el uso del SG en la configuración. En ese caso, el sistema también cuenta los grupos de habilidades de los agentes que se marcan a sí mismos disponibles para el MRD específico.
Solicitud de API:
http://<ECE_WEB_Server_IP>/system/egain/chat/entrypoint/inicializar/1001
donde 1001 es el ID del punto de entrada.
Respuesta de 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}
Hay dos opciones para cómo el sistema define que el agente está disponible. El agente está disponible para un chat o hay una profundidad de cola que permite hacerlo. La configuración de profundidad de cola permite el número de clientes que se pueden poner en cola cuando todos los agentes están ocupados.
En la respuesta de la API, preste atención a CheckEligibility: responseType. Indica qué es una disponibilidad de agente en ese momento.
- Si llega como 0, significa que hay un agente disponible para tomar el chat o que no se alcanza la profundidad de la cola.
- Si es 1, indica que no hay agentes disponibles.
- 2 significa que se ha alcanzado la profundidad máxima de la cola.
Si un agente está disponible, el explorador web recibe los demás archivos .js. Como resultado, un cliente ve la página inicial con el nombre de inicio de sesión y los parámetros de asunto para el punto de entrada.
Recopilación de registros
Las respuestas de la API están disponibles desde el lado del cliente (desde el seguimiento de la red del navegador web) o desde el servidor de aplicaciones ECE con nivel de depuración o seguimiento que no se recomienda conservar durante mucho tiempo debido a la E/S alta que se consume.
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)