Itential Automation Platform (IAP) provides a tool known as Automation Builder which enables the user to define processes, called automations, that may be used by applications in the system. These automations are comprised of tasks and transitions.
|Automation||An automation (formerly known as a workflow) is a collection of tasks in a logical order beginning and ending with terminator tasks (start/end).|
|Job||A job is an instance of an automation. It takes a snapshot of the associated automation to create its existence.|
|Task||A task is a functional block within an automation and can be either automated or manual. Automated tasks are shown as green boxes and return one value. With automated tasks, you configure a window of time and when the task starts, it checks the time against that window of time and if the time is within that window, the task will run. Manual tasks are shown as blue boxes, can return multiple values, and are assigned to groups to restrict who is authorized to work them. More detailed task information is presented in the Gen 1 and Gen 2 Automation Builder Task guides.|
|Transitions||A transition connects one task to another. Transitions can be defined by error (red), success (green), or failure (red) routes and can follow a standard (solid line) route or a revert (dashed line) route. Reverts should be used when transitioning backwards in the automation.|
|Scheduler||The job scheduler is the process within IAP that scans for automated tasks to be invoked.|
|Metrics||Metrics are measurements of job execution statistics for automations and tasks.|
|Queue||Tasks live in queues where operators with the appropriate permissions can locate available, claimed, scheduled, and completed tasks.|
|Variable||A value that can change, depending on the information (data) that is passed between applications running on a network. Listed below are the different variable types.|
There are three variable types (static, job, and task) that can be used in a Reference task on the Automation Builder canvas.
Static variables are hard-coded and maintain the same value between function calls. They cannot be modified or changed programmatically in the lifecycle of an automation run. A static variable remains in memory while the automation is running. They are often used to maintain settings whose values should not change once a workflow (automation) has started.
Task variables are values provided as a result of executing another task earlier in the workflow of an automation. Essentially, they provide reference information for another task. This means you are choosing some previously executed task, taking its output, and using that as the selected task’s input.
Job variables allow you to use changeable values in the configuration and execution of a job. You create a variable, give it a name and a value. You can then insert the variable (by referencing its name) in various places in a workflow. When IAP runs a job, it replaces the reference variable with the job variable's value. Job variables are useful in two ways. First, they allow you to pass values as inputs to a workflow each time you execute it. Secondly, anywhere in the workflow, a task can set/update the value of a job variable. As a best practice, use task variables instead of job variables whenever possible, but if task variables will not work, then use job variables.
Automation Builder Generations
Automation Builder Generation 2 was released in 2020.2 and offers a clean, modern user experience to automation designers. While Itential strongly recommends working with Automation Builder Generation 2, the Generation 1 builder is still available and fully featured for users to build automations with.
Figure: Automation Builder Generation 1
Figure: Automation Builder Generation 2
Example Automation (Generation 1)
In the figure below, the automation (job) consists of two tasks:
- An automated task (Snapshot Device) denoted by green.
- A manual task (MOPReviewSummary) denoted by blue.
The arrows represent transitions and show the direction of the automation. Automation Builder also provides optional role-based access control (RBAC) by restricting task ownership to authorized groups. Users are assigned to groups, and automation tasks can be restricted to specific groups. Only group members are authorized to work tasks. Groups will play a part in task assignment and work queues.
The figure below shows an automation designed to perform automated and manual tasks using success and failure transitions with revert capabilities. Transitions are identified by two properties:
- The exit status of the leading task.
- The direction of the transition (standard or revert).
Different transitions allow automations to correct anomalies, repeat parts of an automation, skip tasks, manually intervene, or follow the planned execution path.
Example Automation (Generation 2)
In the figure below, an example automation was built in the next generation builder (Gen 2) to demonstrate high-level differences in layout and structure. Note that while the above example from the Generation 1 Builder uses reverts and evaluations to branch and handle runtime errors, the Generation 2 example uses the decision task to decide a single path when multiple options are available, and uses dedicated handlers to process errors.
This sections summarizes the various lifecycles states in bulding an automation.
Upon start, a job is set to running status. Running jobs can move into cancelled, completed, or error states.
Figure: Job State Machine
When a job is started, its tasks are set to an incomplete status. From incomplete, tasks move into running or scheduled states. A running task can move to completed, canceled, or error states.
Figure: Task State Machine
An actor is a user that executes an automatic task in a job. By default, the actor that executes an automatic task is the Itential user, but any user in IAP can be an actor. When building an automation, a Designer can specify for each automatic task which user should be designated as the actor. The user can be one of the following:
- Itential - The machine user.
- Job Initiator - The user that started the job.
- Any Prior Manual Task - The user of a manual task that occurs previous to the currently configured automatic task within the automation.
When the task runs, it calls the method, writes to the Audit Trail, and is authorized in the same manner as if that user had called the method associated with the task via the Northbound API. If the task invokes an external system API, IAP uses the actor's credentials in the external system API call, which leverages defined access control mechanisms that might be defined on the external system. If an actor is selected from a manual task that is on a branch that does not run, then the Automation Engine will fallback to the IAP user.
Managing Actors within Automations
Actors are managed in Automation Builder. A Designer can select from either the default IAP user, the Job initiator, or a user from any prior manual task. A common use-case for actors is to associate a network change with the user that approved (worked) a Dry Run Review task.
In the following automation, an actor will be added to the Automatic Success task.
When editing the Automatic Success task, or any other automatic task in IAP, you now have the option to select the actor. The Actor field displays the following options in the dropdown.
- Itential (Pronghorn) user (default).
- Job initiator (always available).
- Branch Task (only option available to the Designer).
A conscious decision was made to not allow users from manual tasks inside a prior child job to be available as actors.
Upgrade Script Not Required
No upgrade script is required. However, all actors will be set/run as the Itential user by default. In order to assign an actor to a task other than the Itential user, the Automation Builder will need to edit the desired automations to benefit from the new feature.