VMware vRealize Automation – Hide blueprints in catalog when using Advanced Service Designer (part 2)

Recently I received a good question in the comment section of my blog post (http://solutionyst.com/?p=47) about ASD requests that appear as completed before the machine provisioning is done.

This was also a problem I encountered when I started using the ASD for requesting virtual machines. Ideally you want the ASD request to kick-off and silently wait until the blueprint request has been completely finished. In addition, if something goes wrong during the request, building or provisioning phase and the blueprint request failed then the original ASD request must also fail.

In this post I will first explain the reason why the request is marked completed so quickly. After this I will give my solution on how to handle this problem.

The problem

When the user requests an ASD service blueprint, a vRO workflow is triggered in the background. This workflow will (normally) make use of the ‘requestCatalogItem’ action that has following parameters:

Input parameters Output parameters
Inputs : Properties objectItem:vCACCAFE:CatalogItem actionResult:VCACCAFE:CatalogItemRequest

When the action is invoked, the workflow will end (assuming that the creation of the request is the last element in the workflow). The finished workflow is a sign for vRA that the request is completed. When the requestor of the ASD workflow looks in requests tab it will see that the request is completed but there is no virtual machine yet. I created an illustration below to make things more clear.

asd request no trigger

Sequence diagram to illustrate the problem of the early ASD request completion.

As you can see in the sequence diagram, the vRO gives a result back to vRA too quickly. To solve this, we should make sure the ASD workflow does not end before the provisioning of the virtual machine is completed (see next image).

asd request trigger

Sequence diagram of the ideal flow of the ASD request


Now how can we do that? The easy solution would be to create a sleep for X amount of time. However this is absolutely not the way to go and doing a naïve sleep without having a checking mechanism and an end condition in a vRO workflow is not done in my opinion.

The solution

So if we do not want to have a naïve sleep in our workflow, what can we do?

Well, a hint of the solution to our problem is already given in the ‘problem’ section of this blog post. When we look at the output parameters of the ‘requestCatalogItem’ action we see that a vCACCAFE:CatalogItemRequest object is returned.

This object is one part of our solution. The second part is a trigger and the built-in ‘waiting event’ workflow.

In the vCACCAFE API there is an object called vCACCAFERequestsHelper that contains the createTriggerForCatalogItemRequest method. This method expects following parameters:


Input parameters Output parameters
request:VCACCAFE:CatalogItemRequesttimeout:long trigger:Trigger


Note: setting the time-out paramter value to 0 equals infinite wait time

The output of the method is a Trigger object that can be used as input parameter for the built-in ‘waiting event’ workflow.

The ‘waiting event’ workflow will halt the ASD workflow until the request of the blueprint is active. In case of an error or exception in the provisioning process, the trigger will fail and the failure will be visible in the requests tab.

Combining the ‘CatalogItemRequest’ object together with a trigger and the ‘waiting event’ workflow results in an ASD workflow that waits until the virtual machine provisioning process is completed.

asd workflow

Illustration of the final solution with code snippet.

The result

When implementing the trigger based on the created catalog request in the ASD workflow, the user will only see the request completed when the machine is actually provisioned. Also in case of a failure in the provisioning process, the user will see the request as failed.