Open Thema mit Navigation
Skripte des Typs E-Mail
Skripte dieses Typs haben verschiedene Funktionen. Einige der Skripte sind Teil der Standardsystemkonfiguration und müssen an die kundenspezifische Systemkonfiguration angepasst werden. Sie können auch eigene Skripte hinzufügen.
WICHTIGE INFORMATION
Seit ConSol CM-Version 6.9.4 gibt es zwei Modi für eingehende E-Mails:
- Mule/ESB - dieser Modus war schon in allen früheren CM-Versionen verfügbar
- NIMH (New Incoming Mail Handler) - neu in Version 6.9.4
Für alle Konfigurationen/Einstellungen, die für beide Modi gelten, gibt es keine weiteren Hinweise. Für alle Einstellungen, die je nach Modus unterschiedlich sind, gibt es zwei einzelne (d. h. Mule/ESB- or NIMH-spezifische) Abschnitte.
E-Mail-Skripte für die Verarbeitung von eingehenden E-Mails im ESB/Mule Mail-Modus
Wenn ConSol CM eine E-Mail erhält, wird diese von mehreren Skripten verarbeitet, siehe folgende Abbildung.
Abbildung 396: ConSol CM Admin Tool - E-Mail-Skripte (Mule/ESB Mail)
- IncomingMailRouting.groovy
Standardskript. Dies ist das erste Skript, das ausgeführt wird, wenn eine neue E-Mail eingeht. Hier wird entschieden, ob ein neues Ticket erstellt werden soll, ob die E-Mail zu einem vorhandenen Ticket gehört (dann wird AppendToTicket.groovy ausgeführt), oder ob die E-Mail zu einem geschlossenen Ticket gehört (dann wird MailToClosedTicket.groovy ausgeführt). Dieses Skript muss nicht geändert werden, um es an eine kundenspezifische Umgebung anzupassen.
- CreateTicket.groovy
Standardskript, das für die Erstellung eines Tickets zuständig ist, wenn eine E-Mail in einem der für ConSol CM konfigurierten Postfächer eingeht (siehe Abschnitt E-Mail). Wenn der E-Mail-Betreff nicht zum regulären Ausdruck im E-Mail-Betreff passt, mit dem die E-Mail an ein vorhandenes Ticket angehängt werden kann, wird dieses Skript ausgeführt. Hier werden, unabhängig vom Postfach, alle E-Mails verarbeitet, die ConSol CM erhalten hat (und die nicht einem vorhandenen Ticket zugewiesen wurden). In diesem Skript muss eine Standard-Queue für eingehende E-Mails definiert werden. Zusätzlich können weitere Werte von Benutzerdefinierten Feldern definiert werden (wie z. B. die Standardpriorität der per E-Mail erstellten Tickets). Alternativ kann anhand der To-Adresse oder anderer Parameter entschieden werden, in welcher Queue das neue Ticket erstellt werden soll. Dieses Skript muss normalerweise stark angepasst werden. Bitten Sie dafür einen ConSol CM-Consultant um Unterstützung.
- AppendToTicket.groovy
Standardskript, mit dem eine E-Mail an ein vorhandenes Ticket angehängt wird. Die Zuweisung der E-Mail zum Ticket wird normalerweise über einen Vergleich des E-Mail-Betreffs mit dem regulären Ausdruck vorgenommen. Eine detaillierte Beschreibung dieses Kontextes finden Sie im Abschnitt E-Mail. Normalerweise muss dieses Skript nicht verändert werden.
- MailToClosedTicket.groovy
Standardskript, das für die Verarbeitung von E-Mails, die zu geschlossenen Tickets gehören, zuständig ist. Das Standardsystemverhalten ist, ein neues Ticket für den Kunden (Absender der E-Mail) zu erstellen und eine Referenz zum alten/geschlossenen Ticket zu setzen. Normalerweise muss dieses Skript nicht verändert werden.
E-Mail-Skripte für die Verarbeitung von eingehenden E-Mails im NIMH-Modus
Wenn ConSol CM eine E-Mail erhält, wird diese von mehreren Skripten verarbeitet, siehe folgende Abbildung.
Abbildung 397: ConSol CM Admin Tool - E-Mail-Skripte (NIMH)
- NimhIncomingMailRouting.groovy
Standardskript. Dies ist das erste Skript, das ausgeführt wird, wenn eine neue E-Mail eingeht. Hier wird entschieden, ob ein neues Ticket erstellt werden soll, ob die E-Mail zu einem vorhandenen Ticket gehört (dann wird NimhAppendToTicket.groovy ausgeführt), oder ob die E-Mail zu einem geschlossenen Ticket gehört (dann wird NimhMailToClosedTicket.groovy ausgeführt). Dieses Skript muss nicht geändert werden, um es an eine kundenspezifische Umgebung anzupassen.
- NimhCreateTicket.groovy
Standardskript, das für die Erstellung eines Tickets zuständig ist, wenn eine E-Mail in einem der für ConSol CM konfigurierten Postfächer eingeht (siehe Abschnitt E-Mail). Wenn der E-Mail-Betreff nicht zum regulären Ausdruck passt, mit dem die E-Mail an ein vorhandenes Ticket angehängt werden kann, wird dieses Skript ausgeführt. Hier werden, unabhängig vom Postfach, alle E-Mails verarbeitet, die ConSol CM erhalten hat (und die nicht einem vorhandenen Ticket zugewiesen wurden). In diesem Skript muss eine Standard-Queue für eingehende E-Mails definiert werden. Zusätzlich können weitere Werte von Benutzerdefinierten Feldern definiert werden (wie z. B. die Standardpriorität der per E-Mail erstellten Tickets). Alternativ kann anhand der To-Adresse oder anderer Parameter entschieden werden, in welcher Queue das neue Ticket erstellt werden soll. Dieses Skript muss normalerweise stark angepasst werden. Bitten Sie dafür einen ConSol CM-Consultant um Unterstützung.
- NimhAppendToTicket.groovy
Standardskript, mit dem eine E-Mail an ein vorhandenes Ticket angehängt wird. Die Zuweisung der E-Mail zum Ticket wird normalerweise über einen Vergleich des E-Mail-Betreffs mit dem regulären Ausdruck vorgenommen. Eine detaillierte Beschreibung dieses Kontexts finden Sie im Abschnitt E-Mail. Normalerweise muss dieses Skript nicht verändert werden.
- NimhMailToClosedTicket.groovy
Standardskript, das für die Verarbeitung von E-Mails, die zu geschlossenen Tickets gehören, zuständig ist. Das Standardsystemverhalten ist, ein neues Ticket für den Kunden (Absender der E-Mail) zu erstellen und eine Referenz zum alten/geschlossenen Ticket zu setzen. Normalerweise muss dieses Skript nicht verändert werden.
Unterschiede zwischen den Skripten in Mule/ESB Mail und NIMH
Wenn NIMH aktiviert ist, müssen in den E-Mail-Skripten andere Groovy-Klassen verwendet werden als im ESB/Mule Mail-Modus. Eine Zuordnung finden Sie in der nachfolgenden Tabelle.
|
wenn erforderlich:
import com.consol.cmas.esb.mail.MailContextService
|
wenn erforderlich:
import com.consol.cmas.nimh.extension.MailSupportService
import com.consol.cmas.nimh.common.model.MailHolder
|
|
mailContextService
|
mailSupportService
|
|
msg
mit den entsprechenden Methoden:
mailLog.info("Routing " + msg.getUniqueId())
|
mailHolder
mit den entsprechenden Methoden:
mailLog.info("Routing " + mailHolder.getUid()
|
|
mailLog
|
mailLog
|
|
spring cm services
|
spring cm services
|
|
alle Stellen, an denen mailHolder verwendet wird
Beispiel: siehe Beispiel ALT unten
|
pipeContext (als Parameter in Aufrufen von mailSupportService verwendet)
Beispiel: siehe Beispiel NEU unten
pipeContext ist ein Objekt der Klasse MailPipeContext
|
|
msg.setProperty(...)
|
pipeContext.setAttribute(...)
|
|
ESB-Endpunkte im Mail-Routing-Skript ("target handlers"):
endpoints["esb_mail_mailToClosedTicketEndpoint"]
endpoints["esb_mail_appendToTicketEndpoint"]
endpoints["esb_mail_createTicketEndpoint"]
|
Skript-Endpunkte im Mail-Routing-Skript ("target handlers"):
endpoints["mailToClosedTicketScript"]
endpoints["appendToTicketScript"]
endpoints["createTicketScript"]
|
Beispiel ALT:
String email = mailContextService.extractMailFromField(msg)
Beispiel NEU:
String email = mailSupportService.extractMailFromField(mailHolder, pipeContext)
Die Schritte, die Sie ausführen müssen, um Ihr ConSol CM-System vom Mule/ESB Mail-Modus auf dem NIMH-Modus umzustellen, sind im Abschnitt Wechseln von Mule/ESB Mail zu NIMH beschrieben.
E-Mail-Skripte für ausgehende E-Mails
Für jede Queue kann ein E-Mail-Skript konfiguriert werden. Im Abschnitt Queue-Verwaltung finden Sie eine Erklärung über die Konfiguration dieses Skripts. Eine E-Mail, die (automatisch durch den Workflow oder manuell durch einen Bearbeiter) aus einem Ticket in dieser Queue geschrieben wird, durchläuft dieses Skript, bevor sie das ConSol CM-System verlässt. In diesem E-Mail-Skript können Sie also queue-spezifische Einstellungen für die ausgehende E-Mail ändern oder setzen. Ein häufiger Anwendungsfall ist das Einstellen einer queue-spezifischen Reply-To-Adresse, um teamspezifische Reply-To-Adressen verwenden zu können.
Ein Beispiel für ein ausgehendes E-Mail-Skript ist folgendes Skript, das zur ConSol CM-Standardapplikation gehört:
- ChangeOutgoingMail.groovy
Standardskript, das nicht verwendet wird, aber als Template für andere ausgehende E-Mail-Skripte dient. Sie können mit diesem Template queue-spezifische E-Mail-Skripte konfigurieren.
Innerhalb des ausgehenden E-Mail-Skripts ist das Java-Objekt mailEntry implizit als Objekt mail verfügbar. Sie müssen alle erforderlichen Attribute für die ausgehende E-Mail mit den Methoden mail.setAttribute() oder mail.setAttributes() setzen.
def queueReplyAddress = "serviceteam@mycompany.com"
// you might also use system properties for the queue-specific e-mail addresses and fetch an
// address using the configurationService!
mail.setAttribute('Reply-to', queueReplyAddress)
Code-Beispiel 63: E-Mail-Skript
Häufige E-Mail-Attribute sind:
- Bcc
- From
- Reply-to
- To
- Cc
- Subject
In RFC 5322 finden Sie eine sehr detaillierte Beschreibung des E-Mail-Formats.
Beachten Sie das folgende technische Verhalten von ConSol CM bei der Konfiguration von Reply-To-Adressen und passen Sie Ihr System entsprechend an!
Der technische Hintergrund:
Es gibt vier mögliche Reply-To-Adressen, mit denen Sie zu tun haben:
- Die Reply-To-Adresse, die in der System-Property mail.reply.to festgelegt ist. Wenn sie gesetzt ist, wird sie im Ticket-E-Mail-Editor im Web Client angezeigt. Ob es tatsächlich die Reply-To-Adresse ist, die in einer E-Mail angewendet wird, hängt von der Konfiguration des queue-spezifischen Skripts für ausgehende E-Mails ab. Siehe nächster Punkt. Wenn das Attribut der Seitenanpassung showReplyTo für den Typ mailTemplate auf false gesetzt ist, wird im Ticket-E-Mail-Editor keine Reply-To-Adresse angezeigt. Wenn die Property mail.reply.to gesetzt ist, wird diese Adresse trotzdem verwendet, außer es wird eine andere Adresse in einem Skript für ausgehende E-Mails gesetzt, siehe nächster Punkt.
- Die Reply-To-Adresse, die in einem queue-spezifischen Skript für ausgehende E-Mails gesetzt wird. Da das Skript für ausgehende E-Mails die letzte Instanz ist, die eine ausgehende E-Mail verarbeitet, ist die in diesem Skript gesetzte E-Mail-Adresse immer die angewendete Reply-To-Adresse. Falls die Property mail.reply.to gesetzt ist, wird diese mail-reply.to-address nicht verwendet (aber trotzdem im Ticket-E-Mail-Editor angezeigt, was verwirrend sein kann. Im nächsten Abschnitt ist erklärt, was dies für die Systemkonfiguration bedeutet).
- Die E-Mail-Adresse, die in der System-Property mail.from gesetzt ist. Wenn diese gesetzt ist und weder mail.reply.to noch eine queue-spezifische Reply-To-Adresse gesetzt ist, setzen die meisten E-Mail-Clients die From-Adresse als Reply-To-Adresse.
- Die E-Mail-Adresse des aktuellen Bearbeiters (der Bearbeiter, der im Web Client angemeldet ist). Diese persönliche E-Mail-Adresse wird als Reply-To-Adresse für E-Mails aus dem Web Client verwendet, wenn weder die Property mail.reply.to gesetzt ist, noch ein queue-spezifisches Skript für ausgehende E-Mails konfiguriert ist, noch die Property mail.from gesetzt ist.
Im Web Client wird im Ticketprotokoll immer die Reply-To-Adresse angezeigt, die für eine ausgehende E-Mail tatsächlich verwendet wurde. So wird immer die angewendete E-Mail-Adresse angezeigt, auch wenn die im Ticket-E-Mail-Editor angezeigte Adresse (die Property mail.reply.to) und die tatsächlich verwendete Reply-To-Adresse (die Reply-To-Adresse im queue-spezifischen Skript für ausgehende E-Mails) unterschiedlich sind. Die tatsächliche E-Mail-Adresse wäre in diesem Fall die Adresse aus dem Skript.
Unsere Empfehlung:
Es sollte immer eine Reply-To-Adresse für das System gesetzt werden! Sie können entscheiden, ob Sie
- mit der Reply-To-Adresse arbeiten, die in einem queue-spezifischen Skript für ausgehende E-Mails gesetzt wird
oder
- die System-Property mail.reply.to verwenden.
Da die E-Mail-Kommunikation immer über ConSol CM stattfinden soll und nicht über persönliche E-Mail-Adressen, sollte eine der beiden oben beschriebenen Systemeinstellungen verwendet werden, um zu verhindern, dass ConSol CM persönliche E-Mail-Adressen als Reply-To verwendet. Letzteres würde bedeuten, dass die E-Mails der Kunden an das persönliche E-Mail-Postfach des Bearbeiters gesendet werden statt an CM.
Auswirkungen auf die Systemkonfiguration:
- Der einfachste Weg, um eine Reply-To-Adresse zu setzen, ist die Verwendung der System-Property mail.reply.to. Sie wird im Ticket-E-Mail-Editor angezeigt und ist die tatsächlich verwendete Reply-To-Adresse.
- Wenn queue-spezifische Reply-To-Adressen erforderlich sind, empfehlen wir, ein Skript für ausgehende E-Mails zu schreiben, in dem die Queue-Namen den entsprechenden Reply-To-Adressen zugeordnet werden. Dieses Skript kann dann für Bcc, Cc oder andere Adressen ergänzt werden.
Sie können die Property mail.reply.to und die queue-spezifischen Reply-To-Adressen auch kombinieren: Für alle Queues ohne ein spezielles Skript für ausgehende E-Mails wird die Adresse aus mail.reply.to verwendet; für alle Queues mit einem queue-spezifischen Skript für ausgehende E-Mails, das eine Reply-To-Adresse enthält, wird diese verwendet.
Auswirkungen auf Workflow-Skripte, die E-Mails versenden:
(Eine detaillierte Erklärung dazu finden Sie im ConSol CM Process Designer-Handbuch!)
- Verwenden Sie das Objekt und die Methode configurationService.getValue("cmweb-server-adapter","mail.reply.to"), um den Wert der System-Property abzurufen und in der ausgehenden E-Mail als Reply-To-Adresse zu setzen.
- Verwenden Sie das Objekt Mail, wenn das queue-spezifische Skript verwendet werden soll, z. B. mail.useDefaultScript() . Damit wird die Property mail.reply.to überschrieben!
Wenn weder die System-Property noch das queue-spezifische Skript für ausgehende E-Mails verwendet wird, d. h. wenn die Reply-To-Adresse nicht gesetzt ist, wird vom E-Mail-Client normalerweise die From-Adresse als Reply-To-Adresse verwendet.
