&UCCX; SocialMiner: Análise do log da avaliação do bate-papo da bolha e do bate-papo do cargo

(1)

&UCCX; SocialMiner: Análise do log da

avaliação do bate-papo da bolha e do bate-papo

do cargo

Índice

Introdução Logs exigidos

Fluxo do bate-papo da bolha Análise dos logs

Etapa 1. Logs do console do cliente: Clique a conversar.

Etapa 2. Ccppublicapps manutenção programada: Mergulho DB ao mmca_webhook Etapa 3. UCCX MADM: Recebe o pedido para a configuração do Widget.

Etapa 4. Manutenção programada Publicapps:200 ESTÁ BEM na configuração do Widget. Etapa 5. Logs do console do cliente: Resposta ao navegador cliente que mostra detalhes em JSON.

Etapa 6. Manutenção programada Publicapps: Pedido entrante do bate-papo. Etapa 7. Runtime manutenção programada: O contato social é criado.

Etapa 8. Manutenção programada Publicapps: Atualiza o SocialContact criado ao público API. Etapa 9. Runtime manutenção programada: Envia a notificação a CCX Webservice API em MADM.

Etapa 10. UCCX MADM: Webservices mostra o pedido entrante do bate-papo. Etapa 11. UCCX MADM: Envie a mensagem JM ao motor CCX.

Etapa 12. UCCX MIVR:

Etapa 13. Manutenção programada Publicapps: O agente junta-se e a sessão dos bate-papos começou.

Etapa 14. Logs do console do cliente: O agente junta-se ao chat room. Etapa 15. Manutenção programada Publicapps: O usuário sae do chat room.

Etapa 16. Logs do console do cliente: Sucesso da avaliação do bate-papo das mostras do navegador do usuário.

Etapa 17. Manutenção programada Publicapps: os ccppublicapps recebem a avaliação do bate-papo do cargo do navegador.

Etapa 18. UCCX MIVR: Atualização XMPP recebida da manutenção programada. Etapa 19. UCCX MIVR: Escreva o bate-papo que avalia ao base de dados.

Introdução

Este original descreve o fluxo do bate-papo da bolha junto com a análise fim-a-fim do log para um bate-papo de trabalho da bolha, que possa ser usado como uma referência de trabalho para pesquisar defeitos as edições.

A solução expressa unificada do Contact Center (UCCX) com a liberação de UCCX e SocialMiner (manutenção programada) 11.6(2) adicionaram a característica nova do bate-papo da bolha.

(2)

A característica do bate-papo da bolha (ou a bolha do bate-papo) permite que você alcance um negócio usando um webform minimamente intrusivo, flutuando do bate-papo que se mova com o página da web (com desdobramento), é totalmente customizável e igualmente atualiza

imediatamente toda a personalização sem a necessidade de demover o webform no local. Contribuído por Jayant Suneja, Arunabh Bhattacharjee, planejamento de Cisco.

Logs exigidos

A fim seguir o fluxo do todo, os logs cobrem o iniciador do bate-papo (cliente) ao UCCX. Logs do console do cliente: Estes são os logs do console do navegador onde o usmer da extremidade inicia o bate-papo.

●

Logs manutenção programada: logs dos ccppublicapps, logs de tempo de execução, logs do gato.

●

Logs UCCX: Logs MIVR (logs do motor com eliminação de erros SS_CHAT e

SS_ROUTEANDQUEUE), logs MADM (logs CCX Admin com UCCX_WEBSERVICES).

●

O resto da análise (depois que o chat room é juntado) é idêntico ao fluxo clássico do bate-papo (isto é XMPP simples que eventing entre o dispositivo do agente de SocialMiner na fineza e o cliente final - quem são conectadas sobre um túnel XMPP)

Fluxo do bate-papo da bolha

O fluxo pode ser resumido pelas 19 etapas mostradas nesta imagem. Cada etapa é esboçada nos logs.

(3)

Análise dos logs

Quando um cliente clica sobre o clique para conversar o botão, o formulário do bate-papo da bolha está apresentado usando o código do Javascript no widget do bate-papo.

O formulário do bate-papo da bolha faz a rendição do lado de servidor - onde busca a

configuração do bate-papo para carregar o UI para que o utilizador final comece um bate-papo. Se você abre o widget do bate-papo, você verá a URL configurada neste formato:

https://<SOCIALMINER>/ccp/ui/BubbleChat.html?host=<SOCIALMINER>&wid=<WIDGET_ID>&secure=true

Os <SOCIALMINER> e os <WIDGET_ID> são o FQDN de SocialMiner e a identificação do widget respectivamente.

A configuração recebida aqui está no formulário JSON.

(4)

Uma vez que as imprensas do cliente final clicam para conversar no Web page faz um GET à manutenção programada com estas três URL.

1.

Note a identificação do Widget é enviado no terceiro pedido. 2.

Todo o estes devem retornar com uma APROVAÇÃO 200 bem sucedida a fim carregar o indicador do bate-papo da bolha.

3. 1) GET https://sm-fqdn/ccp/ui/BubbleChat.html?host=sm-fqdn&wid=1&secure=true [HTTP/1.1 200 OK 0ms] 2) GET https://sm-fqdn/ccp/ui/js/ccp/bubblechat/ccp-chat-components.js [HTTP/1.1 200 OK 0ms] 3) GET https://sm-fqdn/ccp/bubblechat?wid=1 [HTTP/1.1 200 OK 289ms]

Etapa 2. Ccppublicapps manutenção programada: Mergulho DB ao

mmca_webhook

A manutenção programada faz um mergulho DB à tabela do mmca_webhook no base de dados Informix manutenção programada e busca o Webhook URL para este pedido entrante do bate-papo com a ajuda da identificação do Widget. Em nosso caso, é widegetid=1.

1.

A manutenção programada usa então este webhook URL para buscar a configuração do widget de UCCX. 2. 1) GET https://sm-fqdn/ccp/ui/BubbleChat.html?host=sm-fqdn&wid=1&secure=true [HTTP/1.1 200 OK 0ms] 2) GET https://sm-fqdn/ccp/ui/js/ccp/bubblechat/ccp-chat-components.js [HTTP/1.1 200 OK 0ms] 3) GET https://sm-fqdn/ccp/bubblechat?wid=1 [HTTP/1.1 200 OK 289ms]

Etapa 3. UCCX MADM: Recebe o pedido para a configuração do Widget.

O UCCX Webservices como parte de um MADM recebe este pedido obter a configuração do widget.

1.

A configuração do Widget contém os caráteres tipo da fonte, cores, a denominação do widget do bate-papo, a informação de formulário, etc.

2.

UCCX então faz um mergulho DB e busca a configuração do widget da tabela chatbubble em UCCX Informix (db_cra).

3.

Esta configuração é retornada de volta ao navegador do usuário através dos ccppublicapps API como uma resposta JSON.

4.

(5)

[HTTP/1.1 200 OK 0ms]

2) GET https://sm-fqdn/ccp/ui/js/ccp/bubblechat/ccp-chat-components.js [HTTP/1.1 200 OK 0ms]

3) GET https://sm-fqdn/ccp/bubblechat?wid=1 [HTTP/1.1 200 OK 289ms]

Etapa 4. Manutenção programada Publicapps:200 ESTÁ BEM na configuração do

Widget.

A manutenção programada recebe a APROVAÇÃO 200 para o pedido que GET enviou ao CCX para buscar a configuração do widget do bate-papo.

1) GET https://sm-fqdn/ccp/ui/BubbleChat.html?host=sm-fqdn&wid=1&secure=true [HTTP/1.1 200 OK 0ms] 2) GET https://sm-fqdn/ccp/ui/js/ccp/bubblechat/ccp-chat-components.js [HTTP/1.1 200 OK 0ms] 3) GET https://sm-fqdn/ccp/bubblechat?wid=1 [HTTP/1.1 200 OK 289ms]

Etapa 5. Logs do console do cliente: Resposta ao navegador cliente que mostra

detalhes em JSON.

Está aqui uma amostra de resposta JSON recebida no lado do cliente como parte de todas as operações acima.

1.

Este JSON é usado para carregar o indicador do bate-papo da bolha com a fonte, a indicação de problema, a cor configuradas etc. como recebido.

2.

Nota: Todas as operações acima são feitas a fim carregar o indicador do bate-papo da bolha assim que o cliente pode agora encher acima seus detalhes para começar conversar com o Contact Center. Um fluxo mais adicional uma vez que o cliente submete detalhes do bate-papo é o mesmo como era no fluxo clássico do bate-papo do legado.

Etapa 6. Manutenção programada Publicapps: Pedido entrante do bate-papo.

O pedido entrante do bate-papo é recebido pela manutenção programada e o contato social é criado:

1) GET https://sm-fqdn/ccp/ui/BubbleChat.html?host=sm-fqdn&wid=1&secure=true [HTTP/1.1 200 OK 0ms]

(6)

[HTTP/1.1 200 OK 0ms]

Etapa 7. Runtime manutenção programada: O contato social é criado.

O contato social é criado pelo motor de SocialMiner (serviço do Runtime).

Etapa 8. Manutenção programada Publicapps: Atualiza o SocialContact criado ao

público API.

O contato social é atualização criada é considerado em logs dos ccppublicapps.

Etapa 9. Runtime manutenção programada: Envia a notificação a CCX Webservice

API em MADM.

A notificação é enviada da manutenção programada aos serviços de Web CCX que informam o CCX que há um bate-papo entrante novo.

Etapa 10. UCCX MADM: Webservices mostra o pedido entrante do bate-papo.

O contato entrante do bate-papo é recebido pelo CCX em MADM com o UCCX_WEBSERVICES permitido de debugar.

1) GET https://sm-fqdn/ccp/ui/BubbleChat.html?host=sm-fqdn&wid=1&secure=true [HTTP/1.1 200 OK 0ms]

(7)

[HTTP/1.1 200 OK 0ms]

Etapa 11. UCCX MADM: Envie a mensagem JM ao motor CCX.

O motor é informado agora do contato novo através do barramento da mensagem JM, isto é UCCX MADM (a administração Webservice API) informa o MIVR (motor) para enfileirar este contato. 1) GET https://sm-fqdn/ccp/ui/BubbleChat.html?host=sm-fqdn&wid=1&secure=true [HTTP/1.1 200 OK 0ms] 2) GET https://sm-fqdn/ccp/ui/js/ccp/bubblechat/ccp-chat-components.js [HTTP/1.1 200 OK 0ms] 3) GET https://sm-fqdn/ccp/bubblechat?wid=1 [HTTP/1.1 200 OK 289ms]

Etapa 12. UCCX MIVR:

O subsistema do bate-papo (SS_CHAT) enfileira o contato do bate-papo e o subsistema da rota e da fila (SS_ROUTEANDQUEUE) atribui o bate-papo ao agente. Isto é visto nos logs do motor UCCX (MIVR) com o SS_CHAT e o SS_ROUTEANDQUEUE permitidos de debugar.

O agente é enviado a uma notificação para aceitar o bate-papo e a sala é criada entre o usuário e o agente.

O fluxo de todo este mesmo que o bate-papo do legado assim que não cobre muito dos logs para este fluxo.

Etapa 13. Manutenção programada Publicapps: O agente junta-se e a sessão dos

bate-papos começou.

A sessão do papo foi estabelecida uma vez que o túnel XMPP é criado. O widget do bate-papo do usuário e o SocialMiner o dispositivo do bate-bate-papo que (hospedado na fineza) é

conectado agora através de XMPP e de você podem ver os eventos da presença que estão sendo enviados e recebidos.

(8)

Etapa 14. Logs do console do cliente: O agente junta-se ao chat room.

Os logs do lado do cliente mostram que o agente se junta ao chat room. O mesmo é indicado no widget do bate-papo. 1) GET https://sm-fqdn/ccp/ui/BubbleChat.html?host=sm-fqdn&wid=1&secure=true [HTTP/1.1 200 OK 0ms] 2) GET https://sm-fqdn/ccp/ui/js/ccp/bubblechat/ccp-chat-components.js [HTTP/1.1 200 OK 0ms] 3) GET https://sm-fqdn/ccp/bubblechat?wid=1 [HTTP/1.1 200 OK 289ms]

Nota: O cliente termina agora o bate-papo. Aqui o fluxo é um bit diferente em relação ao bate-papo do legado porque há uns novos recursos da avaliação do bate-papo do cargo adicionada com bate-papo da bolha.

Etapa 15. Manutenção programada Publicapps: O usuário sae do chat room.

Um usuário deixa o bate-papo e agora o agente está sozinho no chat room. Isto igualmente mostra que o usuário sae da sala.

Nota: Se uma avaliação do bate-papo do cargo é permitida a manutenção programada recebe esta avaliação do papo uma vez que o usuário submete a avaliação do bate-papo do cargo.

Etapa 16. Logs do console do cliente: Sucesso da avaliação do bate-papo das

mostras do navegador do usuário.

Submissão bem sucedida da avaliação do bate-papo usando uma APROVAÇÃO 200 recebida no navegador do usuário. 1) GET https://sm-fqdn/ccp/ui/BubbleChat.html?host=sm-fqdn&wid=1&secure=true [HTTP/1.1 200 OK 0ms] 2) GET https://sm-fqdn/ccp/ui/js/ccp/bubblechat/ccp-chat-components.js [HTTP/1.1 200 OK 0ms] 3) GET https://sm-fqdn/ccp/bubblechat?wid=1 [HTTP/1.1 200 OK 289ms]

Etapa 17. Manutenção programada Publicapps: os ccppublicapps recebem a

avaliação do bate-papo do cargo do navegador.

(9)

Feedback de avaliação recebido na manutenção programada.

10.78.91.166: Aug 06 2018 09:33:34.277 +0530: %CCBU__CCPPUBLICAPPS-6-CHAT_FEEDBACK_RECEIVED : %[ChatFeedback=com.cisco.ccbu.ccp.publicapps.api.chat.ChatFeedback@d82623[rating=4]][Session= 3F8B8C08D7E8144C7B1AD7AF144A4C1E][social_contact_id=0D66B2241000016500235A740A4E5BA6]:

Received chat feedback

Nota: Quando o feedback do bate-papo for recebido na manutenção programada com informação de avaliação que a informação salvar primeiramente no socialcontact no datastore manutenção programada antes que notificar o CCX. Caso que o datastore manutenção programada está para baixo, a submissão da avaliação do bate-papo falha com uma pequena notícia de

"CCPPUBLICAPPS-3-UPDATE_CHAT_SOCIALCONTACT_EXTENSION_FIELD_FAILED"

Etapa 18. UCCX MIVR: Atualização XMPP recebida da manutenção programada.

A manutenção programada envia a atualização XMPP ao CCX que informa a da avaliação recebida do utilizador final.

10.78.91.166: Aug 06 2018 09:33:34.277 +0530: %CCBU__CCPPUBLICAPPS-6-CHAT_FEEDBACK_RECEIVED : %[ChatFeedback=com.cisco.ccbu.ccp.publicapps.api.chat.ChatFeedback@d82623[rating=4]][Session= 3F8B8C08D7E8144C7B1AD7AF144A4C1E][social_contact_id=0D66B2241000016500235A740A4E5BA6]:

Received chat feedback

Etapa 19. UCCX MIVR: Escreva o bate-papo que avalia ao base de dados.

A avaliação submetida do bate-papo é escrita ao base de dados CCX e salvar na tabela do textratingdetail, que é uma tabela recentemente adicionada em UCCX 11.6(2).

O propósito principal desta tabela é armazenar avaliações do bate-papo para relatar finalidades.

3723276: Aug 06 09:33:34.299 IST %MIVR-SS_ROUTEANDQUEUE-7-UNK:[Smack Listener Processor (1)] RouteAndQueueSubsystemLogger: com.cisco.wf.subsystems.routeandqueue.aggregator.historical. HistoricalManager : Writing Historical Record: TRDR: ContactID=0D66B2241000016500235A740A4E5BA6,

rating=4, ratingTime=java.util.GregorianCalendar[time=1533528214299,areFieldsSet=true, areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0 , useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1, YEAR=2018,MONTH=7,WEEK_OF_YEAR=32,WEEK_OF_MONTH=2,DAY_OF_MONTH=6,DAY_OF_YEAR=218,DAY_OF_WEEK=2, DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=4,HOUR_OF_DAY=4,MINUTE=3,SECOND=34,MILLISECOND=299, ZONE_OFFSET=0,DST_OFFSET=0]