Logs and errors

As logs and errors go well together, let's use them. We will improve the InstallFreshVM workflow to catch errors, as follows:

  1. Open the InstallFreshVM workflow for editing.
  2. Click on Schema and open the Log toolbox.
  3. Drag a System Error element onto the Create simple virtual machine element.
  4. You will see that System Error connects itself to the Create simple virtual machine element with a dashed red line. This is the error line.
  5. Click on the edit symbol of the Create simple virtual machine element and have a look at the Exception tab. You will find that a new attribute called errorCode is linked to the element. Check out the IN-parameters of the System Error element. You will also find the errorCode attribute here. These were automatically created and linked when you pulled the Log element onto it.
    Logs and errors
  6. All we now need to do is assign a string value to the IN-parameter text, and we are ready. Do this, and fill its value with something meaningful, such as "Banana?".
  7. Now, we need to create an error. You could lift some of the restrictions that you entered in the presentation and create a VM with 0.5 processors. This will create an error when the virtual machine is built.
  8. Run the workflow with the debugger and have a look at the resulting logs:
    Logs and errors

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.

Logs and errors

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.

Tip

Please note that the log files are rotated. This means that after some time, the older entries will be overwritten. The events are purged from the database according to the purging policy defined in the Orchestrator configuration.

Catching and dealing with an error

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.

  1. In this example, we will lift the CPU restrictions and create an intentional error, which will then be rectified by using error handling while the program is running:
  2. You can make a copy of your InstallFreshVM deploy workflow just to be on the safe side or increase the version.
  3. Open the workflow for editing.
  4. Move the vmNbCpus input parameter to be an attribute and reassign it to the Create simple virtual machine workflow element.
  5. Create a new input parameter of type number called vmCPUs. We will use this to capture the input.
  6. Add the vmCPUs attribute as an IN-parameter and vmNbCpus as an OUT-parameter to the ConvertMB2GB scriptable task. Now, add the 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.

  7. Now, drag a (basic) Decision element onto the red error line and then drag a scriptable task onto the Decision element. After doing this, you will have to rearrange the lines. The 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:
    Catching and dealing with an error
  8. In the Decision element, check whether errorCode contains numCPUs. What this does is check whether the error that we are getting is due to a problem with the CPU count. Check the error message that you received in the last example.
  9. Assign the vmNbCpus attribute to be an OUT-parameter of the scriptable task and add the vmNbOfCpus=1; script.
  10. Done. Now save and run the workflow and enter 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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset