ErrorHandling
  • Dark
    Light
  • PDF

ErrorHandling

  • Dark
    Light
  • PDF

ErrorHandling Task Purpose

The ErrorHandling manual task is available under Tools and performs error handling in a workflow. The task allows you to provide a severity level of fatal, warning or success as well as a status message. You may specify whether retry is allowed in the event of a fatal error, which is allowable by default. In the event of a fatal error, retry should revert back to a previous task in the workflow. Please see the section below under examples for more information.

Note: ErrorHandling is a manual task and must be assigned to a group in order to run.

Properties

Incoming Description
severity string (required) The severity level must be one of the following values: fatal, warning or success.
status string (required) The status is a string which should be indicative of the error state, and will be displayed to the user. This could be the returned status code from a REST call, or a custom message you supply.
retry boolean Specifies whether retry is allowable in the event of a fatal error. Retry is true by default.


Outgoing Description
response The task will output a variable called response which will have one of the following values: success, failure, retry or error.

Severity Level

The severity level variable may be supplied statically or dynamically, but must be one of the following values:

Severity Description
fatal A fatal error is one which would prevent the workflow from reaching completion. The user will be prompted to either retry (if allowed) or abort the job.
warning A warning will alert the user and allow them to proceed or abort the job. The warning level should be used for non-critical failures which will not hinder the completion of the job, but which should be made aware to the user. The warning level can also be used for control flow, allowing the user to continue down a given path with a warning or divert the job flow down another path if the user chooses to abort.
success This can be used to confirm that a given task or series of tasks completed successfully. Note that the severity level can also be supplied dynamically, and this severity level can simply be used as a check before proceeding down a given path.

Response

The ErrorHandling task will output a variable called response. This variable is especially useful when the severity level is provided dynamically, and the control flow of the job can be directed depending on the value. The response variable will be a string with one of the following values:

Response Description
success This indicates either a successful status, or that the user has selected to proceed with warning.
retry This indicates the user has selected to retry. In this case the output should revert back to an earlier task in the workflow.
failure This indicates the user has chosen to abort.
error This response is output when the severity level is supplied incorrectly, in the case that it is dynamically provided. This is merely a sanity check, and the response should never be an error.

Examples

The following examples demonstrate various use cases for the ErrorHandling task.

Reverting to a Previous Task

Upon entering a state of fatal error, the user will be prompted to either retry (if allowed) or abort. It is a good idea to give the user the option to retry and revert to a prior state. As mentioned in the previous section, the response variable output from the ErrorHandling task will have the value of retry if the user has chosen to retry.

ex01-Fatal Error

To perform this check, simply place an evaluation task after the error handling task.

ex02-Evaluate Retry

From here, add a success edge to revert back to a prior task in the workflow, and then add a failure edge connecting to the end point of the workflow.

ex03-Revert and Retry

Directing Control Flow

There are scenarios where you may wish to direct the flow of control, such as performing cleanup tasks after an error has occurred. The ErrorHandling task can be used to give the user a warning, and then allow them to choose a path of execution.

ex-04Warning

The success path in this case would execute cleanup tasks, while the abort (failure) path would immediately end the job.

ex05-Control Flow

Verifying Successful Completion of a Task

The success severity level can be used to verify successful execution of a task or series of tasks.

ex06-201 Created

This is useful in scenarios where the severity level and status are dynamically supplied.

ex07-Success

Invalid Input

If invalid input is supplied to the ErrorHandling task, the task will output an error state with the following message.

ex08-Error

This is a failsafe in the event that the severity level is provided dynamically and does not match one of the allowable severity level types.


What's Next