In this Page

Scenario

I want to configure retry logic within my pipeline that cannot be run as an Ultra Task.

Requirements

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

...

• 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.

Configuration

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.

Parent Pipeline

This pipeline consists of:

...