This recipe is dedicated to showing how to handle errors in workflows. We will learn how to catch errors and redirect them.
We just need a working Orchestrator, and you will need the rights to create new workflows and run them. We will work with the Orchestrator Client.
- Create a new workflow. We will reuse this workflow in the recipe, Resuming failed workflows in Chapter 4, Programming Skills.
- Add the following variables:
Name
Type
Section
Use
numberNumber
IN
Used to create an intentional error
- Assemble the workflow (as seen in the following screenshot) by dragging a Scriptable task into the workflow and then a Throw exception element from the generic section onto the Scriptable task. Add the two log elements to the workflow by just dropping them onto the lines:
- Bind the in-parameter to the scriptable task and add the following script, which will throw an error when the value
5is entered:if (number==5) { throw "Intentional Error"; } - In the Scriptable task, click on Exception. You will find that Orchestrator has automatically created a new workflow attribute called errorCode of the
Stringtype and bound it to the Output exception. - Use the log elements to indicate in the logs which path has been taken. You can do this by removing the in-parameter
Textin the log element. In the scripting part of the log element, replace the variableTextwith something such asNormal PathandError Path. - Save and close the workflow.
- Run the workflow. If you enter
5, the workflow will exit with an error. Check the workflow logs.
The default error handler is used to catch all errors regardless of where they originated and pushes them into one error-handling routine. This cleans up the workflow and makes them easier to follow.
- Copy the workflow you have created in the last section or copy the example workflow,
05.03.01 Error Handling. - Delete the error path including the exception.
- Drag the default error handler onto the schema (anywhere).
- Insert a new log element and test the workflow.
Error handling is defined as a reaction to an error (an exception) when it occurs.
In automation, there are generally two types of handling errors: push through and rollback. What this means is that you can either decide that you push on and try to resolve the error in the code, or you roll back any change that you made to the system. It mostly depends on the task you are performing and exceptions you have.
In our little example, we intentionally created an error using the JavaScript command throw, as errors normally only occur when one doesn't need or want them.
Each Orchestrator element has an Exception section in which you can define an attribute of the type String, which will carry the error message that occurred in this element. In addition to this, each Orchestrator element has a blue line (normal execution) and red dashed line (exception).
We connected the red (exception) line to the Throw exception element to stop further execution of the workflow, but we used a log element in between. Have a closer look at the workflow. You will notice that there is a red line from the scriptable task to the error log, but there is a blue line between it and the Throw exception element. What this means is that, if an error occurs in the scripting, we fork the program into a new path. Instead of stopping the workflow in a failed state, we could have used other programming elements to resolve the error.
For example, if you have a workflow that creates a VM and the workflow fails with the error Not enough space, you can then use Orchestrator to attach an additional data store and then rerun the created VM workflow.
It is also possible to ignore errors in a workflow. To do so, you just drag the red line to the same element that the blue line already points to. The result is a red and blue dashed line. This basically means that the workflow continues with or without an error to the next element. If you don't need the error message that will be generated, bind the exception to Null.
A typical example of this configuration is deleting a VM. If you want to delete a VM, it has to be stopped. The workflow, Power off virtual machine and wait, will give an error if the VM is already switched off. To solve this, you can connect the blue and the red path of the Power Off workflow to the Delete VM workflow. This will make sure that a VM is powered off; if not, then the error will just be ignored.
