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.
Terminology
| Term | Description |
|---|---|
| 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, return one value, can be scheduled, and make a call to the Business Logic layer (see IAP Platform Architecture in the Administrator Guide for more information). Manual tasks are shown as blue boxes, can return multiple values, and are assigned to groups to restrict who is authorized to work them. |
| 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. |
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.
Lifecycles
This sections summarizes the various lifecycles states in bulding an automation.
Job Lifecycle
Upon start, a job is set to running status. Running jobs can move into cancelled, completed, or error states.
Figure: Job State Machine
Task Lifecycle
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
Actors
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).
Known Limitations
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.