Abbrechen

Ereignisaktion - Kurzfassung

Zweck: Bricht Ereignisbehandlungen sofort mit oder ohne Anzeige einer Fehlermeldung ab und führt einen Rollback für die Transaktion aus. In einem Client Workflow-Verhalten wird ein "Fehlerinformation"-Objekt an die Aktionen bei "falsch" übergeben.

Tooltip

• Verwendung: Ermöglicht das Abbrechen der Ereignisverarbeitung in einer Ereignisbehandlung oder in einem Client Workflow-Verhalten.

• Parameter:

  • Der Parameter Fehlertyp steuert in einer Ereignisbehandlung die Ausgabe der Fehlermeldung. Im Client Workflow spiegelt er sich nur im Feld errorLevel des "Fehlerinformation"-Objekts.

  • Als Fehlercode kann ein Resource Name aus dem Resoruce Bundle error angegeben werden, um die entsprechende Lokalisierung als Fehlermeldung auszugeben.

  • Die Standardfehlermeldung definiert per Direkteingabe oder als Wert-Konfiguration Text der als Fehlermeldung erscheint, falls kein Fehlercode angegeben oder für diesen keine Lokalisierung definiert ist.

  • Optional definierbare Parameter ersetzen zugehörigen Platzhalter ({0}, {1}, ...) im Text der Fehlermeldung.

• Output:

  • In Ereignisbehandlungen: Benachrichtigung (gemäß Fehlertyp) und Transaktionsabbruch/Rollback.

  • Im Client Workflow: Übergabe eines "Fehlerinformation"-Objekts an die Aktionen bei "falsch".

Das Ausführen der Abbrechen-Ereignisaktion beendet die Ereignisverarbeitung sofort. Abhängig vom Kontext hat dies unterschiedliche Auswirkungen:

Der Text für die ggf. ausgegebene Fehlermeldung (errorText) wird durch eine der folgenden Methoden bestimmt:

• Direkteingabe im Parameter Standardfehlermeldung (ohne Rücksicht auf die Aktuelle Sprache)

• Wert-Konfiguration für den Parameter Standardfehlermeldung (ggf. lokalisierbar über den Wert aus Sprachverwaltung-Wertauflöser)

• Verweis auf einen Fehlercode, der in der Sprachverwaltung (Bundle: error, Resource: <Fehlercode>) oder über Firmenspezifische Sprachanpassungen lokalisiert ist.

Optional kann die Konfiguration Parameter definieren, die zur Laufzeit - sofern vorhanden - Platzhalter ({0}, {1}, ...) in der Standardfehlermeldung oder im Lokalisierungstext für den angegebenen Fehlercode ersetzen.

 HINWEIS  Die Werte der Parameter können wahlweise durch statische Direkteingabe oder per Wert-Konfiguration bestimmt sein. Bei Bedarf kann auch hier der Wert aus Sprachverwaltung-Wertauflöser eingesetzt werden, um lokalisierte Texte als Parameterwert zurückzugeben.

Parameter

Fehlertyp

Die optionale Auswahl für den Parameter Fehlertyp bestimmt in Ereignisbehandlungen und in einem Client Workflow den Wert für das Feld errorLevel (s. Tabellenspalte) im beim Abbrechen zurückgegebenen "Fehlerinformation"-Objekt (ErrorInfo).

• Die Auswahlmöglichkeiten für den Fehlertyp sind durch die statische Aufzählung "Abbruchtyp" (AbortType) vordefiniert.

• Ohne Auswahl wird der Standard-Fehlertyp "Process Exception" (ProcessException) ausgelöst bzw. der errorLevel-Wert 1 zugeordnet.

 HINWEIS 

• Unabhängig von der Auswahl für den Fehlertyp wird das Ausführen der Abbrechen-Ereignisaktion zur Laufzeit immer als "Process Exception" gewertet. Im Kontext von Ereignisbehandlungen wird daher immer ein Rollback ausgelöst.

• Die konfigurierte Rückmeldung erscheint nicht beim Ausführen von Tests. Stattdessen erscheint als Ergebnis immer ein "Fehlerinformation"-Objekt (ErrorInfo). Der Fehlertyp wird spiegelt sich in dessen errorLevel-Feld (s. a. Tabellenspalte oben).

• Wird die Abbrechen-Ereignisaktion innerhalb einer Try-Catch-Aktion ausgeführt, steht dasselbe "Fehlerinformation"-Objekt (ErrorInfo) im "Catch"-Block zur Verfügung.

• Wurde die abgebrochene Ereignisverarbeitung durch ein Lobster_data-Profil (z. B. einen Import) ausgelöst, wird dort immer eine "Process Exception" gemeldet.

• Wird als Rückmeldung eine Notification eines beliebigen Typs angezeigt, öffnet ein Mausklick auf die Benachrichtigung die Fehlermeldung als Dialog wie beim Fehlertyp "Process Exception".

Fehlercode

Wenn für den optionalen Parameter Fehlercode ein statischer Textwert eingetragen wird, wird zur Laufzeit geprüft, ob ein Lokalisierungseintrag für diesen Text als Resource Name im Bundle error existiert (Sprachverwaltung bzw. Firmenspezifische Sprachanpassungen).

• Existiert ein Lokalisierungseintrag für den Fehlercode im Bundle error, wird als Fehlermeldung die Lokalisierung für die Aktuelle Sprache aus diesem Lokalisierungseintrag verwendet. Der Parameter Standardfehlermeldung wird dann ignoriert.

• Sind im Wertauflöser Parameter konfiguriert, werden diese ggf. auf Platzhalter im Lokalisierungstext für den Fehlercode abgebildet.

Beispiel:

Der Fehlercode CORESYSTEM_BaseDataManager_failedToDelete ist per Standard in der Sprachverwaltung wie folgt lokalisiert:

Die Fehlermeldung kann über den Platzhalter {0} per Parameter individualisiert werden:

 ANMERKUNG  In der Praxis wäre anstelle des simplen statischen Texts ("Sorry!") im ersten Parameter ({0}) sicher eher eine Wert-Konfiguration anzutreffen, etwa um zu spezifizieren, welches Objekt nicht gelöscht werden könnte und/oder warum.

Standardfehlermeldung

Im Parameter Standardfehlermeldung kann per Direkteingabe ein statischer Klartext eingegeben oder - nach einem Klick auf den kleinen grauen Pfeil links unten - eine Wert-Konfiguration vorgenommen werden:

Die Standardfehlermeldung definiert den Text, der genau dann als Fehlermeldung ausgegeben wird bzw. im errorText-Feld erscheint, wenn die folgende Bedingung erfüllt ist:

• Es wurde kein Fehlercode angegeben oder für das Bundle error wird kein Lokalisierungseintrag gefunden, dessen Resource Name mit dem angegebenen Fehlercode exakt übereinstimmt.

Sofern der statisch eingegebene oder zur Laufzeit per Wert-Konfiguration zur ermittelte Text Platzhalter enthält, können diese durch Parameter (s. u.) gefüllt werden.

 HINWEIS   Liefert der Fehlercode einen Lokalisierungseintrag, für den als Lokalisierung für die Aktuelle Sprache eine leere Zeichenfolge gilt, wird nicht die Standardfehlermeldung als Fehlermeldung gesetzt sondern die leere Zeichenfolge.

Parameter

Der Konfiguration können per Klick auf das -Symbol optional Definitionen für Parameter hinzugefügt werden.

Jeder Parameter definiert einen Text, für den Platzhalter im Text für die Fehlermeldung, der sich auf die Indexnummer des Parameters in der Konfiguration bezieht.

• Der erste Parameter adressiert den Platzhalter {0}, der nächste den Platzhalter {1}, usw.

• Derselbe Parameter kann in der Fehlermeldung mehrfach adressiert werden, indem der Platzhalter wiederholt eingesetzt wird.

Platzhalter können sowohl im Lokalisierungstext für einen Fehlercode (s. o.) als auch in der Standardfehlermeldung (s. o.) enthalten sein.

Für jeden Parameter kann wahlweise per Direkteingabe ein statischer Klartext eingegeben oder - nach einem Klick auf den kleinen grauen Pfeil links unten - eine Wert-Konfiguration vorgenommen werden.

In den folgenden Beispielen werden jeweils beide Optionen (Direkteingabe, Wert-Konfiguration) für je einen Parameter genutzt.

 ANMERKUNG  Die Direkteingabe des Texts "LÖSCHEN" mag im linken Fall Sinn machen, weil die Fehlermeldung insgesamt keine Lokalisierung berücksichtigt. Rechts dagegen ist die Verwendung von "LÖSCHEN" kritisch, wenn eine andere Aktuelle Sprache als "Deutsch" verwendet wird. Denn dann würde zwar die Fehlermeldung lokalisiert aber nicht der Text für den Platzhalter {1}.

Sonderfall

---

Falls die Wert-Konfiguration für einen Parameter insgesamt den Wert einer Dynamischen Aufzählung zurückgibt, greift AUSNAHMSWEISE auch im Kontext von Ereignisbehandlungen ausnahmsweise die Lokalisierung für die Aktuelle Sprache.

Beispiele

Einfacher Anwendungsfall: Client Workflow ohne Meldung abbrechen

Im Kontext eines Formulars (s. Portale bzw. Erfassungsmasken) soll ein Client Workflow-Verhalten abgebrochen werden, wenn die initial ausgeführte Suche (Ereignisaktion) kein Ergebnis liefert, die auf ein Benutzerkonto (s. Benutzer) zugreifen soll.

Konfiguration:

Laufzeitverhalten:

Sofern der Zugriff auf das "gesuchte" Benutzerkonto scheitert, bricht die Ereignisverarbeitung innerhalb des Client Workflow-Verhaltens sofort ab:

• Sofern unterhalb der oben dargestellten Wenn Dann Sonst-Ereignisaktion weitere Ereignisaktionen konfiguriert sind, werden diese nicht ausgeführt.

• Auf der Ebene des Client Workflow-Verhaltens (s. Verhalten) werden außerdem die Aktionen bei "falsch" ausgeführt (sofern vorhanden) und nicht die Aktionen bei "wahr".

• Als Eingabewert ($input) wird den Aktionen bei "falsch" ein "Fehlerinformation"-Objekt (ErrorInfo) übergeben, dessen Feld errorLevel mangels Auswahl für den Fehlertyp in der Abbrechen-Ereignisaktion den Standardwert 1 für den Fehlertyp "Process Exception" (ProcessException) angibt.

 HINWEIS  Über das "Fehlerinformation"-Objekt als Rückgabewert kann in den Aktionen bei "falsch" eine Hinweis anzeigen-Aktion ausgeführt werden.

Konfiguration:

 ANMERKUNG  Der Fehlertyp (bzw. der errorLevel kann zwar nicht dynamisch auf die Auswahl für den Typ in der Hinweis anzeigen-Aktion abgebildet werden. Bei Bedarf könnte man allerdings abhängig vom errorLevel-Wert das "Fehlerinformation"-Objekt an eines von mehren Verhalten übergeben, in denen jeweils ein spezifischer Typ für die Hinweis anzeigen-Aktion verwendet wird. Lediglich das Erscheinungsbild für den Standard-Fehlertyp mit den oben beschriebenen erweiterten Interaktionsmöglichkeiten kann so nicht simuliert werden.

Konfiguration:

Diese Art der "Fallunterscheidung" ist nur dann wirklich sinnvoll, wenn ein Client Workflow mehrere Instanzen der Abbrechen-Ereignisaktion beinhaltet und sich diese auf zu unterscheidende Fehlertypen beziehen.

 HINWEIS  Vergleichbare Ergebnisse kann man auch erzielen, wenn man im Client Workflow unmittelbar vor der Abbrechen-Ereignisaktion eine Hinweis anzeigen (Popup)-Ereignisaktion ausführt, die als Fehlermeldung parametriert wird. Dann erübrigt sich die Parametrierung der Abbrechen-Ereignisaktion und die Konfiguration von Aktionen bei "falsch" eventuell komplett.

Komplexerer Anwendungsfall: Ereignisbehandlung mit/ohne Meldung abbrechen

Bei jedem Speichern einer Entität vom Typ "Bestellung" (s. Bestellungen) werden vielfältige Kriterien ausgewertet, um abhängig vom aktuellen Arbeitsstatus (s. Aktueller-Arbeitsstatus-Regel) ggf. automatisch einen im Workflow nachfolgenden Arbeitsstatus zuzuweisen (s. Aktuellen Arbeitsstatus setzen).

Details zum Workflow sollen hier keine Rolle spielen. Allerdings soll der automatische Wechsel zu bestimmten Arbeitsstatus nur ausgeführt werden, wenn der Benutzer dies ausdrücklich per Benutzer-Rückfrage bestätigt. Dabei sollen folgende Fälle unterschieden werden:

Konfiguration:

Laufzeitbeispiel:

 HINWEIS  Ein Sprachgemisch innerhalb der Meldungen kann nur vermieden werden, wenn alle konfigurierbaren Inhalte konsequent lokalisiert werden, sodass die Aktuelle Sprache für alle Texte greift. Anstelle von statischem Text sollte jeweils der Wert aus Sprachverwaltung-Wertauflöser verwendet werden.