6

VMware vRealize Automation – Hide blueprints in catalog when using Advanced Service Designer

VMware vRealize Automation offers two ways to call a blueprint:

  • the standard way as you are familiar with (shown in the left picture below)
  • and probably less familiar for most of you, by using the Advanced Service Designer (ASD) (shown in the right picture below, where we request the same blueprint, but using the ASD).
asd blueprint request comparison

The left image illustrates a regular blueprint request. The right image illustrates a request form generated by ASD. It contains a slider, customized drop-down boxes and additional tabs.

Using the ASD to call a blueprint, offers many advantages. First of all you can change the looks, customize the fields by using (for example) sliders, customize tabs, reorganize fields and make your request form truly dynamic. In addition, the fact that you are calling a vCO workflow before making your actual request also offers some interesting options (eg. making a request on behalf of another user, … ).

While this post is not about “how to use the ASD to call a blueprint” (stay tuned as I will blog about this in the near future), it is rather about “IF” you use the ASD to call a blueprint, the user will actually see two requests in the “Requests” tab. The first is the ASD catalog request and the second one is the actual request of the blueprint. Let me further explain this:

The problem

If you are using the ASD to request blueprints, chances are you are seeing the scenario illustrated in the screenshot below:

asd portal before change

The left catalog item is the ASD workflow used to request the Linux Service Blueprint on the right. While this is no problem, it can confuse users. It would be better if the Linux Service Blueprint would be hidden and the user can only request blueprints via the ASD workflow.

The other part that can cause confusion is visible in the request section. There are two requests visible for the user in the request section (see next image). The user who requested the blueprint sees two different requests:

  • A request for the ASD workflow submitted by himself
  • A request for the Linux Service submitted by the vco service user

It is preferred the user only sees one request, namely the one from the ASD.

asd request before change

The cause of the problem

To understand the problem and corresponding solution it is good to know how the ASD process to request virtual machines works in the background. The next images give the full overview of the different phases in the process.

Screen Shot 2015-03-05 at 21.26.31

The actor (user) requests the ASD workflow with the necessary parameters to create a virtual machine. This request triggers the ASD workflow in the orchestrator. The workflow uses all the input parameters from the user to create a request for the corresponding (in this case Linux) blueprint.  The request will be made using the orchestrator user account and most likely contains the “requestedFor” custom property. The “requestedFor” property is the equivalent of requesting a virtual machine “on behalf of” another user.

The combination of these two elements (custom property and request issued from orchestrator account) causes the user to see two requests on the requests page.

Because the orchestrator issues a request on behalf of the user, the user needs to be entitled to the blueprint. This entitlement is the reason the user sees the ASD and the blueprint in the catalog.

The solution

Like the problem, the solution also contains two parts.

The first part of the solution is to modify the request of the Advanced Service Designer. Instead of using the “requestedFor” custom property, the “Cafe.Shim.VirtualMachine.AssignToUser” property has to be used. The “Cafe.Shim.VirtualMachine.AssignToUser” assigns a virtual machine to the user irrespective of which account is used to create the request. The “requestedFor” property will create the request on behalf of another user. This property also requires the user to be entitled to the blueprint. The “Cafe.Shim.VirtualMachine.AssignToUser” property does not have this requirement.

The second part to the solution is to re-organise the entitlements. The blueprints should only be entitled to the orchestrator account (and other users that are allowed to see the ASD and the blueprint) and not to others. You can enforce this by creating a new entitlement for the blueprints and removing the orchestrator account and blueprints from the original entitlement.

The result

The result of the solution can be seen below:

asd portal after change

The user can now only request a virtual machine via the ASD workflow and when looking at the request page, the user only sees his request. Users with permissions to see all requests can still find the orchestrator request by changing the submitter in the upper right corner.

asd request after change

yannickstruyf