Event-Trigger

Einführung zu Event-Tiggern

In Geschäftsprozessen treten häufig Ereignisse auf, um die sich ein Bearbeiter im Rahmen des regulären Prozesses kümmern muss. Zum Beispiel kann es erforderlich sein, den Teamleiter zu informieren, wenn jemand die Priorität eines Tickets auf Sehr hoch stellt. Oder es muss nach dem Zuweisen eines neuen Bearbeiters zu einem Ticket überprüft werden, ob dieser Bearbeiter angemeldet ist (wenn er nicht angemeldet ist, muss das Ticket an einen anderen Bearbeiter übertragen werden). Es gibt im Arbeitsalltag eine Vielzahl an Beispielen für solche Ereignisse.

Abbildung 91: ConSol CM Process Designer - Event-Trigger

ConSol CM kann Ereignisse mithilfe von Event-Triggern erfassen und auf die folgenden Arten von Ereignissen reagieren:

• Ändern des Bearbeiters
• Ändern der Queue
• Ändern des Themas
• Ändern von zusätzlichen Bearbeitern
• Verknüpfte Ressourcen
• Zeitbuchung
• Ändern eines Kommentars
  (normalerweise durch Hinzufügen eines Kommentars, d. h. eines Textkommentars oder einer E-Mail)
• Ändern eines Ticketfeldes, das vom Systementwickler definiert wird
  (dies kann z. B. die Priorität, eine Kategorie oder der Inhalt eines bestimmten Textfeldes sein)

Wenn das Ereignis eintritt, feuert der Event-Trigger.

Sie als Workflow-Entwickler müssen alles implementieren, was geschehen soll, wenn ein Event-Trigger gefeuert hat! Es gibt keine automatischen Aktionen. Der Event-Trigger gibt lediglich das Signal Ereignis eingetreten.

Ein Workflow kann so viele Event-Trigger haben, wie benötigt werden. Sie müssen allerdings sicherstellen, dass es im Prozess möglich ist, dass alle Event-Trigger potentiell feuern können (und dass keiner von einer Aktion abhängt, die nie auftreten kann, da ein anderer Event-Trigger (oder Zeit-Trigger) vorher gefeuert hat). Weitere Informationen dazu finden Sie im Abschnitt Prozesslogik.

Hinzufügen eines Event-Triggers zu einem Workflow

Event-Trigger können nur an Bereichen hängen, nie an Aktivitäten.

Hinzufügen eines Event-Triggers zu einem Bereich

Klicken Sie in der Palette auf das Event-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 die Reihenfolge der Trigger zu ändern oder das Layout zu verbessern).

Ein Event-Trigger, der an einem Bereich hängt, kann nicht in einen anderen Bereich verschoben werden. Wenn Sie einen Event-Trigger an einen anderen Bereich anfügen möchten, entfernen Sie den bereits erstellten Trigger und erstellen Sie einen neuen Trigger für den richtigen Bereich.

Um die Eigenschaften des Triggers zu konfigurieren, wählen Sie ihn im Bearbeitungsbereich aus und setzen Sie im Eigenschaftseditor die richtigen Werte. Siehe Abschnitt Eigenschaften eines Event-Triggers.

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 Event-Trigger ausgeführt wird, muss immer eine automatische Aktivität sein!

Eigenschaften eines Event-Triggers

Abbildung 92: ConSol CM Process Designer - Eigenschaften eines Event-Triggers

Ein Event-Trigger kann folgende Eigenschaften haben:

• Queue

  Markieren Sie diese Checkbox, wenn der Event-Trigger auf den Wechsel der Queue reagieren soll, d. h. der Trigger feuert, wenn ein Ticket in eine andere Queue verschoben wird. Es ist nicht relevant, ob es sich um eine manuelle Aktion oder eine automatisch vom System durchgeführte Aktion handelt.

• Bearbeiter

  Markieren Sie diese Checkbox, wenn der Trigger auf den Wechsel des zugewiesenen Bearbeiters des Tickets reagieren soll. Dies kann eine manuelle oder eine automatische Aktion sein. Es gibt drei mögliche Konstellationen:

  • Das Ticket hatte keinen Bearbeiter und es wird ein Bearbeiter gesetzt.
  • Das Ticket hat einen Bearbeiter und wird einem anderen Bearbeiter zugewiesen.
  • Das Ticket ist einem Bearbeiter zugewiesen und der Bearbeiter wird auf null (kein Bearbeiter) gesetzt.

• Thema

  Markieren Sie diese Checkbox, wenn der Trigger auf eine Änderung des Ticketthemas reagieren soll.

• Kommentar

  Markieren Sie diese Checkbox, wenn der Trigger auf eine Änderung eines Kommentars reagieren soll, d. h.:

  • Ein Bearbeiter hat einen neuen Kommentar (Text) eingegeben.
  • Ein Kunde hat über ConSol CM/Track einen neuen Kommentar (Text) eingegeben.
  • Das Ticket hat eine E-Mail erhalten.
  • Aus dem Ticket wurde eine E-Mail gesendet.
  • Es wurden ein oder mehrere Attachments zum Ticket hinzugefügt.

• Weitere Bearbeiter

  Markieren Sie diese Checkbox, wenn der Trigger auf eine Änderung von zusätzlichen Bearbeitern mit bestimmten Bearbeiterrollen im Ticket reagieren soll (Ticketbereich Zusätzliche Bearbeiter). Dies kann in folgenden Situationen geschehen (manuell gesetzt oder automatisch vom System gesetzt):

  • Das Ticket hatte keine zusätzlichen Bearbeiter und es werden ein oder mehrere zusätzliche Bearbeiter gesetzt.
  • Das Ticket hat einen oder mehrere zusätzliche Bearbeiter und einer oder mehrere dieser Bearbeiter werden auf null gesetzt oder ihr Name wird geändert.
  • Das Ticket hat einen oder mehrere zusätzliche Bearbeiter und alle diese Bearbeiter werden auf null (kein Bearbeiter) gesetzt.

• Zugeordnete Ressource

  Markieren Sie diese Checkbox, wenn der Trigger auf die Änderung einer verknüpften Ressource im Ticket reagieren soll, d. h.: 

  • Die Relation zur Ressource wurde gelöscht.
  • Es wurde eine neue Relation zu einer Ressource hergestellt.
  • Eine Relation wird geändert (z. B. die Beschreibung wird geändert)

• Zeitbuchung

  Markieren Sie diese Checkbox, wenn der Trigger auf Änderungen an Zeitbuchungen im Ticket reagieren soll, d. h.:

  • Es wird eine neue Zeitbuchung hinzugefügt.
    

• Benutzerdefiniertes Feld

  Öffnen Sie das Pop-up-Fenster Event Trigger (siehe folgende Abbildung) mit dem Button (...) und wählen Sie die Ticketfelder, die überwacht werden sollen. Mit den Buttons Plus und Minus können Sie weitere Felder hinzufügen oder die Anzahl der überwachten Felder verringern. Wie bei der Definition von Ticketfeldern (siehe ConSol CM Administratorhandbuch, Abschnitt Verwaltung von Ticketfeldern) müssen Sie zuerst im linken Drop-down-Menü die Ticketfeldgruppe auswählen und dann im rechten Drop-down-Menü eines der Ticketfelder dieser Gruppe auswählen. Sie können so viele Ticketfelder auswählen, wie Sie möchten.

  

  Abbildung 93: ConSol CM Process Designer - Eigenschaft "Benutzerdefiniertes Feld" eines Event-Triggers

• Skript nach Event

  Hier können Sie (mit dem ConSol CM-Skripteditor) ein Skript definieren, das ausgeführt werden soll, wenn der Event-Trigger gefeuert hat. Das Skript muss true oder false zurückgeben. Wenn es true zurückgibt, wird das Ereignis tatsächlich gefeuert, d. h. die automatische Aktivität nach dem Event-Trigger wird ausgeführt. Wenn das Skript false zurückgibt, wird das Ereignis blockiert und die automatische Aktivität wird nicht ausgeführt. Auf diese Weise können Sie genau steuern, wann die Aktion (Aktivität) ausgeführt werden soll, z. B. reagiert der Trigger auf eine Änderung der Priorität, feuert aber nur, wenn die neue Priorität Sehr hoch ist. Das Skript überprüft die neue Priorität und gibt nur dann true zurück, wenn der neue Wert Sehr hoch ist. Für alle anderen Werte gibt das Skript false zurück.

  Das Skript nach Event wird nur verwendet, um das Feuern des Event-Triggers zu steuern und einzustellen! Alle Aktionen, die durchgeführt werden sollen, wenn der Trigger feuert, müssen sich in einer automatischen Aktivität hinter dem Trigger befinden! Damit wird eine gute Prozesslogik sichergestellt und Sie können den Prozess im Process Designer leichter visualisieren.

Geschäftslogik von Event-Triggern

Reihenfolge des Feuerns bei serialisierten Event-Triggern

Wenn ein für den Event-Trigger relevantes Ereignis eingetreten ist, feuert dieser Trigger. Danach wird das Skript nach Event ausgeführt. Wenn es true zurückgibt, wird die folgende automatische Aktivität oder der Entscheidungsknoten mit den beiden folgenden automatischen Aktivitäten ausgeführt.

Wenn der Bearbeiter mehr als einen Ticketparameter ändert und für diese Parameter im Bereich unterschiedliche Event-Trigger definiert wurden, feuern die Event-Trigger entsprechend ihrer Reihenfolge im Bereich.

Abbildung 94: ConSol CM Process Designer - Reihenfolge des Feuerns von Event-Triggern (1)

Wenn einer der Event-Trigger das Ticket an eine neue Position verschiebt (d. h. es befindet sich danach nicht mehr in dem Bereich, in dem sich der nächste Event-Trigger befinden würde), feuert der folgende Event-Trigger nicht. Im Beispiel in der nächsten Abbildung feuert der Event-Trigger (3) nicht, wenn der Trigger Neuberechnung der Priorität gefeuert hat (2) (siehe Anwendungsfall 2 im Abschnitt Beispiele für Event-Trigger), da die nachfolgende Aktion das Ticket in eine andere Queue übergeben hat.

Abbildung 95: ConSol CM Process Designer - Reihenfolge des Feuerns von Event-Triggern (2)

Reihenfolge des Feuerns von Event-Triggern in hierarchischen Bereichen

Wenn sich Event-Trigger in hierarchischen Bereichen befinden, wird das Ereignis vom innersten Event-Trigger verbraucht, d. h. vom Event-Trigger im am weitesten innen liegenden Bereich. Alle Ereignisse, die nicht verbraucht wurden, werden vom nächst äußeren Bereich verarbeitet und so weiter.

Fall 1

Abbildung 96: ConSol CM Process Designer - Hierarchische Event-Trigger (1)

Gefeuerte Ereignisse:

Ereignisse	Gefeuerte Trigger
Queue	Innerer
Queue und Bearbeiter	Innerer für beide
Bearbeiter	Innerer

Fall 2

Abbildung 97: ConSol CM Process Designer - Hierarchische Event-Trigger (2)

Gefeuerte Ereignisse:

Ereignisse	Gefeuerte Trigger
Queue	Äußerer
Bearbeiter	Innerer
Queue und Bearbeiter	Innerer und äußerer

Fall 3

Abbildung 98: ConSol CM Process Designer - Hierarchische Event-Trigger (3)

Gefeuerte Ereignisse:

Ereignisse	Gefeuerte Trigger
Queue	Innerer
Bearbeiter	Äußerer
Queue und Bearbeiter	Innerer (Queue) und Äußerer (nur Bearbeiter)

Beispiele für Event-Trigger

Beispiel 1: Auf Kommentare reagieren

Wenn ein neuer Kommentar von jemanden hinzugefügt wurde, der nicht der aktuelle (zugewiesene) Bearbeiter des Tickets ist, wird ein Overlay zum Ticket-Icon hinzugefügt. Auf diese Weise wird das Ticket markiert und der Bearbeiter kann in der Ticketliste sehen, dass es einen neuen Kommentar in einem seiner Tickets gibt. Der Kommentar kann von einem anderen Bearbeiter gemacht worden sein, der Schreibrechte auf die Queue hat, oder von einem Kunden, der über ConSol CM/Track Kommentare hinzufügen kann. Oder es ist eine E-Mail eingegangen.

Abbildung 99: ConSol CM Process Designer - Event-Trigger mit folgenden Aktivitäten

Abbildung 100: ConSol CM Process Designer - Eigenschaften eines Event-Triggers (1)

return (engineerService.current == ticket.engineer)

Code-Beispiel 13: Code des Skripts des Entscheidungsknotens

Abbildung 101: ConSol CM Web Client- Mit neuem Overlay gekennzeichnetes Ticket

Beispiel 2: Auf Änderungen an Ticketfeldern reagieren

Dieses Beispiel stammt aus einer ITIL-Servicedesk-Umgebung. Nach den ITIL-Standards wird die Ticketpriorität anhand von zwei Werten berechnet: Auswirkung und Dringlichkeit. Das bedeutet, dass es im Ticket zwei Felder gibt, die vom Bearbeiter geändert werden können, und die Priorität automatisch aus diesen beiden Werten berechnet wird. Die Priorität kann das als Ticketfarbe oder als Auswahl in einer schreibgeschützten Liste (oder beides) angezeigt werden.

Dieses Prinzip erfordert eine Neuberechnung der Priorität, wenn mindestens eines der beiden Felder (Auswirkung/Dringlichkeit) geändert wurde. Dazu wird ein Event-Trigger mit einer nachfolgenden Aktivität, in der die Neuberechnung durchgeführt wird, erstellt.

Abbildung 102: ConSol CM Process Designer - Event-Trigger mit nachfolgender automatischer Aktivität

Abbildung 103: ConSol CM Process Designer - Eigenschaften eines Event-Triggers (2)

Abbildung 104: ConSol CM Process Designer - Eigenschaft "Benutzerdefiniertes Feld" eines Event-Triggers (2)

Code-Beispiel 14: Code der automatischen Aktivität zur Neuberechnung der Priorität

Beispiel 3: Fortsetzen des Geschäftsprozesses nach Änderung eines Ticketfeldes

Dies ist ein Beispiel aus einem Versand- und Auslieferungsprozess. Es werden neue Komponenten (z. B. Hardware) bestellt. Das Ticket wartet im Bereich Bestellung: Auf Lieferung warten. Wenn die Lieferung eingetroffen ist, erfasst ein anderes Team die Lieferung und setzt den Tag Ware eingegangen. Diese Änderung der Ticketdaten (Ware eingegangen von false in true) wird von einem Event-Trigger erfasst, der den Wert des entsprechenden Boolean-Felds (der Checkbox) überwacht. Nachdem der Event-Trigger gefeuert hat, wird die Checkbox (im Entscheidungsknoten) überprüft, und wenn der Wert auf true gesetzt ist, wird das Ticket in den nächsten Bereich Lieferung Komponenten geschoben. Die Bearbeiter, die für die Lieferung zuständig sind, sehen das Ticket jetzt in ihrer Sicht Für Auslieferung bereite Komponenten und können die Lieferung über Alle Komponenten geliefert bestätigen, wenn sie fertig sind.

Abbildung 105: ConSol CM Process Designer - Workflow für Anwendungsfall 3

Beispiel 4: Senden von E-Mails nach Änderung eines Ticketfeldes

Wenn ein Event-Trigger feuert, dann hat sich im Ticket etwas geändert. Was sich geändert hat, können Sie in einem Report festhalten. Das Objekt, das die benötigten Informationen enthält, ist ein Objekt der Klasse TicketChanges.

Das folgende Beispiel zeigt, wie Sie die Änderung der Deadline in einem Aufgabenticket für das Reporting erfassen können. Wenn die Deadline sich ändert und das Ticket aktuell einem Bearbeiter zugewiesen ist, soll dieser Bearbeiter per E-Mail darüber informiert werden, dass sich das Datum geändert hat.

Abbildung 106: Event-Trigger mit verknüpfter automatischer Aktivität. Im Beispiel überwacht der Trigger, ob sich das Ticketfeld "Deadline" im Ticket ändert (nicht sichtbar).

Code-Beispiel 15: Senden einer E-Mail an den aktuellen Bearbeiter des Tickets, wenn sich das Feld "Deadline" im Ticket geändert hat (Daten nicht formatiert)

Best Practices für die Verwendung von Event-Triggern

Siehe Abschnitt Vermeiden von sich selbst auslösenden Event-Triggern.