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 Use Plug-In Workflow Steps for more information.

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 resource, such as a 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 — These are used to represent both non-virtual assets (such as a phone) and tasks that modify existing assets (such as the installation of a database instance on an existing server).

    Custom components differ from resources, such as VMs, and virtual service components in that 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). You can also configure a service from individual components in Commander, for example:

  • 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 you can do with component-level completion workflows

  • 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 isn't 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 you can do with service-level completion workflows

  • 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.
  • 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.
  • 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.