Welcome to Part 3 where we will associate state change workflows to execute against vCO. Fundamentally this is the step that will populate the actions you would like to take when a state changes during automation process.
For this example we are going to use the a simple workflow that collects the properties assigned to a given request. The benefit is it’s simple, the challenge is that it may not yet be clear yet how beneficial it is. My goal is to give the foundation before executing the real world applications. After Part 4 we will focus efforts on making the workflow more meaningful.
Ideally I just want you to think about the things you might do at any of those state changes, for example
- On BuildingMachine you may enter data into a DB, then create the computer account in an OU, then Add to DNS
- On MachineProvisioned you may want to enter additional data into that DB, then run code to update administrator password
- On MachineExpired you may want to disable the computer account in AD, then update data in that DB again
- On MachineDisposing you may want to remove the computer form AD, then remove any data from the DB
If you haven’t reviewed the previous posts you may want to consider exploring the parts below
Part 1: vCAC and vCO – Configuration
Part 2: vCO -> Powershell, vCenter, and AD
Part 3: Automating a state change
Part 4: Automating a menu item
Now all the formalities out of the way, let’s get the workflow assignments completed!
First I’ll illustrate the pristine state of the blueprint before we execute make the vCO assignment. As you should notice in this screen shot, I have navigated to one of my blueprints and there is no actual workflows assigned in the custom properties.
Now let’s go and assign a workflow to be run at build machine. For this activity we will work from the vCO fat client or the client.jnlp that you can download from your vCAC server. URL should look like this https://vcac_virtual_appliance.fqdn:8281/vco/client/client.jnlp
* warning java update earlier this year requires trusted sites to run the client.jnlp file. If you run into issues with launching the client.jnlp due to security issues, make sure you add https://vcac_virtual_appliance.fqdn:8281 to your trusted site list in your java settings.
Now in the vCO client navigate to Library->vCloud Automation Center->Extensibility and run the “Assign a state change … workflow”
- Choose the workflow stub – I am choosing BuildMachine but any of the following can be used
- Set vCAC Host – use the tree view to navigate and select your vCAC host
- Select Blueprints – WinRM
- Choose if you want this applied to existing machines – Not important in this example but consider the idea of applying for Expiration
- Choose workflow – I search for a generalized workflow
- Add vCO workflow input- I leave set to no but if you have a workflow that accepted strings you could promote those to prompt the user during request
- Add last vCO workflow – Leave as no (we will learn more about this later)
Assignment of the workflow has been complete
Now just for the sake of sanity let’s review in the vCAC web interface. As you can see there is now a workflow that will run at build time.
Congrats you have now completed the configuration of running a workflow. If you would like to use the workflow that I have in this example please feel free to download here.
[…] Now that all of this is complete you can take this workflow and assign it to the blueprints you wish to execute against on MachineProvisioned. To learn how to assign workflows go to my previous post […]