Best Practices

Verwendung von Bereichen zur Organisation des Workflows

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:

Variante A: Verwenden eines globalen Bereichs

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 168: 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 Ende eine bestimmte Reaktion des Tickets benötigen, können Sie zusätzlich einen Mail-Trigger verwenden, der am Bereich Ende hängt.

Variante B: Verwenden von drei oder mehr Hauptbereichen

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 169: ConSol CM Process Designer - Workflow mit drei Arten von Hauptbereichen

Position des Startknotens

Die beste Postion für den Startknoten (siehe Abschnitt 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 170: ConSol CM Process Designer - Position des Startknotens (1)

Abbildung 171: ConSol CM Process Designer - Position des Startknotens (2)

Speichern von Skripten

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.

Verwenden Sie im Workflow-Skript folgende Syntax (siehe auch Beispiel im folgenden Abschnitt):

scriptExecutionService.execute("myscript.groovy")

Wann im Admin Tool gespeicherte Workflow-Skripte verwendet werden

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:

Wie im Admin Tool gespeicherte Workflow-Skripte verwendet werden

Admin-Tool-Skripte, die im Workflow verwendet werden, müssen vom Typ Workflow sein. Ein Admin-Tool-Skript wird normalerweise über die Interface ScriptExecutionService aus dem Workflow aufgerufen.

scriptExecutionService.execute("myscript.groovy")

Code-Beispiel 78: Aufrufen eines Admin-Tool-Skripts aus dem Workflow

// 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("myscript.groovy", params)

Code-Beispiel 79: Aufrufen eines Admin-Tool-Skripts aus dem Workflow unter Verwendung von Parametern

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.

Optimierung von Trigger-Kombinationen

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 von unnötigen Ticket-Update-Events

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 80: Code, der ein TicketUpdateEvent anstößt

//this method does NOT throw a TicketUpdateEvent!

ticket.setEngineer(workflowApi.currentEngineer)

Code-Beispiel 81: Code, der kein TicketUpdateEvent anstößt

Verwenden des Parameters zum Deaktivieren von automatischen Aktualisierungen

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"

Vermeiden von sich selbst auslösenden Event-Triggern

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

Verwenden der richtigen Komponenten mit Zeit-Triggern

Abbildung 177: Ein Zeit-Trigger mit einer automatischen Aktivität

Es gibt zwei Möglichkeiten, um ein Ereignis zu implementieren, das eintreten soll, wenn ein Zeit-Trigger gefeuert hat:

Die Best Practice von ConSol CM bezüglich dieses Anwendungsfalls ist Folgende: