Table Of Contents

Introducing the Cisco ANA Workflow Editor

About the Cisco ANA Workflow Editor

What Is a Workflow Task?

What Is a BQL Task?

What Is a Lock/Unlock Task?

Workflow Call (Synchronous Workflow Nesting)

Introducing the Cisco ANA Workflow Editor

---

This chapter describes the Cisco ANA Workflow Editor. In addition, it provides a description of tasks that are used to create workflow templates.

•About the Cisco ANA Workflow Editor—Provides an overview of the Cisco ANA Workflow Editor.

•What Is a Workflow Task?—Describes tasks and their activation status.

•What Is a BQL Task?—Describes the customized BQL task.

•What Is a Lock/Unlock Task?—Describes the locking resources mechanism.

•Workflow Call (Synchronous Workflow Nesting)—Describes synchronous workflow nesting.

About the Cisco ANA Workflow Editor

The Cisco ANA Workflow Editor enables the creation and execution of logical flows of atomic tasks (activation commands), including, complex rollback scenarios. This logic enables the user to define relationships between tasks, including sequences, branches, failure procedures, and access to Cisco ANA Commands as well as Cisco ANA's Information Model. The Workflow Editor can interface with an external system such as an order management system in order to create a full solution for service provisioning, which is user-customizable and user-extendable.

The Cisco ANA Workflow Editor is a GUI-oriented process management tool that acts as a powerful visual design and execution tracing tool for defining and deploying activation workflows (a workflow consists of several tasks grouped together and arranged in a hierarchy). Workflow management is supported in runtime and includes a runtime GUI control console. The easy-to-use GUI is flexible enough to enable complex flows to be created with a minimum of effort.

The Cisco ANA Workflow Editor allows the construction of workflows which run Gateway commands and provide complete access to Cisco ANA's live network information model. The Cisco ANA Workflow Editor provides a nested structure. Workflow commands are also available through the Cisco ANA API.

The Workflow engine resides on the Cisco ANA Gateway, using AVM 66. All of the deployed workflows are stored on the Cisco ANA Gateway. After a workflow is deployed, it is accessible via Cisco ANA Manage for viewing properties and status. Deployed workflows can be invoked via the Cisco ANA API using BQL. The workflow engine provides default workflow inherent rollback.

In addition, the user can view a history of the invoked workflows using Cisco ANA EventVision.

What Is a Workflow Task?

Tasks are added to workflows to define the processes. Each task performs a specific function. Tasks can be quickly added and configured using the Cisco ANA Workflow Editor.

Tasks can be classed as predecessor or successor tasks. A predecessor task is one that must be completed before the next task can be executed. A successor task is one that is executed after a predecessor task. For example, if there is a workflow that consists of two tasks, namely, Configure Switch (first task) and Configure Router (second task) then the Configure Switch task is the predecessor task the must be completed before the Configure Router (successor task) can be executed.

There is an activation state associated with each task, which can be one of the following:

•Ready—The task is ready to begin when the constraints (for example, start time or predecessors) have been satisfied.

•Active—The task is being executed.

•Done—The task is complete.

•Abort—The task has failed or the state has been set manually. The task can be manually reset to Ready or Done.

•Passive—The task exists, but is no longer relevant. For the purposes of successive tasks the passive task is considered Done.

The workflow below indicates the typical task sequence:

Figure 1-1 Typical Task Sequence

What Is a BQL Task?

The Execute BQL task is found in the task toolbar of the Cisco ANA Workflow Editor. This task executes the BQL command specified in the Command Template tab of the Task Properties dialog box, and stores the result in a Task attribute called Result so that it can be used by scripts and other tasks.

The Command Template tab can reference workflow attributes and task attributes. At runtime, the attribute's values are substituted into the template before it is executed.

What Is a Lock/Unlock Task?

The Lock task has two main objectives, namely:

•To allow workflow instances to declare the resources that they use and the scope of their usage.

•To ensure that those resources are not used by any other workflow instance during that scope.

The Lock task enables the user to protect any component from concurrent use by multiple workflows. The user can lock an object that represents a single resource and guard the access to it. A resource's identifier serves as the name of the lock. At any given time, a lock can only be owned by at most one workflow. Resources can be automatically locked during rollback.

The system prevents deadlocks before they occur. Upon detecting an imminent deadlock, the lock operation belonging to the workflow with the least progress will fail. A failed lock may or may not abort the workflow.

The locking mechanism does not cover every access to every resource. Only workflows participate in the locking process. Non-workflow activities may access a resource even when it is locked by a workflow. Participation in the locking process is optional.

The user can:

•Lock or unlock single or multiple resources.

•Unlock resources when a workflow terminates.

•Lock resources during rollback.

Workflow Call (Synchronous Workflow Nesting)

Synchronous workflow nesting allows workflow designers to invoke sub-workflows synchronously and pass arguments to each sub-workflow invocation. This enables the workflow designer to isolate the tasks executing in the sub-workflow as much as possible from the tasks executing in the parent workflow and in other sub-workflows.

The following functionality is available:

•The child workflow is executed in a separate workflow. The parent workflow waits for the child workflow to terminate.

•When a child workflow is aborted it causes its parent workflow to also abort.

•The child workflow has a separate scope for attributes.

•The output of the child workflow is directed to the parent workflow.

•The parent workflow can pass parameters to its child workflow.

•The correct rollback sequence is maintained throughout the depth of the lineage.

•The child workflows are not visible through the API. The user interacts directly with the parent.

•Delete and abort operations on parent workflows are delegated to child workflows.

---

Note The maximum workflow nesting depth is defined in the Registry. The default value is 16.

---