Cisco Active Network Abstraction Customization User Guide, 3.6.4
Introducing the Cisco ANA Workflow Editor

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 and the tasks that are used to create workflow templates. The chapter contains the following information:

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)


Note Changes to the registry should be performed only with the support of Cisco. For details, please contact the Cisco Project Manager or Cisco Account Team.


About the Cisco ANA Workflow Editor

The Cisco ANA Workflow Editor is used to create and run the logical flows of activation commands, including complex rollback scenarios. This logic enables you to define relationships between tasks, including sequences, branches, failure procedures, and access to Cisco ANA commands as well as the information model. The Workflow Editor can interface with an external system such as an order management system to create a full service-provisioning solution that is user-customizable and user-extendable.

The Workflow Editor is a process management GUI that acts as a powerful visual design and execution tracing tool for defining and deploying activation workflows. A workflow consists of several tasks grouped and arranged in a hierarchy. Workflow management is supported in runtime, and includes a runtime GUI control console.

The Workflow Editor is used to construct workflows which run gateway commands and provides complete access to the Cisco ANA live network information model. The Workflow Editor provides a nested structure. Workflow commands are also available through the Cisco ANA API.

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

In addition, you 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 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 run after a predecessor task.

For example, if a workflow consists of two tasks, Configure Switch (first task) and Configure Router (second task), the Configure Switch task is the predecessor task and must be completed before the Configure Router (successor task) can be run.

An activation state is associated with each task:

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

Active—The task is being run.

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.

Figure 8-1 presents the typical task sequence.

Figure 8-1 Typical Task Sequence

What Is a BQL Task?

The Execute BQL task is found in the Workflow Editor toolbar. This task runs 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 run.

What Is a Lock/Unlock Task?

The Lock task has two main objectives:

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 you to protect any component from concurrent use by multiple workflows. You can lock an object that represents a single resource and guard access to it. A resource's identifier serves as the name of the lock. At any given time, a lock can be owned by, at most, only 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 fails. A failed lock might or might not abort the workflow.

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

You 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 subworkflow invocation. This enables the workflow designer to isolate the tasks running in the subworkflow as much as possible from the tasks running in the parent workflow and in other subworkflows.

The following functionality is available:

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

When a child workflow is stopped, it causes its parent workflow to stop as well.

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.

Child workflows are not visible through the API. You interact 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.