Table of Contents

Search

  1. Preface
  2. Taskflows and linear taskflows
  3. Taskflows
  4. Linear taskflows

Taskflows

Taskflows

Throw step

Throw step

Use a Throw step to catch a fault, return the fault details, stop the execution of the taskflow, and set the taskflow status to failed.
You can use a Throw step for the following use cases:
To catch faults in a taskflow
You can add a Throw step to the main path of a taskflow to catch faults in a taskflow and return the fault details. You cannot add a step after the Throw step because the Throw step is an interrupting step. If a fault occurs, the Throw step stops the execution of the taskflow and sets the taskflow status to failed.
For example, consider the following sample taskflow:
The image shows a sample taskflow with a Start step, a Notification Task step, and a Throw step.
If a fault occurs in the Notification Task step, the Throw step is executed. The Throw step stops the execution of the taskflow and sets the taskflow status to failed.
To act as a boundary event for a specific step in a taskflow
When you enable custom error handling for a taskflow step, you can use a Throw step in the error handling path to act as a boundary event for the step. A boundary event is an event that catches an error that occurs within the scope of the step where it is defined.
You can add a Throw step to the error handling path of the following steps because they support custom error handling:
  • Data Task
  • Command Task
  • File Watch Task
  • Ingestion Task
You can also add a Throw step to the error handling path of a Subtaskflow step if you configure the Subtaskflow step to catch faults. If the taskflow that is contained within the Subtaskflow step fails, the parent taskflow also fails. When you view the execution details of the parent taskflow in Monitor, you can click the Throw step that is associated with the Subtaskflow step to understand why the subtaskflow failed.
When you add a Throw step to the error handling path, the error handling path breaks off from the main path of the taskflow. If a fault occurs, the taskflow takes the path that you define for handling the error. For example, in the error path, you might add a Notification Task step to send an email notification followed by a Throw step to catch the fault and stop the taskflow execution.
In the error handling path, you cannot add a step after the Throw step because the Throw step is an interrupting step. If a fault occurs, the Throw step stops the execution of the taskflow and sets the taskflow status to failed. The subsequent steps in the main path of the taskflow that exist after the step that is associated with the Throw step are not executed.
For example, consider the following sample taskflow:
The image shows a sample taskflow with a Subtaskflow step, a Data Task step, and an End step. The Subtaskflow step is configured to catch faults. The fault handling path contains a Notification Task step and a Throw step.
The Subtaskflow step is configured to catch faults. If a fault occurs, an email notification is sent as configured in the Notification Task step. The Throw step then stops the execution of the taskflow, returns the fault details specifying why the subtaskflow failed, and sets the taskflow status to failed. The Data Task step is not executed.

0 COMMENTS

We’d like to hear from you!