Eigenes Aktionsevent auslösen (Aktion)
Ereignisaktion - Kurzfassung
Zweck: Löst ein Eigenes Aktionsevent mit einem definierten Datenobjekt als Datenkontext aus, das vor der Fortsetzung der umgebenden Ereignisbehandlung komplett verarbeitet wird.
Eigenes Aktionsevent auslösen (Aktion)
Die Ereignisaktion Eigenes Aktionsevent auslösen (Aktion) löst ein Eigenes Aktionsevent aus und übergibt dabei entweder das aktuelle Bezugsobjekt oder ein als Rückgabewert eines Wertauflösers ermitteltes abweichendes Bezugsobjekt als "Eingabewert".
Welche Auswirkungen das Auslösen eines Ereignisses hat, hängt davon ab, ob Ereignisbehandlungen existieren, die es aus Auslöser berücksichtigen. Oft definieren die "Prüfenden Regel" einer Ereignisbehandlung spezifische Anforderungen, z. B. eine Typprüfung, so dass sie nur aktiv wird, wenn ein geeigneter "Eingabewert" übergeben wird.
Über Optionen (Details s. "Konfiguration") kann gesteuert werden, wann das Eigene Aktionsevent zur Laufzeit ausgelöst werden soll (sofort oder nach dem Commit) und wie ggf. Ereignisbehandlungen dann ausgeführt werden (synchron/seriell oder asynchron/parallel).
Im Datenkontext des ausgelösten Ereignisses stehen neben dem beim Auslösen definierten Bezugsobjekt auch alle im aufrufenden Kontext vorliegenden Variablen zur Verfügung. Allerdings werden diese nicht direkt übergeben sondern vorher "geklont". Deshalb sind die Werte von Variablen, die beim Verarbeiten des ausgelösten Ereignisses geändert oder neu angelegt werden, anschließend nicht im Kontext der aufrufenden Ereignisbehandlung verfügbar. Sie können daher nicht verwendet werden, um "Rückmeldungen" für die aufrufende Ereignisbehandlung bereitzustellen. Wo das erforderlich ist, muss die "Rückmeldung" über das von der aufrufenden Ereignisbehandlung bereitgestellte Bezugsobjekt erfolgen. Ggf. kommt als Bezugsobjekt auch ein per Erzeuge Instanz ("Client Objekt") oder Erzeuge Liste generiertes Datenobjekt infrage, dem geeignete "Rückgabewerte" zugewiesen werden können.
Konfiguration
|
Der Parameter Eigenes Aktionsevent unterstützt über ein Auswahlfeld/Combobox mit Suchfunktion (s. Screenshot rechts) die statische Auswahl für genau ein Eigenes Aktionsevent auf der Basis der zugehörigen Dynamischen Aufzählung. ►HINWEIS◄ Die Auswahloptionen werden über Dynamische Aufzählungsfilter eingeschränkt, sofern diese im Kontext der Konfiguration anwendbar sind. Eine bestehende Auswahl muss nicht in der Auswahlliste enthalten sein. Sie kann beibehalten, geändert oder entfernt aber nach dem Entfernen nicht erneut auswählbar. |
|
|
Der Parameter Datenobjekt bestimmt über einen Wertauflöser den Eingabewert, der an das per Eigenes Aktionsevent identifizierte Ereignis übergeben wird:
|
|
Die Ereignisaktion Eigenes Aktionsevent auslösen (Aktion) sieht zwei Optionen vor, die steuern, wann und wie ein Eigenes Aktionsevent ausgelöst wird:
Die Option Nach dem Commit in einer neuen Transaktion auslösen kann gesetzt werden, wenn das Ereignis nicht innerhalb der aktuellen Transaktion und sofort ausgeführt werden soll, sondern erst (und nur) wenn diese erfolgreich abgeschlossen wird ("Commit").
Wenn ein Ereignis "nach dem Commit in einer neuen Transaktion" ausgelöst wird, hängt der genaue Ablauf von der Option Asynchron auslösen ab:
Ist die Option Asynchron auslösen nicht ausgewählt (Standard), dann wird das Ereignis zwar erst nach dem Commit ausgelöst, aber trotzdem synchron ausgeführt. Dann werden die ausgelösten Ereignisbehandlungen demselben Thread auf der Server-CPU zugeordnet, der auch die auslösende Ereignisbehandlung bearbeitet. Die auslösende Ereignisbehandlung gilt erst dann als effektiv beendet, wenn die Behandlung aller nach dem Commit synchron ausgelösten Ereignisse abgeschlossen ist. Sofern dies mehrere Ereignisse betrifft werden diese durch den Thread "seriell" also strikt nacheinander entsprechend der Reihenfolge verarbeitet, in der sie ausgelöst wurden.
Wird die Option Asynchron auslösen ausgewählt, dann kann wird die betreffende Ereignisbehandlung asynchron ausgeführt und dazu dem nächsten verfügbaren Thread aus dem Threadpool der Server-CPU zugeordnet. Sofern das Ereignis einem anderen Thread zugeordnet werden kann, widmet sich die auslösende Ereignisbehandlung sofort dem ggf. vorhandenen Nachfolger in der "Warteschlange" für die Auslösung nach dem Commit. Dieser wird dann sofort parallel zum asynchron ausgelösten Vorgänger gestartet und synchron oder wiederum asynchron verarbeitet.
►HINWEIS◄ Die Option Asynchron auslösen beeinflusst den Ablauf der Ereignisverarbeitung ähnlich wie die Option "Synchron" den Profilaufruf beim Export (nur mit unterschiedlicher Polarität der Aus-/Abwahl).
Da die Option Asynchron auslösen nur in Verbindung mit der Option Nach dem Commit in einer neuen Transaktion auslösen auswählbar ist, können drei Anwendungsfälle konfiguriert werden:
|
Wann auslösen? ► Wie auslösen? ▼ |
sofort auslösen |
Nach dem Commit der aktuellen Transaktion auslösen |
|
synchron |
Das Ereignis wird sofort und synchron ausgelöst und vor allen nachfolgenden Ereignisaktionen "behandelt". |
Das Ereignis wird nach dem Commit und synchron ausgelöst. Ereignisbehandlungen verwenden denselben Thread wie die auslösende Ereignisbehandlung. Mehrere synchron ausgelöste Ereignisse werden seriell abgearbeitet. |
|
asynchron |
(Asynchron auslösen ist "vor dem Commit" nicht anwendbar) |
Das Ereignis wird nach dem Commit und asynchron ausgelöst. Es wird dem nächsten verfügbaren Thread zugeordnet. Ggf. nachfolgende Ereignisse können also parallel abgearbeitet werden.
|
►HINWEIS◄ Mit der Asynchron Option werden sämtliche Variablen als Kopie weitergegeben, um parallele Zugriffe auf dort enthaltene Objekte zu verhindern.
Beispiel
Einfaches Beispiel
Im Zuge einer interaktiven Aktion für eine bestehende Sendung (z. B. Zuweisen des Arbeitsstatus "Freigabe") soll der verantwortliche Benutzer in kompakter Form über die in Firmen- und Adressattributen spezifizierten "Beteiligten" an der betreffenden Sendung informiert werden. Dabei soll der Firmentyp als Titel und eine Verkettung von ausgewählten Adressmerkmalen in einer eigenständigen Benachrichtigung für jedes relevante Attribut erscheinen.
Beispiel:
Konfiguration:
Damit die Anzeige von Adressattributen im gewünschten Format auch in anderen Zusammenhängen eingesetzt werden kann, wird ein Eigenes Aktionsevent mit dem Namen "Info: Adresse" definiert. Dieses Ereignis kann immer dann ausgelöst werden, wenn ein Benutzer über den Inhalt eines bestimmten "Firmen- und Adressattributs" benachrichtigt werden soll.
Für unser Beispiel wird eine Ereignisbehandlung erstellt, die ausgelöst wird, wenn einer Sendung der Arbeitsstatus "Freigabe" zugewiesen wird.
|
Die "Aktionen bei bestandener Regel" werden wie rechts abgebildet konfiguriert:
|
|
Für die Ausgabe der Benachrichtigung als Reaktion auf das "Info: Adresse"-Ereignis wird folgende Ereignisbehandlung konfiguriert:
|
|
►HINWEIS◄ Der Event Recorder macht nachvollziehbar, mit welchem Eingabewert ein Eigenes Aktionsevent wann aufgerufen wurde:
Analog zum eingangs gezeigten Beispiel wurden im Bild drei Adressattribute in einer Sendung vorgefunden und zwecks "Benachrichtigung" an das Eigene Aktionsevent "Info: Adresse" weitergegeben.
Der Reiter Eingabewert im Detailbereich zeigt das Datenobjekt des letzten Aufrufs mit dem Firmentyp "Abholadresse" (DPA).