In diesem Kapitel werden folgende Themen behandelt:
Eines der ersten Dinge, die Sie bei der Entwicklung des Konzepts für einen Workflow berücksichtigen müssen, ist die Anzahl und Anordnung der Bereiche (Scopes). In der Einführung in Bereiche können Sie Ihr Wissen über Bereiche auffrischen.
Natürlich können Sie den Workflow zu einem späteren Zeitpunkt immer noch ändern, was sich aber auf bereits vorhandene Tickets, Sichten und Reports auswirken kann. Dies ist insbesondere dann wichtig, wenn der Workflow in einer Produktionsumgebung eingesetzt wird.
Berücksichtigen Sie folgende Punkte beim Aufsetzen der Grundstruktur eines Workflows:
Ein globaler Bereich ist ein Bereich, der alle anderen Bereiche des Workflows enthält. Möglicherweise möchten Sie so einen globalen Bereich verwenden, weil in einigen Prozessen während des gesamten Prozesses auf Events reagiert werden muss. Diese Events werden mithilfe von Triggern implementiert, die an den globalen Bereich angehängt werden. Wenn Sie zum Beispiel im gesamten Prozess überwachen möchten, ob eine E-Mail eingegangen ist, hängen Sie einen Mail-Trigger (siehe Abschnitt Mail-Trigger) an den globalen Bereich. Alle Unterbereiche des globalen Bereichs erben die Überwachung durch diesen Trigger. Wenn die E-Mails nur für einen Unterbereich überwacht werden sollen, können Sie den Mail-Trigger an diesen Unterbereich anhängen.
Das gleiche gilt für alle anderen Trigger, d. h. Event-Trigger (siehe Abschnitt Event-Trigger) und Zeit-Trigger (siehe Abschnitt Zeit-Trigger).
Der Startknoten sollte immer außerhalb des globalen Bereichs positioniert werden.
Abbildung 167: ConSol CM Process Designer - Workflow mit globalem Bereich
Denken Sie daran, dass Sie in inneren Bereichen immer Trigger verwenden können, die das Ereignis verbrauchen (siehe Abschnitt Reihenfolge des Feuerns von Event-Triggern in hierarchischen Bereichen als Beispiel für Event-Trigger). Wenn Sie zum Beispiel einen Mail-Trigger für den gesamten Prozess im globalen Bereich verwenden möchten, aber im Bereich Abgeschlossen eine bestimmte Reaktion des Tickets benötigen, können Sie zusätzlich einen Mail-Trigger verwenden, der am Bereich Abgeschlossen hängt.
Ein alternativer Weg zum Aufbauen eines Workflows ist die Verwendung von drei oder mehr Hauptbereichen:
Die folgende Abbildung zeigt ein Beispiel für einen Workflow, der nach diesem Prinzip aufgebaut ist.
Abbildung 168: ConSol CM Process Designer - Workflow mit drei Arten von Hauptbereichen
Die beste Postion für den Startknoten (siehe Abschnitt Workflow-Komponenten: Startknoten) hängt von der Verwendung von Triggern im auf den Knoten folgenden Bereich ab. Wenn im ersten Bereich, in den die Tickets nach dem Startknoten wandern, Zeit-Trigger verwendet werden, sollte der Startknoten außerhalb des Bereichs platziert werden. Wenn sich der Startknoten im ersten Bereich befindet, wird der Zeit-Trigger möglicherweise nicht richtig initialisiert. Platzieren Sie den Startknoten also im Standardbereich.
Abbildung 169: ConSol CM Process Designer - Position des Startknotens
Skripte, die immer wieder in Workflow-Aktivitäten und/oder Bedingungsskripten verwendet werden, sollten im Abschnitt Skripte des Admin Tools gespeichert und aus dem Workflow aufgerufen werden.
Abbildung 170: Direktes Aufrufen eines Skripts im Workflow
Abbildung 171: Aufrufen eines Admin-Tool-Skripts aus einer Workflow-Aktivität
Wir empfehlen weder diese Methode immer zu verwenden, noch raten wir von dieser Methode ab. Stattdessen zeigen wir Ihnen die Vor- und Nachteile dieses Ansatzes und Sie können selber entscheiden, wo Sie sie in Ihrem System anwenden möchten.
Die Vorteile des Speicherns von Workflow-Skripten im Admin Tool sind:
Die Nachteile des Speicherns von Workflow-Skripten im Admin Tool sind:
Admin-Tool-Skripte, die im Workflow verwendet werden, müssen vom Typ Workflow sein. Ein Admin-Tool-Skript wird immer über die Interface ScriptProvider aus dem Workflow aufgerufen.
def scriptProvider = scriptProviderService.createDatabaseProvider("scriptName.groovy")
def r = scriptExecutionService.execute(scriptProvider)
Code-Beispiel 94: Aufrufen eines Admin-Tool-Skripts aus dem Workflow (einziger Weg in CM-Versionen 6.10.4 und älter, in CM 6.10.5 und höher noch verfügbar)
// Create the scriptProvider for the required Admin Tool script, here "scriptName.groovy"
def scriptProvider = scriptProviderService.createDatabaseProvider("scriptName.groovy")
// Define a HashMap with the key-value pairs which you would like to pass to the Admin Tool
def params = [ "templateName": "newCustomer" ]
// Execute the script. The passed parameters are available in the Admin Tool script. In the
// example, the variable templateName does not have to be defined in the Admin Tool script
// but it is present based on the definition in the passed HashMap.
// The variable r will contain the return value of the script or Null if there is no return
// value
def r = scriptExecutionService.execute(scriptProvider, params)
Code-Beispiel 95: Aufrufen eines Admin-Tool-Skripts aus dem Workflow unter Verwendung von Parametern (einziger Weg in CM-Versionen 6.10.4 und älter, in CM 6.10.5 und höher noch verfügbar)
scriptExecutionService.execute("MyScript")
Code-Beispiel 96: Aufrufen eines Admin-Tool-Skripts aus dem Workflow (nur CM-Versionen 6.10.5 und höher)
Da das Objekt workflowApi (siehe Abschnitt workflowAPI) in den Admin-Tool-Skripten nicht verfügbar ist, müssen Sie andere Klassen mit Methoden finden, die Sie anstelle der Methoden von workflowAPi verwenden können.
Vermeiden Sie das unnötige Ausführen von Triggern! Es verbraucht Ressourcen und verlangsamt die Performance der Applikation.
Beispiel 1:
Dieses Beispiel zeigt viele Event-Trigger in einem großen globalen Bereich.
Abbildung 172: ConSol CM Process Designer - Bereich mit Triggern
Beispiel 2:
Verwenden Sie Trigger wenn möglich im kleinstmöglichen Bereich (in diesem Beispiel wurde der Trigger für Entscheidung6 in einen kleineren Bereich verschoben).
Abbildung 173: ConSol CM Process Designer - Verschieben eines Triggers in einen kleineren Bereich
Beispiel 3:
Wenn es nicht möglich ist, Trigger in kleinere Bereiche zu verschieben und Sie nicht alle Trigger aufrufen möchten, wenn eine Aktivität ausgeführt wird, verschieben Sie diese Aktivität in einen äußeren Bereich ohne Trigger.
Abbildung 174: ConSol CM Process Designer - Separate Bereiche mit und ohne Trigger
In diesem Beispiel wurde die Position von Aktivität3 optimiert. Sie hat vorher viele Entscheidungen angestoßen, die alle bei Nichts landeten. Die Ausführung von Aktivität3 außerhalb des globalen Bereichs sorgt für eine gute Qualität der Workflow-Performance!
Vermeiden Sie unnötige Ticket-Update-Events (Java-Klasse TicketUpdateEvent)!
Das Zuweisen des aktuellen Bearbeiters (der Bearbeiter, der angemeldet ist und im Web Client arbeitet) zu einem Ticket kann auf zwei Wegen erfolgen. Bei einer Lösung wird ein Ticket-Update-Event angestoßen, bei der anderen Lösung nicht. Wenn es für den Anwendungsfall nicht erforderlich ist, einen TicketUpdateEvent anzustoßen, sollten Sie dies vermeiden, da unnötige Aufrufe von TicketUpdateEvent die Performance verschlechtern.
//this method throws a TicketUpdateEvent after assigning the current engineer to the ticket
workflowApi.assignEngineer(workflowApi.currentEngineer)
Code-Beispiel 97: Code, der ein TicketUpdateEvent anstößt
//this method does NOT throw a TicketUpdateEvent!
ticket.setEngineer(workflowApi.currentEngineer)
Code-Beispiel 98: Code, der kein TicketUpdateEvent anstößt
Seien Sie vorsichtig bei der Verwendung des Flags Autom. Aktualisierung deaktivieren!
Denken Sie daran, dass standardmäßig nach der jeder Ausführung einer Aktivität ein Ticket-Update-Event angestoßen wird. Ein Ticket-Update-Event ist eine Operation mit großen Auswirkungen, die vorsichtig eingesetzt werden sollte!
Um Performance-Probleme zu vermeiden, können Sie den Flag Autom. Aktualisierung deaktivieren setzen. Es hängt von der Geschäftslogik ab, ob es Sinn macht, den Flag zu verwenden oder nicht.
In einer Kette mit automatischen Aktivitäten ist eine gute Vorgehensweise zum Beispiel:
Abbildung 175: ConSol CM Process Designer - Aktivitäten mit der Option "Autom. Aktualisierung deaktivieren"
Wenn Sie einen Event-Trigger verwenden, auf den eine automatische Aktivität folgt, achten Sie darauf, dass in dieser automatischen Aktivität die Felder oder Objekte, die den Event-Trigger auslösen, nicht noch einmal geändert werden (wodurch der Trigger erneut feuern würde)!
Wenn der Anwendungsfall vorsieht, dass die Felder, die das Feuern des Triggers ausgelöst haben, erneut geändert werden müssen, muss die Logik, mit der die Felder geändert werden, außerhalb des Bereichs, in dem sich der Trigger befindet, platziert werden.
Abbildung 176: ConSol CM Process Designer - Vermeiden von sich selbst auslösenden Event-Triggern