Part II. vAPI and JavaScript
This is the second part of the series of articles related to VMware vSphere Automation with vRO 7 – Tags and vAPI.
In Part I we have covered the vSphere Tags and the setup of the vAPI for vRO7.
Here, we will be discussing how to work with vAPI and how to use JavaScript to do what we need.
Lets start with modifying the Scriptable Task in List all tagging categories workflow.
Duplicate the workflow first as a good practice instead of directly changing a built-in workflow.
JavaScript code:
This is the code for getting the Name/ID output discussed in the Part I.
Note: If you need a good online reference for the JS language, I would recommend Mozilla MDN JS reference or w3schools
The above code is a simple one – the endpoint is the input parameter(type VAPI:VAPIEndpoint).
There are few other variables – the var client which is assigned the returned type from invocation of the client() method of the endpoint.
The var category is assigned an object( an instance of class com_vmware_cis_tagging_category), which is created by passing var client as a param to the constructor. So var category is a ‘live’ object of type com_vmware_cis_tagging_category, residing in memory.
The var CategoryID is of type array of string(string[]) , because the list() method of the class com_vmware_cis_tagging_category returns all category IDs on the system( so one ore more…) and the types of these are stings. So var categoryID ia an array which contains all IDs.
Then simple for loop which on each iteration fetches the respective categoryID entry (with categoryID[i]).
In the loop body we first send the ID to the Logs output( with System.log(categoryID[i])), then we use it as a param to the get() method of the class com_vmware_cis_tagging_category. The get() method returns an object of type com_vmware_cis_tagging_category_model that has a property name,which contains the name of the respective category with the ID passed to the get().
Using the magnifying glass next to the two arrows (Search API), opens a browser in which the classes and class member can be examined.
For instance let see the members of the class com_vmware_cis_tagging_category:
The classes containing ‘com_vmware_cis_tagging_category’ in their names will be displayed. Upon double click on the class name,additional information will appear on the left side. There we can see its methods and properties.
Note the top most method – com_vmware_cis_tagging_category(VAPIClient)– that is the constructor.
This method is an object constructor, which is called whenever a new object of the class com_vmware_cis_tagging_category is created/instantiated( when the new keyword is used).
The constructor takes one argument of type VAPIClient,so that is why we are passing the var client (in our example) as a parameter to the constructor.
The var client is of type VAPIClient, because that is the type returned by the client() method of the endpoint(VAPIEndpoint) variable:
Notice the client() method signature of the VAPIEndpoint class, the returned type is VAPIClient. Its the same type expected by the constructor.
One point here – in vRO, the white square next to a member means the member is property, a variable( like name,Id). The black square means method/action/function which takes parameters and returns something ( like client(), get(), list() ). The methods have brackets – () – after their names and show what input parameters they accept and the return type( after the colon 🙂
For example client(String,String): VAPICLient is a method of class VAPIEndpoint. It has two optional params of type String (username,password)
and returns object of type VAPIClient. The parameters are optional, so they are not provided when we call the client() method in our code.
In the API explorer for class com_vmware_cis_tagging_category we also see the list() method.
The method doesn’t accept any argument( no params) and returns an array of strings( string[]). We invoke the method in our code with category.list()
The get() method(method signature visible in API exploer) is invoked when calling category.get(categoryID[i]).
The method accepts string parameter( the ID of the category – categoryID[i]) and returns an object of type com_vmware_cis_tagging_category_model.
That object has a property name. We read that property in our code with the statement – category.get(categoryID[i]).name
We do it on one line instead of doing it like this, for example:
var a = category.get(categoryID[i]);
var b = a.name;
We directly read the name property of the returned object on the fly. Both ways deliver the same result.
These explanations ( though obvious and simple for some readers) were provided with the sole idea in mind to help people who are new to vRO.
To help orient themselves how to work with the API, how the classes are organized, why the code looks the way it does, etc.
I realize it made the post long, but I feel that among those lines a person may find some important piece of information to help him or her move forward.
Last thing I want to cover in this article is related to using a workflow Attributes as a constant/global variable.
Here is what I mean – if you work a bit with the tags and categories workflows, you will notice that every time you run the workflow, you need to provide the vAPI endpoint URL. So you browse every time and select it. There is way how we can put the vAPI endpoint URL in an attribute so it wont prompt on a run time, but will read it from there.
So lets open the workflow for edit( the pen icon when the workflow is selected), then we navigate to Inputs tab,select the endpoint input parameter and click R+ button:
Then the endpoint input param will disappear from the Inputs tab and will appear in General tab under Attributes:
Now we set the Value( browsing – vAPI plugin – vAPI endpoint URL) to the vAPI URL, then Save & Close and we are done.
If we run the workflow it will just execute without asking to enter vAPI URL and since this is the only parameter in this workflow , it wont prompt for anything actually.
The workflow will just execute and will read the endpoint value automatically every time( because it is an attribute to the workflow).
Also let me say that in our example we send the category names to the Logs output console via System.log().
But they can be for instance stored in array and then provided to the user to select the category from a drop down menu…
What we’ve discussed in this article can be applied to different use cases,.
vRO and vRA are very powerful tools and a lot can be accomplished with them.
This is the end of Part II. In Part III and last part of the series we will continue with reviewing different examples of tagging workflows.
I hope the readers will find the the information posted here useful in their own practice.
Before trying anything on a production environment, always exercise a good judgement and try to test the things first.
Any ideas about improvements or if something can be done differently or in better way are always welcome!
Angel Iliev
Latest posts by Angel Iliev (see all)
- vSphere Automation with vRO 7 – Tags and vAPI – Part II - November 29, 2016
- vSphere 6 Automation with vRO 7 – Tags and vAPI – Part I - November 25, 2016
Pingback: vSphere 6 Automation with vRO 7 - Tags and vAPI - Part I - The Virtualist
Pingback: Point to vAPI Endpoint with JavaScript in vRO - The Virtualist