Category: api

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/

vra-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.

Actions:

  • 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();

ld.setCertificateAlias("");

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

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

System.debug(certInfo);

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;

System.getModule("ar.util.rest").importCert(url);

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

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();
	headers.put("Content-Type","application/json");
}

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

for each (var header in headers.keys) {
	System.debug("Headers: "+header+":"+headers[header]);
	request.setHeader(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.

ar.vra.util.rest.getAccessTokenHeaders

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);
headers.put("Content-Type","application/json");
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.

ar.vra.util.rest.genericRestAPI

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.

ar.vra.util.rest.getDeployments

var  url = "/deployment/api/deployments";
if (deploymentId != null)  {
	 url=url+"/"+deploymentId;
} 
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