Zum Inhalt springen

Fehlgeschlagenen Vorgang in Jitterbit Studio erneut ausführen

Einführung

Vorübergehende Fehler (wie API-Ratenlimit-Antworten, kurze Netzwerk-Timeouts oder temporäre Serviceverfügbarkeit) können dazu führen, dass ein ansonsten fehlerfreier Vorgang zeitweilig fehlschlägt. Anstatt einen einzelnen Fehler die Integration zu stoppen, führt ein Retry-Controller-Skript den Vorgang automatisch bis zu einer konfigurierten Anzahl von Malen erneut aus, bevor ein endgültiger Fehler ausgelöst wird.

Diese Anleitung zeigt, wie man ein Retry-Controller-Skript mit While, RunOperation, GetLastError und RaiseError schreibt.

Diese Anleitung setzt Vertrautheit mit der Verwendung von Skripten zum Aufrufen von Vorgängen voraus. Hintergrundinformationen finden Sie unter Vorgänge verketten und steuern. Überlegungen zum asynchronen Ausführen von RunOperation finden Sie unter Asynchrone Vorgänge verwalten.

Entwurfsmuster

Das Muster verwendet zwei Vorgänge:

  • Zielvorgang: Der Vorgang, der vorübergehend fehlschlagen kann, typischerweise einer, der eine externe API aufruft.
  • Controller-Vorgang: Ein einzelner Skriptschritt, der das Ziel mit RunOperation in einer While-Schleife mit einem Zähler aufruft.

Drei Variablen koordinieren die Schleife:

  • maxRetries: die Gesamtzahl der Versuche vor dem Auslösen eines Fehlers. Legen Sie dies auf die maximale Anzahl fest, wie oft der Vorgang ausgeführt werden soll, einschließlich des ersten Versuchs.
  • attempt: die aktuelle Versuchszahl, initialisiert auf 0 und am Anfang jeder Schleifenwiederholung erhöht.
  • success: ein Flag, das auf false initialisiert und auf true gesetzt wird, wenn RunOperation erfolgreich ist, wodurch die Schleife vorzeitig beendet wird.

Teil 1: Zielvorgang konfigurieren

Der Zielvorgang kann ein beliebiger Vorgang sein: ein HTTP v2 GET, eine Connector-Abfrage oder eine Transformationskette. Die einzige Anforderung ist, dass er als benannter Vorgang auf der Designoberfläche vorhanden ist, damit RunOperation ihn nach Tag aufrufen kann.

Wenn der Vorgang bereits auf der Oberfläche als eigenständiger Vorgang vorhanden ist, sind keine Änderungen erforderlich. Wenn er sich derzeit inline in einer größeren Kette befindet, verschieben Sie ihn in einen eigenen Vorgang, damit er unabhängig aufgerufen werden kann.

Teil 2: Retry-Controller-Skript schreiben

  1. Erstellen Sie auf der Designoberfläche einen neuen Vorgang, der nur einen Script-Schritt enthält.

  2. Doppelklicken Sie auf das Skript, um den Editor zu öffnen, und geben Sie Folgendes ein:

    $maxRetries = 3;
$attempt = 0;
$success = false;

While(!$success && $attempt < $maxRetries,
    $attempt++;
    If(RunOperation("<TAG>operation:Call External API</TAG>"),
        $success = true;
    ,
        WriteToOperationLog("Attempt " + $attempt + " of " + $maxRetries + " failed: " + GetLastError());
    );
);

If(!$success,
    RaiseError("Operation failed after " + $maxRetries + " attempts: " + GetLastError());
);

    Ersetzen Sie Call External API durch den genauen Namen des Zielvorgangs.

  3. Speichern Sie das Skript.

Wichtige Punkte zu diesem Skript:

  • $maxRetries = 3 bedeutet 3 Gesamtversuche. Passen Sie diesen Wert an die Zuverlässigkeitsmerkmale des Zielendpunkts an.
  • Die Schleife wird beendet, sobald RunOperation true (Erfolg) zurückgibt oder nachdem maxRetries Versuche unternommen wurden, je nachdem, was zuerst eintritt.
  • WriteToOperationLog protokolliert jeden fehlgeschlagenen Versuch im Vorgangsprotokoll, sodass man leicht sehen kann, wie viele Wiederholungen vor Erfolg oder endgültigem Fehler aufgetreten sind.
  • RaiseError(GetLastError()) stoppt den Controller-Vorgang und zeigt die letzte Fehlermeldung an, nachdem alle Versuche erschöpft sind.
  • RunOperation ist standardmäßig synchron, daher wartet die Schleife, bis jeder Versuch abgeschlossen ist, bevor die nächste Iteration ausgewertet wird.
  • RunOperation unterliegt auch einer Agentenstufen-Beschränkung für synchrone Aufrufe innerhalb einer einzelnen While-Schleife (50 standardmäßig). Dies liegt weit über jedem typischen maxRetries-Wert, aber wenn Sie eine ungewöhnlich hohe Wiederholungsanzahl konfigurieren, siehe den Hinweis unter RunOperation für Details.

Tipp

Ratenlimit-APIs: Wenn Sie nach einer Ratenlimit-Antwort (HTTP 429) erneut versuchen, fügen Sie einen Sleep-Aufruf vor RunOperation hinzu, um zwischen Versuchen zu pausieren (z. B. wartet Sleep(2) 2 Sekunden). Ein sofortiger Wiederholungsversuch führt zu demselben Ratenlimit wiederholt und verlängert das Fehlerfenster.

Tipp

Um die Anzahl der zulässigen Schleifendurchläufe zu begrenzen, setzen Sie $jitterbit.scripting.while.max_iterations vor dem While-Aufruf. Das Standardlimit beträgt 50.000 Iterationen, was weit über jedem praktischen Wiederholungsversuch liegt. Dies ist daher nur erforderlich, wenn Sie anderswo im Projekt ein niedrigeres globales Limit konfiguriert haben.

Integration überprüfen

Stellen Sie die Controller-Operation bereit und führen Sie sie aus. Überprüfen Sie die Operationsprotokolle: Jeder fehlgeschlagene Versuch wird als separater Protokolleintrag angezeigt. Wenn alle Versuche fehlschlagen, zeigt das Protokoll einen Eintrag pro Versuch gefolgt vom endgültigen ausgelösten Fehler. Wenn die Operation bei einem früheren Versuch erfolgreich ist, werden nur die Fehler bis zu diesem Punkt angezeigt.

Um das Wiederholungsverhalten vor dem Ausführen gegen einen Live-Endpunkt zu testen, konfigurieren Sie die Zieloperation vorübergehend so, dass sie fehlschlägt (geben Sie beispielsweise eine ungültige URL in der Verbindung ein), und setzen Sie $maxRetries = 2. Das Protokoll sollte zwei fehlgeschlagene Versuche und einen endgültigen ausgelösten Fehler anzeigen. Stellen Sie die korrekte Konfiguration wieder her, bevor Sie in der Produktion bereitstellen.