Definition des Bezugsobjekts

Das aktuelle Bezugsobjekt ist im einfachsten Fall die durch den Datenkontext der Ereignisbehandlung bestimmte Entität.

Allerdings gibt es auch Ereignisaktionen (z. B. Ausführen mit oder Für jeden Eintrag wiederholen (Schleife)), die das aktuelle Bezugsobjekt zur Laufzeit vorübergehend übersteuern können. Die Konfiguration der Ereignisaktion sieht dabei jeweils einen definierten Block von Ereignisaktionen vor, die im Kontext des abweichenden Bezugsobjekts ausgeführt werden sollen. Zur Laufzeit gilt für diese Ereignisaktionen das abweichende Bezugsobjekt als aktuelles Bezugsobjekt, wie ggf. über den Wert der Variablen entity nachvollzogen werden kann. Auch die Ereignisaktion Änderungen später speichern bezieht sich innerhalb eines solchen Aktionsblocks ausschließlich auf die vorübergehend als Bezugsobjekt definierte Entität.

Innerhalb einer Ereignisaktion, die ein abweichendes Bezugsobjekt vorsieht, können in der Regel Wertauflöser eingesetzt werden, um ein konkretes Bezugsobjekt zu definieren:

• Eventuell kann das Datenobjekt einer Entität direkt über eine Variable oder ein Objekt-Feld aufgelöst werden.

• Oft muss auch der Wertauflöser Eingabeobjekt (Typsicher) verwendet werden, z. B. um das Datenobjekt einer Entität ausgehend von einer Referenz auf dessen ID (id) zu beschaffen (u. a. Verknüpfter Entitätstyp bzw. Verknüpfter Positionstyp).

• Über den Erzeuge Instanz-Wertauflöser kann das Bezugsobjekt auch neu angelegt und im Rahmen der Transaktion bearbeitet werden. Dann bewirkt die Ereignisaktion Änderungen später speichern "später" das Erstellen der betreffenden Entität.

►WICHTIG◄ Die Aktion sollte nur mit eigenständigen Entitäten als Bezugsobjekt ausgeführt werden und z. B. nicht mit Attributen oder Positionen von Geschäftsobjekten. Zur Laufzeit findet keine entsprechende Prüfung statt und das Ausführen der Ereignisaktion für ein Bezugsobjekt, das eigentlich (interaktiv) nicht eigenständig gespeichert werden kann, führt möglicherweise zu unerwarteten Ergebnissen beim Abschluss der Transaktion.

Vormerkung zum Speichern

Die Vormerkung zum Speichern berücksichtigt den zum Zeitpunkt der Ausführung der Ereignisaktion Änderungen später speichern anwendbaren Anmeldekontext (Firma, Rolle, Benutzer), der zur Laufzeit durch die Ereignisaktion Ausführen als temporär abweichend von der aktuellen Sitzung definiert sein kann.

• Wird die Ereignisaktion Änderungen später speichern innerhalb derselben Transaktion mehrfach für dasselbe Bezugsobjekt ausgeführt, berücksichtigt die Vormerkung ausschließlich den Anmeldekontext der letzten Ausführung.

• Der ausschlaggebende Anmeldekontext wirkt sich auf die Prüfung von Berechtigungen und - soweit anwendbar - die Wertzuweisung für Entitätsattribute beim Speichern (s. u.) aus.

Dass das Speichern nicht unmittelbar durch das Ausführen der Ereignisaktion Änderungen später speichern ausgelöst wird, bedingt außerdem folgende Effekte:

• Wenn nach dem Ausführen von Änderungen später speichern für dieselbe Transaktion ein Rollback (durch eine Abbrechen oder eine "echte" Process Exception) ausgelöst wird, entfällt das "später Speichern" und die ggf. anliegenden Änderungen gehen verloren.

• Der Zeitpunkt der Ausführung der Ereignisaktion für ein bestimmtes Bezugsobjekt innerhalb derselben Transaktion ist unerheblich. Alle Änderungen am Bezugsobjekt innerhalb der Transaktion werden kumulativ berücksichtigt, wenn gespeichert werden soll.

• Das wiederholte Ausführen der Ereignisaktion für dasselbe Bezugsobjekt innerhalb derselben Transaktion ist wirkungslos, außer wenn dabei unterschiedliche Anmeldekontext verwendet werden (s. o.).

Ausführen des Speicherns

Die Vormerkung zum Speichern wird erst mit dem Abschluss der laufenden Transaktion berücksichtigt. Sofern eines der vorgemerkten Bezugsobjekte durch die Transaktion nicht ohnehin gespeichert würde, wird dann versucht diese explizit zu speichern. Falls dieser Versuch fehlschlägt, weil eine Fehlermeldung auftritt, gilt die Transaktion insgesamt als Fehlschlag und ein Rollback wird ausgeführt. Diesbezüglich sind die folgenden Aspekte zu bedenken:

• Der im Zuge der Vormerkung anwendbare Anmeldekontext (s. o.) muss über ausreichende Berechtigungen für das Bezugsobjekt ("Ändern" bzw. "Erstellen" für neue Instanzen) verfügen.

• Sofern das System für den Entitätstyp des Bezugsobjekts inhaltliche Anforderungen prüft (Pflichtangaben, Eindeutigkeit von Merkmalen oder Merkmalskombinationen, usw.), sollte das Bezugsobjekt diese bis zum Abschluss der Transaktion erfüllen.

• Das Ausführen der Ereignisaktion Änderungen später speichern im Try-Block einer Try-Catch-Aktion führt nicht dazu, dass Fehler abgefangen werden, die erst "später" (beim Speichern) auftreten.

►WICHTIG◄ Liegt beim Abschluss der laufenden Transaktion für dieselbe Entität neben einer Vormerkung zum Speichern auch eine Vormerkung zum Löschen (s. Später löschen) vor, dann entfällt das Speichern für diese Entität komplett.

►HINWEIS◄ Das Speichern ist beim Ausführen von Tests für Ereignisbehandlungen wirkungslos. Wird die Ereignisbehandlung dagegen im Testmodus für ein Formular ausgelöst, kann Änderungen später speichern tatsächlich Entitäten ändern oder erstellen.

Beispiel

Ein Eigenes Aktionsevent "Geschäftsobjekt speichern" wird im Kontext von verschiedenen Erfassungsmasken ausgelöst, wenn ein bestimmtes Geschäftsobjekt automatisch gespeichert werden soll. Als Datenkontext für die Verhaltensweise Eigenes Aktionsevent auslösen (Formulardesigner) kommen dabei entweder die Formulardaten (bzw. die in der Erfassungsmaske angezeigte Entität) in Frage oder auch die Daten eines eingebetteten Formulars (s. Formulare einbetten (Sub-Formulare)), mit den Daten einer zusätzlich in das Formular geladenen Entität.