Zum Inhalt springen

Aktionsfehlerbehandlung im Jitterbit App Builder

Fehlerbehandlung

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

Mit Business-CRUD-Aktionen werden plattformübergreifende Vorgänge ausgeführt. In manchen Fällen umfasst der Operation eine oder mehrere API Anfragen an Dienste von Drittpartei wie REST- Endpoints. Es ist oft schwierig, die Daten vor der Ausführung der Aktion zu validieren. Stattdessen müssen Entwickler die Ausnahme abfangen und verarbeiten.

Zu diesem Zweck unterstützen geschäftliche CRUD-Aktionen die folgenden Funktionen:

Bei Fehler fortfahren

Eine geschäftliche CRUD-Aktion ruft die Quellzeilen der Regel stapelweise ab und führt das Ereignis (Einfügen, Aktualisieren oder Löschen) für jede Zeile im Batch aus. Standardmäßig beendet eine unbehandelte Ausnahme den Operation: Es werden keine weiteren Zeilen verarbeitet.

Wenn die Option „Bei Fehler fortfahren“ aktiviert ist, wird die Ausnahme jedoch abgefangen. Die Aktion setzt die Verarbeitung der verbleibenden Zeilen fort und das Ereignis wird erfolgreich abgeschlossen. Es liegt nun in der Verantwortung des Entwicklers, etwaige Fehler mithilfe eines Aktionshandlers zu behandeln.

Aktionshandler

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

  • Während Aktionen so registriert sind, dass sie vor oder nach einem Ereignis ausgeführt werden, werden Aktionshandler ausgeführt, nachdem eine Aktion erfolgreich war oder fehlgeschlagen ist.

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

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

  • Erfassen des Status einzelner Zeilen.

  • Verfolgen des Fortschritts einer lang laufenden CRUD- Operation.

  • Korrelieren von Zeilenfehlern mit Einträgen in der EventHistory öffentliches Datenobjekt.

  • Umkehren der Auswirkungen fehlgeschlagener Aktionen, die nicht durch Datenbank-Transaktionen rückgängig gemacht werden können.

Entwickler können die event() mvSQL- Laufzeit aus Aktionshandlern heraus, um auf Informationen auf Ereignis- und Zeilenebene zuzugreifen, einschließlich Folgendem:

  • contextid: Eine eindeutige Kennung, die zum Korrelieren von Ereignissen verwendet werden kann, die innerhalb einer einzelnen Operation auftreten, z. B. die von einer geschäftlichen CRUD-Aktion ausgeführten Ereignisse.

  • rowid: Eine eindeutige Kennung für die Zeile, für die das Ereignis aufgerufen wurde. Im Fall einer CRUD-Geschäftsregel bezieht sich dies auf die Zielzeile. Im Fall eines Aktionshandlers bezieht sich dies auf die Aktionsquellzeile.

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

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

Der rowid Und source.rowid Eigenschaften ermöglichen es Entwicklern, einen Fehler auf Zeilenebene mit einem Eintrag in der EventHistory öffentliches Datenobjekt. Eine typische Konfiguration könnte Folgendes umfassen:

  • Aktion: Eine geschäftliche CRUD-Einfügeregel, die auf einen REST- Endpoint abzielt. Die Option Bei Fehler fortfahren ist aktiviert.

  • Erfolgshandler: Eine Datenbank-CRUD-Regel, die die Aktionsquellenzeile aktualisiert, um anzuzeigen, 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.

  • Fehlerhandler: Eine Datenbank-CRUD-Regel, die die Aktionsquellenzeile aktualisiert, um anzuzeigen, dass die Zeile fehlgeschlagen ist. Die Datenbank-CRUD-Regel würde die event('rowid') Funktion zum Aufzeichnen der Zeilenkennung.

  • Rollback-Handler: Aktionen, die die Wirkung 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 offenlegen. Beispielsweise könnte der Entwickler eine Seite mit zwei Bedienfeldern erstellen. Das erste Bedienfeld listet die fehlerhaften Zeilen auf. Das zweite Bedienfeld ist an das EventHistory öffentliches Datenobjekt. Das zweite Panel ist an das erste gebunden, passend RowId Zu SourceRowId.