Skripte werden im Bereich Skripte und Templates des Admin Tools gespeichert. Sie werden in Groovy geschrieben und sollten nur von erfahrenen ConSol CM-Consultants und -Administratoren editiert werden.
Öffnen Sie im Admin Tool das Navigationselement Skripte und Templates in der Navigationsgruppe System, um mit den Skripten zu arbeiten. Es wird der Tab Skripte angezeigt.
Abbildung 348: ConSol CM Admin Tool - Verwaltung von Skripten und Templates
Auf der linken Seite sehen Sie eine Liste aller Skripte. Die Liste kann über das Drop-down-Menü gefiltert werden, indem Sie dort den Skripttyp auswählen. Für jedes Skript müssen zwei Parameter gesetzt werden:
Die Buttons unter der Liste stellen die Standardfunktionen des Admin Tools bereit:
Auf der rechten Seite sehen Sie den Quelltext-Editor. Hier wird das in der Liste auf der linken Seite ausgewählte Skript angezeigt. Wenn Sie sich im Editiermodus befinden, können Sie hier den Quelltext des Skripts schreiben.
Der Quelltext-Editor bietet einen Editierbereich mit Syntaxhervorhebung, führt aber keinerlei Validierung des Codes durch. Die Richtigkeit des Codes müssen Sie selbst überprüfen.
Abbildung 349: ConSol CM Admin Tool - Skripte: Quelltext-Editor
Im unteren Bereich des Quelltext-Editors finden Sie folgende Buttons:
Im folgenden Abschnitt werden die möglichen Skripttypen erklärt. Die Beispiele sollen Ihnen einen Eindruck über die Verwendungsmöglichkeiten von Skripten vermitteln.
In diesem Abschnitt sind folgende Skripttypen beschrieben. Eine vollständige Übersicht über alle Skripttypen mit Links zu der entsprechenden Abschnitten finden Sie in der obigen Liste.
Im Web Client kann ein Ticket über die Option Duplizieren im Ticketmenü dupliziert werden. Sie können dies mit oder ohne Skript machen.
Abbildung 350: ConSol CM Web Client - Option Duplizieren im Ticketmenü
Die folgenden Abbildungen zeigen die Duplizierung eines Tickets ohne Duplizieren-Skript.
Abbildung 351: ConSol CM Web Client - Ursprüngliches Ticket
Abbildung 352: ConSol CM Web Client - Duplizieren des Tickets (ohne Duplizieren-Skript)
Wenn ein Ticket dupliziert wird, werden die folgenden Daten aus dem ursprünglichen Ticket übertragen (vergleichen Sie die beiden obigen Abbildungen):
Wenn ein Ticket dupliziert wird, werden die folgenden Daten nicht aus dem ursprünglichen Ticket übertragen (vergleichen Sie die beiden obigen Abbildungen):
Falls die Queue, in der sich das Ticket befindet, ein Duplizieren-Skript verwendet (siehe Abschnitt Queue-Verwaltung), wird dieses Skript ausgeführt, wenn der Bearbeiter auf Duplizieren klickt. Das Skript kann ähnlich wie ein Standardwerte-Skript eingesetzt werden (siehe folgender Abschnitt): Sie können Werte im zu erstellenden Ticket vorbelegen. Während der Duplizierung, d. h. vor der Erzeugung des Tickets, werden die Benutzerdefinierten Felder im Web Client mit diesen Werten gefüllt. Der Bearbeiter kann die Werte bei Bedarf ändern.
Denken Sie daran, dass Sie bei einem Duplizieren-Skript nicht im Workflow-Kontext arbeiten! Das heißt, das Objekt workflowApi (Implementierung von WorkflowContextService) ist nicht verfügbar!
Im folgenden Beispiel wird das Duplizieren-Skript zum Zurücksetzen des Datenfeldes Gewünschter Termin verwendet, um zu vermeiden, dass (duplizierte) ServiceDesk-Tickets ein falsches Service-Datum enthalten.
ticket.set("serviceDesk_fields.desiredDeadline", null)
Code-Beispiel 57: Duplizieren-Skript zum Zurücksetzen des Benutzerdefinierten Felds für den gewünschten Termin
Wenn das Skript der Queue zugewiesen ist (in diesem Beispiel ServiceDesk), ist das Feld für den gewünschten Termin leer, wenn das duplizierte Ticket dem Bearbeiter angezeigt wird (siehe folgende Abbildung).
Abbildung 353: ConSol CM Web Client - Dupliziertes Ticket (mit der Queue zugewiesenem Duplizieren-Skript)
Manchmal ist es erforderlich, dass ein Datenfeld eines Tickets bei der Erstellung des Tickets einen bestimmten Wert hat, d. h. wenn der Bearbeiter auf Neues Ticket klickt und das entsprechende Formular im Web Client geöffnet wird, sollen ein oder mehrere Werte voreingestellt sein. Dies erspart dem Bearbeiter den Aufwand, den Wert jedes Mal setzen zu müssen, z. B. wenn die Standardpriorität normal ist, kann dieser Wert voreingestellt werden. Sollte hoch oder niedrig erforderlich sein, kann der Bearbeiter den Wert entsprechend ändern.
Dieses Verhalten von ConSol CM kann durch ein oder mehrere Standardwerte-Skripte erreicht werden. Die Standardwerte können für jede Queue einzeln definiert werden. Pro Queue kann genau ein Standardwerte-Skript zugewiesen werden. Siehe folgendes Beispiel.
Abbildung 354: ConSol CM Web Client - Neues Ticket ohne Standardwerte
Ohne Standardwerte-Skript wird kein Wert für die Priorität gesetzt, wenn ein Bearbeiter ein neues Ticket im Web Client erstellt.
Um einen Standardwert zu definieren, muss ein Skript des Typs Standardwerte erstellt werden. Zuerst suchen wir in der Verwaltung der Benutzerdefinierten Felder das entsprechende Benutzerdefinierte Feld (in welcher Benutzerdefinierten Feldgruppe es sich befindet und welchen Namen es hat). Details dazu finden Sie im Abschnitt Verwaltung von Benutzerdefinierten Feldern (Einrichten des Ticketdatenmodells).
Denken Sie daran, dass Sie bei einem Standardwerte-Skript nicht im Workflow-Kontext arbeiten! Das heißt, das Objekt workflowApi (Implementierung von WorkflowContextService) ist nicht verfügbar!
Abbildung 355: ConSol CM Admin Tool - Verwaltung von Benutzerdefinierten Feldern
Da es sich bei priority um ein enum-Feld (d. h. eine Sortierte Liste) handelt, müssen Sie die möglichen (technischen) Werte prüfen, die in der Liste auftreten können, und den gewünschten Standardwert in der Verwaltung der Sortierten Listen suchen.
Abbildung 356: ConSol CM Admin Tool - Werte für die Priorität in der Verwaltung der Sortierten Listen
Die Gruppe, das Feld und der korrekte Wert können dann im neuen Skript in der entsprechenden Groovy-Methode verwendet werden.
Abbildung 357: ConSol CM Admin Tool - Verwendung von Gruppe, Feld und Wert im Skript
In der Queue-Verwaltung müssen wir das Skript der Queue zuweisen, in der der Standardwert verwendet werden soll.
Abbildung 358: ConSol CM Admin Tool - Zuweisen eines Standardwerte-Skripts zur Queue in der Queue-Verwaltung
Wenn der Bearbeiter die Ticketerstellung jetzt im Web Client beginnt, wird der Standardwert normal für das Feld Priorität gesetzt.
Abbildung 359: ConSol CM Web Client - Neues Ticket mit Standardwert
Denken Sie daran, dass es für jede Queue nur ein Standardwerte-Skript geben kann. Wenn Sie mehrere Standardwerte definieren möchten, müssen Sie dies in einem Skript tun. In diesem Fall können Sie auch den Namen des Skripts anpassen.
Wenn der gleiche Standardwert in unterschiedlichen Queues gesetzt werden soll und es noch andere Standardwerte gibt, muss dies ebenfalls in einem eigenen Skript pro Queue programmiert werden.
Standardmäßig werden die Felder eines Tickets, die mit dem Standardwerte-Skript vorausgefüllt werden, nicht überschrieben, d. h. wenn das Ticket in eine andere Queue verschoben wird, der ihr eigenes Standardwerte-Skript zugewiesen ist, versucht das zweite Skript Felder zu setzen, die bereits vom ersten Skript gefüllt wurden. Da dies nicht möglich ist, bleiben die Standardwerte des ersten Skripts erhalten.
Wenn ein Standardwerte-Skript vorhandene Werte überschreiben soll, muss der Modus Überschreiben aktiviert werden. Um diesen Modus zu aktivieren, fügen Sie am Anfang des Standardwerte-Skripts folgenden Code ein:
import com.consol.cmas.common.model.ticket.TicketPrototypeContext
TicketPrototypeContext.enableOverwriteMode()
Abhängige sortierte Listen sind hierarchische Listen, die eine ähnliche Datenstruktur abbilden wie MLAs (siehe Abschnitt MLA-Verwaltung). Im Gegensatz zu MLAs wird bei abhängigen sortierten Listen immer nur eine Ebene gleichzeitig angezeigt. Abhängig von dem Wert, den der Benutzer auf der aktuellen Listenebene auswählt, wird eine andere Liste der untergeordneten Ebene geöffnet. Es muss nicht für jeden Listeneintrag eine untergeordnete Liste geben. In der Graphenterminologie kann eine Liste also eine Kombination aus Knoten und Blättern sein. Ein Skript für abhängige sortierte Listen wird der Benutzerdefinierten Feldgruppe, Datenobjektgruppe oder Ressourcenfeldgruppe zugewiesen, für die es benötigt wird.
Siehe folgendes Beispiel:
In einem Helpdesk-Ticket kann ein Ort ausgewählt werden. Zuerst wählt der Benutzer den Kontinent aus. Je nach ausgewähltem Kontinent wird eine Unterliste mit Subkontinenten oder mit Ländern angezeigt. Alle Benutzerdefinierten Felder müssen zuerst als normale Felder des Typs enum (Sortierte Liste) definiert werden. Im Skript wird der Wert der ersten Listenebene überprüft und je nachdem, welcher Wert ausgewählt wurde, wird eine andere Liste auf der zweiten Ebene angezeigt. Sie können so viele Ebenen anlegen, wie Sie möchten. Bedenken Sie aber, dass das Editieren des Skripts immer komplexer wird.
Das Skript für abhängige sortierte Listen wird im Admin Tool gespeichert. Lassen Sie sich beim Erstellen bzw. Editieren des Skripts von einem ConSol CM-Consultant unterstützen, da es sich um eine ziemlich komplexe Aufgabe handelt.
Abbildung 360: ConSol CM Admin Tool - Skript für abhängige sortierte Listen
Das Skript für abhängige sortierte Listen wird der Benutzerdefinierten Feldgruppe, Datenobjektgruppe oder Ressourcenfeldgruppe zugewiesen, für die es benötigt wird.
Abbildung 361: ConSol CM Admin Tool - Zuweisen eines Skripts für abhängige sortierte Listen zu einer Benutzerdefinierten Feldgruppe
Im Web Client sieht der Bearbeiter nur die Unterliste des Wertes, den er auf der ersten Listenebene ausgewählt hat.
Abbildung 362: ConSol CM Web Client - Unterliste des Kontinents Europa
Abbildung 363: [fuzzy]ConSol CM Web Client - Unterliste des Kontinents Amerika
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:
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.
Wenn ConSol CM eine E-Mail erhält, wird diese von mehreren Skripten verarbeitet, siehe folgende Abbildung.
Abbildung 364: ConSol CM Admin Tool - E-Mail-Skripte (Mule/ESB Mail)
Wenn ConSol CM eine E-Mail erhält, wird diese von mehreren Skripten verarbeitet, siehe folgende Abbildung.
Abbildung 365: ConSol CM Admin Tool - E-Mail-Skripte (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.
|
Mule |
NIMH |
|---|---|
|
wenn erforderlich:
|
wenn erforderlich:
|
|
|
|
|
mit den entsprechenden Methoden:
|
mit den entsprechenden Methoden:
|
|
|
|
|
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 |
|
ESB-Endpunkte im Mail-Routing-Skript ("target handlers"):
|
Skript-Endpunkte im Mail-Routing-Skript ("target handlers"):
|
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.
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:
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 58: E-Mail-Skript
Häufige E-Mail-Attribute sind:
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:
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
oder
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:
Auswirkungen auf Workflow-Skripte, die E-Mails versenden:
(Eine detaillierte Erklärung dazu finden Sie im ConSol CM Process Designer-Handbuch!)
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.
Skripte dieses Typs sind im Admin Tool gespeichert, da sie in vielen Workflow-Skripten verwendet werden, d. h. der Code des Admin-Tool-Skripts wird mehr als einmal in einem oder mehreren Workflows benötigt. Es ist einfacher, weniger fehleranfällig und zeitsparender, die Skripte an einem zentralen Ort (im Admin Tool) zu speichern und sie in den Workflows nur zu referenzieren, anstatt den gleichen Code an unterschiedlichen Stellen in jedem Workflow, in dem er verwendet wird, zu editieren. Außerdem kann das Admin-Tool-Skript während der Workflow-Entwicklung einfach geändert werden und die Änderung ist sofort wirksam, wohingegen ein veränderter Workflow zuerst installiert werden muss.
Eine detaillierte Einführung in die Workflow-Programmierung finden Sie im ConSol CM Process Designer Handbuch. An dieser Stelle finden Sie ein kurzes Beispiel.
Der Code in einer Workflow-Aktivität referenziert lediglich das Skript, z. B.:
scriptExecutionService.execute(scriptProviderService.createDatabaseProvider("DisplayCustomerData.groovy"))
Das entsprechende Skript wird im Admin Tool gespeichert:
Abbildung 366: ConSol CM Admin Tool - Workflow-Skript
Es ist auch möglich, Parameter (key-value pairs) an das Admin-Tool-Skript zu übergeben. Dies ist detailliert im ConSol CM Process Designer Handbuch beschrieben.
In bestimmten Anwendungsfällen ist es möglicherweise erforderlich, ein Skript auszuführen, nachdem ein Ticket eine Workflow-Aktivität durchlaufen hat. Diese Art von Skript kann zum Beispiel verwendet werden, um nach der Ausführung einer Workflow-Aktivität ein anderes Ticket im Web Client anzuzeigen. Aus der Sicht des Bearbeiters springt der Web Client zum nächsten Ticket. Dies kann, je nach Anwendungsfall, ein Child-Ticket oder das nächste Ticket in der Liste sein.
Das Systemverhalten wird in einem Admin-Tool-Skript definiert, dem PostActivityExecutionScript (manchmal auch Standardskript für Workflow-Aktivität genannt). Der Name des Skripts muss in der System-Property cmweb-server-adapter, postActivityExecutionScriptName gesetzt werden, siehe System-Properties.
Dieses Skript wird nach jeder manuellen Workflow-Aktivität ausgeführt. Dies bedeutet, dass Sie alle Kontrollmechanismen und die gesamte Intelligenz in das Skript einfügen müssen:
Ab Version 6.10.2 kann ConSol CM mit einem PostActivityExecutionScript einen der vier unterschiedlichen Seitentypen (im Ansichtsmodus) öffnen:
Das Skript muss nur das entsprechende Objekt zurückgeben. Der folgende Code zeigt ein Beispiel für jeden der vier Typen.
switch(activity.name){
case 'defaultScope/Goto_ticket':
return ticketService.getByName("SUP-11")
case 'defaultScope/Goto_contact':
return unitService.getById(123)
case 'defaultScope/Goto_company':
return unitService.getById(456)
case 'defaultScope/Goto_resource':
return resourceService.getById(890)
}
Beispiel: Zum nächsten Ticket in einer Liste springen.
Abbildung 367: ConSol CM Admin Tool - Property zur Definition von postActivityExecutionScriptName
Das PostActivityExecutionScript ermöglicht es auch, zu einer Unit-Seite (d. h. einer Firmenseite oder einen Kontaktseite) oder einer Ressourcenseite zu springen, indem die Unit bzw. die Ressource im Skript zurückgegeben wird.
Siehe folgendes Beispielskript:
switch(activity.name){
case 'defaultScope/Goto_the_ticket':
return ticketService.getByName("SUP-11")
case 'defaultScope/Goto_the_contact':
return unitService.getById(123)
case 'defaultScope/Goto_the_company':
return unitService.getById(456)
case 'defaultScope/Goto_the_resource':
return resourceService.getById(890)
}
Code-Beispiel 59: PostActivityExecutionScript
Ein anderes Beispiel, das das Verhalten des Web Clients zeigt:
Abbildung 368: ConSol CM Admin Tool - PostActivityExecutionHandler-Skript
switch(activity.name){
case 'defaultScope/Service_Desk/New_ticket/Open_Page_of_Main_Contact':
def main_cont = ticket.getMainContact()
return main_cont
// ( ... )
}
Code-Beispiel 60: PostActivityExecutionHandler
Abbildung 369: ConSol CM Process Designer - Aktivität, die mit dem PostActivityExecutionScript gesteuert wird
Abbildung 370: ConSol CM Web Client - Ticket mit Workflow-Aktivität, mit der der Web Client zur Kontaktseite springt
Abbildung 371: ConSol CM Web Client - Kontaktseite, die direkt aus dem Ticket geöffnet wurde