Tag: vro

Let’s Start to Fill Our Toolbox

One of the best features of vRA is the API first* approach to management, but I need some tools to get there. Postman is great for learning and prototyping, but I need solid vRO Actions to build functional workflows to integrate with the Event Subscriptions and to automate the configuration of vRA itself.

Much of this will be repetitive to experienced vRO users, but hopefully helpful to others who are just starting. In future blogs the actions covered here will be used in examples and I wanted readers to be able to have a reference. And as I warned the readers in the welcome, the ramblings will go where anywhere that I find interesting.

The toolbox and examples are all designed with the intent to use the vRealize Automation Cloud API available on VMware {code} or you can access the swagger API within the vRA deployed appliance.

https:// [vRA Appliance] /automation-ui/api-docs/


vRO has the built-in REST plugin which allows you to add REST Hosts, REST Operations, and generate operation workflows. Don’t use it! Ok, let me walk that back a bit. For certain use cases such as Puppet DB querying adding the trust keys to the vRO keystore and then setting up the DB rest host using the keys works well. Configuring the REST plugin with basic user/password authentication becomes a lot of maintenance later and plugin configurations cannot be migrated if you run multiple vRA environments. I really wish someone would have told me 5 years ago, but we live and learn.

Bypassing the REST plugin I use 3 base actions as my starting point for REST API integration. These work well for me and I take no credit for writing them. I used VMware {code} and vCommunity posts to find code examples to cobble these together. The driving design is to keep them simple, easy to use, and then build additional specialized actions extending the functionality of the core functionality which can be an slippery slope of action overload. Package of all actions shown in this post is available here.


  • ar.util.rest.importCert
  • ar.util.rest.createTransientRestHost
  • ar.util.rest.request

importCert: does exactly what the name implies.  The code was borrowed from the vRO Library workflow “Import a Certificate from URL” and simplified down to this action. Since running in my isolated lab environment I don’t check  most standard certificate validation and will only throw an exception if the certificate is expired.

var ld = Config.getKeystores().getImportCAFromUrlAction();
var model = ld.getModel();


var model = ld.getModel();
model.value = url;

var certValidation = ld.validateCertificates();
var certInfo = ld.getCertInfo();


if ( certValidation.isCertificateExpired() == true )   throw "Certificate is expired. \n " + certinfo;
var error = ld.execute();
if (error != null) throw error;

createTransientRestHost: This action allows me to bypass the REST Plugin. As the name suggests it creates a temporary and transient REST Host for the duration of the workflow and it is automatically destroyed. Input is the FQDN of the rest host and uses the importCert to add the certificate to vRO.

if (fqdn == null || fqdn == "" ) return null;

var url = "https://" + fqdn;


var restHost = RESTHostManager.createHost("TransientRESTHost-"+fqdn);
var transientRestHost = RESTHostManager.createTransientHostFrom(restHost);

return transientRestHost;

request: This is the generic action for virtually any REST request and returns the REST Response object. I debated adding additional response error handling in the action, but opted leave out in this action. The responsibility for all error handling rests (pun intended) in the workflow/action using this low level action.  Several inputs have been configured to defaults used for the most common requests as well.

if (fqdn == null || fqdn == "" ) return null;
if (url == null || url == "" ) return null;
if (method == null || method == "" ) var method="GET";
if (contentType == null || contentType == "") var contentType="application/json";
if (content == null) content="";
if (headers == null) {
	var headers = new Properties();

var restHost = System.getModule("ar.util.rest").createTransientRESTHost(fqdn);
var request = restHost.createRequest(method,url,content);

for each (var header in headers.keys) {
	System.debug("Headers: "+header+":"+headers[header]);

var response=request.execute();
System.debug("Response Code: "+  response.statusCode);
return response;

Now let’s use these actions to get the vRA Authentication Bearer Token used for subsequent API requests. This is the first of many specialized actions to extend the functionality of the core REST actions. I also wanted to make my vRA interactions extremely simple so I externalized the vRA url, userid, and password into configuration attributes.  The action to get the bearer token requires no inputs and the return properties object is the headers required for further vRA requests.


var username=System.getModule("ar.util.helpers").getLabConfig("vra_userid");
var password=System.getModule("ar.util.helpers").getLabConfig("vra_password");
var fqdn=System.getModule("ar.util.helpers").getLabConfig("vra_fqdn");

var url="/csp/gateway/am/api/login?access_token";
var method="POST";
var content = {
	"username": username,
	"password": password

var response = System.getModule("ar.util.rest").request(fqdn,url,method,JSON.stringify(content),null,null);
var responseJSON=JSON.parse(response.contentAsString);
var headers = new Properties();
headers.put("Authorization","Bearer "+responseJSON.access_token);
return headers;

The next must have action is an action to make any REST API call to vRA using all the building blocks so far.


if (url == null || url == "" ) return null;
if (method == null || method == "" ) var method="GET";
if (content == null ) var content="";

var headers=System.getModule("ar.vra.util.rest").getAccessTokenHeaders();
var fqdn=System.getModule("ar.util.helpers").getLabConfig("vra_fqdn");
return System.getModule("ar.util.rest").request(fqdn,url,method,content,headers,null);

At this point I have a single action one-liner in any scriptable task to interact with vRA.

var response=System.getModule("ar.vra.util.rest").genericRestAPI("/iaas/api/cloud-accounts","GET",null);

Time to jump on that slippery slope that I mentioned above for a ride. There are certain vRA API calls I use many times over. Building further specialized actions for specific API calls can be very useful, but it can also result in action overload which is where I tend to end up. A useful getDeployments action will retrieve one or all deployments for based on the one input of variable deploymentId.


var  url = "/deployment/api/deployments";
if (deploymentId != null)  {
System.debug("getDeployments url: "+url);
return System.getModule("ar.vra.util.rest").genericRestAPI(url,null,null);

The toolbox will be gaining many more tools in the future, but now I have a starting point to get deeper into the Event Broker Service subscriptions and start to configure environments during provisioning – stay tuned. Package of all actions from this post is available here.

*Maybe should say “almost” to an API first approach to management since the current public API does not cover 100% of product configurations, but I hope this will be fixed in upcoming releases of vRA.

Anytime you learn, you gain.             -Bob Ross

How about we peek under the covers of the vRA 8 Event Broker for a bit.

Those of you familiar with vRealize Automation (vRA) 7.x may have had the pleasure (or head ache) of working with the Event Broker Subscriptions (EBS). The good news is the EBS in vRA 8 is much simpler to add individual events, can run good old vRO workflows or new ABX actions, and has added a recovery runnable item.  It has lost the publish/draft capability allowing you to disable an event without deleting and the ability to subscribe to all events in a category with one configuration.  At this time the EBS is not available as a public API, but possible by reverse engineering the UI with your browser. Hopefully the API will be made officially public soon. I’m really tired of having to recreate all of these subscriptions every time I deploy a new vRA appliance.


What is really important to know is what events are available, when do they fire, and what property payloads are available to the workflows. To accomplish this I have subscribed all the events that run during provisioning to a single workflow – EBS Events.

Event Subscriptions

I setup a basic blueprint to deploy into a vCenter to trigger the events.  The blueprint is nothing fancy.  It contains 4 photon VMs, attached to a pre-existing network, and one disk attached.


Here is the EBS Event workflow.  As you can see from the view of the workflow runs, all we know is a lot of event have fired. Not very useful until you drill into each of the execution logs to see what is really going on. 

EBS Events

This is where things start to get exciting if you are into this kind of thing like I am. The EBS Events workflow pulls information from the system context metadata, sets the __tokenName, and passes it to a nested workflow, __token EBS Events. This makes it much easier to see what order the EBS subscriptions fire and how many times for various different resources. 

__Token EBS Events

Now this view actually gives you some very useful information just from looking at the the workflow runs. You can see all the events that fired, the order, per deployment or resource, and who requested the blueprint deployment. The user bit of who is very handy for a production system with many requests to weed through for trouble shooting.  Just watching the vRO runs during the deployment gives you a good idea on the progression of a deployment as well. Similarly the events for the destroy of the deployment. 

Destroy Events

Now let’s dive into some individual event logs to see what vRA passes to the workflows. The Disk Allocation Pre event runs early in the provisioning and you can start get the feel for the data that is available to vRO either as the inputProperties or in the _metadata context. The disk allocation only runs once corresponding to the single disk added in the blueprint, but 4 disks are allocated in vSphere cooresponding to the 4 VMs deployed.


The Network Configure runs once for the to the single network on the blueprint — I see a pattern forming. The properties during networking get a bit more interesting. The event contains all the information for the network configuration of the 4 VMs from the deployment such as custom properties, network profiles ids, and network subnet selection ids. I’ve been playing in this event quite a bit to understand this schema of multi-level arrays for selection and to see what can be modified, but that is for a future post. Hopefully the anticipation and sneak peak of whats to come that will keep you coming back for more.


One of the more straightforward payloads is for the Deployment Resource Request Pre. There is a bundle of information available to drive customized workflows and this event fires for every resource on the deployment.


Hopefully this gives a little bit of understanding to what  events are available and what data can be used for customization workflows during vRA deployment.  I will be doing future deep dives into many of these events topics to see just what can be modified.

Here is a vRO package with the EBS Events workflows so you can start to explore EBS events and payload properties in your environment.

vRO 8 Web Interface and Legacy Swing Usage

vRealize Orchestrator 8.0 comes with a new web only interface and other changes you can view in the official release notes. The new interface is the first release by VMware to modernize vRO and abandon the legacy Java Swing technology. The web interface has a some nice features such as limited native git integration, operations dashboards, and the all new HTML editor interface.

One of the most annoying “features” of the web interface is you can no longer use folders to manage workflows. Workflows are grouped by tags. Don’t get me wrong, I like tags. But coming from a world where workflow sorting/grouping are directory based (including all of the built-in vRO 8 Library), transitioning to one big flat folder for all new custom workflows just doesn’t fit how I currently work. Existing folder infrastructure is represented as tags and all newly created workflow get a default “webroot”tag.

Now I have never been a huge fan of the JAVA Swing client — but it is still better than the new web interface. Ok maybe not better and I am probably just “Get off my lawn!!!!” old and don’t like change. But lucky for me the vRO 7.6 Swing client is still mostly functional with vRO 8 server.

You need to deploy a 7.6 vRO appliance to get the client running. I installed the 7.6 vRO Workflow Designer locally and nuked the 7.6 appliance. In the login enter the URL of your vRO or vRA 8.0 appliance. The client will show a server mismatch version, but just ignore this and plow forward and the client will launch.

The other big gotcha is if you edit a workflow via the web interface it can no longer be edited, deleted, moved, or copied from the swing client. You can view it and look at the logs. Also any workflow created in with the web interface is dumped into one folder “web-root” which will become a big pile of what does this workflow do quickly without a good tagging/naming scheme.

Not quite all rainbows and unicorns unfortunately. Packages will not import and you must go back to web interface for import.

I’m guessing the Swing client will cease to function in future 8.x or 9 release. Hopefully by then the vRO product team extends the functionality of the web interface to fill the bring back the folder structure as part of the HTML interface. Hint for the Product Manager on the VMware Orchestrator team if they are reading this.

And I must have a standard disclaimer: Use the SWING client at your own risk and I’m pretty sure it is not endorsed or supported by VMware. I’m going to keep using it and will post any updates to enhancements to the HTML interface… Or when SWING is officially broken.