vRealize Orchestrator: Finding a REST Host from a vCenter SDK connection

By | March 13, 2018

vRealize Orchestrator can communicate directly with the vCenter Server(s) that it is connected to, but uses the old SOAP API. However, with the advent of the REST API for vSphere, some things are easier (for example, tagging) and only possible to handle outside of the builtin abilities. In this post I will look at how to find a REST Host from a vCenter SDK connection in vRealize Orchestrator – this can be used to reduce the number of inputs on a workflow or make it easier to create multiple-vCenter workflows.

Each vSphere object has an “sdkConnection” property that refers to the vCenter Server. This is useful, but if you wish to use the REST API, we’ll need to provide a RestHost object type. We could provide that as an input to the workflow, but this is not dynamic and we shouldn’t force unnecessary parameters on users.

There must be an easier way, right ?

We should assume that every vCenter Server that is connected to vRealize Orchestrator is also configured as a Rest Host. This configuration only needs to be done once, though we will look at automating this at the end of the article.

Thus, we can enumerate the REST Hosts and find the one we’re after by comparing the URL of the vCenter API endpoint to the vCenter REST API endpoint. There is a catch in that the URLs are different so we will need to do a little string manipulation to make it work.

For example:

  • The vCenter Server is https://auto-vc.auto.internal:443/sdk
  • The REST Host is https://auto-vc.auto.internal/rest

I believe it is a fair assumption that the protocol will always be https for both, so we can ignore that – to match up we would need to ensure that the vCenter Server has been added with either the FQDN or hostname identically in both locations – if not then the lookup will fail. Personally I don’t see anything wrong with always using the FQDN 🙂

Adding a REST Host

I have no doubt that this has been done many times before on many other blogs, but for the sake of completeness I will document how I’ve added the REST host below.

This next step is me being lazy – I’m going to pass in the SSO administrator credentials. This is not best or even good practice – you should pass in user credentials or a role-limited vco-specific account.

I haven’t included screenshots of the (3a) and (4a) wizard pages – I have accepted the defaults. Change if you need to !

Comparing Values

Our code will need to strip the protocol and the port (if either of them exist) from an URL, returning the hostname. We’ll use this on both the vCenter URL and every REST Host URL to see if they match. Since this is a straight forward bit of a code, we’ll put it in an action.

The main configuration of the action is below:

As seen above, the action assumes an input named “vcenter” of type VC:SdkConnection and returns an output of type REST:RESTHost.

 

The “gethostname” function is responsible for stripping the URL down to the hostname. We use the RESTHostManager object to loop through configuration hosts and return the host if there is a match.

Now when creating workflows that would require a REST Host object, we can retrieve the correct object from the sdkConnection property of the managed object, thereby removing the need to add another input to the workflow, and if you have a workflow against multiple vCenters this should really make life easier !

Next Steps

We will take this on to do some vSphere tagging using the REST API 🙂

 

Summary

I’ve created an action for this and saved it in my github – the unencrypted action file can be found here.

Let me know your thoughts in the comments 🙂