Problembehandlung bei E-Mails, die zur Standard-Ausnahmewarteschlange in ECE wechseln

Einleitung

In diesem Dokument wird beschrieben, wie Sie Probleme im Zusammenhang mit E-Mails, die an die Standard-Ausnahmewarteschlange in Cisco Enterprise Chat und E-Mail (ECE) weitergeleitet werden, isolieren und beheben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Cisco Unified Contact Center Enterprise (UCCE) Version 12.6.X
• Cisco Packaged Contact Center Enterprise (PCCE) Version 12.6.X
• Enterprise Chat und E-Mail (ECE) Version 12.6.X

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• UCCE-Version 12.6.2
• Enterprise Chat und E-Mail (ECE) 12.6.1

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

In Warteschlangen werden eingehende Kundenserviceaktivitäten wie E-Mails und Chat-Sitzungen abgehalten, die darauf warten, den Agenten zugewiesen zu werden.

ECE ist mit einer bereits verfügbaren Default Exception Queue ausgestattet. Weitere Warteschlangen können der Anwendung durch den Import von MRDs hinzugefügt werden. Dadurch wird ein Unified CCE-Warteschlangentyp erstellt, und das Routing der Aktivitäten aus dieser Warteschlange wird von Unified CCE durchgeführt.

Die Ausnahmewarteschlange wird standardmäßig in jeder Abteilung erstellt. Aktivitäten werden in folgenden Fällen an die Ausnahmewarteschlange weitergeleitet:

• In der Abteilung sind keine aktiven eingehenden Workflows vorhanden.
•  Bei der Verarbeitung von Aktivitäten in einem Workflow ist ein Fehler aufgetreten.
•  Die in einem Workflow verwendete Warteschlange wird inaktiv. Alle Aktivitäten, die in die inaktive Warteschlange gelangen, werden in die Ausnahmewarteschlange geroutet.
•  E-Mails werden zurückgesendet.
•  Eine new_task_failure-Meldung wird von Unified CCE zurückgegeben. Sobald EAAS die New_Task_Failure-Antwort dreimal nach der ersten Fehlerantwort (d. h. erste Fehlerantwort + 3 Wiederholungsversuche) erhält, leitet EAAS diese Aktivitäten an die Ausnahmewarteschlange weiter.
•  Wenn eine Verbindung mit dem Cisco Routing-System unterbrochen wird, z. B. wenn der MR-PIM-Rechner vorübergehend heruntergefahren wird oder neu startet.

Vorgehensweise

Dieses Dokument zeigt die erforderlichen Schritte zur Fehlerbehebung und Isolierung von Problemen mit eingehenden E-Mails, die an die Standard-Ausnahmewarteschlange weitergeleitet wurden. Diese Checkliste hilft den Technikern dabei, relevante Probleme schneller zu isolieren oder zu lösen.

Zur effektiven Fehlerbehebung bei ECE unterteilen Sie den Datenfluss in drei Abschnitte. Dies ähnelt der Vorgehensweise bei Sprachanrufen.  Diese drei Stufen sind wie folgt:

1. Eingangs-Leg: Verbindung vom Kunden zur ECE.
2. Behandlungsarm - Übergang von ECE zu UCCE.
3. Agent Leg: Verbinden des Kunden mit einem Agenten

Verifizierung

Dieses Dokument konzentriert sich hauptsächlich auf das Bein der Behandlung, indem es folgende Punkte überprüft:

Workflow-Engine: Prozess- und Instanzstatus überprüfen

Hinweis: Überprüfen Sie die EAAS- und EAMS-Prozesse, wenn sie aktiv sind und aktiv sein müssen.

Verfügbarkeit des E-Mail-Channel-Agenten überprüfen

Es gibt viele Möglichkeiten, um zu überprüfen, ob die Agenten angemeldet sind, aber Sie können den Test verwenden.

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

Workflow-Status überprüfen

Sie müssen den Namen des Workflows auf der Überwachungsseite der Aktivität sehen, wie Sie ihn im Bild sehen.

Anschließend können Sie überprüfen, ob der Workflow aktiv ist. Navigieren Sie zu service> workflow.

Workflow-Aktivität - Verarbeitungsvalidierung

Regelprozessprotokolle auf INFO-Ebene können Ihnen nützliche Informationen liefern, um die relevanten Probleme zu isolieren und zu beheben.Um die korrekte Ablaufverfolgungsebene sicherzustellen, navigieren Sie zu Partition > Systemressourcen > rules-Prozess.

Stellen Sie sicher, dass die maximale Ablaufverfolgungsebene auf "4-Info" festgelegt ist.

Dieser Workflow zeigt, wie E-Mails verwaltet werden, die in ein Unternehmen eingehen. Zunächst wird ein Servicelevel für die E-Mails festgelegt. Anschließend leitet er die Aktivität abhängig von der Zweigbedingung an die entsprechende Warteschlange weiter.

Am Startknoten können Sie den Alias dem eingehenden Workflow zuordnen. In diesem Beispiel ist dies info@uccelab.tac.

Mit Servicelevels können Sie die erwarteten Reaktionszeiten bei eingehenden Kundenserviceinteraktionen festlegen. Die Servicestufe kann für Tickets und alle Aktivitäten außer Chat-Aktivitäten festgelegt werden. Nach der Definition werden sie in Workflows verwendet, um das Aktivitätsrouting zu beeinflussen. In diesem Beispiel wird der SLA-Knoten Lab SLA erläutert, der mit der RuleLab SLA Rule verknüpft ist, die alle eingehenden E-Mails an info@uccelab.tac angibt. Diese gibt an, welche Aktionen ausgewertet und ausgeführt werden, da die eingehende E-Mail an info@uccelab.tac gesendet wurde.

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

Branch Node ist ein Entscheidungspunkt, bei dem Sie entscheiden, welche Art von Arbeit an welche Ressource weitergeleitet werden soll. Mithilfe von Regeln können Sie die Arbeit automatisch an die Ressourcen weiterleiten, die sie verarbeiten können. Aktivitäten können an Benutzer, Warteschleifen, Abteilungen oder einen anderen Workflow weitergeleitet werden. In diesem Beispiel wird die TAC-Außenstelle des Außenstelle-Knotens erläutert, die mit der Regel TAC-Regel verknüpft ist, die alle eingehenden E-Mails mit dem Titel angibt, der SR# enthält. Diese wird ausgewertet und die seit der eingehenden E-Mail mit dem Titel SR#123456789 ausgeführten Aktionen werden ausgeführt.

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

In dieser Protokollzeile wird erklärt, dass die Aktivität gemäß dem Workflow-Design in die Warteschlange verschoben wurde.

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

Im gleichen Beispiel wird der Verzweigungsknoten TAC Branch erläutert, der mit der TAC-Regel verknüpft ist, die alle eingehenden E-Mails mit dem Titel angibt, der SR# enthält, der speziell ausgewertet wird, sowie die False-Aktion, die für die Regel ausgeführt wurde, da die eingehende E-Mail mit dem Titel versehen war, der Case # 123456789 enthält, und keine SR# im Titel enthielt. Daher wurde die Aktivität nicht verarbeitet und in die Standardausnahmewarteschlange verschoben.

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

Tipp: Wenn die Aktivität vor dem Senden von New_task in die Ausnahmenwarteschlange geroutet wird, müssen Sie sich auf die Workflowkonfiguration und Workflowregeln konzentrieren. Wenn die Aktivität nach dem Senden von New_task in die Ausnahmenwarteschlange geroutet wird, müssen Sie sich auf den EAAS-Prozess konzentrieren.

Keine aktiven eingehenden Workflows bei der Abteilungsüberprüfung

In diesem Beispiel wird der Unterschied zwischen dem aktiven Workflow für eingehende Anrufe und dem Fall ohne aktive Workflows für Protokolle veranschaulicht.

Die Vertriebsabteilung ist mit einem aktiven WF-Workflow für eingehenden Vertrieb konfiguriert. Wie Sie sehen, wird die Aktivität normal an die Warteschlange weitergeleitet, nachdem der eingehende Workflow ausgelöst wurde.

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

Wenn dagegen kein aktiver eingehender Workflow vorhanden ist, löst ECE den Beenden-Workflow aus. Dieser Workflow wird ausgeführt, wenn für die Abteilung kein definierter Workflow für eingehende E-Mails vorhanden ist.

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

Konfiguration und Problembehebung bei Alarm-Workflows

Der Alarm-Workflow ist praktischer, wenn sich eine große Anzahl von E-Mails in der Standard-Ausnahmewarteschlange befindet. Der Alarm-Workflow ist so konfiguriert, dass er Benachrichtigungen sendet, wenn Aktivitäten aufgrund von Workflowfehlern bei der Verarbeitung von Aktivitäten an die Ausnahmewarteschlange weitergeleitet werden.

Sie können E-Mail-Aktivitäten in der Standardausnahmewarteschlange im Alarm-Workflow wie in diesem Beispiel abschließen. Dieser Workflow sucht in der Standard-Ausnahmenwarteschlange nach E-Mail-Aktivitäten, die in 30 Minuten fällig sind, um sie an die TAC-Warteschlange zurückzuleiten. Sie müssen vermeiden, dass alle Aktivitäten zurück an die TAC-Warteschlange geroutet werden. Konfigurieren Sie diesen Fluss: Start > Alarm > TAC Queue.

Im Startknoten müssen Sie die Standardausnahmewarteschlange auswählen.

Auf der Registerkarte "Zeitplan" können Sie diesen Alarm-Workflow konfigurieren. In diesem Beispiel wurde sie einmal zu einem bestimmten Zeitpunkt ausgelöst.

In der Konfigurationsbedingung für Alarmregeln müssen Sie konfigurieren, welche Bedingungen Ihren spezifischen Geschäftsanforderungen entsprechen. In diesem Fall wurde sie für E-Mail-Aktivitäten konfiguriert, die sich in der Standard-Ausnahmewarteschlange befinden, deren SLA immer noch nicht für mehr als 30 Minuten verloren geht.

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

Wenn die Alarmkonfiguration auf "true" festgelegt ist, müssen Sie genauer auf die E-Mails eingehen, die von der Standard-Ausnahmewarteschlange zur TAC-Warteschlange geroutet werden, um unnötige E-Mails zu vermeiden, die an den Agenten weitergeleitet werden und deren Zeit vergeuden. In diesem Beispiel wird die Betreffbedingung angegeben, wenn sie case anstelle von SR enthält, wie im eingehenden Workflow angegeben, sodass E-Mails wieder an die TAC-Warteschlange weitergeleitet werden.

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

Schließlich sehen Sie hier in diesen Bildern, wie die Aktivität von der Standard-Ausnahmenwarteschlange zum verfügbaren Agenten in der TAC-Warteschlange geroutet wurde, nachdem der konfigurierte Workflow ausgelöst wurde.

Jetzt können die Agenten die Aktivitäten mit dem Betreff "Enthält Groß-/Kleinschreibung#" anstelle von "SR#" anzeigen.