Retry Failed Workflows

[colin_mckibben]

	Description	These workflows allow you to retry failed workflow executions within a given time range.
	Legal Agreement	By using this CoLab item, you are agreeing to SailPoint’s Terms of Service for our developer community and open-source CoLab.
	Repository Link	colab-workflows/workflows/retry-failed-workflows at main · sailpoint-oss/colab-workflows · GitHub
	New to Workflows in the CoLab?	Read the getting started guide for Workflows in the CoLab.
	Supported by	Community Developed

Overview

These workflows + form allow you to retry all failed workflow executions for a given workflow and time range by submitting a form in ISC.

Requirements

You must have an Identity Security Cloud tenant with the Workflows and Forms features enabled.

You must also read “When to NOT retry an execution” in the following blog post to understand the consequences of retrying certain workflow executions. Reading this section can save you from causing issues in your ISC tenant or external systems.

How to Retry Workflows in Identity Security Cloud

[Tutorials-Blue] Introduction Identity Security Cloud provides a service called Workflows, which allows you to execute custom functionality in response to events that occur in your system. As with any automation, you may encounter issues with your workflows that cause them to fail, such as a bug in in the logic, a downstream API being unavailable, or the Workflows service itself being unavailable. It is important to be able to recover from these failures and retry the workflow so that you do…

Guide

Creating the form

Start by creating the form that will be used to initiate the retry workflow. The form JSON can be found here: colab-workflows/workflows/retry-failed-workflows/RetryFailedWorkflowsForm.json at 035e82d9ab0e30ec73d6af0fb86288e964469950 · sailpoint-oss/colab-workflows · GitHub

The easiest way to create the form is by invoking the create form endpoint and pasting the form JSON into the request body. You will have to change the owner to an identity in your tenant.

If you want to build this from scratch, here is what it should look like:

• Workflow ID is a required Text Field and has this Regular Expression validation: ^[{]?[0-9a-fA-F]{8}-([0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}[}]?
• Start Date is a required Date Field
• Start Time is a required Text Field and has this Regular Expression validation: ^[0-9]{2}:[0-9]{2}:[0-9]{2}
• End Date is a required Date Field
• End Time is a required Text Field and has this Regular Expression validation: ^[0-9]{2}:[0-9]{2}:[0-9]{2}

You will want to check the Add to MySailPoint option on the form.

Creating the recursive processor

This workflow recursively retries every failed execution for the given workflow between the specified start and end date. “Recursive” means that this workflow uses an external trigger to invoke itself as many times as it needs to process each item within the date range. Since workflow loops have a limit of 100 items per loop, this workflow will retry 100 failed executions via the loop, and then call itself again to process the next 100 failed executions. It will repeat this process until all failed executions have been retried.

To create this workflow, download this JSON file and then upload it when creating a new workflow.

sailpoint-oss/colab-workflows/blob/035e82d9ab0e30ec73d6af0fb86288e964469950/workflows/retry-failed-workflows/RetryFailedWorkflowsRecursiveProcessor.json

The following steps will need to be configured in order for it to work in your tenant.

• External Trigger
  • Click on New Access Token. Save the client ID, client Secret, and client URL somewhere safe
• Get Failed Executions
  • Edit each URL field to replace devrel with your tenant name
  • Set the Client ID and Client Secret using a PAT from a user in your tenant
• Get Execution Details
  • Edit each URL field to replace devrel with your tenant name
  • Set the Client ID and Client Secret using a PAT from a user in
• Retry Failed Workflow
  • Edit each URL field to replace devrel with your tenant name
  • Set the Client ID and Client Secret using a PAT from a user in
• Process next 100
  • Edit the Token URL to use your tenant name instead of devrel
  • Set the Client ID and Client Secret to the values generated from the External Trigger
  • Set the Request URL to the client URL generated from the External Trigger

Creating the form handler workflow

The form handler workflow will trigger when someone submits the form to retry failed workflows. It’s primary purpose is to start the recursive workflow to retry the executions as well as notify the form submitter that the processing has started.

To create this workflow, download this JSON file and then upload it when creating a new workflow.

sailpoint-oss/colab-workflows/blob/035e82d9ab0e30ec73d6af0fb86288e964469950/workflows/retry-failed-workflows/RetryFailedWorkflowsFormHandler.json

The following steps will need to be configured in order for it to work in your tenant.

• Form Submitted
  • In the Form to Filter dropdown, select the “Retry Failed Workflows” form
• Start Processing
  • Edit the Token URL to use your tenant name instead of devrel
  • Set the Client ID and Client Secret to the values generated from the External Trigger in the recursive processor
  • Set the Request URL to the client URL generated from the External Trigger in the recursive processor

Final steps

Enable both workflows to start listening for form submissions and to process the failed executions.