Cisco Active Network Abstraction Network Service Activation 1.0 Customization Guide, 3.7
Customizing Cisco ANA Network Service Activation Workflows
Downloads: This chapterpdf (PDF - 660.0 KB) The complete bookPDF (PDF - 3.55 MB) | Feedback

Customizing Cisco ANA Network Service Activation Workflows

Table Of Contents

Customizing Cisco ANA Network Service Activation Workflows

Cisco ANA NSA Workflow Customization Overview

Cisco ANA NSA Workflow Design

Cisco ANA NSA Workflow Attributes

Cisco ANA NSA Required Workflow Attributes

Workflow Creation Overview

Customizing Cisco ANA Network Service Activation Workflows

The following topics provide a detailed information for customizing Cisco ANA NSA workflows. Topics include:

Cisco ANA NSA Workflow Customization Overview

Cisco ANA NSA Workflow Design

Cisco ANA NSA Required Workflow Attributes

Workflow Creation Overview

Cisco ANA NSA Workflow Customization Overview

You use the Cisco ANA Workflow Editor to perform all Cisco ANA NSA workflow customizations. The Workflow Editor creates and runs the logical flows of activation commands, including rollback scenarios. Workflow Editor defines relationships between tasks, including sequences, branches, and failure procedures. You can also use Workflow Editor to access Cisco ANA commands and information model.

Note For information about the Cisco ANA Workflow Editor, see "Using the Workflow Editor to Create Task Workflows" in the Cisco Active Network Abstraction 3.7 Customization User Guide.

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

To customize a Cisco ANA NSA workflow, you open Cisco ANA Workflow Editor and retrieve the files from the server. You perform the workflow customizations, then upload the workflows. Customizing Cisco ANA NSA workflows requires the following:

Proficiency using the Cisco ANA Workflow Editor.

Familiarity with workflow programming logic.

Detailed knowledge of the workflow service activation objective.

Cisco ANA NSA Workflow Design

Cisco ANA NSA workflows guide the activation sequences based on the network operator input entered in the activation wizards. Regardless of whether you plan to customize a packaged workflow or create a new one, you must first understand important Cisco ANA NSA workflow design principles and ensure they are incorporated into your workflow customizations:

Exception handling—Workflows must anticipate and adequately account for exception occurrences.

Rollback (best effort)—Workflows must be prepared to roll back all completed operations when exceptions occur. If a workflow performs an activation sequence on multiple devices and an exception occurs on the last device, all completed device sequences must be rolled back. This capability is extremely important to ensure device and network stability.

Service removal (best effort)—The rollback capability built into Cisco ANA NSA workflows is extended to allow operators to manually remove activations using the Cisco ANA NSA Service Activation List. For information about the Service Activation List, see the Cisco Active Network Abstraction Network Service Activation 1.0 User Guide.

Multi-platform and inter-platform capability—Service activations are often provisioned on multiple devices. Because not all attributes are provisioned on all devices, workflows must include multiple branches to accommodate the different devices on which the activation is provisioned.

These design principles are demonstrated in the E-LAN Hub workflow (NSA_ELAN_HUB.template) shown in Figure 3-1. After the workflow is initiated, the first decision point determines whether the workflow is an activation or a deactivation. If yes (the workflow was initiated from a Cisco ANA NSA Activation window wizard), the workflow proceeds to the activation branch. If no (the workflow was initiated from the Cisco ANA NSA Service Activation List window), the workflow proceeds to the activation removal branch.

Figure 3-1 E-LAN Hub Workflow Activation Decision Point

If the workflow is an activation, the device type is the next workflow branch decision, which is based on the operator's device selection in the activation wizard. The E-LAN hub service can be provisioned on Cisco 9000 Series and Cisco 7600 Series routers. Therefore, the workflow includes a branch for each device type. In general, device branches are mirrored, although individual attributes vary, depending on what the device supports.

At the end of each device track, error catching logic is included so that if an error occurs at any point during the router provisioning, the workflow switches to the rollback branch. Figure 3-2 shows the multiple platform and error catching branches.

If the workflow is a deactivation—the operator initiated the call as a deactivation from the Service Activation List window—the workflow proceeds to the rollback branch.

Figure 3-2 E-LAN Hub Workflow Multiple Platform Support and Error Catching

Cisco ANA NSA Workflow Attributes

Cisco ANA NSA workflows contain the attributes that are collected by the activation wizards and required for activation of services at the device. Several guidelines apply to Cisco ANA NSA workflow attributes. First, Cisco ANA NSA requires a set of attributes be present in all workflows. For example, the corresponding workflow ID attribute (AA_coWFId), appears in the Service Activation List window and allows operators to identify the activation they might decide to remove. Required Cisco ANA NSA attributes begin with the prefix, "AA". A list of required Cisco ANA NSA is provided in Cisco ANA NSA Required Workflow Attributes.

Cisco ANA NSA workflows also employ internal attributes. Internal attributes are added in the same manner that external attributes (attributes required by the service activation) are added. The only difference is how the initial values of the external attributes are populated. The external attributes are populated either through a default value or as part of the set of workflow invocation parameters. Internal attributes are typically temporary variables. To prevent internal attributes from appearing on the workflow attribute list, internal attributes always begin with an underscore: "_".

Another Cisco ANA NSA workflow attribute naming convention is the inclusion of "_list" after multivalued attributes that may be "|" delimited.

Figure 3-3 shows the attribute groups within the E-LAN Hub workflow.

Figure 3-3 E-LAN Hub Attributes


Required attributes


External attributes (beginning)


Internal attributes


Caution If you modify input attributes (add/remove/rename) to a workflow that is deployed, do not use the same workflow or wizard names (<ID> tag) in Service.xml. Save the modified workflow by a new name and use a new wizard name. If you do not change the name and deployed service activations are deactivated, the service deactivations will invoke the modified workflow. Because the arguments changed, the deactivation will fail. Cloning will also fail for the same reason. If the arguments change, attempts to use the saved activation for cloning will attempt to copy a mismatched set of parameters to the wizard model.

Cisco ANA NSA Required Workflow Attributes

The following attributes must be present in all Cisco ANA NSA workflows. As a convention, required attributes begin with "AA".



Values—Free form.

Default— Set by the workflow designer. Most workflows default this attribute to "See Workflow Output for more details."

Description—The value entered in this attribute is shown in the Info column of the Service Activation List window. The value is updated in the workflow to reflect a user-friendly message about the status of the workflow execution.



Values—an "|" delimited set of values: {"add", "remove"}.

Default—"add|remove". All workflows provided in the delivered Cisco ANA NSA package support both add and remove capabilities.

Description—This value is set by the workflow designer to reflect the capabilities of the workflow.




Description—Maintains an association between related workflows. A workflow performing an initial "add" operation should have a "" (default) value. If a "remove" is later performed, the "remove" workflow AA_NSA_coWFId value should be set to that of the workflow Id of the "add" workflow and the "add" workflow AA_NSA_coWFId should be set to that of the "remove" workflow ID.



Values—{"add" | "remove"}.


Description—Set by the Cisco ANA NSA activation component to "add" for a service activation. For a service deactivation, the value is set to "remove".



Values—{"none" | "false" | "pending" | "true"}


Description—Controls the purging behavior for a workflow instance record in the dwe tablespace. If the value is set to "none" or "pending", the workflow instance remains indefinitely in the database. If the value is set to "true", it is purged based on the standard aging behavior. For information about Cisco ANA NSA purging, see the Cisco Active Network Abstraction Network Service Activation 1.0 User Guide.




Description—Set by the Cisco ANA NSA activation component to the value of the ID tag of the IMetaDataListEntry in the Service.xml metadata file corresponding to the current workflow invocation. The Service Activation List window and the Clone Activation feature use this attribute to retrieve a more user-friendly display name for the activation from the Service.xml metadata file.




Description—Set by the Cisco ANA NSA activation component to "NSA" so Cisco ANA NSA workflows can be distinguished from non-Cisco ANA NSA workflows. This value is strictly internal to Cisco ANA NSA; it cannot be modified.

Workflow Creation Overview

The following steps provide the general workflow creation flow that you should follow when creating a new Cisco ANA NSA workflow:

1. Use Cisco ANA Workflow Editor to create the workflow. You cannot use any other workflow application to create or modify Cisco ANA NSA workflows.

2. Define the required Cisco ANA NSA workflow attributes. (See Cisco ANA NSA Required Workflow Attributes.)

3. Define the external workflow attributes. These are the attributes that will be collected from the activation wizard.

4. Define the internal workflow attributes. These attribute names should begin with "_".

5. Implement the workflow service logic.

6. Implement the removal and exception handling rollback logic.

7. Deploy the workflow to the server.

8. Activate the workflow using BQL to debug and verify.

Figure 3-4 shows The E-LAN Hub workflow. Key points in the workflow include:

Initialization—Internal attribute initialization.

Operation check—Determines whether the workflow is invoked to perform an add or remove operation. That is, was the workflow invoked from the Activation window or the Service Activation List window Deactivate action?

Tokenizing—Workflows sometimes support repetitive looping, meaning multiple values for an attribute are passed to the workflow. The wizard activation packs multiple values into an attribute using an "|" delimiter between values (for example, attributeFoo_list = "val1|val2|val3"). Creating workflow tasks to tokenize the values from the listed attribute and assigning them to a temporary internal attribute for usage within the looping flow is a recommended practice.

Platform check—Most Cisco ANA NSA workflows support multiple devices. The device platform type (product type, for example, Cisco 7600 Series, Cisco 9000 ASR) must be identified to determine which platform-specific tasks and scripts to invoke.

Use of subworkflows—Many service activation workflows require fairly complex logic and/or use common logic from other workflows. For readability and maintainability, workflows often invoke subworkflows or call other workflows.

Removal and rollback—All Cisco ANA NSA workflows support service removal and best-effort rollback. Because the logical flow for both features is similar, the logic is combined.

Figure 3-4 E-LAN Hub Workflow Overview




Exception handling


Operation check


Use of subworkflows/workflow calls


Tokenizing multi-valued attributes


Removal and rollback branches


Platform check