vCloud Automation Center – Creating State Change Workflows

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:

  • BuildingMachine
  • MachineProvisioned
  • MachineRegistered
  • UnprovisionMachine
  • MachineDisposing
  • MachineExpired

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:

  • On
  • Off

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 has written an excellent article on how to create a new workflow that is triggered in the “On” state.

The Challenge

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.

The Solution

  1. Install the vCAC Designer if not already done so
  2. 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.
  3. Press the Save button to export the workflow and save it to a file. I saved it as “WFStubMachineRequested.xaml”
  4. Open the saved file in the text editor of your choice and replace ALL occurrences of “MachineProvisioned” with “MachineRequested”
  5. Save the file again
  6. 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
  7. 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
  8. 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”
  9. Specify the Custom Property that you want to use to enable the workflow in the <Property> tag. I’ve specified this as “ExternalWFStubs.MachineRequested”
  10. 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”
  11. 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
  12. Save the file. I’ve saved the file as “WFStubMachineRequested.xml”
  13. Copy the file to C:\Program Files (x86)\VMware\vCAC\Server\ExternalWorkflows\xmldb folder on the vCAC server
  14. Restart the VMware vCloud Automation Center Service
  15. After the service is restarted, click the Load button in the vCAC Designer and verify that you can now load the new workflow
  16. 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”
  17. Save the workflow in the Model Manager by pressing the Send button
  18. 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="">
  <plugin fullName="DynamicOps.External.RepositoryWorkflows.InvokeRepositoryWorkflow" priority="1">
      <NameValue name="WorkflowName">WFStubMachineRequested</NameValue>
      <NameValue name="WorkflowTimeout">00:30:00</NameValue>
      <NameValue name="FailureState">Disposing</NameValue>

Related posts:

  1. 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...
  2. 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...
  3. 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...
  4. 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...
  5. 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...

1 Comment on “vCloud Automation Center – Creating State Change Workflows”

  1. #1 Ronald Rink
    on Feb 18th, 2014 at 8:46 pm

    Hi Armin, good article. Just a side note regarding the requirements for a cdk license. I always thought the same, that you cannot install new workflows without that license. But this is actually not true. You can certainly do it without using the ODATA REST API as described in my article: So a lot of functionality at no additional cost… Regards, Ronald

Leave a Comment