One of the things that you need to become familiar with as you use the Cloud Automation Services more and more is the Cloud Assembly API (and the CSP API). The API is required for some of the more advanced use cases leveraging extensibility that you might want to implement.
A typical extensibility use case might be to perform an operation via vRO using the payload of attributes that the Event Broker sends to vRO when an event occurs. This is relatively simple if all the information you need to perform your vRO operations is contained within the event payload but what if it isn’t? What if you need to get more information from Cloud Assembly to carry out your extensibility? Well that’s when the APIs come into play.
The Scenario
In this series of articles I am going to cover how to implement a reasonably common use case which is all about getting the right data out of Cloud Assembly to populate a CMDB type system.
Every time a machine is deployed I want the following information placed into a CMDB:
- VM hostname
- VM IP address(es)
- VM spec (vCPU and memory quantity)
- Deployment name
- Endpoint name
On the surface this seems straight forward, I can just get this information straight from a event topic right? Well unfortunately this is not always the case and for this scenario I am going to have to make some API calls to get some of the required information.
REST Hosts
To do any type of API call back to Cloud Assembly you need to have REST hosts configured, not just one host but several. These are:
The first of these REST hosts is for the Cloud Services Platform and allows us to do things such as authenticate, look at billing info and get at other information and services that are platform wide.
The second REST host is for Cloud Assembly and allows as to get at all the constructs within an organisation as well as deployments, machines etc.
The combination of both of these REST hosts makes it possible to use the APIs programmatically within vRO to perform numerous operations and get access to lots of information that is simply not available within an event payload.
You can use the out of the box “Add Rest Host” workflow to add both hosts, using no authentication.
Authentication
To do anything with APIs you must be authenticated. This is done by means of getting a bearer token for the user account you want to use from the Cloud Services Platform API and then using the bearer token in subsequent API calls to other services within the platform.
To obtain the bearer token you need to go into your Cloud Services account via the GUI and get an API token (otherwise known as a refresh token). The token will cover the parts of Cloud Services you want to access. In this example I am generating an API token for my user account that covers everything.
The generated API token shows what it can be used for and when it expires (they don’t last forever!). The token ID (visible by clicking on “show”) is what you need so copy that down.
Authentication Action
One of the most useful things to do is to build an authentication action which will take the API token and exchange it for a bearer token. This is because every API call you subsequently write will need to do this as bearer tokens periodically expire (their lifetime is very short compared to the API token above).
This is an action I built for taking in a REST host and API token and then returning a corresponding bearer token.
When I call if from a workflow and pass it the CSP REST host as well as a valid API token for a user account I get the following response.
The action returns the bearer token as an output parameter as well as printing it to the system log.
In the next part of this series I will use this authentication to start gathering the required data.
vnuggets 
Pingback: Cloud Assembly – Using the API via vRO (Part 2) | vnuggets