vRA 8 – My First Extensibility Workflow – ABX Edition

Sure, if you want to get technical, this is my second vRA 8 extensibility workflow, but since this is kind of a part 2 to a blog of a similar title with the focus being on an ABX action this time rather than a vRO workflow I figured it couldn’t hurt to use a similar title. This time the focus will be on the new extensibility engine available in vRA 8, Action Based Extensibility, or ABX. Since ABX is brand new, I may take a little more time in explaining each element here. 

What is ABX?

The vRA 8 documentation describes ABX as follows: 

Action-Based Extensibility uses streamlined scripts of code within vRealize Automation Cloud Assembly to automate extensibility actions.

Action-Based Extensibility provides a lightweight and flexible run-time engine interface where you can define small scriptable actions and configure them to initiate on particular events provided by the Event Broker Service (EBS).

You can create these extensibility action scripts of code within vRealize Automation Cloud Assembly and assign them to subscriptions. Similarly to workflows, the extensibility action script triggers when an event included in an extensibility subscription occurs. Extensibility action scripts are used for more lightweight and simple automation of tasks and steps. They are also hosted on the cloud as opposed workflows which are hosted on-premises by using a vRealize Orchestrator server. 

Action-Based Extensibility provides:

– An alternative to vRealize Orchestrator workflows, using small and reusable scriptable actions, for lightweight integrations and customizations.

– A way to reuse action templates, which contain reusable parameterized actions.

Note: Extensibility actions are project-specific.



Here is what I am aiming for in this post: 

  1. Perform the same steps referenced in the blog post linked above where we will inject custom properties and tags in to the machine payload during the Compute Allocated state.
  2. Create one action to return the tags to the virtual machine – use nodejs runtime
  3. Create another action to return the custom properties – use python runtime
  4. Use the “Action Flow” construct to call the tags and custom properties actions to demonstrate how to chain multiple actions similar to a vRO workflow

Action Setup

Create the Set VM Tags Action

For this portion of this post, I will be following the official vRA 8 documentation’s sample for tagging VMs during provisioning with extensibility actions

All of your ABX actions can be managed from Cloud Assembly by going to Extensibility > Library > Actions

When you first create an action, you are presented with a few different options for your action. We are going to start with the Template field. There are 8 available templates out of the box in ABX, since there is already a “Tag VM” template included, we are going to use the Tag VM template for this action. 

Here is what the template looks like prior to modification

After I have modified the template to meet my requirements, below is what it looks like. Note that we are specifying the same properties that we specified with the vRO workflow in part 1. The syntax is a bit different, but ultimately we derive the same result. Also note that we are still able to pull the metadata fields about the request in ABX to dynamically set the value of the tags. 

Below you can see what the entire action looks like. One of the features I want to highlight here is that I was able to take an existing ABX action run, and copy the JSON payload from an existing VM to recreate the tags and __metadata input fields. I can use this real world data when testing the action using the “Test” button. 

After I have tested the action, the UserName and EventTopic tags are added to my output payload as expected. 

Create the Set VM Custom Properties Action

Normally I would probably modify the tags and custom properties in the same action for something as simple as this example is doing, but I think the capabilities of ABX are better demonstrated by chaining two workflows together in an Action Flow. Plus, I want to know how action flows work, and I would also like to see if you are able to pass variables between actions in an action flow. The other thing that you will note in this action is that I am using python for my runtime selection instead of nodejs as in the Set VM Tags action. 

For the Set VM Custom Properties action, my script is going to look very similar. In fact, I even started with the Tag VM template for the python 3 runtime. 

When I test the action, you can see the two additional properties are added to the property stack in the output. 

Create the Action Flow

To create an action flow, you start just as you would with a standard action. You still select the “New Action” button, and then name the action and select a project. Then once the action is loaded, you will want to select the Action Flow template from the Template field. Once you have selected the Action Flow template, you will notice that the view changes. You can now see a pictorial representation of the action flow and how the action flows between the different elements on the canvas. 

When you highlight (or delete) the action_placeholder text, you are presented with a dropdown of the actions available to the project selected for the Action Flow. 

Also worth noting is that when you insert an additional line below each action section, the available options are displayed for additional parameters 

Here is what the finished Action Flow looks like

A couple of things about the Action canvas are of note: 

  1. For an action flow, you can still insert JSON properties for testing by going to the details tab
  1. In the upper right hand corner, you can very quickly identify (and navigate to) the number of versions of the action, the number of subscriptions the action is used in, the number of action flows that reference the action, and the number of action runs have been executed for the action. 

Update Event Subscription

I had already created an Event Subscription for post 1, so all I am going to do is modify that event subscription to point to the ABX action instead of the vRO workflow. 

Once I deploy a blueprint, I am able to navigate to the action run and see that the tags and properties have been modified as expected. When I go to verify that they have been added to the Virtual Machine as well, they can be viewed there as well. 


These are just some notes regarding some things that I found interesting as I went through the process of testing Extensibility with ABX and running ABX through its paces. 

  • Since actions are project specific, even if your subscription is set to execute for all projects, that action will only execute for deployments in the project where the action is defined. 

The only way I was able to get the action flow to fire for another project was to export the action flow, and then re-import the action flow under the separate project. Now I have duplicate actions available for ABX, and what happens when I have to modify code for one of these actions and propagate those changes to all of my projects. This can become unmanageable real quick. You will definitely want to take this into consideration when considering which extensibility engine to leverage for your organization, as this could lead to a large number of actions to have in your environment if you have a large number of projects.  

  • Under Action Runs, when you are using an action flow, you will see the execution for the action run, as well as executions for each action called by that action run: 
  • An action flow actually returns the entire property stack as an output, whereas an action only returns what you have specified as outputs and returned in the action. For example, my tags workflow only returns outputs.tags, and my properties workflow only returned outputs.customProperties, but the action flow that includes the two actions returned every property in addition to the modified tags and customProperties outputs. 


This was another very simple example of how to get started with extensibility in vRA 8. With the addition of another extensibility engine, organizations running vRA 7 today have a lot of decisions to make in regards to how to get to vRA 8. Sid Smith has taken a really in-depth look at what can be involved when doing workflow migrations from vRA 7 to vRA 8 and the extensive amount of work that could be involved to prepare your existing vRO workflows for vRA 8. If your organization is considering leveraging ABX for future extensibility needs you will also want to account for the learning curve in not only learning a new tool that leverages two different languages, but also the differences in behavior noted above could potentially lead to having to manage more code within the organization.

At SovLabs, we have been helping many vRA customers migrate away from their customizations on vRA7 to the modules produced by SovLabs in preparation for migrating to vRA8.  Whether you are solely using lifecycle workflows, or using XaaS Blueprints in vRA to meet your businesses needs, we can help. Migrating your customizations to policy-driven software (Yes, SovLabs software…shameless plug) now will allow you to avoid having to rewrite code. And, migrating your SovLabs configurations from vRA7 to vRA8 is seamless.

2 thoughts on “vRA 8 – My First Extensibility Workflow – ABX Edition”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: