In vRealize Automation you have two methods for requesting virtual machines in the self-service portal:

Publish the blueprint that you’ve created in the converged blueprint designer to the vRA catalog. With this method the blueprint is directly published in the portal. Create a Advanced Service Designer (ASD) XaaS blueprint that is published in the self-service portal. The XaaS blueprint is used to do the request of the actual blueprint as discussed in option 1.

Both options have their pros and cons. Option 1 is the default method that most people will use; it’s quick and works straight forward. You can customize the request form to some extent and at custom properties. You can also add form interaction if required using vRO actions. Although the customization options for this kind of forms improved with the release vRA 7.x, you will still face limitations if you have specific customization requirements. For example: some organizations want to have one request form that is linked to different blueprints, or you want to customize the appearance of form you will face unsolvable challenges. In this case option 2 comes into the picture.

With options 2, using the ASD and XaaS blueprints, you can create the request exactly the way you want it. On top of this, it is possible to bundle different blueprints in one request. This is a two-step-process: You prepare the blueprint request using the ASD, and when it’s finished you do the actual request of the blueprint. An additional great benefit of this method is that a check is performed concerning the required resources for the requested virtual machine, before the actual request is submitted. Some vRA implementations that use option 1 add extra resources in the BuildingMachine phase (for example because of some t-shirt sizing functionality). Although this works fine, the check for required resources is performed before the BuildingMachine phase. This means you don’t have any guarantees the required extra resources that are allocated in the vRO workflow are actually available. Again, with option 2 (ASD/XaaS) you first prepare the request and then submit the request, this guarantees required resources are available and allocated. If resources are not available the request will fail.

In vRealize Orchestrator (vRO) you can find the workflow “Request a catalog item with provisioning request” template, that can be used to build a XaaS blueprint/ASD request. Although I will not go into detail how to build such a request, we will have a look at the JavaScript code that works behind the scenes, I’ve added some comments to explain how this example works.

The following code is from the Request a catalog item with provisioning request workflow in vRO:

//Create a provisioning request for a catalogItem (blueprint) in the portal var provisioningRequest = vCACCAFERequestsHelper.getProvisioningRequestForCatalogItem(catalogItem); //Set some parameters provisioningRequest.setDescription(description); provisioningRequest.setReasons(reasons); if(requestedFor){ //Set a different user if this request is for somebody else provisioningRequest.setRequestedFor(requestedFor); } provisioningRequest.setBusinessGroupId(catalogItem.getOrganization().getSubtenantRef()); //Change some data in the JSON request, in this example increase the number of CPUs to 2. var jsonData = vCACCAFERequestsHelper.getProvisioningRequestData(provisioningRequest); var json = JSON.parse(jsonData); //Change cpu example json.ComponentName.data.cpu = 2; vCACCAFERequestsHelper.setProvisioningRequestData(provisioningRequest, JSON.stringify(json)); //Do the actual request request = System.getModule("com.vmware.library.vcaccafe.request").requestCatalogItemWithProvisioningRequest(catalogItem, provisioningRequest);

This example is included on most blogs; it discusses how you can change the number of CPUs or the amount of memory. In the rest of this article I will have a closer look at how to change the disk configuration: to be more specific, how to add an extra disk to the request.

The part where the JSON string is manipulated is the most interesting in the provided example: all parameters that are included in the request are available as a JSON string. The JSON string is converted to a JavaScript object with JSON.parse(jsonData). Then one of the properties is changed (in this example, json.ComponentName.data.cpu=2), in next step the json JavaScript object is converted back to a JSON string (JSON.stringify) and linked to the request.

Note that ComponentName in this example is the name of virtual machine in the blueprint. Since vRA 7.x you have the universal blueprint construct, which is a framework around the components that are included in the blueprint. If a blueprint contains one virtual machine, you have the blueprint construct and a virtual machine that is part of this construct. If we look at the JSON this means you have to point to a virtual machine, for this you have to use the ComponentName property. So let’s say the VM in blueprint is name Linux, you will get:

json.Linux.data.cpu = 2;

If you’re using dots in the VM name (for example centOS-7.0) there’s another syntax you have to use:

json["centOS-7.0"].data.cpu = 2;

I’ve included the structure of the JSON in the next picture. Use a JSON reader for this, I’m using VisualJSON for this:

As you can see, json[“centOS-7.0”].data.cpu = 1 and json[“centOS-7.0”].data.memory = 2048.

When it comes to disks you see an array is used to build the disk configuration. Let’s zoom into this:

In this example you see one disk (available in position 0), with 16 GB of capacity:

json["centOS-7.0"].data.disks[0].data.capacity=16

Adding an extra disk to the request can be achieved by adding an extra cell to the array. Let’s take a look at the following javascript code that will accomplish this:

disk = new Properties(); //create disk properties object diskdata = new Properties(); //create disk data object //Set the properties at the data level diskdata.capacity = "35"; diskdata.custom_properties = null; diskdata.initial_location = ""; diskdata.is_clone = false; diskdata.label = "Hard disk 2"; diskdata.userCreated = true; diskdata.volumeId = 1; //Set the properties on the disk object. disk.classId = "Infrastructure.Compute.Machine.MachineDisk"; disk.componentId = null; disk.componentTypeId = "com.vmware.csp.iaas.blueprint.service"; disk.typeFilter = null; //Add diskdata properties object to the disk object disk.put ("data",diskdata); //Now push the new cell to the disks array in the JSON object json["centOS-7.0"].data.disks.push (disk);

As you can see the second disk is now part of the JSON object:

The actual request will show the second disk in the vRA GUI interface:

To make the request work it’s important that the configuration of the blueprint allows increasing the disk size:

That’s it, I hope this was useful.