As logs and errors go well together, let's use them. We will improve the InstallFreshVM workflow to catch errors, as follows:
"Banana?"
.Check the Variables. As you can see, the errorCode attribute now contains the error code that vCenter returned. If you check the logs, you will also see that the error was logged. However, you will also see the error text that we created. In the older versions, the error code may be shown instead.
It is obvious that our error text is not as clear as the one that we got from vCenter. However, this was just to showcase what each IN-parameter does. When you program, you can replace the original error message with something that either is a bit more descriptive, or contains a link to an internal document that shows the user how to solve the problem.
There are basically nine log workflow elements in the schema, and they differ in terms of where they log and the severity that they log. The info level logs are just for information and do not show up as an error. The warning logs indicate that something happened but it can be ignored. The Error log level indicates that something that has happened can or should not be ignored.
The main difference between server and system logs is that the server logs are stored as events in the Orchestrator database, and the system logs are stored in the system.log
file. In addition to this, the system entries will appear in the Logs tab of a workflow token as long as the Orchestrator Client is open when the workflow runs. However, the server entries will appear in the Events tab of the workflow.
This is a bit advanced, but it gives you a good idea of how powerful error handling can be. As this is going be an advanced topic, you will need to use all the skills that you have acquired so far.
vmNbOfCpus=vmCPUs;
line to your script.This is done so that we can later change the attribute to another value. Remember that input parameter cannot be assigned as the OUT-parameters of the workflow elements.
true
line should point to the scriptable task and the false
line to the log element. Connect the line from the scriptable task back to the Create simple virtual machine element, as shown in the following figure. Please note that this task requires you to delete and create new lines, as seen in Chapter 5, Combining and Modifying Workflows:vmNbOfCpus=1;
script.0.5
vCPUs.If you've managed to create and run the preceding example successfully, you can start calling yourself an Orchestrator developer. Well done!
As you can see, we can catch an error and then try to use the error message to rectify the situation.