Einmalverarbeitung ausgeführt
Ereignisaktion - Kurzfassung
Zweck: Setzt einen Merker für die laufende Transaktion, der das mehrfache Ausführen desselben "Jobs" verhindern soll.
Die Ereignisaktion Einmalverarbeitung ausgeführt setzt einen Merker, der im weiteren Verlauf der aktuellen Transaktion mit Hilfe der korrespondierenden Regel vom Typ Einmalverarbeitung ausgeführt? ausgewertet werden kann.
Jeder Merker wird durch die Kombination der Werte für die Parameter Job Name und Job Besitzer identifiziert, die in der Konfiguration für die Ereignisaktion jeweils optional über Wertauflöser befüllt werden können.
Die Einmalverarbeitung ausgeführt?-Regel prüft anhand derselben Parameter, ob innerhalb der laufenden Transaktion der jeweilige Merker als gesetzt gilt. Der Abschnitt "Konfiguration" beschreibt wichtige Details zum Abgleich der Parameter.
Ein Merker kann nur gesetzt werden, indem die Ereignisaktion Einmalverarbeitung ausgeführt ausgeführt wird. Er bleibt dann bis zum Ende der Transaktion bestehen.
Wiederholtes Ausführen der Ereignisaktion Einmalverarbeitung ausgeführt mit übereinstimmenden Werten für die Parameter hat keinerlei Effekt.
Das "Löschen" bzw. "Zurücksetzen" eines bereits gesetzten Merkers im Verlauf der Transaktion ist nicht vorgesehen.
Wie der Name der Ereignisaktion nahelegt, soll der Einsatz solcher Merker in der Regel die wiederholte Ausführung eines bestimmten "Jobs" verhindern. Das kann dazu dienen, um Redundanzen zu vermeiden oder die Performance zu optimieren aber auch notwendig sein, um Endlosschleifen bei der Ereignisverarbeitung auszuschließen, wenn wechselseitige Abhängigkeiten zwischen Ereignissen und Ereignisbehandlungen bestehen. Das Setzens eines Merkers kann, aber auch ausschließlich wegen der Signalwirkung innerhalb der Transaktion nützlich sein.
►WICHTIG◄ Wenn eine Kette von Ereignissen verarbeitet wird (s. a. Eigenes Aktionsevent auslösen (Aktion)), dann gilt ein per Einmalverarbeitung ausgeführt-Ereignisaktion gesetzter Merker für alle Ereignisbehandlungen entlang der Kette. Im Unterschied zu Variablen (s. Variable), der Werte innerhalb einer Ereigniskette nur "vorwärts" - von der aufrufenden an die aufgerufene Ereignisbehandlung - weitergegeben werden, können Merker daher verwendet werden, um Rückmeldungen für aufrufende Ereignisbehandlungen bereitzustellen. Diese können mit der Einmalverarbeitung ausgeführt?-Regel prüfen, ob beim Verarbeiten einer ggf. mehrstufigen Ereigniskette bestimmte Merker gesetzt wurden, wenn die Verarbeitung in der aufrufenden Ebene fortgesetzt wird.
Konfiguration
Der optionale Parameter Job Name wird durch einen Wertauflöser bestimmt, dessen Rückgabewert als Zeichenfolge interpretiert wird, sofern er nicht "kein Wert" (null) ist.
Der optionale Parameter Job Besitzer wird durch einen Wertauflöser bestimmt, dessen Rückgabewert als Datenobjekt interpretiert wird.
Die Einmalverarbeitung ausgeführt?-Regel verwendet dieselben Parameter und vergleicht den Job Name als Zeichenfolge und den Job Besitzer als Datenobjekt, um festzustellen, ob ein bestimmter Merker im bisherigen Verlauf der Transaktion gesetzt wurde oder nicht.
►HINWEISE◄
Da beide Parameter optional sind, kann die Ereignisaktion auch ohne Parameterwerte (bzw. mit den Werten null/null) ausgeführt werden. Die Prüfung per Einmalverarbeitung ausgeführt?-Regel wird mit "übereinstimmenden Parametern" (null/null)auch dann bestanden.
Ausschlaggebend für die Übereinstimmung beim Parameter Job Name ist eine exakte Übereinstimmung des in eine Zeichenfolge umgewandelten Rückgabewerts des Wertauflösers. Dabei kann z. B. eine Ganzzahl (z. B. ein Long-Wert aus einem id-Feld einer Entität) mit einer als Text bereitgestellten Ziffernfolge verglichen werden. Sollen "Kommazahlen", Datums/Zeitangaben, usw. mit z. B. als "Literal" bereitgestellten Texten verglichen werden, muss die Formatierung exakt so gewählt werden, dass sie dem Ausgabeformat des jeweiligen Werts innerhalb einer Hinweis anzeigen (Popup)-Ereignisaktion entspricht.
Wie Datenobjekte im Parameter Job Besitzer verglichen werden, hängt vom jeweiligen Objekttyp ab:
Wird eine Entität bzw. ein Attribut einer Entität mit einer vom System verwalteten ID (id) als Job Besitzer angegeben, dann bezieht sich der Abgleich ausschließlich auf die ID (id) des Objekts, so dass es auch dann von einer Einmalverarbeitung ausgeführt?-Regel "anerkannt" wird, wenn an den Daten der Entität seit dem Setzen des Merkers Änderungen vorgenommen wurden.
Wird ein frei definiertes Datenobjekt (z. B. ein "Client Objekt") als Job Besitzer zugewiesen, dann wertet der Abgleich alle im Objekt enthaltenen Daten (seinen Hash-Wert) aus, der zwischen einer Zuweisung beim Setzen des Merkers und dem in der Einmalverarbeitung ausgeführt?-Regel gelieferten Objekt übereinstimmen muss. Ob es sich tatsächlich um dieselbe Objektinstanz (s. a. Erzeuge Instanz) handelt, ist dagegen unerheblich, solange alle Merkmale übereinstimmen.
Beispiele
Typischer Anwendungsfall
Anforderungen:
Beim Speichern einer Bestellung (Geschäftsobjekt) prüft eine Ereignisbehandlung, ob das Referenzattribut "Auftragsnummer" erstmals ausgefüllt wurde. Falls ja, soll für die Bestellung der Trackingstatus "Beauftragt" gesetzt werden.
Eine andere Ereignisbehandlung wird durch das Setzen des Trackingstatus "Beauftragt" ausgelöst. Sie soll das Referenzattribut "Auftragsnummer" automatisch mit einem Wert aus einem Nummernkreis (s. Nummernkreise) belegen, falls "bei Beauftragung" noch keine konkrete Angabe vorliegt.
Die "Beauftragung" einer Bestellung soll also - interaktiv oder via Integration - auf zwei unterschiedlichen Wegen ausgelöst werden können: Entweder durch das Eintragen einer Auftragsnummer in der Bestellung oder durch das Setzen des Trackingstatus "Beauftragt".
Ohne besondere Vorkehrungen würde beim Zuweisen des Trackingstatus "Beauftragt" zu einem Geschäftsobjekt ohne "Auftragsnummer" der Trackingstatus doppelt hinzugefügt, weil beim automatischen Befüllen der "Auftragsnummer" durch die zweite Ereignisbehandlung die erste Ereignisbehandlung ausgelöst wird, die dann feststellt, dass die "Auftragsnummer" ausgefüllt wurde und deshalb erneut den Trackingstatus "Beauftragt" zuweist. Auch wenn hier keine "Endlosschleife" droht, weil die zweite Ereignisbehandlung nur aktiv wird solange die "Auftragsnummer" noch fehlt, soll die Doppelzuweisung des Trackingstatus verhindert werden.
Konfiguration:
Wie oben schematisch dargestellt, wird die Ereignisaktion Einmalverarbeitung ausgeführt in Verbindung mit der Regel "Einmalverarbeitung ausgeführt?" in den beiden beteiligten Ereignisbehandlungen verwendet.
Dabei wird im konkreten Fall der Job Name "TS_ORDER" als statischer Text zugewiesen und als Job Besitzer die eindeutige ID der Bestellung zugewiesen, wie in der folgenden Konfiguration für die Ereignisaktion Einmalverarbeitung ausgeführt:
►ANMERKUNG◄ Die Einmalverarbeitung ausgeführt?-Regel muss dieselben Parameterwerte verwenden.
Alternative Verwendung (Rückgabewert aus einer Ereigniskette)
Eine Ereignisbehandlung, die auf ein Eigenes Aktionsevent reagiert, soll das als "Eingabewert" übergebene Firmen- und Adressattribut eines Geschäftsobjekts "plausibilisieren" und die aufrufende Ereignisbehandlung "informieren", wenn ein Regelverstoß vorliegt. Dabei soll zwischen "Warnungen" und "Fehlern" abgestuft werden können. Details zur konkreten Logik der Plausibilisierung sind für das Beispiel nicht erheblich.
Entscheidend ist, dass die Überprüfung bei bestimmten Arbeitsstatuswechseln für sämtliche vorhandenen Firmen- und Adressattribute ausgelöst werden soll, um im weiteren Verlauf der aufrufenden Ereignisbehandlung die Prüfergebnisse für bestimmte Firmentypen (s. Firmentyp) in spezifischen Regeln und Fallunterscheidungen berücksichtigen zu können. Zu diesem Zweck sollen mit Hilfe der Ereignisaktion Einmalverarbeitung ausgeführt Merker gesetzt werden, deren Job Name die Schwere eines Verstoßes angibt, während als Parameter Job Besitzer den Firmentyp des Firmen- und Adressattributs spezifiziert.
Konfiguration:
►ANMERKUNG◄ Der Aufruf von Einmalverarbeitung ausgeführt zur Deklaration eines "Fehlers" oder einer "Warnung" könnte innerhalb einer komplexer ausgeprägten Ereignisbehandlung an unterschiedlichsten Stellen erfolgen und auch so, dass für denselben Firmentyp sowohl eine "Warnung" als auch ein "Fehler" ausgewiesen wird. Die Konfiguration rechts schließt das eher zufällig bzw. vor dem Hintergrund einer besonderen Prüflogik aus, die hier keine Rolle spielen soll. |
|
Eine aufrufende Ereignisbehandlung, für diese Prüfung könnte etwa so aussehen:
|
Im Beispiel bezieht sich die aufrufende Ereignisbehandlung per Typprüfung auf den Geschäftsobjekttyp "Bestellung" (nicht im Bild dargestellt). Als Aktionen bei bestandener Regel werden folgende Ereignisaktionen ausgeführt:
|
|
