/
Retry Rows

Retry Rows

Owned by Ben Clark
Last updated: Jul 13, 2023
3 min read

Overview

 

 

  • This is likely to be used by more techncial users when integrating with unreliable systems.

  • This step allows a user to retry a set number of times to try to achieve a succesfull result.

  • We will show the steps where the row can be returned to

Plugin Configuration

General

 

The following settings can be configured:

Setting

Description

Setting

Description

Step Name

Name of the step

Loop counter field

The field that will be used to hold the retry counts. You can choose to use any integer field including the standard loopcount field added by our Realtime Input and Process Future event steps.

Number of Retries

The number of times a row will be retried. This can be set via parameter if required. Maximum of 10 retries.

Target Step

Dropdown list of steps where a row could be placed to retry. The eligle steps are defined through the following conditions:

  • It must be upstream of the retry step.

  • It must have the same input fields (or fewer) than the retry step

  • There must not be any step that changes the number of rows inbetween the retry step and the retry target - i.e. “Split field to rows”, “Row normaliser”, “Row denormaliser”

  • The retry target must have a single input connector

Delay Type

  • None - We will retry the row immediately

  • Constant - Allows you to stipulate a delay. This is set in the Delay Time field below.

Delay Time (m)

Sets the delay time for the step up to 5000 ms. Default 1000 ms.

 

Scenario 1

Retrying a Unreliable HTTP POST

The filter rows step identifies failed posts via the “HTTP status code”. The Retry HTTP Post step picks up the row and places it back in the main flow at “Unreliable HTTP post” to be tried again. If the number of retries exceeds the Number of Retries it flow through the retries step to the Fail output.

 

Scenario 2

The Check Status Code step dentifies failed posts based on the HTTP status code. In the event of a failure, the "Retry HTTP Post" step retrieves the row and reintroduces it into the main flow at the HTTP post step for another attempt. If the number of retries surpasses the specified limit (Number of Retries), the process progresses from the retries step into the Fail output.

We evaluate the result of the post, and if we are dissatisfied with the outcome, we make another attempt using the "Retry HTTP 2" step, which places the row back into the HTTP Post stage for further processing.

 

Related content