Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Panoramica funzionale

Flusso di accesso agente

Flusso di disponibilità dell'agente

Disponibilità richiesta in punto di ingresso chat

Raccolta log

Introduzione

In questo documento viene descritto come Enterprise Chat and Email(ECE) identifica lo stato di disponibilità dell'agente quando i client avviano sessioni di chat.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

- Enterprise Chat and Email

- Web browser Strumenti di sviluppo

- Gestione intelligente dei contatti unificata Enterprise

Componenti usati

Le informazioni fornite in questo documento si basano sulla versione software ECE 11.6.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti.

Panoramica funzionale

Affinché Cisco Unified Intelligent Contact Management Enterprise (ICM) possa gestire le attività dell'agente e instradare correttamente le attività, ICM deve monitorare tutti gli agenti collegati a ICM. Le istanze dell'applicazione, come ECE, segnalano le attività dell'agente e lo stato dell'agente tramite l'interfaccia ICM CTI/ARM (Agent Report and Management) estesa.

Il servizio ARM è basato sulle funzionalità correnti del server CTI e consente a un'applicazione client di monitorare gli agenti dell'applicazione e l'attività. L'interfaccia ARM consente a un'applicazione client di monitorare un insieme specifico di agenti (modalità workstation) o tutti gli agenti (modalità bridge) associati a un'applicazione.

L'immagine mostra ulteriori dettagli delle interfacce ARM.  Un'istanza dell'applicazione utilizza l'interfaccia ARM per gestire gli agenti su uno o più PG agente (collegarli e disconnettere i supporti, ecc.) e per creare un report sulla loro attività (Inizio operazione, Fine operazione, ecc.).

Flusso di accesso agente

La disponibilità dell'agente è identificata dal lato server CTI. Quando un agente accede alla console dell'agente, il processo Listener ECE invia la richiesta al server CTI. La richiesta indica che l'agente è connesso e si è contrassegnato come disponibile.

Questi sono gli indicatori inviati dall'applicazione ECE al server CTI:

Ogni volta che un agente è connesso, un listener invia un MEDIA_LOGIN_REQ. MEDIA_LOGIN_REQ registra l'agente specificato in un Media Route Domain (MRD) (registra l'agente in tutte le abilità configurate per tale MRD e agente). Quando un agente contrassegna se stesso come disponibile, il listener invia altre due richieste che indicano che l'agente è ROUTABLE o NOT ROUTABLE e READY o NOT READY e fornisce informazioni sull'agente definite dal client. Il client CTI deve aver specificato il percorso dell'applicazione per la coppia di periferiche MRD correlata nel messaggio di richiesta di apertura o l'accesso viene rifiutato. Affinché l'accesso riesca, l'agente deve inoltre essere configurato in modo da appartenere ad almeno un gruppo di competenze che appartiene all'MRD indicato.

Nell'immagine è illustrato il diagramma di flusso dei messaggi per la richiesta di accesso:

Log del listener con il livello di traccia 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 il livello di traccia predefinito:

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

Lo stato 0 indica che non si sono verificati errori dal lato server CTI.

Flusso di disponibilità dell'agente

Se l'agente è associato al gruppo di sicurezza della chat e questo gruppo di sicurezza è associato alla coda ECE nel punto di ingresso della chat, quando l'agente contrassegna se stesso come disponibile verranno visualizzate due richieste, MAKE_AGENT_ROUTABLE_IND e MAKE_AGENT_READY_IND.

Make Agent Routable Indication indica a ICM che l'agente specificato è stato impostato su una modalità ROUTABLE per l'MRD specificato.

Nota: È possibile inviare il messaggio Make Agent Routable Indication mentre attende una risposta Make Agent Not Routable e annulla la richiesta Make Agent Not Routable in sospeso.

Una volta che la richiesta di creazione di un'indicazione pronta per l'agente viene ricevuta dal listener dal server applicazioni, il listener inoltra la richiesta al server CTI e in quel momento l'agente considerato disponibile per ECE. In tal caso, se la chat viene avviata contemporaneamente, il sistema consente di avviare e crea l'attività di chat per quella chat.

Il log del listener mostra queste richieste se la traccia INFO è abilitata:

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:

L'output dei registri dei processi CTI Server e OPC è il seguente:

### 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

Di conseguenza, il processo OPC rimuove l'agente dallo stato AS_NOT_READY e imposta lo stato AS_NOT_ACTIVE. NewState=AS_NOT_ACTIVE è in realtà lo stato Ready per Chat/Email.

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

Al momento, l'agente è instradabile e disponibile dal punto di vista del router. Il modo migliore per verificare questa condizione consiste nell'utilizzare l'utilità 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 - NonAttivo

0:2 - AttivitàAcite:LimiteAttivitàConcorrente

RA - R è instradabile (se impostato), A indica che il router considera l'agente disponibile per le nuove operazioni in questo dominio

Attenzione: In ICM 11.5, 11.6 e 12.0 si può colpire il difetto CSCvq11852 Chat ed email non vengono assegnati agli agenti anche se sono disponibili. In tali scenari è possibile vedere nell'output del test rttest [na-0:2,RD], dove D indica che il dominio non è disponibile (come riportato dal percorso dell'app).

Oltre a ciò, è possibile controllare lo stato dell'agente dalle utilità OPCtest e Agent PG procmon.

Esempi:

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

Dove 5000 è l'ID periferica in cui viene creato l'agente e 15003 è l'ID periferica dell'agente.

Disponibilità richiesta in punto di ingresso chat

Nelle inizializzazioni di chat, i client possono visualizzare il messaggio "Grazie per la richiesta. I nostri orari di assistenza sono dalle 9:00 alle 17:00 PST, dal lunedì al venerdì". Questo messaggio può essere visualizzato anche quando è presente un agente in stato Pronto per una chat. Per identificare la disponibilità dell'agente, il sistema invia la chiamata API quando i client eseguono l'URL del punto di ingresso. La richiesta API passa dal server Web ECE al server applicazioni ECE. Questa disponibilità è determinata dalle sessioni create sul server applicazioni.

In ECE 11.6 il requisito di disponibilità esamina la disponibilità di MRD e se in MRD è disponibile un agente, allora è disponibile Chat. Il problema è che se in CHAT MRD si dispone di 2 SG, se in uno degli SG è disponibile un agente, il MRD diventa attivo e viene offerta la CHAT. Questo problema è stato risolto in ECE 12.0 e versioni successive. Il miglioramento è stato ottenuto utilizzando il gruppo di disponibilità nella configurazione. In tal caso, il sistema conta anche i gruppi di competenze per gli agenti che si dichiarano disponibili per lo specifico MRD.

Richiesta API:

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

dove 1001 è l'ID del punto di ingresso.

Risposta 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}

Sono disponibili due opzioni per definire la disponibilità dell'agente. L'agente è disponibile per una chat oppure è disponibile una profondità di coda che consente di eseguire questa operazione. La configurazione della profondità della coda consente di specificare il numero di clienti che possono essere accodati quando tutti gli agenti sono occupati.

Nella risposta API prestare attenzione a checkEligibility: valore responseType. Indica la disponibilità di un agente in quel momento.

- Se ha valore 0, significa che l'agente è disponibile per la chat oppure che non è stata raggiunta la profondità della coda.

- Se è 1, indica che non sono disponibili agenti.

- 2 indica che è stata raggiunta la profondità massima della coda.

Nota: Non sono disponibili opzioni per verificare il numero di agenti disponibili in un determinato momento.

Se è disponibile un agente, gli altri file js vengono ricevuti dal browser Web. Di conseguenza, un client non visualizza la pagina iniziale con il nome di accesso e i parametri dell'oggetto per il punto di ingresso.

Raccolta log

Le risposte API sono disponibili dal lato client (dal browser Web Network trace) o dal server applicazioni ECE con livello di debug o traccia che non è consigliabile mantenere per molto tempo a causa dell'I/O elevato utilizzato.