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. To understand completion workflows, you need to understand the Embotics® vCommander® concepts of service and component.
A service is a container for IT assets — something that is 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:
•virtual services (vApps and cloud services)
•cloud templates (CloudFormation and ARM 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 is not displayed or tracked in vCommander or the Service Portal.|
A service can be predefined (for example, as a vApp in vCenter) or built from individual components in vCommander.
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 do not act on a stack's resources (that is, its child VMs, auto scaling groups, load balancers and databases). Completion workflows act only on the 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 network security applications
•Power off a VM and delete it from disk
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.
|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 does not 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.|
If the Dynamic Resource Scheduling (DRS) automation level for a cluster is set to Fully Automated and VM-level DRS control is allowed, vCommander temporarily disables DRS during post-deployment configuration for new VMs deployed into the cluster. Disabling DRS ensures that vSphere will not migrate a newly provisioned VM before customization is complete. DRS is re-enabled once the service is completed or the request is rejected. A vCommander 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 and higher.
Configuration menu > Service Request Configuration > Completion Workflow tab
vCommander Role of Superuser and Enterprise Administrator
For examples, see:
•the Knowledge Base article Installing Software Using Completion Workflows
•the Knowledge Base article Automating Self-Service Decommissioning
1.Choose from one of the following options:
•to add a new workflow, click Add, or select an existing workflow in the list and click Copy
•to edit an existing workflow, select the workflow from the list and click Edit
For a new service request, choose the type of component the workflow will target:
•cloud template (including CloudFormation templates and ARM templates)
This choice determines the actions available on the Steps page of the wizard.
For a change request, select After a Change Request is fulfilled.
You cannot change this choice once you have saved the workflow.
4.On the Steps page, select from the drop-down menu to add actions to your workflow (the list of available actions is determined by your choice in the previous step). See Workflow Steps Reference for details on each step type.
|Adding any or all of these steps is optional. For example, let's say you have set up a default VM completion workflow to run every time a new VM is provisioned, but you don't want that workflow to run on one or more specific VMs. In this case, you can configure a VM completion workflow that contains no steps - its only purpose is to override the default VM completion workflow.|
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.
After you create a step, click Add to create another step, or click Next to move to the next page.
Conditional steps: You can make a step conditional by selecting Execute when conditions are met from the Step Execution drop-down menu. See Making Workflow Steps Conditional.
Other actions you can take:
•To delete any step, select it on the Step Order list and click Delete.
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 do not 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.Click Next and Finish.