Configuraciones útiles de la traza para la herramienta de la readaptación del Cisco Unified Contact Center Enterprise

Introducción

 Este documento describe algunas configuraciones útiles de la traza para la herramienta unificada de la readaptación de Enterprise(UCCE) del Centro de contacto para las versiones UCCE antes de la versión 11.x que ayuda a señalar donde encontrar la información el mirar a las preguntas siguientes.  

P..

1. ¿Cuándo la readaptación sucedió?
2. ¿Quién (es decir que cuenta del supervisor) hizo la readaptación?
3. ¿Qué el supervisor hizo? es decir. ¿Agregaron/quitaron a qué grupos de capacidades de qué agentes?
4. ¿Dónde o que el PC fue utilizado por el supervisor determinado?

R.

Para recopilar este la información, las trazas de siguiente deben ser habilitadas:
1. CMSNode
Comience el regedit del menú Start (Inicio) de Windows, después navegue al HKLM \ al SOFTWARE \ a Cisco Systems, Inc. \ ICM \ <instance> \ distribuidor \ EMS \ CurrentVersion \ biblioteca \ procesos \ CMS \ EMSTraceMask y fije el valor al FF.
Para recoger los registros, utilice el dis del <instance> del cdlog de la línea de comando de la ventana y del tipo donde significa distribuidor del dis y CMS /last /of cms.log del dumplog del funcionamiento

2. Aplicación de la readaptación
Navegue a \ icm \ tomcat \ webapps \ uiroot \ WEB-INF \ propiedades \ campo común \ apiserver \ logManager \ APIServer.properties y el enablelogging modificando el verbosity=LOCAL_DUMP (cerca de la parte inferior del archivo). El registro predeterminado es (apagado) verbosity=VERBOSITY_NONE.
Desde
    APIServer.TraceFilter.localTraceFilter.className=com.cisco.ics.util.log.trace.WLTraceMessageFilter
    APIServer.TraceFilter.localTraceFilter.verbosity=VERBOSITY_NONE
A
   APIServer.TraceFilter.localTraceFilter.className=com.cisco.ics.util.log.trace.WLTraceMessageFilter
   APIServer.TraceFilter.localTraceFilter.verbosity=LOCAL_DUMP

Recoja los registros siguientes después de que el problema se haya reproducido de C:\icm\tomcat\webapps\uiroot\WEB - INF \ los registros \ *

3. Apache Tomcat
Paso 1. Sostenga el archivo C:\icm\tomcat\conf\server.xml a otra carpeta
Paso 2. Pare el servicio de Apache Tomcat de los servicios de Windows

Paso 3. Modifique el archivo \ icm \ tomcat \ conf \ server.xml agregando la parte resaltada:

  appBase= " webapps” del " localhost” del name= del <Host
  ” autoDeploy= verdadero " del unpackWARs= " verdad”
  ” xmlNamespaceAware= falso " del xmlValidation= " falso " >

  el className= " org.apache.catalina.valves.AccessLogValve” del <Valve directory= " registra” localhost_access_log del prefix= el ". pattern= resolveHosts= " común”/> " falso” del .txt” del “suffix=”
 </Host>

Paso 4. Comience el servicio de Tomcat
Recoja el comienzo de los archivos con de localhost_access_log.2014-02-14.txt bajo \ icm \ tomcat \ registros \

Ahora, déjenos vuelven a esas preguntas que fueron planteadas al principio.

Pregunta 1. ¿Cuándo la readaptación sucedió?
Usted ve las actividades en el registro de CMSNode o el log de aplicaciones de la readaptación. 

Registros de la muestra:
----------Registros de CMSNode----------
traza de 11:26:44:208 dis-CMS: [2014/06/16 12:26:44] [ProcessID=5236, proceso ThreadID=5524] 8 DIAG-TRACE (42071): Transportador - PREM recibido - [BLOCK-START][REM-START]"2014-6-16-11-26-44""300000""192.168.250.63:87999af:14506964d71:-8000""192.168.250.63:-59aa96ef:146a1f65ce4:-7ff4""6""4""0""""""IPCCAdmin""2""175""0""1584"""[REM-END][STATUS-START]"2014-6-16-11-26-44""0""""""""0""0""0""0""0""0""0""""""""0"""[STATUS-END][VECTOR-START][TABLE-START]"Skill_Group_Member"[COLUMN-START]"SkillGroupSkillTargetID""AgentSkillTargetID"[COLUMN-END][ROW-START]"-1""2""0""5004""5001"[ROW-END][TABLE-END][VECTOR-END][BLOCK-END] CMSSVR.DLL E:\Jenkins\workspace\SHARED _ICM \ icm \ AW \ CMS \ línea #523 de CmsSvr \ cmssvr.cpp

Búsqueda IPCCAdmin en los registros de CMS. Vemos que la aplicación de IPCCAdmin que es la herramienta de la readaptación tenía una actividad en 11:26:44. Vemos la misma actividad en el log de aplicaciones de la readaptación también con el mismo grupo fecha/hora. Búsqueda ipccAdmin.reskill.saveAgent

----------Log de aplicaciones de la readaptación----------
06/16/2014 TRAZA LOCAL_DUMP “servlet com.cisco.ics.inf.servlet.UIServlet” com.cisco.ics.inf.servlet.UIServlet UIServlet.service "UIServlet_13 de 11:26:44.195: start=1402882004194SID=24tlnjkq30 req SD = de la falta de información =

"" ipccAdmin.reskill.saveAgent” - Petición del servlet HTTP para el URL: http://192.168.250.63/uiroot/uicommander
Parámetros:
personChangeStamp = 1
lastName = uno
agentChangeStamp = 4
loginEnabled = verdad
useDBListCachedParams = falso
cree = falso
agentID = 1001
agentTeamID = Team1
descripción =
skgIDList = 5004
el deskSetting = ADS_Default
SkillGroupsEditListInput = 5004
firstName = agent1
req = ipccAdmin.reskill.saveAgent
clave = 5001
supervisorAgent = falso
loginName = agent1

Pregunta 2. ¿Quién (que cuenta del supervisor) hizo la readaptación?
Esto se puede ver solamente en el log de aplicaciones de la readaptación. Aquí está un snippet del registro de la muestra.

06/16/2014 TRAZA CLASS_DUMP “envío” com.cisco.ics.inf.uiserver.APIServer APIServer.dispatchCommand "UIServlet_15 de 11:44:04.846 del comando: start=1402883044845SID=24tlnjkq30 req SD = del valor por defecto = "" ipccAdmin.reskill.loginSupervisor” - comando dump: mensaje: name= ipccAdmin.reskill.loginSupervisor
<u>MsgProperties para ipccAdmin.reskill.loginSupervisor</u>
<ul>
<li>password (valor suprimido)
<li>name = supervisor1
<li>req = ipccAdmin.reskill.loginSupervisor
<li>svcDomain = valor por defecto
<li>loginByAgentID = falso
</ul>

La búsqueda ipccAdmin.reskill.loginSupervisor y nosotros considera que era supervisor1 que hizo la readaptación.

Pregunta 3. ¿Qué el supervisor hizo? es decir. ¿Agregaron/quitaron a qué grupos de capacidades de qué agentes?
Podemos conseguir esta información del registro de CMS o del log de aplicaciones de la readaptación. Por ejemplo, aquí está un snippet de los registros de CMS:

traza de 11:26:44:208 dis-CMS: [2014/06/16 12:26:44] [ProcessID=5236, proceso ThreadID=5524] 8 DIAG-TRACE (42071): Transportador - PREM recibido - [BLOCK-START][REM-START]"2014-6-16-11-26-44""300000""192.168.250.63:87999af:14506964d71:-8000""192.168.250.63:-59aa96ef:146a1f65ce4:-7ff4""6""4""0""""""IPCCAdmin""2""175""0""1584"""[REM-END][STATUS-START]"2014-6-16-11-26-44""0""""""""0""0""0""0""0""0""0""""""""0"""[STATUS-END][VECTOR-START][TABLE-START]"Skill_Group_Member"[COLUMN-START]"SkillGroupSkillTargetID""AgentSkillTargetID"[COLUMN-END]

[ROW-START]"-1""2""0""5004""5001"[ROW-END][TABLE-END][VECTOR-END][BLOCK-END] CMSSVR.DLL E:\Jenkins\workspace\SHARED _ICM \ icm \ AW \ CMS \ línea #523 de CmsSvr \ cmssvr.cpp

La información que conseguimos del mensaje arriba resaltado es que la herramienta de la readaptación (IPCCAdmin) intentada para agregar al grupo de capacidades con el SkillTargetID 5004 al agente que tiene SkillTargetID = 5001 (el número 2 en la parte highlighgted indica agrega).

traza de 13:23:52:973 dis-CMS: [2014/06/16 13:23:52] [ProcessID=5236, proceso ThreadID=5524] 8 DIAG-TRACE (42071): Transportador - PREM recibido - [BLOCK-START][REM-START]"2014-6-16-12-23-52""300000""192.168.250.63:87999af:14506964d71:-8000""192.168.250.63:-59aa96ef:146a1f65ce4:-7ff4""8""4""0""""""IPCCAdmin""2""175""0""1584"""[REM-END][STATUS-START]"2014-6-16-12-23-52""0""""""""0""0""0""0""0""0""0""""""""0"""[STATUS-END][VECTOR-START][TABLE-START]"Skill_Group_Member"[COLUMN-START]"SkillGroupSkillTargetID""AgentSkillTargetID"[COLUMN-END]

[ROW-START]"-1""3""0""5004""5002"[ROW-END][TABLE-END][VECTOR-END][BLOCK-END] CMSSVR.DLL E:\Jenkins\workspace\SHARED _ICM \ icm \ AW \ CMS \ línea #523 de CmsSvr \ cmssvr.cpp

Y sobre CMS el mensaje confirma que la herramienta de la readaptación (IPCCAdmin) intentada para borrar al grupo de capacidades con el SkillTargetID 5004 al agente que tiene SkillTargetID = 5002 (el número 3 en la parte highlighgted indica la cancelación).

Del log de aplicaciones de la readaptación, no podemos ver los cambios exactos al perfil del agente pero podemos ver qué grupos de capacidades intenta la herramienta de la readaptación salvar. Por ejemplo:
06/16/2014 TRAZA LOCAL_DUMP “servlet com.cisco.ics.inf.servlet.UIServlet” com.cisco.ics.inf.servlet.UIServlet UIServlet.service "UIServlet_13 de 11:26:44.195: start=1402882004194SID=24tlnjkq30 req SD = de la falta de información = "" ipccAdmin.reskill.saveAgent” - petición del servlet HTTP para el URL: http://192.168.250.63/uiroot/uicommander
Parámetros:
personChangeStamp = 1
lastName = uno
agentChangeStamp = 4
loginEnabled = verdad
useDBListCachedParams = falso
cree = falso
agentID = 1001
agentTeamID = Team1
descripción =

skgIDList = 5004
el deskSetting = ADS_Default
SkillGroupsEditListInput = 5004
firstName = agent1
req = ipccAdmin.reskill.saveAgent
clave = 5001
supervisorAgent = falso
loginName = agent1

En el snippet antedicho del registro, no podríamos ver qué grupos de capacidades perteneció el agente antes de la actividad de la readaptación. Pero, sabemos después de la actividad de la readaptación, el agente nos suponemos para tener grupo de capacidades 5004 asociado a.

Pregunta 4. ¿Dónde o que el PC fue utilizado por un supervisor determinado?
Vemos la dirección IP donde el cliente accedió la aplicación de los registros del acceso de Tomcat. Por ejemplo:

¿192.168.250.101 - - [16/Jun/2014:11:44:02 +1000] “GET /uiroot/uicommander? req=ipccAdmin.reskill.logoutSupervisor el HTTP/1.1" 200 3769

¿192.168.250.101 - - POSTE /uiroot/uicommander [16/Jun/2014:11:44:04 +1000] “? svcDomain=default&req=ipccAdmin.reskill.loginSupervisor el HTTP/1.1" 200 3022

Del mensaje antedicho, vemos que PC del cliente con la dirección IP 192.168.250.101 terminó la sesión y abrió una sesión a la aplicación de la readaptación en 11:44.

En un resumen, con los debugginges antedichos girados, podemos conocer más detalles de las actividades hechas por la herramienta de la readaptación.