Pipeline: Configure Retry logic

Configure retry logic within the pipeline that cannot be run as an Ultra Task.

Requirements

The following example contains a pattern for retry logic using self referential pipeline, a retry count, retry limit, and a ForEach Snap.

It consists of three pipelines:

The pipeline to be retried.
The retry pipeline. This pipeline does the actual validation of the retry policy, checks the retry count against the retry limit, calls pipeline #1. If pipeline #1 fails, this process calls itself by incrementing the retry count.
A parent pipeline. This is a wrapper on pipeline #2, that would first call pipeline#1; if failed calls pipeline #2 and sets a retry count and retry limit.

The pipeline to be retried

No special configuration is needed here.

The Retry pipeline

This pipeline consists of:

Pipeline parameters retryCount of 1 and retryLimit of 5 defined in the pipeline properties.
A Mapper Snap (Retry params in the screenshot) with:
- No input view.
- The transformation of:
  - parseInt(_retryCount) mapping to $retryCount.
  - parseInt(_retryLimit) mapping to $retryLimit.
A Filter Snap (Is count less than limit in the screenshot) with a Filter expression of: $retryCount<=$retryLimit
A ForEach Snap (Retry child in the screenshot) with:
- Pipeline set to the pipeline to be retried.
- A valid Snaplex selected.
- Execution mode set to Synchronous.
- Batch Size of 1.
- Maximum Instances of 1.
- Snap Execution Validate & Execute.
- Error view set to route error to error view.
A ForEach Snap (Self referencial in the screenshot) attached to the error view of the previous ForEach Snap with:
- Pipeline set to this pipeline.
- A valid Snaplex selected.
- Execution mode set to Synchronous.
- Batch Size of 1.
- Pipeline parameters set as follows:
  - retryCount to parseInt($original.data.retryCount) + 1
  - retryLimit to _retryLimit
- Maximum Instances of 50.
- Snap Execution Execute only.

The Parent pipeline

This pipeline consists of: