One of the cool features of vCloud Automation Center (vCAC) is the ability to extend functionality by creating new or customizing existing workflows. VMware provides 6 state change workflows by default that you can customize using the vCloud Automation Center Designer. This tool includes a library of activities that serve as building blocks for your custom workflows. The most powerful activities are the ones that enable you to invoke external scripts, being either PowerShell or SSH or invoking vCenter Orchestrator (vCO) workflows.
The default state change workflows that are available are available to you are:
To create new workflows, you need a vCAC Development Kit license. The workflow generator plugin guides you in creating different types of workflows and helps you create the supporting configuration files for each type of workflow. Using the workflow generator wizard, you can create new workflows in Visual Studio for the above states plus the following states:
For more information about vCAC workflows see also chapter 2 of the vCAC Extensibility Guide. If you’re interested in an example of creating a new state change workflow using the workflow generator in Visual Studio, my colleague Omer Kushmaro over at ElasticSkies.com has written an excellent article on how to create a new workflow that is triggered in the “On” state.
My challenge was a bit different as I wanted to be able to run a vCO workflow right after a user has requested a new machine, but before the machine was queued for approval. I already identified “Requested” as the state that I wanted to run my workflow in using the extensibility guide, but quickly found that this state is not available in the Visual Studio workflow generator. So I needed a smart workaround for this problem. The following procedure allows you to create a new state change workflow that can run in any available state without using Visual Studio.
Wait a minute, did you just say without the hassle of installing Visual Studio?
Yes, that’s correct. No Visual Studio required using this method!
NOTE: Before you continue, please note that this new method still requires a valid vCAC Development Kit license. Without this license you will be unable to install the workflow in the model manager.
- Install the vCAC Designer if not already done so
- Start the vCAC Designer and load an existing workflow from the Model Manager using the Load button. In this example I will use the “WFStubMachineProvisioned” workflow.
- Press the Save button to export the workflow and save it to a file. I saved it as “WFStubMachineRequested.xaml”
- Open the saved file in the text editor of your choice and replace ALL occurrences of “MachineProvisioned” with “MachineRequested”
- Save the file again
- Use the CloudUtil.Exe utility located in the C:\Program Files (x86)\VMware\vCAC\Design Center folder to install the workflow in the Model Manager. Use the following command syntax, where –f specifies the filename and –n specifies the name of the workflow:
CloudUtil.exe Workflow-Install -f WFStubMachineRequested.xaml –n WFStubMachineRequested
- Next step is to create a “WFStubMachineRequested.xml” configuration file. You can use the “ExternalWFStubs.xml” file that contains the configuration for the 6 standard available workflows as an example or copy the one I’ve created at the end of this article
- Specify the state that you want to run your workflow in by changing the value of the <MasterWFStateCriteria> tag. In my case I’ve changed this to “Requested”
- Specify the Custom Property that you want to use to enable the workflow in the <Property> tag. I’ve specified this as “ExternalWFStubs.MachineRequested”
- Specify the name of the workflow that you want to run using the “WorkflowName” argument in the <WorkflowArguments> tag. This name needs to be exactly the same as the name you used to import the workflow into the Model Manager using the CloudUtil.Exe tool earlier. I’ve used “WFStubMachineRequested”
- Specify the failure state that the machine will go into when something goes wrong in your workflow. Because nothing has been configured when hitting the “Requested” state yet, I’ve selected “Disposing” as the failure state to dispose the machine
- Save the file. I’ve saved the file as “WFStubMachineRequested.xml”
- Copy the file to C:\Program Files (x86)\VMware\vCAC\Server\ExternalWorkflows\xmldb folder on the vCAC server
- Restart the VMware vCloud Automation Center Service
- After the service is restarted, click the Load button in the vCAC Designer and verify that you can now load the new workflow
- Use the vCAC Designer to add custom code to the new workflow. I’ve added the “InvokeVcoWorkflow” activity to call a vCO workflow named “WFStubMachineRequested”
- Save the workflow in the Model Manager by pressing the Send button
- The only thing that’s left to do now is enabling the workflow by adding the custom property to a blueprint
You’re not limited to creating only one single state change workflow that is triggered in a specific state, but you can add additional workflows for the same state if required. Those workflows would typically be triggered simultaneously. If there is however a dependency between workflows that are triggered in the same state, you can leverage the priority attribute. Workflows are run in order of priority, meaning that the highest priority workflows run before the 2nd highest priority workflows, etc. You can find this attribute in the XML configuration file.
Example XML configuration file:
<?xml version="1.0" encoding="utf-8"?> <plugins xmlns="http://dynamicops.com/schemas/externalwf"> <plugin fullName="DynamicOps.External.RepositoryWorkflows.InvokeRepositoryWorkflow" priority="1"> <MasterWFStateCriteria>Requested</MasterWFStateCriteria> <MasterWFTypeFullNameCriteria>*</MasterWFTypeFullNameCriteria> <ExecuteWhen>PreActivityExecution</ExecuteWhen> <AssemblyPath>[ExternalWorkflowsDirectory]\DynamicOps.External.RepositoryWorkflows.dll</AssemblyPath> <AllPropertiesExist> <Property>ExternalWFStubs.MachineRequested</Property> </AllPropertiesExist> <WorkflowArguments> <NameValue name="WorkflowName">WFStubMachineRequested</NameValue> <NameValue name="WorkflowTimeout">00:30:00</NameValue> <NameValue name="FailureState">Disposing</NameValue> </WorkflowArguments> </plugin> </plugins>
- vCloud Automation Center Part 1 – Components Overview Tweet Last year VMware acquired DynamicOps and their product called DynamicOps Cloud Automation Center (DCAC). DynamicOps originally started as part of the Credit Suisse’s Global Research and Development Group in...
- vCloud Automation Center Part 2 – Preparing the Installation Tweet Installing vCloud Automation Center (vCAC) requires some preparation. Although you can potentially install all components including the database on one single server, this isn’t an approach that’s suitable for...
- Versioning and Renaming Elements in vCenter Orchestrator Tweet During the development cycle of a workflow, your workflow can change drastically whenever you add new functionalities. Therefore a good practice is saving different versions of your workflow. One...
- Move/Replace vCloud Director NFS Transfer Server Storage Tweet In a multi-cell vCloud Director installation, all cells need access to a shared spooling area, also known as NFS transfer server storage. When you need to move or replace...
- Moving your Virtual Center SQL database – Beware! Tweet I ran into an issue with a vCenter database recently, where I couldn’t see historical performance data anymore in the past week-, month- and year-view. When investigating it, it...