Retry

Discover more about the Retry connector and how to use it on the Digibee Integration Platform.

Retry allows new retries of steps defined in a subpipeline to be executed.

Parameters

Take a look at the configuration parameters of the connector. Parameters supported by Double Braces expressions are marked with (DB).

Parameter	Description	Default value	Data type
Maximum Number of Retries	The first retry also counts, so if the step fails in the first execution and you want a new retry to be made, the value of this parameter should be 2.	3	Integer
Timeout Of The Whole Retry Operation	Maximum length of the sum of all retry attempts, including the first one (in milliseconds).	30000	Integer
Fail On Error	If the option is activated, the Retry execution that reaches the maximum number of tries or the maximum length will end with an error and will be interrupted; otherwise, the pipeline execution continues, but the result of the last try will be delivered to the next connector.	False	Boolean

Defining the subpipeline to be executed on each new retry

To work with this type of connector, it's important to consider:

• Subpipeline defined in onProcess: subpipeline to be executed on each new retry.

• Subpipeline defined in onException: subpipeline to be executed after an unsuccessful retry.

To better understand how subpipelines work, read the Subpipelines documentation.

On each new retry, the first step on the subpipeline defined in onProcess receives the output message from the last processed step. Therefore, data to be reused on new retries must be correctly handled to be accessible during the new retries (that is, the data manipulation through the Session connector).

Informing success to a Retry block execution

The Retry connector expects a "success" property with the "true" value to be informed in the last step of the subpipeline for the execution to be considered successful. If an error occurs or the “success” property is informed with a "false" value or doesn’t even exist, Retry will understand that a new retry must be executed.

Messages flow

Input

Any structure is accepted.

Output

The output message of the last processed step.

Handling Errors

When an error occurs during the processing of the subpipeline in onProcess, the subpipeline defined in onException will be invoked, if it's defined.

In onException, it's possible to:

• have access to the details of the error that occurred during the processing of the last retry.

• define if the Retry connector continues with the retries, informing a “success” property with the "false" value. If a “success” property is specified with the "true" value, then Retry will be successfully finished and no other retry will be executed.

Usage scenarios of the Retry connector with errors handling

Enabled Fail on Error property and no subpipeline defined in onException

• the pipeline will be interrupted after all the retries;

• an error will be thrown from the Retry connector;

• no other connector will be invoked after the Retry.

Enabled Fail on Error property and a subpipeline defined in onException

• the pipeline will be interrupted after all the retries;

• the subpipeline defined in onException will be executed after every new retry;

• an error will be thrown from the Retry connector;

• no other connector will be invoked after the Retry.

Disabled Fail on Error property and no subpipeline defined in onException

• the pipeline will not be interrupted after all the retries;

• no error will be thrown from the Retry connector;

• the next connector will be invoked receiving the output message from the Retry.

Disabled Fail on Error property and a subpipeline defined in onException

• the pipeline will not be interrupted after all the retries;

• the subpipeline defined in onException will be executed after every new retry;

• no error will be thrown from the Retry connector;

• the next connector will be invoked receiving the output message from the Retry.

If an error connector (such as Throw Error or Assert) is used on the subpipeline in onProcess, or if an error occurs, the attempt fails and Retry tries again until it reaches Maximum Retries. The error is not propagated at that point. Whether an exhausted Retry raises anything is decided by Fail On Error: with Fail On Error disabled the pipeline continues and the next connector receives the last failed attempt's message; with Fail On Error enabled the pipeline is interrupted. Besides, whenever the success property is defined with the true value on the last step of the subpipeline in onException, the Retry execution will be finished, even if the Fail on Error property is activated.