- Category: Advanced Extensibility
- Published: Wednesday, 11 September 2013 16:14
- Written by Zack Kielich
- Hits: 16993
As of 5.2, vCAC is able to call out to vCO workflows really easily by using the extensibility through the vCAC workflow designer. The below instructions can be used to call out to any vCO workflow, with one caveat-- the vCO workflow has to be designed to only accept string inputs. This means that if you have a vCO workflow that is expecting a complex data type, you have to alter the vCO workflow so that it looks up the complex value from a string value. We refer to this lookup action as a "vCO workflow wrapper". To build a vCO workflow wrapper, check out another article I wrote on vCOteam.info
In the below example, we'll be focusing on adding and removing computers from AD using a vCO workflow. I can't stress enough though, that these are the same steps for calling out to ANY vCO workflow that expects string inputs.
First Thing's First
1. Configure the vCO endpoint by following the instructions in the vCAC to vCO: Configuration article.
Generally speaking, this is where you would go off and find out what inputs the vCO workflow is expecting. Usually it's just easiest to ask the vCO workflow developer. You can ask them "could you please send me the generated documentation for the vCO workflow that I'm supposed to call?" They should return with a document that shows you all of the inputs their workflow expects, along with what field type they are. Again, if that document comes back saying that one of the inputs isn't a number or string, go back to the vCO workflow developer and ask them to build a wrapper so that the vCO workflow only asks for strings or numbers.
Here are the documents created for the workflows that go along with with article if you're following along: http://www.vcacteam.info/files/vCAC_Workflow_Documentation.zip
You can see that in both cases it's expecting a computer name and an OU to place the new computer into.
Specific to Those Following Our Example
Our vCO workflow is going to be asking for some information: the machine name and the OU in AD where we want to put the machine. The machine name is easy, it gets determined based on the machine prefix, but the OU is specific to your environment. To gather this information, you can hard code it into a property on the blueprint, or you can create a drop down for the end users to select the OU when requesting the machine.
In our example, we have created a property called "Location.Custom.Property" on the blueprint. For our purposes here, hard code the value to be the name (not the AD path) of a uniquely named OU. In the screen shot, you can see that I have an AD OU named "Private Cloud" which has become the value for the "Location.Custom.Property" property.
Alter the MachineProvisioned Stub
Here starts the part that is the exact same for calling out to any vCO workflow. Stubs are out of the box places along the machine lifecycle where we can make calls out to other systems or alter the lifecycle’s behavior. You will need to have access to the vCAC designer tool (usually located on the vCAC Windows server) for these next steps1. Open the vCAC designer tool and click the load button
|2. Select the stub with the name “WFStubMachineProvisioned” and press ok. We're choosing this stub because it will be called when the status of the machine is "MachineProvisioned", which occurs immediately after the provisioning process is complete|
|3. Double click on the Machine Provisioned/Try area|
|4. Scroll down through the workflow and double click on the Custom Code area|
|5. Select the InvokeVcoWorkflow action from the left side toolbar and drag it into the workflow. Then press the button to choose a workflow from vCO. The result is that you will get a popup of all the vCO workflows.|
|6. Choose the workflow that you would like to call and press OK|
|7. Note that the activity in the workflow updates to match the input parameters that the vCO workflow is expecting. Note that these are the same that are in the documentation. If you're following along with|
|8. Now we need to go and get all of the values from the vCAC machine and put them into variables. Usually the machine name is needed in vCO workflows. To get that, drag the GetMachineName activity from the left side bar into the workspace.|
|9. Double click the GetMachineName action in the workspace and enter in the variable for the Machine Id, which is a vCAC standard parameter called VirtualMachineId.|
|10. Next, we enter in a name of a variable that we want to put the machine’s name into. At this point, this variable name could be anything (vmName is usually a good, descriptive variable name)|
|11. You will note a red exclamation mark denoting that there is an error. This is happening because that variable name has not yet been declared. To access the variable area, click on the variables tab at the bottom of the workspace|
|12.Click “create variable”
13. Enter the name of the variable you entered in step 10
|14. Your exclaimation mark should now go away on the activity. Navigate back to your custom code area by using the breadcrumbs at the top of the workspace|
|15. Now we need to get any other properties from the machine that will be required for the vCO workflow to run. Drag in the GetMachineProperty activity into the workspace|
|16. Double click on the GetMachineProperty and again, for the Machine Id enter VirtualMachineId.
17. Fill in the rest of the information like the property name and what variable you would like the information to be placed into **IMPORTANT** Your property name has to be in quotes!
|18. Create the new variable to match the name of the variable to you just called to set|
|19. Navigate back to the custom code area of the workflow
20. Continute to call properties as you need and adding them to variable until you have all the information you need to complete the vCO call. When you’re done, string your activities together by hovering over the bottom of one activity (until a grey box shows up) and dragging to the activity you want to conenct it to
|21. We can now fill in the values for our vCO workflow input from the variables we made and set|
On the right side of the screen, there is a properties tab when you click on the vCO activity. The field does not show up in the workspace—only in the properties pane—but you have to fill in the VirtualMachineId field with the value of VirtualMachineId.
|23. Now that there are no errors, click the Send button at the top of the designer to push it into the database|
|24. When prompted, you can enter versioning information|
|25. After pressing OK you should get a confirmation|
Calling the Stub from Blueprint
1. Log into vCAC as an enterprise administrator and navigate to Enterprise Administrator > Global Blueprints
A list of all available stubs and their corresponding properties can be found in the vCAC Extensibility guide: https://www.vmware.com/pdf/vcac-51-extensibility-guide.pdf
Test Your Work
1. Log into vCAC as an end user and request a machine from the blueprint you told the call the MachineProvisioned stub