Print this page
23 May 2016

vRO: vRA7 Catalog Item Provisioning Requests, JSON and Referencing Properties Featured

In VMware vRealize Automation 7 (vRA), blueprints are converged, rather than the single vs. multi machine blueprints that we were used to in vRA6. This presents an interesting challenge when requesting new catalog items from vRO.

In vRA6, if you wanted to request a new catalog item from vRO, you would run the “Request catalog item” workflow and simply pass any property values along with your request and those property values would be applied to the resulting item in vRA. For instance, when requesting a new VM with 2 vCPUs specified as part of the request, you could specify the following custom property in as part of the request from vRA6:

provider-VirtualMachine.CPU.Count = 2;

In vRA7, you could still use the “Request a catalog item” workflow, however you’ll find that the “provider-<propertyName>“ properties passed with the request are not honoured and will have no effect on the resulting virtual machine. The reason this is happening is because of the converged blueprint. You now need to specify the VM for which the property value is mean to be set. It’s no longer assumed that you only have one virtual machine as part of your blueprint.

 

Request catalog item with provisioning request

In order to specify properties on individual components within a blueprint, use the “Request catalog item with provisioning request” workflow or similar method. There is a sample workflow included in the vRA7 vRO plugin that you can go and have a look at or copy it you like. However, here are the basics of the Javascript code to get it done:

To start, we need to obtain the provisioning request for the catalog item, as it would be presented within the vRA portal. This will not actually request the item from vRA, but rather provide us with a Javascript object that represents the request to be submitted. We can then alter the properties on the provisioning request object and then submit the object to vRA as a request to be processed. We’ll assign the request to a new object called myProvisioningRequest in Javascript like this:

var myProvisioningRequest = vCACCAFERequestsHelper.getProvisioningRequestForCatalogItem(attCatalogItem) // attCatalogItem is of type vCACCAFE:CatalogItem

If you were to do a System.log(myProvisioningRequest); now, you’d see a block of unformatted JSON data (amongst other things in a dynamic wrapper), containing all of the data relevant to the catalog request for the catalog item specified.

With the provisioning request now contained within the myProvisioningRequest object, we can set properties such as the description and the request reason using built-in methods, just like we would in the vRA request portal.

myProvisioningRequest.setDescription(“Some description”);
myProvisioningRequest.setReason(“Some reason”);

Setting other properties before requesting the catalog item

In order to set properties such as CPU, memory, or any other custom properties we’ve defined on the virtual machine within the blueprint, we can get the provisioning request data from our myProvisioningRequest object and change the data. To do this, we call the getProvisioningRequestData method and pass in our myProvisioningRequest object as a parameter.

var getProvisioningRequestData = vCACCAFERequestsHelper.getProvisioningRequestData(myProvisioningRequest);

With the provisioning request data contained in the getProvisioningRequestData object, we can use the JavaScript JSON.parse() function to create a usable object:

var setRequestData = JSON.parse(getProvisioningRequestData);

Cool eh?!

Dumping the contents of setProvisioningRequestData, you’ll see the properties that can be set. To set them simply do:

setRequestData.<blueprintComponentName>.data.property = value; 

Like so:

setRequestData.vSphere_Machine_1.data.cpu = 2;

So this is all easy, and makes sense right? Yes, until when it doesn’t… What if you have a custom property defined like this:

My.Department.Name

or a built in one like this:

VirtualMachine.Software0.Name

In this case, you’d think you can just specify them and get away with it, but no, you can’t just do this:

setRequestData.vSphere_Machine_1.data.VirtualMachine.Software0.Name = “MySoftware” //Wrong

If you specify the property like I’ve done above you’ll get the following error:

“TypeError: Cannot read property “VirtualMachine” from undefined”

What does that mean?! It means that JavaScript is trying to access a property called VirtualMachine rather than a property called “VirtualMachine.Software0.Name”. This is happening because JavaScript sees the dot (.) as a delimiter, so it starts to walk an object tree that doesn’t exist. We need to try and escape the “.” and we can do so by calling the property in a different way altogether:

setRequestData.vSphere_Machine_1.data[“VirtualMachine.Software0.Name”] = “MySoftware”; //Correct

So after the custom properties are set in our JSON object, we need to set the request data back on the provisioning request object:

vCACCAFERequestsHelper.setProvisioningRequestData(myProvisioningRequest, JSON.stringify(setRequestData));

Now with the provisioning request updated, we can go ahead and make the provisioning request to vRA:

System.getModule(“com.vmware.library.vcaccafe.request”).requestCatalogItemWithProvisioningRequest(attCatalogItem, myProvisioningRequest);

 

 

Written by  0 comment
Last modified on Sunday, 05 June 2016 11:29
Rate this item
(7 votes)

Latest from Rynardt Spies

Related items