Skip to Content

Retry a failed operation in Jitterbit Studio

Introduction

Transient failures (such as API rate-limit responses, brief network timeouts, or temporary service unavailability) can cause an otherwise healthy operation to fail intermittently. Rather than letting a single failure halt an integration, a retry controller script re-runs the operation automatically up to a configured number of times before raising a final error.

This guide shows how to write a retry controller script using While, RunOperation, GetLastError, and RaiseError.

This guide assumes familiarity with using scripts to call operations. For background, see Chain and control operations. For considerations around running RunOperation asynchronously, see Manage asynchronous operations.

Design pattern

The pattern uses two operations:

  • Target operation: The operation that may fail transiently, typically one that calls an external API.
  • Controller operation: A single script step that calls the target using RunOperation inside a While loop with a counter.

Three variables coordinate the loop:

  • maxRetries: the total number of attempts to make before raising an error. Set this to the maximum number of times the operation should run, including the first attempt.
  • attempt: the current attempt count, initialized to 0 and incremented at the start of each loop iteration.
  • success: a flag initialized to false and set to true when RunOperation succeeds, which exits the loop early.

Part 1: Configure the target operation

The target operation can be any operation: an HTTP v2 GET, a connector query, or a transformation chain. The only requirement is that it exists as a named operation on the design canvas so that RunOperation can call it by tag.

If the operation is already on the canvas as a standalone operation, no changes are needed. If it is currently inline in a larger chain, move it to its own operation so it can be called independently.

Part 2: Write the retry controller script

  1. On the design canvas, create a new operation containing only a Script step.

  2. Double-click the script to open the editor and enter the following:

    $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());
);

    Replace Call External API with the exact name of the target operation.

  3. Save the script.

Key points about this script:

  • $maxRetries = 3 means 3 total attempts. Adjust this value to suit the reliability characteristics of the target endpoint.
  • The loop exits as soon as RunOperation returns true (success) or after maxRetries attempts have been made, whichever comes first.
  • WriteToOperationLog records each failed attempt in the operation log, making it straightforward to see how many retries occurred before success or final failure.
  • RaiseError(GetLastError()) stops the controller operation and surfaces the last error message after all attempts are exhausted.
  • RunOperation is synchronous by default, so the loop waits for each attempt to complete before evaluating the next iteration.

Tip

Rate-limited APIs: If retrying after a rate-limit response (HTTP 429), add a Sleep call before RunOperation to pause between attempts (for example, Sleep(2) waits 2 seconds). Retrying immediately will hit the same rate limit repeatedly and extend the failure window.

Tip

To limit the number of loop iterations allowed, set $jitterbit.scripting.while.max_iterations before the While call. The default limit is 50,000 iterations, which is well above any practical retry count, so this is only necessary if you have configured a lower global limit elsewhere in the project.

Verify the integration

Deploy and run the controller operation. Check the operation logs: each failed attempt appears as a separate log entry. If all attempts fail, the log shows one entry per attempt followed by the final raised error. If the operation succeeds on an earlier attempt, only the failures up to that point appear.

To test retry behavior before running against a live endpoint, temporarily configure the target operation to fail (for example, by entering an invalid URL in the connection) and set $maxRetries = 2. The log should show two failed attempts and a final raised error. Restore the correct configuration before deploying to production.