Event-Trigger

Event-Trigger sind Interrupts, die signalisieren, dass ein bestimmtes Ereignis für einen Vorgang eingetreten ist. Sie hängen an Bereichen. Ein Bereich kann mehrere Event-Trigger haben. Event-Trigger können auf jegliche Arten von Änderungen reagieren, zum Beispiel Änderungen an den Vorgangsdaten, des Bearbeiters oder der Relationen des Vorgangs. Die Aktionen, die ausgeführt werden sollen, wenn das Ereignis eintritt, müssen im Skript einer mit dem Trigger verbundenen automatischen Aktivität definiert werden.

Beispiele für die Verwendung von Event-Triggern:

• Setzen eines Overlays, wenn der Kunde oder ein Benutzer, der dem Vorgang nicht zugewiesen ist, einen Kommentar hinzufügt.
• Neuberechnung eines Feldwerts, der auf den Werten anderer Felder beruht, wenn deren Werte geändert werden.
• Automatisches Weiterbewegen eines Vorgangs im Geschäftsprozess, wenn der Wert eines bestimmten Feldes geändert wurde.

Prozesslogik mit Event-Triggern

Für Event-Trigger gilt die folgende allgemeine Logik:

1. Das Ereignis, das im Event-Trigger definiert wurde, tritt für einen Vorgang ein, der sich in dem Bereich befindet, an dem der Trigger hängt.
2. Der Trigger feuert, d. h. er signalisiert, dass das Ereignis eingetreten ist.
3. Das Skript, das im Trigger definiert wurde, wird 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 eine Änderung mehr als einen Vorgangsparameter betrifft und für diese Parameter verschiedene Event-Trigger im Bereich definiert wurden, feuern die Event-Trigger in der Reihenfolge, in der sie am Bereich hängen, von links nach rechts. Falls der Vorgang durch eine automatische Aktivität den Bereich verlässt, an dem die Trigger hängen, z. B. indem er über einen Aussprungknoten in eine andere Queue verschoben wird, feuern die restlichen Trigger nicht mehr.

Wenn Event-Trigger sich in hierarchischen Bereichen befinden und auf dieselbe Änderung reagieren, wird das Ereignis vom Trigger im innersten Bereich behandelt. Falls der Trigger im innersten Bereich nicht auf alle eingetretenen Ereignisse reagiert, werden die Ereignisse, die noch nicht behandelt wurden, an den nächst äußeren Bereich weitergeleitet.

Best Practice

• Hängen Sie den Event-Trigger an den innerst möglichen Bereich, um unnötige Trigger-Ausführungen zu vermeiden.
• Wenn eine Aktivität bestimmte Vorgangsdaten ändert, und ein Trigger, der auf diese Änderungen reagiert, nicht ausgeführt werden soll, dann platzieren Sie die Aktivität außerhalb des Bereiches, in dem sich der Trigger befindet.
• Die automatische Aktivität, die auf einen Event-Trigger folgt, sollte keine Vorgangsparameter ändern, auf die der Trigger reagiert. Dies würde zu einer Endlosschleife führen, da der Trigger nach Ausführung der Aktivität erneut feuern würde. Wenn Änderungen an Vorgangsparametern, auf die ein Trigger reagiert, erforderlich sind, dann platzieren Sie die Aktivität außerhalb des Bereiches, in dem sich der Trigger befindet.

Beim Anlegen eines Vorgangs werden Event-Trigger für alle Änderungen ausgeführt, die nach der ersten Speicherung des Vorgangs in der Datenbank vorgenommen wurden.

Unterschiede zwischen synchroner und asynchroner Ausführung

Standardmäßig werden Event-Trigger synchron ausgeführt, d.h. innerhalb der Transaktion, die die Änderung auslöst, auf die der Trigger wartet. Wenn die mit dem Event-Trigger verbundenen Skripte zahlreiche Änderungen vornehmen, kann es sinnvoll sein, den Trigger als asynchron zu konfigurieren, um zu vermeiden, dass der Web Client für den Benutzer während der Verarbeitung der Änderungen blockiert ist. Asynchrone Event-Trigger laufen in einer separaten Transaktion. Das bedeutet, dass der Vorgang den Prozess weiter durchlaufen kann, während die Verarbeitung noch läuft. Wenn die Verarbeitung fehlschlägt, findet kein automatisches Rollback der Haupttransaktion statt.

Die folgende Tabelle veranschaulicht die Unterschiede zwischen synchronen und asynchronen Event-Triggern:

	Synchroner Event-Trigger	Asynchroner Event-Trigger
Wann wird der Trigger ausgeführt?	Der Trigger wird sofort ausgeführt, sobald die Daten geändert werden. Er läuft in derselben Transaktion ab, in der die Daten geändert wurden.	Der Trigger wird ausgeführt, nachdem die Transaktion, in der die Daten geändert wurden, abgeschlossen ist – es sei denn, die Daten wurden durch einen anderen Trigger geändert.
Was passiert, wenn dasselbe Feld mehrmals geändert wird und anschließend wieder seinen ursprünglichen Wert annimmt?	Der Trigger wird bei jeder Änderung einmal ausgeführt.	Der Trigger wird nicht ausgeführt.
Wenn ein Vorgang während einer Transaktion mehrere Bereiche durchläuft und mehr als ein Bereich über einen Trigger verfügt, der auf dieselbe Änderung wartet, welcher Trigger wird dann ausgeführt?	Der Trigger, der dem Bereich zugeordnet ist, in dem sich der Vorgang zum Zeitpunkt der Datenänderung befand, wird ausgeführt.	Der Trigger, der dem Bereich zugeordnet ist, in dem sich der Vorgang am Ende der Transaktion befindet, wird ausgeführt.
Wenn der Vorgang während einer Transaktion mehrere Bereiche durchläuft und einer der Zwischenbereiche einen Trigger enthält, der auf eine Änderung wartet, wird dieser dann ausgeführt?	Ja, Trigger, die an Zwischenbereichen hängen, werden ausgeführt.	Nein, es werden nur die Trigger ausgeführt, die an dem Bereich hängen, in dem sich der Vorgang am Ende der Transaktion befindet.
Was geschieht mit dem Web Client während der Ausführung des Triggers?	Der Web Client ist während der gesamten Transaktion, einschließlich der Triggerausführung, blockiert. Am Ende der Transaktion wird der Web Client aktualisiert.	Der Web Client ist während der Transaktion, die die Daten ändert, blockiert, jedoch nicht während der Ausführung des Triggers. Der Web Client wird am Ende der ersten Transaktion aktualisiert. Nach Abschluss der Trigger-Transaktion wird der Web Client automatisch aktualisiert, sofern keine ungespeicherten Änderungen vorliegen. Liegen ungespeicherte Änderungen vor, wird eine gelbe Informationsmeldung angezeigt, um den Benutzer darauf hinzuweisen.
Was passiert, wenn die Triggerausführung fehlschlägt?	Die gesamte Transaktion, einschließlich der Änderung, die den Trigger ausgelöst hat, wird zurückgerollt.	Es wird eine Meldung in die Log-Dateien geschrieben. Nur die Transaktion der Triggerausführung wird zurückgerollt. Sie müssen Fehlerbehandlung und Folgeaktionen in den mit dem Trigger verknüpften Skripten implementieren.

Verfügbare Einstellungen für Event-Trigger

Es sind folgende Einstellungen für Event-Trigger verfügbar:

• Pfad: Schreibgeschützt. Der Pfad zum Event-Trigger im Workflow. Zum Referenzieren des Triggers in Skripten verwendet.

• Queue: Optional. Wenn diese Checkbox markiert ist, feuert der Trigger, wenn der Vorgang in eine andere Queue verschoben wird. Dabei ist nicht relevant, ob es sich um eine manuelle Aktion durch einen Benutzer oder um eine automatisch vom System durchgeführte Aktion handelt.

• Bearbeiter: Optional. Wenn diese Checkbox markiert ist, reagiert der Trigger auf den Wechsel des zugewiesenen Bearbeiters des Vorgangs. Dazu gehört die Zuweisung eines zuvor noch nicht zugewiesenen Vorgangs an einen Benutzer, die Zuweisung eines Vorgangs an einen anderen Benutzer und das Entfernen eines Benutzers vom Vorgang.

• Vorgangsthema: Optional. Wenn diese Checkbox markiert ist, feuert der Trigger, wenn das Thema des Vorgangs geändert wird.

• Kommunikation: Optional. Wenn diese Checkbox markiert ist, reagiert der Trigger auf Änderungen der Kommunikation im Vorgangsprotokoll, d. h. falls ein neuer Kommentar im Web Client oder in CM/Track hinzugefügt wurde, eine E-Mail gesendet wurde oder eingetroffen ist, oder ein Attachment hinzugefügt wurde oder eine Textklasse geändert wurde.

• Beteiligte: Optional. Wenn diese Checkbox markiert ist, reagiert der Trigger auf Änderungen der Beteiligten. Dazu gehört das Hinzufügen von Beteiligten zu einem Vorgang oder das Entfernen von Beteiligten von einem Vorgang.

• Verknüpfte Ressource: Optional. Wenn diese Checkbox markiert ist, reagiert der Trigger auf Änderungen der verknüpften Ressourcen, d. h. falls eine Ressourcenrelation erstellt, entfernt oder geändert wurde.

• Verknüpfter Vorgang: Optional. Wenn diese Checkbox markiert ist, reagiert der Trigger auf Änderungen der verknüpften Vorgänge, d. h. falls eine Vorgangsrelation erstellt oder entfernt wurde. Der Trigger feuert jeweils für den Quell- und den Zielvorgang der Relation.

• Zeitbuchung: Optional. Wenn diese Checkbox markiert ist, feuert der Trigger, wenn eine neue Zeitbuchung hinzugefügt wurde.

• Vorgangsfelder: Optional. Der Trigger reagiert auf Änderungen der ausgewählten Vorgangsfelder. Sie können ein oder mehrere Felder aus verschiedenen Feldgruppen wählen. Sie können auch alle Felder einer Vorgangsfeldgruppe auswählen.

• Skript: Optional. Bestimmt, ob die folgende automatische Aktivität ausgeführt wird. Das Skript wird ausgeführt, wenn der Trigger gefeuert hat. Es muss true (die Aktivität wird ausgeführt) oder false (die Aktivität wird nicht ausgeführt) zurückgeben. Auf diese Weise können Sie genauer steuern, wann die Aktivität ausgeführt werden soll, z. B. um nur dann zu reagieren, wenn ein bestimmter Wert für ein Vorgangsfeld gesetzt wird.

  Best Practice

  Verwenden Sie dieses Skript nur, um zu bestimmen, ob eine automatische Aktivität ausgeführt werden soll oder nicht. Alle anderen Aktionen sollten in dem Skript der automatischen Aktivität ausgeführt werden, die mit dem Trigger verbunden ist.

• Asynchrone Ausführung: Markieren Sie diese Checkbox, wenn der Trigger asynchron ausgeführt werden soll. Das Timeout für die asynchrone Ausführung wird in der System-Property cmas-core-server, workflow.asyncBusinessEvent.txTimeout.seconds definiert.

Programmieren mit Event-Triggern

Sie können ein Objekt des Typs TicketChanges abrufen, das die am Vorgang vorgenommenen Änderungen enthält:

workflowApi.getTicketUpdateEvent().getModifications()