Zum Inhalt springen

Fehlerbehandlung bei Aktionen im Jitterbit App Builder

Fehlerbehandlung

Die meisten Aktionstypen werden sofort beendet, wenn eine nicht behandelte Ausnahme auftritt. Die Ausnahme wird im Ereignisverlauf protokolliert. Es liegt in der Verantwortung des Entwicklers, die Daten vor der Ausführung der Aktion zu validieren.

Business CRUD Aktionen führen plattformübergreifende Operationen durch. In einigen Fällen umfasst die Operation eine oder mehrere API-Anfragen an Drittanbieterdienste wie REST-Endpunkte. Es ist oft schwierig, die Daten vor der Ausführung der Aktion zu validieren. Stattdessen müssen Entwickler die Ausnahme abfangen und behandeln.

Zu diesem Zweck unterstützen Business CRUD-Aktionen die folgenden Funktionen:

Fortfahren bei Fehlern

Eine Business CRUD-Aktion ruft die Quellzeilen der Regel in Batches ab und führt das Ereignis (Einfügen, Aktualisieren oder Löschen) für jede Zeile im Batch aus. Standardmäßig beendet eine nicht behandelte Ausnahme die Operation: Es werden keine zusätzlichen Zeilen verarbeitet.

Wenn die Option Fortfahren bei Fehlern jedoch aktiviert ist, wird die Ausnahme abgefangen. Die Aktion verarbeitet die verbleibenden Zeilen weiter, und das Ereignis wird erfolgreich abgeschlossen. Es liegt in der Verantwortung des Entwicklers, etwaige Fehler mit einem Aktionshandler zu behandeln.

Aktionshandler

Ein Aktionshandler ist grundsätzlich eine Aktion. Aktionshandler unterscheiden sich jedoch in folgenden Punkten von Aktionen:

  • Während Aktionen registriert sind, um vor oder nach einem Ereignis ausgeführt zu werden, werden Aktionshandler nach dem Erfolg oder Misserfolg einer Aktion ausgeführt.

  • Während Aktionen an die Datenobjektzeile gebunden sind, sind Aktionshandler an die Aktionsquelle gebunden.

Aktionshandler können für folgende Zwecke verwendet werden:

  • Aufzeichnung des Status einzelner Zeilen.

  • Verfolgung des Fortschritts einer lang laufenden Business CRUD-Operation.

  • Korrelation von Zeilenfehlern mit Einträgen im EventHistory öffentlichen Datenobjekt.

  • Um die Auswirkungen fehlgeschlagener Aktionen, die nicht durch Datenbank-Transaktionen zurückgesetzt werden können, umzukehren.

Entwickler können die event() mvSQL-Laufzeitfunktion innerhalb von Aktionshandlern verwenden, um auf Ereignis- und zeilenbezogene Informationen zuzugreifen, einschließlich der folgenden:

  • contextid: Eine eindeutige Kennung, die verwendet werden kann, um Ereignisse zu korrelieren, die innerhalb einer einzelnen Operation auftreten, z. B. die Ereignisse, die durch eine geschäftliche CRUD-Aktion ausgeführt werden.

  • rowid: Eine eindeutige Kennung für die Zeile, auf der das Ereignis ausgelöst wurde. Im Falle einer geschäftlichen CRUD-Regel bezieht sich dies auf die Zielzeile. Im Falle eines Aktionshandlers bezieht sich dies auf die Aktionsquelle-Zeile.

  • source.rowid: Eine eindeutige Kennung für die Quellzeile der geschäftlichen CRUD-Regel. Dies gilt für Einfüge- und Aktualisierungsregeln.

  • exception: Eine Ausnahme-Nachricht. Dieser Wert ist für die Handler von Aktionsfehlern zugänglich, wenn das Ereignis aufgrund einer Ausnahme fehlgeschlagen ist.

Die Eigenschaften rowid und source.rowid ermöglichen es Entwicklern, einen zeilenbezogenen Fehler mit einem Eintrag im öffentlichen Datenobjekt EventHistory zu korrelieren. Eine typische Konfiguration könnte Folgendes umfassen:

  • Aktion: Eine geschäftliche CRUD-Einfügeregel, die auf einen REST-Endpunkt abzielt. Die Option Fortfahren bei Fehlern ist aktiviert.

  • Erfolgs-Handler: Eine Datenbank-CRUD-Regel, die die Aktionsquelle-Zeile aktualisiert, um anzuzeigen, dass die Zeile verarbeitet wurde. Dies kann verwendet werden, um den Status einer laufenden Operation zu melden oder um die Zeile von zukünftigen Durchläufen auszuschließen. (Damit dieser Handler sichtbar ist, muss die zugehörige Regel die Logikschicht anvisieren.)

  • Fehler-Handler: Eine Datenbank-CRUD-Regel, die die Aktionsquelle-Zeile aktualisiert, um anzuzeigen, dass die Zeile fehlgeschlagen ist. Die Datenbank-CRUD-Regel würde die Funktion event('rowid') verwenden, um die Zeilenkennung aufzuzeichnen. (Damit dieser Handler sichtbar ist, muss die zugehörige Regel die Logikschicht anvisieren.)

  • Rollback-Handler: Aktionen, die die Auswirkungen aller erfolgreichen Aktionen umkehren, die vor einer fehlgeschlagenen Aktion aufgetreten sind. Die fehlgeschlagene Aktion selbst wird von diesem Handler nicht behandelt.

Entwickler sollten die Fehler in der Benutzeroberfläche sichtbar machen. Zum Beispiel könnte der Entwickler eine Seite mit zwei Panels erstellen. Das erste Panel listet die fehlgeschlagenen Zeilen auf. Das zweite Panel ist an das öffentliche Datenobjekt EventHistory gebunden. Letzteres Panel ist mit dem ersteren verbunden, wobei RowId mit SourceRowId übereinstimmt.