cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Collecting errors when a workflow fails

Collecting errors when a workflow fails

The catches="complete" option on a workflow step guarantees that the step will run if we hit any runtime errors during workflow execution.

 

The step below called "StepToCreateError" will generate an error at runtime.

 

In the catches step named "Finalize", we will print out any errors that occurred in the workflow messages. 

 

<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE Workflow PUBLIC "sailpoint.dtd" "sailpoint.dtd">

<Workflow explicitTransitions="true" name="Self Registration Test">

  <Variable initializer="string:true" input="true" name="trace"/>

  <Step icon="Start" name="Start">

    <Transition to="StepToCreateError"/>

  </Step>

  <Step icon="Default" name="StepToCreateError" posX="163" posY="24">

    <Script>

      <Source>

// Next line will generate an error...

System.out.println("this will cause an error for sure);

      </Source>

    </Script>

    <Transition to="Stop"/>

  </Step>

  <Step icon="Stop" name="Stop" posX="263" posY="24"/>

  <Step catches="complete" icon="Default" name="Finalize" posX="363" posY="24">

    <Script>

      <Source>

import java.util.ArrayList;

import java.util.Iterator;

import sailpoint.tools.Message;

 

 

System.out.println("Catches happened...");

//System.out.println("wfcase = " + wfcase.toXml());

 

ArrayList messages = wfcase.getMessages();

 

if (messages != null) {

    Iterator iter = messages.iterator();  

    while (iter.hasNext()) {

 

            Message next = (Message) iter.next();

            System.out.println("Message = " + next.toString());

                   

      }

}

 

      </Source>

    </Script>

  </Step>

</Workflow>

Labels (1)
Comments

Hi Chris.

Thanks for the explanation.

Just one more question: Your write

...the step will run if we hit any runtime errors during workflow execution.

Does this mean the step will run ONLY if there is an error or is it guaranteed that the step will run EVEN if there's an error but always as the last step of the workflow?

Thanks,

Daniel

It runs if the workflow ends successfully or if the workflow has an error. Either way.

Hi Chris.

I'm wondering what might be the best way to return an error message to the end user if a custom Form (with Approval elements) in a workflow launched via custom QuickLink fails.

There are some threads here on Compass discussing different options, so could you recommend a best practice here?

The goal is to return an error (or success) message to the dashboard in the same way as the OOTB LCM workflows return these messages.

Your help is highly appreciated.

Best regards,

Daniel

Hi Chris,

            Is there any restriction catches="complete" or Finalize step only used in subprocess or only in  LCM provisioning or is it ok if we can use in both LCM provisioning and subprocess?

You need one catches="complete" step per workflow (this includes subprocesses as well.)

If there were more than one, we wouldn't know which one to run.

I've made a couple of tests and, as far as i've understood, the catches="complete" works only if it's located in the starting workflow. If I design a workflow with no catches that calls a subworkflow with a catch and the latter generates an error, the catch step is ignored. If I move the catch step in the starting workflow, everything works. Is it the intended behavior? Am I missing a configuration step?

Old post but I wanted to add this for anyone reading this question.

This is what I found in my test (workflow 1 schedules workflow 2):

Error in 1 and not in 2:  Finalize step is called from Workflow 1

Error in 2 and not in 1:  Finalize step is called from Workflow 2

Error in both: Finalize step is called from Workflow 1 and 2

I recommend doing your own testing but the above are the results of a quick test I ran.

I am looking for triggering failure email to support team with error message in body..when error occurred for Identity Request during provisioning.  after retry mechanism is exhausted. is there a way to catch run time error from Identity request .. in email error should not be "retry timeout"

This step catches seems to be able to catch some exceptions, such as SQL exceptions in a JDBC connector, but not beanshell syntax errors during execution.

Is there any way to catch any possible exception in the workflow?

Version history
Revision #:
2 of 2
Last update:
‎Jul 26, 2023 05:32 PM
Updated by: