Fehlerbehandlung bei Aktionen in 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 Drittanbieter-Services 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:

• Fehler ignorieren.

• Aktionshandler.

Fehler ignorieren

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 „Fehler ignorieren" aktiviert ist, wird die Ausnahme jedoch abgefangen. Die Aktion setzt die Verarbeitung der verbleibenden Zeilen fort und das Ereignis wird erfolgreich abgeschlossen. Es liegt in der Verantwortung des Entwicklers, Fehler mithilfe eines Aktionshandlers zu behandeln.

Aktionshandler

Ein Aktionshandler ist grundsätzlich eine Aktion. Aktionshandler unterscheiden sich jedoch von Aktionen auf folgende Weise:

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

• Während Aktionen an die Datensatzeile 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 öffentlichen Datenobjekt EventHistory.

• Rückgängigmachen der Auswirkungen fehlgeschlagener Aktionen, die nicht durch Datenbank-Transaktionen zurückgerollt werden können.

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

• contextid: Ein eindeutiger Bezeichner, der verwendet werden kann, um Ereignisse zu korrelieren, die innerhalb einer einzelnen Operation auftreten, z. B. die Ereignisse, die von einer Business CRUD-Aktion ausgeführt werden.

• rowid: Ein eindeutiger Bezeichner für die Zeile, auf der das Ereignis aufgerufen wurde. Im Fall einer Business CRUD-Regel bezieht sich dies auf die Zielzeile. Im Fall eines Aktionshandlers bezieht sich dies auf die Aktionsquellzeile.

• source.rowid: Ein eindeutiger Bezeichner für die Quellzeile der Business CRUD-Regel. Dies gilt für Einfüge- und Aktualisierungsregeln.

• exception: Eine Ausnahmemeldung. Dieser Wert ist für Fehlerhandler von Aktionen zugänglich, wenn das Ereignis aufgrund einer Ausnahme fehlgeschlagen ist.

Die Eigenschaften rowid und source.rowid ermöglichen es Entwicklern, einen Zeilenfehler mit einem Eintrag im öffentlichen Datenobjekt EventHistory zu korrelieren. Ein typisches Setup könnte Folgendes umfassen:

• Aktion: Eine Business CRUD-Einfügeregel, die auf einen REST-Endpunkt abzielt. Die Option Fehler ignorieren ist aktiviert.

• Erfolgshandler: Eine Datenbank CRUD-Regel, die die Aktionsquellzeile aktualisiert, um anzugeben, dass die Zeile verarbeitet wurde. Dies kann verwendet werden, um den Status einer laufenden Operation zu melden oder die Zeile von zukünftigen Ausführungen auszuschließen. (Damit dieser Handler sichtbar ist, muss die zugehörige Regel auf die Logikschicht abzielen.)

• Fehlerhandler: Eine Datenbank CRUD-Regel, die die Aktionsquellzeile aktualisiert, um anzugeben, dass die Zeile fehlgeschlagen ist. Die Datenbank CRUD-Regel würde die Funktion event('rowid') verwenden, um den Zeilenbezeichner zu erfassen. (Damit dieser Handler sichtbar ist, muss die zugehörige Regel auf die Logikschicht abzielen.)

• Rollback-Handler: Aktionen, die die Auswirkungen aller erfolgreichen Aktionen rückgängig machen, 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 anzeigen. Der Entwickler könnte beispielsweise eine Seite mit zwei Bereichen erstellen. Der erste Bereich listet die fehlgeschlagenen Zeilen auf. Der zweite Bereich ist an das öffentliche Datenobjekt EventHistory gebunden. Dieser Bereich ist an den ersten Bereich gebunden und gleicht RowId mit SourceRowId ab.