Automate Academy Advanced Concepts Deep Dive
Automate Desktop

Error Handling

Chapter 1 | Advanced Concepts Deep Dive

Learn how to configure Automate to handle errors on the system, task, and step levels. Brigette Matz, Automate Trainer/Consultant, gives you a guided tutorial on the different settings available on each level for error handling. In this video you’ll learn:

  • The error handling options available in the system, task, and step levels
  • The options in the Error Causes tab that determines what conditions Automate should consider an error
  • How to configure Automate to react to errors and set up the parameters for error triggered actions

Watch this chapter now to learn how to get started.

 

Transcript

Brigette:           Automate provides three levels in which it can automatically detect and handle errors. They include the system or global level, the task level and the step level. And at each level different air handling options are available. At the system level here, under options and default properties [00:00:30] Automate can handle errors globally for all tasks that run on the system. If this option is enabled, Automate will act upon all managed tasks that fail with an error. The first option is email error notification for all tasks. When selected, Automate will send an email containing details about the error. You can also opt to attach a task file which will include a copy of the task file and the task steps associated with that failing task. This file can be opened in any Automate task builder to investigate the cause of the error.

                                [00:01:00] The next option is to run a task on error. When selected, another Automate managed task or Automate task file will be executed upon error. Note here that the dropdown arrow displays only managed tasks created from the task administrator. Errors may also be handled on a per task basis. This is ideal if the user wants Automate to perform specific error handling procedures for a managed task. Task level error handling [00:01:30] can be configured and each managed task properties window under the on air header. As we saw with the global settings level, we have the option here to send an email message containing the generated error information and the option to attach a task file to that email.

                                We can also opt to have Automate write to a task specific text log file. The name of the file is specified by the user [00:02:00] and can be incremented and upended with today's date, if desired. This log file is separate from the Automate system log file. And again here the run a task option allows another managed task or task file to be executed upon error. For example, a default error handling task can be configured to run if an error occurs in this task. And then the last option here is to have an entry created in the windows event log upon task error. [00:02:30] Errors may be handled on a per step basis as well. Normally any failure of a step within a task causes a step error. What causes a step to fail is however dependent on the step and its parameters. These parameters can be adjusted under the error causes tab of any Automate step. If a step fails, the user can select from a number of actions to be carried out. These actions are located in the on error tab of any specific step. Every available action in Automate includes [00:03:00] an error causes tab. The error causes properties allow us to determine what conditions Automate should consider an error for each step. Automate defaults to recognizing all problems as errors. Selecting this dropdown allows us to specify that Automate throw an error only for the conditions selected while any others are ignored.

                                Alternatively, we can tell Automate to throw an error for all conditions except for the ones that are selected, whereas these that are selected will [00:03:30] be ignored. Custom problem codes can also be input here as desired. We also have the option to time out and fail after a specified amount of time. If the step takes longer than the specified time, the step would error and the instructions in the on error tab would be carried out. The on error tab allows the task developer to determine what Automate should do if a particular step encounters a problem. The retry [00:04:00] option allows the developer to control whether the steps should be retried a specific number of times before actually considering it as true step failure. If after these retries the steps still fails, the remainder of the actions below will be carried out. From here, Automate can execute specific actions as desired for error handling.

                                First, we can opt to execute another task if this step generates an error. This is generally used to execute steps to rectify the error. Task specifies a managed task name [00:04:30] or the path and file name of the dot AML task file that should be executed. We also have the option here to set a variable, which specifies that an existing automate variable should be populated with a defined value if the step generates an error. It's important to note here that when a task generates an error, it automatically creates a dataset called AM error. This data set can be used within a task to determine specific facts and characteristics about the error that occurred and as in this example, [00:05:00] we will send those error values from this step to a variable for use later in our task.

                                The send email option if enabled specifies that an SMTP message should be sent if this step generates an error. The message will be populated with information about the specific error that occurred and other task information. In some cases when an error occurs, the developer may want Automate to play a specific sound. [00:05:30] Wave files can be inserted here to enable this feature. Automate can also write entries to the windows event log or the Automate log when an error occurs. Again, here we can use the AM error data set from the expression builder to insert the error detail values from this step when writing to the logs. [00:06:00] Within this dropdown, we can specify how Automate should execute the flow of the task after the error event. The default option is to stop the task. If the error is noncritical or will be handled outside of this steps properties, the continue to next step option will continue execution of the task as if the error had not occurred. The break loop option, if enabled specifies that if the step is inside a loop that the task should stop looping on error. Task execution [00:06:30] then jumps to the first step after the end loop step.

                                We can also redirect the task flow by using the go to action, which specifies that Automate should skip to a label step or another step number in the task if an error occurs. If using a label, the label must already exist in the task. With go to label Automate will execute the steps directly below the label. In this case, Automate will send an email with error details [00:07:00] to the IT department. Similarly, we can tell Automate to jump to and execute step 19. Just remember that if you add or remove any steps in this task that the step number here will change. That's why it's important to try to limit the use of go to within each task, as many go to instructions can produce extremely unmanageable tasks. Another method of error handling at the task level can be managed through the events tab from the task [00:07:30] builder. The task events allow for specified steps to be executed for events such as when a step encounters an error or when the task fails. The on step error events will occur each time a task step generates an error. Simply drag, drop and configure the actions you want to execute upon step failure. The on task failure events will occur each time the [00:08:00] task fails. Again, here we can build steps to execute upon task failure.

Ready for the next chapter?

Chapter 2: Inheritance