In a previous article I covered how to add a vRO instance to Cloud Assembly so that it could be used for some form of extensibility. In this article we are going to use the vRO instance to update the properties of a deployed workload in Cloud Assembly as it goes through the build process.

Note this article was written for vRA Cloud and therefore some parts of it may not be relevant to vRA8.

Verify vRO Connectivity

Before you try and do anything with Cloud Assembly and vRO it is worth verifying that all communications between Cloud Assembly, your proxy appliance and your vRO appliance are working fine. You can do this by performing a status check from the proxy appliance and by checking the integration connection is in a green state.

Building a Shell Workflow

This part is predominantely easy if you are at all familiar with vRA and Event Broker Subscriptions. A workflow that fires based on an event for a particular stage of a VM build will send a payload of information to the workflow. This payload can be navigated and information extracted from it programmatically to do any number of things. The workflow can also return information in a specified format to update configuration (requires the event to be “blocking”).

In order to build the shell of a workflow we need to know what event topic the workflow should fire on. Once we have this we can use the event topic schema to see the make up of inputs/outputs we can use.

In this example I want to update tag information within Cloud Assembly once a machine has been built successfully so I will be using the “Compute Post Provision” topic. To see all the event topics available go to “Extensibility > Event Topics” and then select the event you are interested in.

The schema shows you all of the information that is available at the time the event is detected (there are many more attributes than those shown below).

You can either choose to create a workflow with just the attribute you are interested added as the workflow input or you can create a single input that captures everything and then extract the parts you are interested in programmatically within the workflow (this is the same methodology as vRA 7.x). I will be using the second of these methods as it offers more flexibility.

To start building out the workflow you need to create an empty workflow with a single properties input called “inputProperties”. The schema shows an attribute exists within the payload call “tags”. We can use this as an output for sending the tag information back to Cloud Assembly. A “c” or “complex” attribute shown in the schema is represented in a workflow as a properties object.

The empty workflow now looks as follows:

Creating a Subscription

This step may seem premature as I haven’t written anything into the workflow as of yet but what I want to do is setup the subscription in Cloud Assembly so i can run tests as I add to and adjust the workflow code.

To create the subscription you need to go “Extensibility > Subscriptions” and add a new subscription.

The event topic is then selected from the topic list.

The empty shell workflow can then be selected from the workflow list. It may take a few minutes for the workflow to show up in the list as Cloud Assembly fetches the vRO inventory every 10 minutes.

The finished configuration looks as follows (note I have made this configuration simple and not added any conditions or made it “blocking”). Once saved the subscription becomes active.

Enumerate the Event Payload

Now that there is an active subscription I can add a scriptable task to the workflow to see the information I can get access to programmatically.

Here I have added a scriptable task to the workflow to allow me to implement some test code. The task takes the workflow input “inputProperties” in and returns the output “tags”, both of type “properties”.

To extract the contents of the inputProperties payload you can add a simple loop to print everything to screen/log.

for each(entry in inputProperties.keys)
{
System.log(entry + " : " + inputProperties.get(entry));
}

My next deployment kicks the tagging workflow off and logs out some information. The attributes match the schema of the event topic however some of the attribute values cannot be seen as they are complex objects and require further processing.

I want to get the specification of a deployed machine and use that information to decide how to tag the machine. Machine specifications are held within “customProperties” so I am going to extract this information by adding code to the scriptable task.

for each(entry in inputProperties.keys)
{
System.log(entry + " : " + inputProperties.get(entry));
}

var customProperties = inputProperties.get("customProperties");
System.log("Fetching custom properties");
for each(customProperty in customProperties.keys)
{
System.log(customProperty + " : " + customProperties.get(customProperty));
}

The output of a test deployment now gives more information. Everything from “Fetching Custom Properties” log entry onwards comes from the “customProperties” attribute. I now have access to the image flavour that was used to build the deployment and I will use this information to tag the machines deployed.

Creating an Update

To add the flavour designation as a tag on a deployed virtual machine I need to add some more code to the workflow and re-factor some of the existing code.

var customProperties = new Properties();
var flavour;
var tags = new Properties();

for each(entry in inputProperties.keys)
{
System.log(entry + " : " + inputProperties.get(entry));
if(entry == "customProperties")
{
customProperties = inputPropeties.get(entry);
}
}

if(customProperties.keys.length > 0)
{
System.log("Fetching custom properties");
for each(customProperty in customProperties.keys)
{
System.log(customProperty + " : " + customProperties.get(customProperty));
if(customProperty == "flavor")
{
flavour = customProperties.get(customProperty);
}
}
}

if(flavour)
{
System.log("Adding flavour tag");
tags.put("ACE-Flavour", flavour);
}

Now when the workflow executes and it finds the flavour property it adds this information to the return object (“tags”) which is then taken back into Cloud Assembly (note this requires the the subscription to be “blocking” so I have modified the subscription as well).

Running a Test Build

Now that all the changes have been made I can execute another test deployment and verify that the workflow is doing everything that is required.

Everything looks good. The tag has been added to my test VM within the deployment.