Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Informações de Apoio

Procedimento

Verificação

Mecanismo de Workflow: Verificar Status do Processo e da Instância

Verificar Disponibilidade do Agente de Canal de Email

Verificar Status do Fluxo de Trabalho

Validação do Processamento da Atividade do Fluxo de Trabalho

Nenhum fluxo de trabalho de entrada ativo na verificação de departamento

Configurar e solucionar problemas de fluxos de trabalho de alarme

Introdução

Este documento descreve como isolar e corrigir problemas relacionados a emails roteados para a fila de exceções padrão no Cisco Enterprise Chat and Email (ECE).

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

- Cisco Unified Contact Center Enterprise (UCCE) versão 12.6.X

- Cisco Packaged Contact Center Enterprise (PCCE) versão 12.6.X

- Enterprise Chat and Email (ECE) versão 12.6.X

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

- UCCE versão 12.6.2

- E-mail e bate-papo corporativo (ECE) 12.6.1

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

As filas mantêm as atividades de atendimento ao cliente de entrada, como emails e sessões de bate-papo, que aguardam para serem atribuídas aos agentes.

ECE vem equipado com uma Fila de Exceções Padrão já disponível. Mais filas podem ser adicionadas ao aplicativo pela importação de MRDs. Isso cria um tipo de fila do Unified CCE e o roteamento de atividades dessa fila é feito pelo Unified CCE.

Fila de exceções por padrão, uma fila de exceções é criada em todos os departamentos. As atividades são roteadas para a fila de exceções quando:

- Não há fluxos de trabalho de entrada ativos no departamento.

- Um fluxo de trabalho enfrenta um erro ao processar atividades.

- A fila usada em um fluxo de trabalho fica inativa. Todas as atividades que chegarem à fila inativa serão roteadas para a fila de exceções.

- Os e-mails são devolvidos.

- Uma mensagem new_task_failure é retornada pelo Unified CCE, uma vez que o EAAS recebe a resposta New_Task_Failure 3 vezes a resposta pós-primeira falha (isto é, primeira resposta de falha + 3 tentativa de repetição), o EAAS roteia essas atividades para a fila Exceção.

- Se uma conexão for perdida com o sistema de roteamento da Cisco; por exemplo, se a máquina MR PIM for desligada ou reiniciada temporariamente.

Procedimento

Este documento mostra as etapas necessárias para solucionar e isolar problemas com emails de entrada que foram roteados para a fila de exceções padrão. É uma lista de verificação de procedimentos que ajuda os engenheiros a isolar ou resolver problemas relevantes com mais rapidez.

Para solucionar com eficiência problemas de ECE, você dividirá o fluxo em três partes. Isso é semelhante a como você abordaria um fluxo de chamada de voz.  Estas três pernas são as seguintes:

1. Perna de ingresso - Passando do cliente para a ECE.

2. Perna de tratamento - Passando de ECE para UCCE.

3. Trecho do agente - Conectando o cliente a um agente.

Verificação

Este documento concentra-se principalmente na perna de tratamento, verificando estes pontos:

Mecanismo de Workflow: Verificar Status do Processo e da Instância

Observação: verifique os processos EAAS e EAMS se estiverem ativos e se eles devem estar ativos.

Verificar Disponibilidade do Agente de Canal de Email

Há muitas maneiras de verificar se os agentes estão conectados, mas você pode utilizar rttest.

## The agent does not log in.

rttest: agent_status /agent 5001

domain: Email_MRD (5001), state = [off], 239 secs

C off Inbound_SG (5011, periph# 3)

off agent_peripheral.Email_MRD.14828 (5008, periph# 58660)

domain: OutboundEmail_MRD (5002), state = [off], 239 secs

C off Outbound_SG (5012, periph# 4)

off agent_peripheral.OutboundE.30541 (5009, periph# 74372)

## The agent does log in to ECE but the agent is not marked as available for email channel.

domain: Email_MRD (5001), state = [nr-0:1[0],R], 9 secs

CL nr Inbound_SG (5011, periph# 3)

L nr agent_peripheral.Email_MRD.14828 (5008, periph# 58660)

domain: OutboundEmail_MRD (5002), state = [nr-0:1[0],R], 9 secs

CL nr Outbound_SG (5012, periph# 4)

L nr agent_peripheral.OutboundE.30541 (5009, periph# 74372)

## The agent does log in to ECE as well as the agent is marked as available for email channel.

domain: Email_MRD (5001), state = [na-0:1[0],RA], 4 secs

CL na Inbound_SG (5011, periph# 3)

L na agent_peripheral.Email_MRD.14828 (5008, periph# 58660)

domain: OutboundEmail_MRD (5002), state = [na-0:1[0],RA], 4 secs

CL na Outbound_SG (5012, periph# 4)

L na agent_peripheral.OutboundE.30541 (5009, periph# 74372)

## Here you can find more explanation for rttest output regarding agent's availability.

off- NotLoggedIn

nr - NotReady

na - NotActive

0:1 – AciteTasks(0):ConcurentTaskLimit(1)

RA - R is routable (if set), A indicated the router considers the agent available for new work in this domain.

Verificar Status do Fluxo de Trabalho

Você deve ver o nome do fluxo de trabalho na página de auditoria da atividade como você vê na imagem.

Em seguida, você pode verificar se o fluxo de trabalho está sendo ativado. Navegue até serviço> fluxo de trabalho.

Validação do Processamento da Atividade do Fluxo de Trabalho

Os logs de processo de regras no nível INFO podem fornecer informações úteis para isolar e solucionar problemas relevantes.Para garantir o nível de rastreamento adequado, navegue até Partição > Recursos do Sistema > processo de regras.

Certifique-se de que o nível máximo de rastreamento esteja definido como 4-Info.

Este fluxo de trabalho demonstra como gerenciar emails que chegam a uma empresa. Primeiro, um nível de serviço é definido para os e-mails. Em seguida, com base na condição da ramificação, ele roteia a atividade para a respectiva fila.

No nó inicial, você pode mapear o alias para o fluxo de trabalho de entrada. Neste exemplo, é info@uccelab.tac.

Os níveis de serviço permitem configurar as expectativas de tempo de resposta para interações de atendimento ao cliente de entrada. O nível de serviço pode ser definido para casos e todas as atividades que não sejam atividades de bate-papo. Depois de definidos, eles são usados em fluxos de trabalho para influenciar o roteamento de atividades. Este exemplo explica o nó SLA do Lab SLA que está associado à regra SLA do RuleLab que especifica todos os e-mails de entrada para info@uccelab.tac, especificamente, que é avaliado e as ações verdadeiras executadas desde que o e-mail de entrada foi para info@uccelab.tac.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_rules-process

2024-06-06 15:50:49.186 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.RouteAction <@> execute() <@> Routing to internal workflow item: 1032 - Activity Id: 6081 <@>

2024-06-06 15:50:49.186 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow item: Lab SLA - Activity Id: 6081 <@>

2024-06-06 15:50:49.186 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.DefaultRule <@> apply() <@> Rule Evaluated: Lab SLA Rule - Activity Id: 6081 <@>

2024-06-06 15:50:49.186 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.ComparisonCondition <@> evaluate() <@>  Condition Attribute is : egml_email.to_or_cc_email_address - Comparing: [Ljava.lang.String;@6a6230a5 == info@uccelab.tac - Activity Id: 6081 <@>

2024-06-06 15:50:49.202 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.DefaultRule <@> apply() <@>  True action executed for the Rule: Lab SLA Rule - Activity Id: 6081 <@>

O nó de ramificação é um ponto de decisão onde você decide que tipo de trabalho deve ser roteado para que recurso. Usando regras, você pode rotear automaticamente o trabalho para os recursos capazes de manipulá-lo. As atividades podem ser roteadas para usuários, filas, departamentos ou outro fluxo de trabalho. Este exemplo explica a Ramificação TAC do nó de ramificação que está associada à regra TAC Rule que especifica todos os e-mails de entrada com título que contém SR#, especificamente, que é avaliado e as ações verdadeiras executadas desde o e-mail de entrada com título SR#123456789.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_rules-process

2024-06-06 15:50:49.264 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.RouteAction <@> execute() <@> Routing to internal workflow item: 1033 - Activity Id: 6081 <@>

2024-06-06 15:50:49.264 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow item: TAC Branch - Activity Id: 6081 <@>

2024-06-06 15:50:49.264 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.DefaultRule <@> apply() <@> Rule Evaluated: TAC Rule - Activity Id: 6081 <@>

2024-06-06 15:50:49.264 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.ComparisonCondition <@> evaluate() <@>  Condition Attribute is : egml_email.subject - Comparing: SR#123456789 contains SR# - Activity Id: 6081 <@>

2024-06-06 15:50:49.264 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.DefaultRule <@> apply() <@>  True action executed for the Rule: TAC Rule - Activity Id: 6081 <@>

Essa linha de log explica que a atividade foi movida para a fila de acordo com o projeto de fluxo de trabalho.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_rules-process

2024-06-06 15:50:49.264 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.RuleContextMail <@> routeActivity() <@> Activity moved to Queue Id: 1008 - Activity Id: 6081 - approval_type configured for the queue:  <@>

O mesmo exemplo explica o nó de ramificação, TAC Branch, que está associado à Regra TAC que especifica todos os e-mails de entrada com título que contém SR# especificamente que é avaliado, e a ação False executada para a Regra, já que o e-mail de entrada estava com título que contém case#123456789, e não continha qualquer SR# no título. Com base nisso, a atividade não foi processada e movida para a fila de exceções padrão.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_rules-process

2024-06-06 16:14:20.504 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.RouteAction <@> execute() <@> Routing to internal workflow item: 1033 - Activity Id: 6086 <@>

2024-06-06 16:14:20.504 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow item: TAC Branch - Activity Id: 6086 <@>

2024-06-06 16:14:20.504 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.DefaultRule <@> apply() <@> Rule Evaluated: TAC Rule - Activity Id: 6086 <@>

2024-06-06 16:14:20.504 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.ComparisonCondition <@> evaluate() <@>  Condition Attribute is : egml_email.subject - Comparing: case#123456789 contains SR# - Activity Id: 6086 <@>

2024-06-06 16:14:20.504 GMT+0000 <@> INFO <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.DefaultRule <@> apply() <@>  False action executed for the Rule: TAC Rule - Activity Id: 6086 <@>

2024-06-06 16:14:20.535 GMT+0000 <@> ERROR <@> [68:BPRulesInstance id : 996] <@> ProcessId:4744 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.BPRulesInstance <@> checkAndMoveStuckActivitiesToException() <@> Activity is not processed, moving to exception queue :  Property = ActivityId & value = 6086

Property = CaseId & value = 6052

Property = DepartmentId & value = 999

Property = ActivityType & value = 1

Property = ActivityMode & value = 100

Property = ActivitySubType & value = 1

Property = ActivityStatus & value = 4000

Property = ActivitySubStatus & value = 4100

Property = ActivityPriority & value = 0

Property = DateCreated & value = 2024-06-06 16:14:09

Property = CreatedBy & value = 12

Property = DateModified & value = 2024-06-06 16:14:20

Property = DueDate & value = 06/06/2024 16:24:09

Dica: se a atividade for roteada para a fila de exceções antes de enviar New_task, você precisará focalizar na configuração do workflow e nas regras do workflow, e se a atividade for roteada para a fila de exceções depois de enviar New_task, você precisará focalizar no processo EAAS .

Nenhum fluxo de trabalho de entrada ativo na verificação de departamento

Neste exemplo, ele mostra a diferença da perspectiva de logs quando há um fluxo de trabalho ativo de entrada em comparação com o caso quando não há fluxos de trabalho ativos.

O Departamento de vendas é configurado com o fluxo de trabalho WF de entrada de vendas ativo, como você pode ver, a atividade roteada para a fila normalmente depois que o fluxo de trabalho de entrada é disparado.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_rules-process

2024-08-08 18:02:05.323 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow: Sales Inbound WF - Activity Id: 6139 <@>

2024-08-08 18:02:05.323 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow item: Start - Activity Id: 6139 <@>

2024-08-08 18:02:05.324 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.RouteAction <@> execute() <@> Routing to internal workflow item: 1043 - Activity Id: 6139 <@>

2024-08-08 18:02:05.324 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow item: Sales Queue - Activity Id: 6139 <@>

2024-08-08 18:02:05.324 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.RouteAction <@> execute() <@> Routing to external queue: 1023 - Activity Id: 6139 <@>

2024-08-08 18:02:05.324 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.RuleContextMail <@> routeActivity() <@> Activity moved to Queue Id: 1023 - Activity Id: 6139 - approval_type configured for the queue:  <@>

Por outro lado, se não houver nenhum fluxo de trabalho de entrada ativo, o ECE acionará Concluir fluxo de trabalho. Este fluxo de trabalho será executado se não houver nenhum fluxo de trabalho de email de entrada definido para o departamento.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_rules-process

2024-08-08 18:14:35.831 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Executing Workflow: Finish Workflow - Activity Id: 6140 <@>

2024-08-08 18:14:35.831 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.DefaultEngine <@> applyWorkflow(CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId) <@> Finished execution of Workflow: Finish Workflow - Activity Id: 6140. Time taken = 0 seconds. <@>

2024-08-08 18:14:35.831 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.RuleContextMail <@> doDeferredActions() <@> doDeferredActions Started - Activity Id: 6140 <@>

2024-08-08 18:14:35.831 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.RuleContextMail <@> doDeferredActions() <@> OutBound Activity=false OutBound Rule Applied=false - Activity Id: 6140 <@>

2024-08-08 18:14:35.858 GMT+0000 <@> INFO <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.RuleContextMail <@> doDeferredActions() <@> doDeferredAction completed for - Activity Id:   6140 <@>

2024-08-08 18:14:35.867 GMT+0000 <@> ERROR <@> [3626:BPRulesInstance id : 996] <@> ProcessId:8668 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.bprules.BPRulesInstance <@> checkAndMoveStuckActivitiesToException() <@> Activity is not processed, moving to exception queue :  Property = ActivityId & value = 6140

Property = CaseId & value = 6086

Property = DepartmentId & value = 1002

Configurar e solucionar problemas de fluxos de trabalho de alarme

O fluxo de trabalho de alarme é mais prático quando há um grande número de e-mails na fila de exceções padrão. O fluxo de trabalho de alarme é configurado para enviar notificações quando as atividades são roteadas para a fila de exceções devido a erros de fluxo de trabalho encontrados durante o processamento das atividades.

Você pode concluir as atividades de emails na fila de exceções padrão no fluxo de trabalho de alarme, como você vê neste exemplo. Esse fluxo de trabalho verifica atividades de email na fila de exceções padrão que estão prestes a vencer em 30 minutos para encaminhá-las de volta à fila do TAC. Você deve evitar que todas as atividades sejam roteadas de volta para a fila do TAC. Configure este fluxo: Start > Alarm > TAC Queue.

Observação: os registros de regras de alarmes no nível INFO fornecem informações úteis para isolar e solucionar problemas relevantes. Para garantir o nível de rastreamento adequado, navegue para Partição > Recursos do sistema > processo de regras de alarme.

No nó inicial, você deve selecionar a fila de exceções padrão.

Há uma guia de programação na qual você pode configurar esse fluxo de trabalho de alarme. Neste exemplo, ele foi acionado uma vez em um determinado momento.

Na condição de configuração da regra de alarme, você deve configurar quais condições correspondem às suas necessidades comerciais específicas. Para esse caso, ele foi configurado para atividades de email que estão na fila de exceções padrão, cujos SLA ainda não são perdidos por mais de 30 minutos.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_alarm-rules-process

2024-07-17 16:37:23.303 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.AlarmEngine <@> applyWorkflow( CallerContext oCallerContext, RuleContext oContext, Workflow oWorkflow, long lCurrentItemId ) <@> Executing Workflow item: TAC Case Alarm <@>

2024-07-17 16:37:23.303 GMT+0000 <@> INFO <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.AlarmRule <@> apply( RuleContext oContext ) <@> Alarm Rule Evaluated: Alarm 7__RN_S__ <@>

....

2024-07-17 16:37:23.307 GMT+0000 <@> PERF <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.framework.dataaccess.DataAccess <@> executeSelect() <@> Executing query: calendar:get_business_date   Time taken: 4 <@>

2024-07-17 16:37:23.307 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> buildWhereClause(List oConditions) <@> sAttribute : 0 :  DUE_DATE  <@>

2024-07-17 16:37:23.307 GMT+0000 <@> INFO <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> evaluateClause(List oConditions) <@> Condition String : mins_tilldue >= 30  <@>

2024-07-17 16:37:23.307 GMT+0000 <@> INFO <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> evaluateClause(List oConditions) <@> Where Clause:  DUE_DATE  >= '07/17/2024 17:07:23'  <@>

2024-07-17 16:37:23.307 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.module.routing.service.alarmrules.RuleContextAlarm <@> getAssociationDetails() <@> Number of Associations returned from cache:[21_4] for alarm workflow id: 1029 <@>

2024-07-17 16:37:23.307 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.framework.dataaccess.queryprocessor.QueryProcessor <@> getQuery() <@> Getting static query detail for query name =   rules:get_activities_for_alarm <@>

2024-07-17 16:37:23.307 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.framework.dataaccess.ConnectionPoolMap <@> getPoolName(CallerContext context, String dsName) <@> Trying to get pool name for database and partition id =  customer_db 1  <@>

2024-07-17 16:37:23.307 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.framework.dataaccess.queryprocessor.QueryProcessor <@> getQuery() <@> Now build the complete query. query set name =   rules:get_activities_for_alarm <@>

2024-07-17 16:37:23.308 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.framework.dataaccess.queryprocessor.StaticQuery <@> preProcess() <@> query -> rules:get_activities_for_alarm, Object passed is   where_clause =  DUE_DATE  >= '07/17/2024 17:07:23'  : Type = java.lang.String

workflow_id = 1029 : Type = java.lang.Long

Além disso, na condição verdadeira de configuração de alarme, você deve ser mais específico para os emails que foram roteados da fila de exceções padrão para a fila TAC para evitar que emails desnecessários sejam roteados para o agente e, em seguida, perder tempo. Neste exemplo, a condição do assunto será especificada se contiver maiúsculas e minúsculas em vez de SR, conforme especificado no fluxo de trabalho de entrada, para que os e-mails sejam roteados novamente para a fila do TAC.

## log path -> C:\ECE\eService_RT\logs\eg_log_ece_alarm-rules-process

2024-07-17 16:37:23.366 GMT+0000 <@> DEBUG <@> [73:AlarmRuleInstance id : 989] <@> ProcessId:8632 <@> PID:1 <@> UID:12 <@> UserSessionId:  <@> ClientIP: <@> com.egain.platform.framework.dataaccess.queryprocessor.StaticQuery <@> preProcess() <@> query -> casemgmt::sub_search_activity:mssql, Object passed is   casewhereclause = null

classwhereclause = null

deptwhereclause = ( egpl_department.department_name = N'Service' )  : Type = java.lang.String

caseownerwhereclause = null

contactpointemailwhereclause = null

emailattachmentdatawhereclause = null

userwhereclause = null

emaildatawhereclause = null

toemailaddresswhereclause = null

custdeptwhereclause = null

ccemailaddresswhereclause = null

contactpointwhereclause = null

customerattributeswhereclause = null

whereclause = ( egpl_casemgmt_activity.subject like N'%case%' ESCAPE '\' )  : Type = java.lang.String

contactpointsocialwhereclause = null

routingnodewhereclause = null

contactpersonwhereclause = null

emailwhereclause = null

customerwhereclause = null

contactpointpostalwhereclause = null

Observação: reinicie o serviço Cisco no ECE para ter o alarme configurado normalmente não é necessário. No entanto, em alguns casos, se você enfrentar problemas relacionados a esse fluxo de trabalho de alarme, ele não será acionado e reinicie o serviço Cisco no ECE. Às vezes, isso ajuda a ativá-lo.

Finalmente, você vê aqui nessas imagens como a atividade foi roteada da fila de exceções padrão para o agente disponível na fila TAC depois que o fluxo de trabalho configurado foi disparado.

Agora, os agentes podem ver as atividades com o assunto contém case# em vez de SR#.