The ability to create and manage infrastructure and services for your organization just became more flexible and powerful with the introduction of Custom Resources and Resource Actions in vRealize Automation. Taking advantage of the out-of-the-box integration with vRealize Orchestrator (vRO) you can now create Resources and Day-2 actions using vRO workflows in your blueprints and deployments!  This functionality presents a powerful method for vRealize Automation admins to further customize deployments and provide more options when creating infrastructure resources.


Lets look at both Custom Resources and Resource Actions in more detail.


What are Custom Resources?


When creating blueprints in vRealize Automation Cloud Assembly, there are a number of Resource Types to choose from. Examples of Resource Types include a variety of cloud native objects and machine types, such as S3 Buckets, Cloud Agnostics Machines, NSX networks, vSphere Machines, Azure Resource Groups and much more. However there may be situations where the existing Resource Types may not be adequate for your use case, so in order to fill those gaps we have introduced Custom Resources. Each Custom Resource is based on a vRO workflow.  The Custom Resource then becomes an object that can be dragged onto the blueprint canvas and then is consumed as part of the deployment and are then Lifecycle Managed.

Besides Lifecyle Management option for Custom Resources, admins can also create optional custom Day-2 actions based on vRO Workflows as well. Lets dive into this feature a bit more.


Building Custom Resources


In order to build Custom Resources we will first need to build or identify a vRealize Orchestrator workflow for our use case. You will need to have at least two vRO Workflows identified, one for the creation of the resource and one to destroy the resource when the deployment is deleted. In this blog we will build out a simple use case of creating a vCenter Folder along with the machine deployment.

The vRO Workflow we will use in this example is called “Create Virtual Machine Folder” and the workflow to destroy the folder when the deployment is deleted is called “Delete Virtual Machine Folder”. Both of these are built in vRO Workflows.




Notice that the “Create Virtual Machine Folder” has an Output for type VC:VmFolder, and the delete workflow has an Input for VC:VmFolder. This is needed in the event of a delete action.


Once we have identified the vRO workflow, we can then use that workflow in our Custom Resource object within vRealize Automation Cloud Assembly. Within Cloud Assembly you will see a Design tab at the top, this is where you will configure blueprints and custom resources. Click on Custom Resources and then New Custom Resource. Fill out the form with the following information:


Name – provide a name of the resource

Description – optional description

Resource Type – enter a name you want to give the resource, this will show up in the YAML code property – type. For example I entered Custom.CreateFolder.

External Type – this value needs to match the vRO Type defined in the vRealize Orchestrator workflow for identification, for our example here it is VC:VmFolder, this needs to match the type in vRO. If you look in the workflow images above you will see a column called Type, since this is the type of object we want to create we can get the type from that column.

Activate – choose this if you want the resource to be available now

Scope – define which projects can consume this resource, if you want all projects to see this resource then just leave it to the default.

After configuring the items above, you can then add the workflows you want to use under the LifeCycle Actions section. There are three types of actions you can configure – Create, Update and Destroy. The only two that are required are Create and Destroy.



Once you create the Custom Resource it will show up in the Blueprint canvas as a Resource Type on the left hand side. (Note: If you modified the scope of the Custom Resource to a certain Project, then the Custom Resource will only show up if this blueprint is also tied to the same Project).


Once you drag the Custom Resource onto the canvas then the blueprint YAML code will reflect the object. In this example I have already filled out the needed input bindings and path to the proper vRO inventory section for VC:Folders. With this workflow we have both an Input for the folder name (type: string) and an object to query the parent folder (type: object). When you want to query via type:object then you will need to list out the relevant vRO inventory path, in this case it is $data: ‘vro/data/inventory/VC:VmFolder’.



You can now deploy the blueprint from Cloud Assembly or Service Broker.. Once deployed you can see some information about the Custom Resource in the deployment screen.






What are Resource Actions?


In addition to the Day-2 actions that are already available for Resource Types within vRealize Automation, you can now configure custom Day-2 actions that make changes to your deployed resources. These custom day-2 actions are referred to in vRealize Automation as Resource Actions.


Building Resource Actions


In order to build a Resource Action you will need to first identify the workflow you want to use as the Day-2 Action.

Here is an example workflow that moves a VM to another folder within vCenter. Notice the two inputs – vms and folder. Those both point to the VC (vCenter) plugin so we can query VMs and Folder in the vCenter inventory. For this example there is also an associated action within vRealize Orchestrator that searches for all the VMs by name that is bound to Resource Action, we will see how the binding is done later.




In order to create the Resource Action just go to the Design section where we created the Custom Resource earlier. There you will see a link on the left side called Resource Actions. Fill out the form with the following information:


Display Name – provide a name for the action

Description – optional description

Activate – choose this if you want the resource to be available now

Scope – define which projects can consume this resource, if you want all projects to see this resource then just leave it to the default.

Resource Type – resource type that you want the action bound to, such as Cloud.vSphere.Machine

Workflow – choose the vRealize Orchestrator workflow that will run the action

Requires Condition – choose whether you want a condition tied to the action, such as osType = Linux

Property Binding – create and manage a binding action from vRealize Orchestrator

Edit Request Parameters – choose this if you want to use the Custom Designer to create a Custom Form for the user to interact with when choosing the action from the deployment menu


Earlier I mentioned there was also a vRealize Orchestrator action bound to this resource action, you can see it below in more detail. Basically I need the VM Input to use a Binding Action, I created a vRO action called “getVMbyName”  and it will reference the schema property “resourceName” to pull the name of the VM. This action is not in vRO by default. The “resourceName” property is the name given to the machine by vRealize Automation.

Here is the script used in vRO to do the binding:


Then just configure Return Type to VC:VirtualMachine and create an input called name and leave it as a string value..


The below image shows how to bind the vRO action to the Resource Action in the UI. Basically choose the action then for the Value add ${properties.resourceName}.




After this has been setup you are ready to deploy a blueprint that has a vSphere Machine so we can then see the action to move it to a folder within the Actions menu (it could be the folder you created ealier). Remember the machine that is being deployed is a Resource Type: Cloud.vSphere.Machine, I used that Resource Type here because I want to be able to move it to another vCenter folder. After it is deployed we now see the option to “Move to a Folder” from the Actions dropdown list when you click on the vSphere machine on the canvas. Once that action is chosen the user will be prompted for the destination folder.



Custom Resources and Resource Actions promises to be a powerful way for customers to expand and customize how they will deliver services to the business and quickly provide value in their automation journey. Being able to use highly flexible workflows to create resources and actions opens up a world of possibilities!


For more information on vRealize Automation, check out these recent blogs:

vRealize Automation Action Based Extensibility (ABX) now supports PowerShell

New Resource Limits in Cloud Assembly

Yes! Code Stream Pipelines as Catalog Item