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.

►HINWEISE◄

• 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:

error

CORESYSTEM_BaseDataManager_failedToDelete

Löschen nicht möglich: {0}

Failed to delete: {0}

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}.

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.