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  9 comments
Last modified on Sunday, 05 June 2016 11:29
Rate this item
(7 votes)

Comments (9)

  1. Justin

Hi,

Great info thanks.
Is there any way to override the properties of the request in this manner (i.e. override the properties in the JSON request object), but using an event subscription (e.g. at VMPSMasterWorkflow32.Requested) to do the same...

Hi,

Great info thanks.
Is there any way to override the properties of the request in this manner (i.e. override the properties in the JSON request object), but using an event subscription (e.g. at VMPSMasterWorkflow32.Requested) to do the same manipulation, but being triggered by the normal IaaS request form process (using doing request manually in the vRA gui)?
Yes I can override supported properties based on the custom property reference, but there are some properties that cannot be overridden dynamically in that manner with code such as those linked the to top level vRA Deployment object vs. the component machine object. Am thinking specifically of _deploymentName which is part of the JSON request, but exists at the top level of the JSON rather than under a component node. You cannot override that property at request time using the normal "virtualMachineAddOrUpdateProperties.put" method in vRO (partly becuase the property is not associated with a virtualmachine, and partly becuase as you say in your article the model has changed so the old code to get the "parent" of a vCAC virtualmachine does not work), and I was thinking it might be possible to do this by dynamically by updating the actual JSON request object directly, but in a way that can be called by the event broker (not a vRO workflow directly).

Many thanks
Justin

Read More
  Attachments
 
  1. Rynardt Spies    Justin

This is an interesting question and I'm not sure I follow exactly what you're asking. However, here are my 2 cents worth of opinion:

You can call your workflow via EBS and providing that you have set your blueprint custom properties up to...

This is an interesting question and I'm not sure I follow exactly what you're asking. However, here are my 2 cents worth of opinion:

You can call your workflow via EBS and providing that you have set your blueprint custom properties up to forward all properties for the VM to the workflow when the event subscription is called, your vCACVM object in vRO will have all of it's own properties available for manipulation in vRO. However, your question above seems to be related to the deployment and not the virtual machine within the deployment. So, when EBS calls the workflow with the properties of the vRA machine as an input to the workflow, you should be able to run some methods in your vRO workflow to go and get the deployment that relates to the vRA VM. I don't think that deployment properties are sent through by the EBS as it's the VM's provisioning life cycle state that fires the subscription on VMPSMasterWorkflow32.<state>. You will therefore have to use whatever information you have available in vRO sent by EBS at the time to make a second request to vRA to request the deployment.

We currently do a similar thing in vRO when we want to decommission a single child VM of a deployment. Simply destroying the VM on it's own will leave the deployment object behind in the inventory. So when a workflow is called via the vRO REST API (say from ServiceNow for instance) with data containing only VM name to be destroyed, we have to get the deployment related to that VM as part of teh workflow run, and destroy the deployment rather than the VM.

I hope this answers the question.

Read More
  Attachments
 
  1. Aaron

Hi Rynardt, Great Post. very well explained.
Any suggestions on how you would get <blueprintComponentName> dynamically?

  Attachments
 
  1. Rynardt Spies    Aaron

Hi Aaron,

Erm, the blueprint component name should be in the provisioning request data JSON object. You just need to know what you've called in in the vRA blueprint. I'm not sure how else you'll be able to reference it, as it's the key name to a...

Hi Aaron,

Erm, the blueprint component name should be in the provisioning request data JSON object. You just need to know what you've called in in the vRA blueprint. I'm not sure how else you'll be able to reference it, as it's the key name to a key-value pair in JSON.

Read More
  Attachments
 
  1. Dan

Very helpful, thank you!

  Attachments
 
  1. Lieven

Hi, nice post.
By the way, any suggestion on request the built-in vRA action named "Reconfigure"? I want to add disk with this action called from vRO, hope to receive your comment. Thanks

  Attachments
 
  1. Rynardt Spies    Lieven

Hi Lieven,

Oh dear! Can open; worms everywhere!

In my opinion VMware did a very poor job with the implementation of the reconfigure resource operation and how it's to be called. If you were to hope firebug in Firefox or developer tools in...

Hi Lieven,

Oh dear! Can open; worms everywhere!

In my opinion VMware did a very poor job with the implementation of the reconfigure resource operation and how it's to be called. If you were to hope firebug in Firefox or developer tools in Chrome, you will notice a LOT of data is sent to vRA as part of a reconfigure action request. Even if you simply want to change a tiny thing on a VM in vRA (say add or remove a CPU for instance), you need to include ALL properties for that vRA machine (yes all properties, including the date and time stamp of the request as a property!). This means that your workflow will have to be written to collect all properties from the vRA machine, then format those properties into a propertybag property in a JSON array.

It seriously took me about a week to do this in vRA6, most of the time was spent trying to work out which properties vRA actually expects in the reconfigure request. If you miss out a single property, vRA simply ignores the entire request. A very poor implementation IMHO. However, I've got it working in vRA6, and I haven't tried it in vRA7, but I expect something similar would be required.

I think it's better that you contact me via the contact me form on this site and we can discuss what's required from there.

Thanks

Rynardt

Read More
  Attachments
 
  1. Lieven    Rynardt Spies

Hi Rynardt,
Thanks for your reply first.
Yeah, I agree with you that VMware did a poor job in these built-in actions. So that I want to call these actions through the vRO using API, finally, I found that's also complex to call these actions. I...

Hi Rynardt,
Thanks for your reply first.
Yeah, I agree with you that VMware did a poor job in these built-in actions. So that I want to call these actions through the vRO using API, finally, I found that's also complex to call these actions. I have written some code to call the action, but it do nothing in vCenter, but a weird successful in vRA appears, haha.
You just said that you have successfully called the "Reconfigure" action in vRA 6 via vRO. Is that a vRO workflow? Could you share the workflow/code with me? I want to learn about that and try it in vRA 7. if you are willing to share with me about that, you can contact me at my email (email address removed for privacy). Thanks in advance.

Read More
  Attachments
  Comment was last edited about 9 months ago by Rynardt Spies Rynardt Spies
  1. David Smith

Hi, if you have an XAAS blueprint that does not provision a VM, ie a form to collect user information only, the syntax is (for a field named 'IN_Customer_Notes'):
setRequestData.IN_Customer_Notes = "Hello World";

  Attachments
 
There are no comments posted here yet

Leave your comments

Posting comment as a guest. Sign up or login to your account.
0 Characters
Attachments (0 / 3)
Share Your Location

RT @KingsGatePBO: WE'VE GOT SNOW! Due to the weather, we are not holding our 11:30am service at KingsGate Peterborough. You can watch a liv…
Follow Rynardt Spies on Twitter