Querying vRA 7.x API with Postman

Today I had a seemingly simple request: How many VMs are provisioned a month for a given tenant(s) in vRA? Yeah – I’ve got that info, no problem! I log into a vRA 7.x environment and go to provisioned items, all groups I manage, and… oh. I forgot that there’s no “export” or simple way to get data out of the UI in the items view.

My first thought was old-school me, “Welp, let’s see where this data lives in the database.” My end-of -year 2019-self said, “No – stop, you’re better than this.” This data has to be available via API but… that’s a pain I don’t usually play in those waters. Well, I didn’t. I think 99% of my resistance was based on the actual API configuration (Postman/ARC). I have done POST and GET for a while but for one-off things like NSX syslog config, etc. In order to use my POSTs for anything else I’d have to change it in 3 or 4 places and then what’s the point?

Postman setup

This is super basic and super easy once you understand it. Go ahead and download Postman via https://www.getpostman.com/downloads/ and follow all the default install stuff.

Once setup, the key to Postman, in my opinion, is the use of environment and global variables. I won’t cover the full details here for how to setup an environment in Postman but it’s simple. Simply create a new environment, associate a collection with said environment, and define any variables you may want to use within that environment. Another option is to use global variables but they will be used across all collections so this may not be ideal for some situations. Here is an example of two variables used for this little project called vra-fqdn and token:

Pretty simple, right? It is! Next we can start by actually setting up how we will populate these values. The variable vra-fqdn should be setup manually within Postman though you could get clever and have ways to populate it automatically with different requests. I am setting it manually.

Create a new POST to https://{{vra-fqdn}}/identity/api/tokens and set the Content-Type to application/json. Next, click the Body tab and enter:

Populate the 3 variables in that small code block above with your login credentials for the vRA tenant you specify and click Send. The response you get will be an id as shown below which serves as your bearer token and will allow you to make subsequent authenticated GET and POST calls to vRA:

Ordinarily, you’d take that token and paste it into the header of another GET or POST to pass authentication checks. However, you can take it a step further so as to store the token as a variable within Postman so that you don’t have to copy/paste the token into the header of a call. For that, I found this little snippet of JavaScript that will store the output of id to token which is defined as a variable within this environment called vRA Dev:

Notice that JavaScript is entered on the Tests tab and will be performed after a response is received.

The view above just shows the variables defined for the environment called vRA Dev. The vra-fqdn variable is populated manually for this vRA environment but the token variable is being populated by the JavaScript we entered. Sweet!

Now that we have our credential information and paths defined, we can make a GET call to https://{{vra-fqdn}}/catalog-services/api/consumer/resources/types/Infrastructure.Virtual/ but notice that in the headers section we’re referring header key called Authorization to the variable “Bearer token” which will fill the field with the token id response we received earlier.

Once we hit Send with that GET we should get a response in JSON format the contains not only every single virtual machine managed by vRA but also a slew of attributes such as the owner, the create date, the destroy date, lease info, etc.:

Boom! We can save the above response from Postman or we can select what we want and copy/paste as needed. For my purposes, I saved the output to a text file and imported it from a “web source” in Excel and converted the JSON to a table and then made a pivot table based on month grouping and was able to provide detailed, accurate information to the original request.

It may seem like a bunch of steps but half of this post is initial setup – from there, you can make tons of GET and POST calls to help improve your effectiveness in manipulating data within vRA or other systems, too. You can do so much more than this simple query with API calls such as deploying VMs, reconfiguring VMs, etc., but this is a start.

Thanks for reading let me know your thoughts, comments, or suggestions!

Author: Jon

Share This Post On

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share This
%d bloggers like this: