In diesem Kapitel werden folgende Themen behandelt:
Eine der Kernfunktionalitäten von ConSol CM ist das Zusammenspiel mit einer E-Mail-Infrastruktur. Auf diese Weise können Bearbeiter manuelle E-Mails senden, und das System kann automatische E-Mails an Kunden und Bearbeiter senden, so wie es im entsprechenden Prozessschritt erforderlich ist. Natürlich muss ConSol CM auch E-Mails empfangen. Dazu werden E-Mails aus einem oder mehreren Postfächern mit ConSol CM-E-Mail-Adressen abgerufen. Eine detaillierte Erklärung des Zusammenspiels zwischen dem Mail-Server und ConSol CM finden Sie im ConSol CM Administratorhandbuch und ConSol CM Betriebshandbuch. An dieser Stelle ist nur das Zusammenspiel mit dem Workflow erklärt.
Abbildung 67: ConSol CM Process Designer - Mail-Trigger
Wenn eine E-Mail empfangen wird, die zu einem vorhandenen und aktiven (offenen) Ticket gehört, ist es möglicherweise erforderlich, diese Aktion zu erfassen und danach bestimmte Aktionen durchzuführen. Dies kann durch die Verwendung von einem oder mehreren Mail-Triggern in einem Workflow erreicht werden.
Bedenken Sie, dass (in der Standardkonfiguration, d. h. ohne Änderung des Admin-Tool-Skripts AppendToTicket.groovy) das Anhängen der E-Mail an das Ticket über den Ticket-Tag im Betreff, z. B. Ticket (<TicketNumber>), die einzige automatische Aktion ist, die von ConSol CM nach Erhalt einer E-Mail in einem bestimmten Postfach durchgeführt wird. Siehe auch ConSol CM Administratorhandbuch, Abschnitt Skripte des Typs E-Mail.
Alle anderen Aktionen, die durchgeführt werden sollen, wenn eine E-Mail eingeht, müssen manuell im Workflow (und/oder in Admin-Tool-Skripten) programmiert werden!
Beispiele für die Verwendung von Mail-Triggern sind:
Wenn eine E-Mail eingeht ...
Wenn ein Mail-Trigger an einer Aktivität hängt, wird diese Aktivität nur ausgeführt, wenn eine E-Mail eingegangen ist.
Abbildung 68: ConSol CM Process Designer - Mail-Trigger an Aktivität
Klicken Sie in der Palette auf das Mail-Trigger-Symbol und ziehen Sie es in den gewünschten Bereich. Es wird automatisch an den oberen Rand des Bereichs angefügt. Sie können die Position später ändern (ziehen Sie den Trigger nach links oder rechts, um das Layout zu verbessern). Es kann pro Bereich nur ein Mail-Trigger verwendet werden.
Ein Mail-Trigger, der an einem Bereich hängt, kann nicht in einen anderen Bereich verschoben werden. Wenn Sie einen Mail-Trigger an einen anderen Bereich anfügen möchten, entfernen Sie den bereits erstellen Trigger und erstellen Sie einen neuen Trigger für den richtigen Bereich.
Sie können vom Trigger ausgehend Verbindungen zu Aktivitäten oder Entscheidungsknoten ziehen, die sich hinter dem Trigger befinden sollen. Der erste Schritt, der nach dem Mail-Trigger ausgeführt wird, muss immer eine automatische Aktivität sein!
In dem seltenen Fall, dass Sie einen Mail-Trigger an eine Aktivität hängen müssen (wir empfehlen dies nicht!), klicken Sie in der Palette auf das Mail-Trigger-Symbol und ziehen es in die gewünschte Aktivität. Es wird an die Ecke der Aktivität angefügt.
Ein Mail-Trigger, der an einer Aktivität hängt, kann nicht in eine anderen Aktivität oder einen Bereich verschoben werden. Wenn Sie einen Mail-Trigger an eine andere Aktivität oder einen Bereich anfügen möchten, entfernen Sie den bereits erstellen Trigger und erstellen Sie einen neuen Trigger für die richtige Aktivität bzw. den Bereich.
Ein Mail-Trigger hat keine Eigenschaften.
Wenn für ein Ticket, das sich gerade in dem Bereich befindet, eine E-Mail eingegangen ist, soll das Ticket-Icon im Web Client mit dem Overlay mail gekennzeichnet werden.
Der Mail-Trigger hängt am Bereich und das Overlay wird in der nachfolgenden automatischen Aktivität, die mit dem Trigger verbunden ist, hinzugefügt. Die Overlay-Gültigkeit ist Aktivität.
Auf diese Weise wird das Ticket mit dem Overlay gekennzeichnet, wenn eine E-Mail eingegangen ist. Sobald der Bearbeiter das Ticket in eine andere Aktivität bewegt hat, verschwindet das Overlay.
Bedenken Sie, dass das Ticket seinen Kontext nicht verlässt. Das einzige, was passiert, ist, dass ein Overlay zum Ticket-Icon hinzugefügt wird. Das Ticket kehrt dann an seine ursprüngliche Position im Workflow zurück. Dies wird auch Interrupt genannt. Eine detaillierte Erklärung dazu finden Sie im Abschnitt Prozesslogik.
Abbildung 69: ConSol CM Process Designer - Anwendungsfall 1: Bereich mit Mail-Trigger
Abbildung 70: ConSol CM Web Client - Anwendungsfall 1: Ticket mit Overlay-Icon
Wenn für ein Ticket, das sich gerade in dem Bereich befindet, eine E-Mail eingegangen ist, soll das Ticket-Icon im Web Client mit dem Overlay mail gekennzeichnet werden. Zusätzlich soll das Ticket an eine Position verschoben werden, an der es wartet, bis der Bearbeiter bestätigt, dass er die E-Mail gelesen hat.
Der Mail-Trigger hängt am Bereich und das Overlay wird in der nachfolgenden automatischen Aktivität hinzugefügt. Die Overlay-Gültigkeit ist Aktivität. Auf diese Weise wird das Ticket mit dem Overlay gekennzeichnet, wenn eine E-Mail eingegangen ist.
Innerhalb des Skripts, das auf den Mail-Trigger folgt, wird das Boolean-Feld mail_to_read auf true gesetzt. Im Workflow wird bei Bedarf die Aktivität E-Mail gelesen angeboten. Sie wird nur angezeigt, wenn der Wert des Boolean-Feldes mail_to_read true ist. Dies ist ein stärkerer Mechanismus, um den Bearbeiter an eine eingegangene E-Mail zu erinnern, als nur ein Overlay. Der Bearbeiter muss die E-Mail bestätigen, indem er die Workflow-Aktivität E-Mail gelesen explizit ausführt. Innerhalb dieser Workflow-Aktivität wird der Wert des Boolean-Feldes mail_to_read wieder auf false gesetzt. Jetzt ist das Ticket bereit, eine weitere E-Mail zu erhalten und den Bearbeiter zu benachrichtigen.
Bedenken Sie auch hier, dass das Ticket seinen Kontext nicht in Folge der Aktion verlässt, die nach Eingang der E-Mail ausgeführt wird. Es wird lediglich ein Overlay an das Ticket-Icon angefügt und eine Variable des Typs boolean geändert. Das Ticket kehrt dann an seine ursprüngliche Position im Workflow zurück. Es handelt sich also um einen Interrupt. Eine detaillierte Erklärung dazu finden Sie im Abschnitt Prozesslogik.
Abbildung 71: ConSol CM Process Designer - Anwendungsfall 2: Bereich mit Mail-Trigger
Abbildung 72: ConSol CM Process Designer - Anwendungsfall 2: Eigenschaften der Aktivität "E-Mail empfangen"
Abbildung 73: ConSol CM Admin Tool - Anwendungsfall 2: Neues Boolean-Feld zum Erfassen der E-Mail
Abbildung 74: ConSol CM Process Designer - Anwendungsfall 2: Skript der Aktivität "E-Mail empfangen"
Abbildung 75: ConSol CM Process Designer - Anwendungsfall 2: Aktivität "E-Mail gelesen"
Abbildung 76: ConSol CM Process Designer - Anwendungsfall 2: Eigenschaften der Aktivität "E-Mail gelesen"
Abbildung 77: ConSol CM Process Designer - Anwendungsfall 2: Bedingungsskript der Aktivität "E-Mail gelesen"
Abbildung 78: ConSol CM Process Designer - Anwendungsfall 2: Skript der Aktivität "E-Mail gelesen"
Abbildung 79: ConSol CM Web Client - Anwendungsfall 2: Workflow-Aktivität "E-Mail gelesen"
Wenn eine E-Mail eingegangen ist, feuert zuerst der Mail-Trigger des innersten der möglichen Bereiche.
Beispiel 1:
Das Ticket befindet sich an Position (1) im Bereich Wiedervorlage. Wenn eine E-Mail eingeht, feuert zuerst der Mail-Trigger dieses Bereichs (2) und infolgedessen wird das Ticket in einen anderen Bereich verschoben (3).
Abbildung 80: ConSol CM Process Designer - Beispiel 1: Mail-Trigger eines Unterbereichs aktiv
Beispiel 2:
Das Ticket befindet sich an Position (1) im Bereich Vorgang in Arbeit. Wenn eine E-Mail eingeht, feuert der Mail-Trigger des globalen Bereichs (2) (da der Bereich Vorgang in Arbeit keinen Mail-Trigger hat). Die Position des Tickets wird also nicht verändert (3).
Abbildung 81: ConSol CM Process Designer - Beispiel 2: Mail-Trigger des globalen Bereichs aktiv