Automation Workshop does Tasks! In essence, a Task is the primary operational unit of Automation Workshop. A Task contains full set of instructions which determines what, when, and how of the Task execution. That is why a good understanding of Task structure and states is crucial for efficient system automation. The purpose of this article is to comprehensively explain you the workings of a Task in step-by-step manner.
First of all, every Task in Automation Workshop can be in one of the opposite states, namely, any given Task is either Enabled or Disabled.
What is the difference between enabled and disabled Task? Simply put, disabled Tasks can not execute themselves. Obviously, we would like enabled Tasks to perform their operations, while expecting disabled Tasks to just do nothing. This applies to the situations when the following happens:
In other words, every time when a Task is designed, loaded, or its state is changed, we had better make sure whether we would like enabled or disabled at a particular moment. Remember, the state of a Task can be changed in various simple ways, such as:
Upon Automation Workshop service startup, it reads all Tasks into computer memory. Enabled Tasks are activated according to Run As settings which specify whether and from which user account (with what credentials) the Task will be executed both if user is logged in or if user is logged off at the moment of Task execution. For example, you can choose among Task execution scenarios like these and others:
Disabled Tasks, on the contrary, are only loaded into memory, but not activated. Which, roughly speaking, means that they can not automatically execute themselves.
What is the difference between the Tasks that are activated and those which are not? The only difference between active and inactive Tasks lies in status of their Triggers. A Trigger is the part of a Task which specifies when / on what conditions the Task should execute. Trigger monitors the system and continuously compares its state with predefined set of criteria. When they match, Trigger automatically executes the Task.
Thus, the Task can be considered active if at least one of its Triggers is enabled. Relatedly, when the Task is disabled, all its Triggers become automatically disabled, too. Conversely, if the Triggers are disabled, Task is inactive. If a Task contains no Triggers, there is no difference between enabled and disabled Task status.
Generally speaking, the Triggers of enabled Tasks monitor the system ready to execute the Task. The Triggers of disabled Tasks do not monitor anything and will not execute the Task. It does not mean though that disabled Tasks can not be executed. Even if a Task contains no Triggers or is disabled, it can still be executed both manually and by using Start Task Action which can execute both enabled and disabled Tasks as specified.
The execution of a Task can happen both automatically and manually. While manual Task execution presupposes user to run a Task from Automation Workshop manager, automatic Task execution is possible in three distinct ways:
Suppose the Task is executed. It is important to understand that a Task does not only consists of Triggers, but also of Actions. Actions are sets of commands that are performed when the Task is executed. In fact, the very Actions are responsible for everything done by Automation Workshop (except logging and email reporting), while Triggers only specify when to do that.
When the Task is already executed, the role of the Trigger over. However, it is worth to note that Triggers can be functionally connected with Actions by using Variable Wizard.
For example, File / Folder Watcher monitors specified folder for incoming Word document .doc files and, when a new file arrives, remembers its name and executes a Task which starts to sequentially perform the specified Actions. Send email Action then (by using Variable Wizard) can ask File / Folder Watcher Trigger a name of recently monitored file and add the file as attachment when sending email.
See example - Monitor folder and automatically send email with report files.
On other occasions there is no need to link Triggers with Actions. For example, running predefined file copying operations at specified time (by using Task Scheduler Trigger) where the date and time of execution is not in any way related to the file copying operations performed by Copy file Action.
Other than that, when the Task is executed (triggered by Trigger, started by Action or launched manually) it does not matter anymore whether it is enabled or disabled. From this point forward, the Task just runs. In other words, Task State is only relevant relatedly to Task execution conditions. The state of already running Task is irrelevant for all that matters.
When executed, a Task verifies Run As settings, i.e., checks whether and which user is logged on, what credentials apply to current situation. After verification of user account credentials, the Task also checks whether another instance of the same Task is not already running and, if it does, acts as specified in Settings tab of Task properties. Namely, if an instance of already running Task is being executed, Automation Workshop can be instructed to:
When all above mentioned conditions are met, the Task finally really starts to do its operations by sequentially performing the specified Actions. Note that each Action can be individually enabled or disabled. Enabled Actions perform their operations and disabled ones just do nothing due to being skipped.
Depending on chosen log level of the Task, each Action writes more or less information on its operations into the log file which can be easily reviewed later. There are four log levels available:
Besides logging data in main log file, each Task can be configured to maintain an individual log file, thus providing user with options to individually track the operations of most important or critical Tasks.
When all Task Actions are completed, the Task itself finishes. If no Action has experienced an error during, the Task execution is considered successful. Otherwise, the Task completion status is set to failed. As advanced solution which requires minimum user interference Febooti Automation Workshop explicitly distinguishes successful completion from failed completion. The further operations in case of any of the possible outcomes are specified separately. Both in case of successful completion and failure of the Task, Automation Workshop can send email report, run some other Task, write to Windows System Event log and / or disable the Task.
When the Task is completed, its statistics are updated. Task statistics contain information on number of times the Task has been executed, its longest, shortest and average execution times as well as some other information. After each completion of the Task, average run time is re-calculated. If the Task has performed much faster or slower than usual, the respective run time is updated.
Task statistics provides good means to overview Task execution and can help to track down some actual or possible problems (e.g. seeing that successful completion / failure ratio is higher than expected or some run times happen to be unusually slow or fast). While requiring some acquaintance with the program, statistics can still provide user with useful hints on Task operations.
A Task can be in one of two possible states, namely, either enabled or disabled.
Please do not hesitate to contact our support department with any possible further questions or to solve practical issues connected with Febooti Automation Workshop.