More Workflow Features
Service Dependency
If a workflow contains parallel paths of execution, and one service must be run after another service in another path, you can enforce that order by configuring Priority in Step1 of the Service/Workflow Editor. One such example is illustrated here:
Priority allows the user to determine the order a service runs when two services would otherwise be run at the same time. The typical use case is when a service has two edges exiting from the right side and both edges are the same type. In this case the user may determine the order of the service execution using Priority. The higher number gets run first.
Restart Workflow From Here
Using the right-mouse-click menu, a workflow can be restarted from any service as the "Entry point" and using the runtime payload from a previous run. This is useful if:
- the user is testing a workflow with a lot of services.
-
device targets fail unreliably and automation must be restarted at unpredictable locations in the workflow and:
a) services are not idempotent, meaning that it is not possible to re-run the same services on the devices without breaking, or:
b) there is simply not enough time to re-run all the previous services.
Selecting Restart Workflow from Here
by right clicking on a service
presents the user with a form to select:
Restart Runtime
: The previous runtime to use as the payload for continuing the workflow. This defaults to the runtime that is currently displayed in the workflow builder.-
Targets
gives several options for where to obtain device targets for the new run:- Manually defined: Use the targets manually defined below.
- Restart run: Use the targets from the selected restart runtime.
- Workflow: Use the targets that are currently defined at workflow level.
-
Devices
: for use with theManually defined
option above. Pools
: for use with theManually defined
option above.
Note
Variables, set to values that cannot be streamed as JSON, are not
available to subsequent services after restarting the workflow. For
example, if the user performed a set_var on a python function to allow
it to be used in a subsequent service, this will not work after using
Restart Workflow from Here
.
Connection Cache
When using netconf, netmiko, napalm, and scrapli services in a workflow,
eNMS will cache and reuse the connection automatically. In the Step2
Connection Parameters
section of a service, there are some properties to
change this behavior :
-
Start New Connection
: before the service runs, the current cached connection is discarded and a new one is started. -
Connection Name
: If changed to something other thandefault
, the connection will be cached as a separate connection to that same device. This allows for multiple simultaneous "named" connections to a single device, as in this example:
Close Connection
: once the service is done running, the current connection will be closed.
Waiting Times and Retries
Services and Workflows have a Time to Wait
property: this tells eNMS
how much time it should wait after the service has run before it begins
the next service.
A service can also be configured to Retry
in the event of a failure.
Retries allow for a Number of Retries
, Time between retries
, Max
number of retries
to be configured.
The Max number of retries
exists because it is possible for the user to
manipulate the retries
variable in post processing
section for service
results. For example, the user could set additional retries in the event
of some condition, or perhaps if something is missing in the results, increase
retries by 1
. This Max number of retries
is settable to prevent an
infinite loop from occurring: once it is reached, the service will fail.
To demonstrate the relationship between retries and wait times, an example execution of a service in a workflow is as follows:
First try (failure)
time between retries pause
Retry 1 (failure)
time between retries pause
Retry 2 (Successful, or only 2 Retries specified)
Waiting time pause
Superworkflow
Just as a workflow can contain a subworkflow to subdivide and
encapsulate related functionality, a workflow can also designate a
superworkflow in Step2
. The superworkflow allows for services to
be run before and after the main workflow and using a potentially
different workflow traversal mode (service by service or device by
device).
Superworkflows function like a document template so that activities common to all workflows can be performed. When the same superworkflow is used by multiple main workflows, it behaves like a shared service: a change to the superworkflow affects all workflows that use it.
In the superworkflow definition in Workflow Builder, the
position of the main workflow is designated by adding the Placeholder
service to the graph. And in the main workflow definition, the
superworkflow must be selected from the list of existing workflows.