Dépannage des courriers électroniques entrant dans la file d'attente des exceptions par défaut dans ECE

Introduction

Ce document décrit comment isoler et résoudre les problèmes liés aux e-mails routés vers la file d'attente d'exception par défaut dans Cisco Enterprise Chat and Email (ECE).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Cisco Unified Contact Center Enterprise (UCCE) version 12.6.X
• Cisco Packaged Contact Center Enterprise (PCCE) version 12.6.X
• Enterprise Chat and Email (ECE) version 12.6.X

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• UCCE version 12.6.2
• Chat et e-mail d'entreprise (ECE) 12.6.1

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Les files d'attente contiennent des activités de service client entrantes, telles que des courriers électroniques et des sessions de discussion, en attente d'affectation à des agents.

ECE est livré avec une file d'attente d'exception par défaut déjà disponible. Vous pouvez ajouter d'autres files d'attente à l'application en important des MRD. Cela crée un type de file d'attente Unified CCE et le routage des activités à partir de cette file d'attente est effectué par Unified CCE.

File d'attente d'exception par défaut, une file d'attente d'exception est créée dans chaque service. Les activités sont acheminées vers la file d'attente des exceptions lorsque :

• Il n'y a aucun flux de travail entrant actif dans le service.
•  Un workflow rencontre une erreur lors du traitement des activités.
•  La file d'attente utilisée dans un workflow est désactivée. Toutes les activités arrivant dans la file d'attente inactive sont acheminées vers la file d'attente d'exception.
•  Les e-mails sont renvoyés.
•  Un message new_task_failure est renvoyé par Unified CCE, une fois qu'EAAS reçoit la réponse New_Task_Failure 3 fois après la première réponse d'échec (c'est-à-dire, la première réponse d'échec + 3 tentatives), EAAS achemine ces activités vers la file d'attente des exceptions.
•  Si une connexion est perdue avec le système de routage Cisco ; par exemple, si la machine MR PIM s'arrête temporairement ou redémarre.

Procédure

Ce document montre les étapes requises pour dépanner et isoler les problèmes avec les e-mails entrants qui ont été routés vers la file d'attente d'exception par défaut. Il s'agit d'une liste de contrôle procédurale qui aide les ingénieurs à isoler ou à résoudre les problèmes pertinents plus rapidement.

Pour résoudre efficacement le problème de l'ECE, vous allez diviser le flux en trois branches. Cette approche est similaire à celle que vous adopteriez pour un flux d'appels vocaux.  Ces trois pieds sont les suivants :

1. Jambe d'entrée : passage du client à l'ECE.
2. Jambe de traitement - Passage de l'ECE à l'UCCE.
3. Branche d'agent : connexion du client à un agent.

Vérification

Ce document se concentre principalement sur la jambe de traitement en vérifiant ces points :

Moteur de workflow : vérifier le statut du processus et de l'instance

Remarque : vérifiez que les processus EAAS et EAMS sont actifs et qu'ils doivent l'être.

Vérifier la disponibilité des agents de canal de messagerie

Il existe de nombreuses façons de vérifier si les agents sont connectés, mais vous pouvez utiliser 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.

Vérifier le statut du workflow

Vous devez voir le nom du workflow dans la page d'audit de l'activité tel qu'il apparaît dans l'image.

Ensuite, vous pouvez vérifier si ce flux de travail est actif. Accédez à service> workflow.

Validation du traitement des activités de workflow

Les journaux de processus de règles au niveau INFO peuvent vous fournir des informations utiles afin d'isoler et de dépanner les problèmes pertinents.Afin de garantir le niveau de suivi approprié, accédez à Partition > Ressources système > processus de règles.

Assurez-vous que le niveau de suivi maximal est défini sur 4-Info.

Ce workflow explique comment gérer les e-mails qui arrivent dans une entreprise. Tout d'abord, un niveau de service est défini pour les e-mails. Ensuite, en fonction de la condition de branche, il achemine l'activité vers la file d'attente correspondante.

Au noeud de démarrage, vous pouvez mapper l'alias au workflow entrant. Dans cet exemple, il s'agit de info@uccelab.tac.

Les niveaux de service vous permettent de définir des attentes en termes de temps de réponse pour les interactions de service client entrantes. Le niveau de service peut être défini pour les dossiers et toutes les activités autres que les activités de discussion. Une fois définis, ils sont utilisés dans les workflows pour influencer le routage des activités. Cet exemple explique le noeud SLA Lab SLA associé à la règle RuleLab SLA qui spécifie tous les e-mails entrants vers info@uccelab.tac, en particulier, qui est évalué et les actions vraies exécutées depuis que l'e-mail entrant a été envoyé à 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 <@>

Le noeud Branche est un point de décision où vous décidez quel type de travail doit être acheminé vers quelle ressource. À l'aide de règles, vous pouvez acheminer automatiquement le travail vers les ressources capables de le gérer. Les activités peuvent être acheminées vers des utilisateurs, des files d'attente, des services ou un autre workflow. Cet exemple explique le noeud de succursale TAC Branch qui est associé à la règle TAC Rule qui spécifie tous les e-mails entrants avec le titre qui contient SR#, en particulier, qui est évalué et de vraies actions exécutées depuis l'e-mail entrant avec le titre 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 <@>

Cette ligne de journal explique que l'activité a été déplacée vers la file d'attente selon la conception du workflow.

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

Le même exemple explique le noeud de branche, TAC Branch, qui est associé à la règle TAC qui spécifie tous les e-mails entrants avec le titre qui contient SR# spécifiquement qui est évalué, et l'action False exécutée pour la règle puisque l'e-mail entrant était avec le titre qui contient case#123456789, et il ne contenait pas de SR# dans le titre. Sur cette base, l'activité n'a pas été traitée et déplacée vers la file d'attente des exceptions par défaut.

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

Conseil : si l'activité est acheminée vers la file d'attente des exceptions avant l'envoi de New_task, vous devez vous concentrer sur la configuration et les règles de workflow du workflow, et si l'activité est acheminée vers la file d'attente des exceptions après l'envoi de New_task, vous devez vous concentrer dans le processus EAAS .

Aucun flux de travail entrant actif dans le service Vérification

Dans cet exemple, il montre la différence du point de vue des journaux lorsqu'il y a un flux de travail actif entrant par rapport au cas où il n'y a pas de flux de travail actif.

Le service des ventes est configuré avec un workflow WF entrant de vente actif, comme vous pouvez le voir, l'activité est acheminée vers la file d'attente normalement après le déclenchement du workflow entrant.

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

En revanche, s'il n'existe aucun workflow entrant actif, l'ECE déclenche l'option Terminer le workflow. Ce flux de travail est exécuté s'il n'existe aucun flux de travail de courrier entrant défini pour le service.

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

Configuration et dépannage des workflows d'alarme

Le workflow d'alarme est plus pratique lorsqu'il y a un grand nombre de courriers électroniques dans la file d'attente d'exception par défaut. Le workflow d'alarme est configuré pour envoyer des notifications lorsque les activités sont routées vers la file d'attente d'exception en raison d'erreurs de workflow rencontrées lors du traitement des activités.

Vous pouvez terminer les activités de messagerie dans la file d'attente d'exception par défaut dans le workflow d'alarme comme vous le voyez dans cet exemple. Ce flux de travail vérifie les activités de messagerie dans la file d'attente d'exception par défaut qui sont sur le point d'arriver à échéance dans 30 minutes pour les router vers la file d'attente du centre d'assistance technique. Vous devez éviter que toutes les activités soient redirigées vers la file d'attente du centre d'assistance technique. Configurez ce flux : Start > Alarm > TAC Queue.

À partir du noeud de démarrage, vous devez sélectionner la file d'attente des exceptions par défaut.

Il existe un onglet de planification dans lequel vous pouvez configurer ce workflow d'alarme. Dans cet exemple, il a été déclenché une fois à un certain moment.

Dans la condition de configuration de règle d'alarme, vous devez configurer les conditions qui correspondent à vos besoins professionnels spécifiques. Dans ce cas, il a été configuré pour les activités de messagerie qui se trouvent dans la file d'attente d'exception par défaut, et dont le SLA n'est toujours pas perdu pendant plus de 30 minutes.

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

En outre, dans la condition true de configuration d'alarme, vous devez être plus spécifique pour les e-mails qui ont été routés de la file d'attente d'exception par défaut à la file d'attente du TAC pour éviter d'avoir des e-mails inutiles routés à l'agent et de perdre leur temps. Dans cet exemple, la condition d'objet est spécifiée si elle contient des cas au lieu de SR comme spécifié dans le workflow entrant, de sorte que les e-mails sont routés à nouveau vers la file d'attente 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

Enfin, vous voyez ici dans ces images comment l'activité a été routée de la file d'attente d'exceptions par défaut vers l'agent disponible dans la file d'attente du centre d'assistance technique après le déclenchement du workflow configuré.

À présent, les agents peuvent voir que les activités avec l'objet contient case# au lieu de SR#.