What’s New in vRealize Operations 6.7 REST APIs

What’s New in vRealize Operations 6.7 REST APIs

This post was originally published on this site ---

Calling all coders, scripters and automation nerds!  With the release of vRealize Operations 6.7 we have quite a few updates to the REST APIs.  The full list is attached at the bottom of this post, but I wanted to call out a few that are notable and helpful.  I get questions from customers, partners and the VMware field almost daily on REST APIs so I know there are many of you using them for integrating vRealize Operations with other solutions.

 

Auth Changes and Enhancements

 

You should read the complete list of changes, but I wanted to point out a couple of items as these could impact your current code or scripts now or in the near future.  First, by default in vRealize Operations 6.7 REST APIs basic authentication is enabled.  However, this may not always be the case in future releases.  If you require basic authentication for the APIs, you should be aware of a configuration setting that is located in the file /usr/lib/vmware-vcops/user/conf/api-conf.properties

Look for “basicAuthentication.enabled” and you will want this set to “true” if you find that you have problems with REST calls using basic auth.

By the way, VMware engineering advises that it really is best to use token-based auth because it is more secure and much faster.

Other auth changes include the ability to create a VIDM authentication source and an optional new notion extension for basic auth that includes the auth source type.

Alerts APIs Enhacements

 

Probably the most exciting (well, to me anyway) enhancements is a new API to retrieve symptoms of an alert.  Previously, this could only be done by making several calls to retrieve the alert, the impacted object symptoms and reconcile this with the alert symptoms in the alert definition.  Sort of expensive!  Now, you can simply:

GET /api/alerts/contributingsymptoms

and add the alert ID (or IDs) query to get the contributing symptoms for that alert.  For example:

GET /api/alerts/contributingsymptoms?id= ad108ca6-6190-45d1-bda6-b31c4d3e3fbe&id=50b9fad6-a957-4fe0-8be2-79d27c49103d

In my lab, this returns:

Of course, you may still want to get the triggered symptom message (i.e. “Write Latency (ms) 16.333 > Threshold (ms) 15.0”), which can be done via the getSymptoms or querySymptoms APIs, but I believe this new API will be a time saver!

 

The queryAlerts API gets some welcome enhancements as well.  Now you can filter on alert-name, user-name and resource-kind using the new regex filters for the same to find alerts which contain the regex expression for these properties.

Other Alerts APIs enhancements include:

  • queryAlerts now provides the alertImpact property which provides the impact field, i.e. Health, Risk, Efficiency.
  • queryAlerts now provides reporting of the alert owner name using extractOwnerName in the alert-query body
  • A new API to filter alerts using grouping for alert groups (i.e. time, definition, etc)

 

Other Updates

 

There are more updates and enhancements, which are listed in the document linked below.  Additionally, the Java client got some updates including a token-based authentication interface that renews the token when it expires.

Be sure to check out my Postman collection for vRealize Operations REST API on Sample Exchange.  It is updated whenever I add new a new request.  I’ve already added the new API to get alert contributing symptoms.  Hopefully the information above is useful to you and I welcome your feedback in the comments or via twitter @johnddias.

REST API Updates in vRealize Operations 6

The post What’s New in vRealize Operations 6.7 REST APIs appeared first on VMware Cloud Management.

Leave a Reply

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.