Creating Completion Workflows

Completion workflows allow you to specify actions to be carried out after deployment of a new service request, or after fulfillment of a service change request. These actions are defined in series of workflow steps.

See Workflow Steps Reference for details on the steps that you can add to workflows. For details on supplemental plug-in workflow steps, see the readme files included with the plug-in step JAR files added to your system at <Commander_install_directory>\tomcat\wfplugins\. See Using Plug-In Workflow Steps for more information.

In this topic:

Services and components

To understand completion workflows, you need to understand the Commander concepts of service and component.

A service is a container for IT assets that can be requested, approved, deployed, and completed as a unit. A service can consist of anything from a single VM to a combination of service components, such as:

  • Multi-cloud templates
  • VM templates
  • Amazon Marketplace AMIs
  • Virtual service templates
  • Cloud templates (CloudFormation templates, ARM templates, and GCP deployment configurations)
  • OVA/OVF templates
  • Custom components — used to represent both non-virtual assets (such as a phone) as well as tasks that modify existing assets (such as the installation of a database instance on an existing server)

Custom components are different from VM and virtual service components. Once a request for a custom component is completed, the custom component isn't displayed or tracked in Commander or the Service Portal.

A service can be predefined (for example, as a vApp in vCenter) or built from individual components in Commander. Examples of services are:

  • A new hire service — which includes everything a new hire needs, such as a desktop machine, installed software applications, and a phone.
  • A lab service — which includes everything required to set up a software testing lab environment.

Based on these concepts, there are two types of completion workflows for new service requests:

  • Component-level completion workflows are triggered when a VM or virtual service component has been deployed and released. For custom components, a component-level completion workflow is triggered immediately after request approval.

    Completion workflows don't act on an application stack's resources (that is, its child VMs, auto scaling groups, load balancers and databases). Completion workflows act only on the application stack component itself.

  • Service-level completion workflows are triggered when all components of a service are in the Completed state, meaning that all VM and virtual service components are deployed and released, and all component-level completion workflows have been completed.

What can you do with a component-level completion workflow?

  • Assign an IP address
  • Install an operating system and patches
  • Install applications
  • Install network security applications
  • Power off a VM and delete it from disk

IMPORTANT: The first step in a component-level completion workflow for a new VM should be a Wait for Guest OS to Power On step, so that variables such as IP addresses have values before other steps are run. For Windows VMs, it may take longer than the default 300 seconds (five minutes) to obtain an IP address and DNS name. You may want to use two steps: one that waits for guest OS customization to complete, and one that waits for IP address and DNS name. For VMware VMs, if VMware Tools is not installed, you may want to use Wait for Time to Elapse instead, so that VMware has sufficient time to update all properties changed by Commander. Adding a Wait for Event step also ensures that VM properties in acknowledgment emails, such as CPU count, MAC address, are correct.

You can apply a component-level completion workflow to specific components, or make it the default workflow for all components of that type. For example, a virtual service completion workflow can be applied to all virtual services or to virtual services you specify.

While it's possible to create completion workflows for all component types, they are especially recommended for all custom components. If no completion workflow is assigned, a custom component moves immediately to the Completed state once approved. A completion workflow allows for provisioning steps to be carried out before the component moves to Completed. The completion workflow for a database instance, for example, could include a script to create the database.

What can you do with a service-level completion workflow?

  • Wire multiple components together from a networking perspective: If you have a service containing a Tomcat server, a SQL server database, and an nginx web server, a service-level completion workflow can configure and link the three components by updating configuration files with proper networking information (such as IP addresses).
  • Configure a load balancer or firewall for a group of components: Once all deployed components in a service are configured, a service-level completion workflow can communicate with a load balancer to include the service into its cluster.
  • Advertise that a service is available: A service-level completion workflow can specify that whenever an asset, VM or service is created or deleted, your IT management and CMDB software are updated.

Notes:

  • By default, when a service request is fulfilled, the person who made the request will receive an email with many details about the VM that has been deployed. However, the email doesn't include a direct link to the deployed VM, so configuring a completion workflow that includes a direct URL may be appreciated. See the Knowledge Base article Providing Direct Links to Requested VMs.
  • When using vSphere, if the Dynamic Resource Scheduling (DRS) automation level for a cluster is set to Fully Automated and VM-level DRS control is allowed, Commander temporarily disables DRS during post-deployment configuration for new VMs deployed into the cluster. Disabling DRS ensures that vSphere won't migrate a newly provisioned VM before customization is complete. DRS is re-enabled once the service is completed or the request is rejected. A Commander event is generated for the cluster when DRS is disabled, and again when it's re-enabled. This feature is supported for VMware 4.0 or higher.

Creating completion workflows

Access through:

Configuration > Self-Service

Available to:

Commander Role of Superuser and Enterprise Admin

For examples of how to create a completion workflow, see:

To create a completion workflow:

  1. Click the Completion tab.
  2. Click Add.

    As a shortcut, you can select a workflow in the list and click Copy. This option can save you time because it copies much of the workflow's existing configuration.

  3. On the Name & Type page, provide a name for the workflow.
  4. From the Apply this Workflow menu, choose when the workflow should be applied, then click Next:
    • If the completion workflow is for a service-level new request, choose after a Service is deployed.
    • If the completion workflow is for a component-level new request, choose after a <component type> is deployed. The component type may be a VM, shared VM, virtual service, cloud template, or custom component.
    • If the completion workflow is for a change request, choose after a Change Request is fulfilled.

    Your choice will determine the actions that are available on the Steps page of the wizard. You also can't change this choice once you have saved the workflow.

  5. On the Steps page, click Add and select a step to include in the workflow module, and then set its configuration parameters in the Step Details pane.

    When configuring steps, you should consider the following points:

    • By default, steps execute automatically. However, you can set steps to execute only for specific conditions. To make a step conditional, select Step Execution > Execute when conditions are met, then click Edit and define the condition. See Making Workflow Steps Conditional for more details.
    • You can click vars-20x20 in any text field that supports variables to open the Variable Assistant. The Variable Assistant allows you to select variables for the current context and access help for each variable.
    • By default, if a step fails when a workflow is run, no re-attempt to execute is made. If you want a workflow to re-attempt to execute a failed step, then click Add > Retry Selected Step. For more information, see Adding Retry Steps to Workflows.

  6. Continue to add steps to the workflow, as appropriate, then click Next after you have finished adding steps.

    Notes:

    • To change the order of a step, use the up and down arrows, or click Delete to remove it.
    • The first step in a component-level completion workflow for a new VM should be a Wait For Event step that waits for the "Guest OS to power on" event, so that variables such as IP addresses exist before other steps are run.
  7. Assign the workflow:
    • For a service-level completion workflow for a new request: On the Assigned Services page, make this the default workflow, or select the services that will trigger this workflow's actions once deployed. You can create only one default service-level completion workflow.
    • For a component-level completion workflow for a new request: On the Assigned Components page, make this the default workflow, or select the components that will trigger this workflow's actions once deployed. You can create only one default component-level completion workflow for each component type.
    • For a completion workflow for shared VMs: On the Assignment page, make this the default workflow for all shared VMs, or, if you don't want to activate the workflow yet, select Do not apply this workflow to any Shared VM.
    • For a change request completion workflow: On the Assigned Forms page, make this the default workflow, or select the forms that will trigger this workflow's actions. You can create only one default completion workflow for change requests.
  8. On the Summary page, enter details about the workflow in the Description of Changes field.

    For example, you might describe the purpose of a new workflow or, if you are editing an existing workflow, the nature of the changes that you made.

  9. Review the workflow's configuration details, and click Finish when you're done.

    If necessary, go back to the appropriate pages and make changes.

Deleting completion workflows

Access through:

Configuration > Self-Service

Available to:

Commander Role of Superuser and Enterprise Admin

At any time, you can remove a workflow from Commander. After you have removed a workflow, all settings associated with the workflow, including approvers and actors, emails, scripts, and any deployment information, are no longer available. To use those settings again, you must associate them with another workflow.

To delete a completion workflow:

  1. Click the Completion tab.
  2. Select the workflow from the displayed list.
  3. Click Delete and confirm the deletion.