Completion Request Details in vRO7.x

As some of you will be aware, vRA6 will be end of life support by the end of 2017 and as a result i was tasked with deploying a POC for vRA / vRO 7.3 in order to check if our current vRO code was compatible. I expected to see some challenges as we are heavily reliant on vRO for our Service Catalog, however one specific issue I did not expect caught me out.

As part of our Private Cloud offering, we use vRO to request a catalog item rather than vRA. The overall workflow also contains many post request actions such as deploying agents, resetting default passwords etc. All of these rely on the successful deployment passing us the hostname after the catalog request completes. After setting up the POC and running a test deployment I  noticed that although the request was successful, the overall Workflow was failing. Looking deeper I saw some differences in the completion details of vRA7.

In vRA6, we used to get the following, where “tyler-prefix04” is the hostname of the newly created VM:

“requestCompletion” : {

“requestCompletionState” : “SUCCESSFUL”,

completionDetails” : “Request succeeded. Created tyler-prefix04.

However, vRA7 output gives us only:

requestCompletionState”: “SUCCESSFUL”,

 “completionDetails”: null


This is down to the fact that vRA7 no longer distinguishes between a single or Multi-Machine Blueprints. Instead they are have been brought together in a new “Composite Blueprint”.

With this in mind, myself and a colleague began to use the API Explorer in vRO. This is a great part of vRO which allows you to find all the objects that you may be interested in. From here we were able to find that we can use “vCCACCAFEntitiesFinder” to retrieve the Catalog Resources

Therefore, using the catalog item request ID which is still given to us from a vRA7 request, we where able to search for our specific request and extract the hostname from the resources using a new scriptable task in vRO: 

At this point I though we had cracked it, however it became apparent that the resource had 2 names and was returning both. Due to the nature of Composite Blueprints, it was returning both the parent and child resource types. The parent name is usually named “BlueprintName-uniqueID” and associated to the reference type of “composition.resource.type.deployment”.

In order to retrieve the actual hostname then we have to extract from the resources, our hostname associated to the child, or “Infrastructure.Virtual” reference type

An additional  array was added as below:

From there we can now get our hostname and continue with our Workflow. Almost a “silly” issue but time consuming nonetheless!!


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.