vRealize Orchestrator

How to get vCAC:VirtualMachine object and entity from VC:VirtualMachine

A quick post to show you a couple of ways to get the vCAC:VirtualMachine object and the entity from a VC:VirtualMachine object. Note, below I have got the VC:VirtualMachine as an input parameter called vm.

There are a few ways we can achieve this and one way would be to use a filter on Server.findAllForType. Here’s a snippet of code:

// filter on vm.id

var vraVm = Server.findAllForType("vCAC:VirtualMachine", "ExternalReferenceId eq '" + vm.id + "'");

// end of code

This returns an array. I found it is best to use LinqPad to work out what you can filter on. For example, if you filter on the vCAC:VirtualMachine properties, some are different cases and won’t return a result.

You can also filter using an ‘and’. For example:

// Filter using an 'and'

var vraVm = Server.findAllForType("vCAC:VirtualMachine", "IsDeleted eq false and ExternalReferenceId eq '" + vm.id + "'");

//end of code

Notice that I am using IsDeleted, which is what LinqPad defines, rather than isDeleted, which is what the property in the vCAC:VirtualMachine scripting object has defined.

However, the ExternalReferenceId could have multiple values if you have more that one vCenter endpoint configured. Another value you can filter on if you do have multiple VC’s is VMUniqueID.

So, simply as follows:

// filter on vm.config.instanceUuid

var vraVm = Server.findAllForType("vCAC:VirtualMachine", "VMUniqueID eq '" + vm.config.instanceUuid + "'");

// end of code

Notice that we use vm.config.instanceUuid now instead of vm.id. The attribute simply returns a different value.

In this case, vraVm returns an array, as we are doing a findAllForType, which puts the result set into an array. Therefore, we can get the first index to get our vCAC:VirtualMachine object and then use the getEntity() method to get the entity.

// get entity

var vmEntity = vraVm[0].getEntity();

// end of code

Simple stuff. You can use comparison operators, but generally speaking, I find that you are matching of specific values returned from the VC object, vm.id or vm.config.instanceUuid.

You should also check the length of your array as if the array returns more than 1 index, then you know you have multiple matches – can happen when using multiple VC endpoints.

If you return more than one index, then you can do extra checking, like match on the virtual machine name.

However as you may be using this in an action item for a resource action, try to keep down the code evaluation to improve performance.You can use the filter for any other scripting object, for example vCAC:Blueprint and use LinqPad to work out what you can filter on.

vRealize Orchestrator – using Telnet to test port connectvitiy

vRealize Orchestrator has a TelnetClient scripting class that you can use to test port connectivity. This is far easier to use than dropping to a telnet client on a cli and test connectivity that way. Together with using the TelnetClient scripting class and a workflow that would loop and wait for the port to be open, fail gracefully or continue the workflow but notify that connectivity wasn’t available, the options the TelnetClient scripting class gives you are very handy.

Here a screenshot of what the scripting class looks like in the API browser:

Screen Shot 2015-03-08 at 11.19.18

The constructor looks like this:

var telnet = new TelnetClient(string)

The parameter is a string and takes a terminal type, which be default is VT100. Other terminal types would be ANSI, VT52, VT102, VTNT and so on. VVT stands for video terminal so mostly you can use the default value of VT100.

Here is some simple code to test telnet connectivity:

var port = 22; // number
var target = "localhost"; // string

try {

// testing for port connectivity on target host
System.log("Trying to connect to port " + port + " on host  " + target);
var telnet = new TelnetClient("vt100") ;
telnet.connect(target, port);
connectionSuccess = telnet.isConnected();
System.log("Connectivity to target host " + target + " is successful")

} catch (e) {

connectionSuccess = telnet.isConnected();
System.log("Connection failed: " + e)

} finally {



The isConnected() method returns a boolean of true or false, depending on the connection result, so together with this block of code and a loop workflow, you can test connectivity to a telnet port or wait for a socket to be up. Using a try / cath / finally statement, you catch any errors and disconnect appropriately, although strictly speaking disconnec() can go in the try statement as you’ll only ever connect in the try block so you can only ever disconnect there as well. Skin a cat in several ways on that one. Up to you 🙂

Here’s a screenshot of a workflow that puts it all together. The decision just checks for true or false which is set depending on the connection response.

Screen Shot 2015-03-08 at 11.27.05

Obviously in the sample code above, you should configure the inputs appropriately for the target and the port. This is also a good way to check if a service is available, for example check for SMTP or a REST API service by using telnet.

Happy telnetting!





vRealize Orchestrator – VCO CLI setup and use cases

I wanted to understand how to get more of a IDE user experience when using vRealize Orchestrator and a colleague mentioned the VCO CLI tool found here – https://labs.vmware.com/flings/vco-cli. Its a plugin you install via the vRO configuration and a batch file that launches a vCO CLI GUI. Whilst I wouldn’t classify the VCO CLI tool and a classic IDE or a tool that you should develop workflows in, it does offer IDE auto complete to 2nd level and deeper methods, attributes and properties, whereas the vRealize Orchestrator client only offers top level IDE autocomplete on object types it knows about configured as inputs or attributes.

vCO CLI setup

To set up the VCO CLI tool, you need java 1.7 installed (although I’ve not tested with other versions). It’s also important you have you java home directory set in your environment variables.


Then download the VCO CLI package and install the plugin using vRO Configurator


Then once you have the plugin installed, you need to then open up the vRealize Orchestrator and run the vCO CLI Start Session workflow:

Screen Shot 2015-03-08 at 19.20.12

Once you have a session started, you can then connect to that session when you run the vCO CLI GUI. To run the vCO CLI GUI, go to the folder you have downloaded and unzipped the vCO CLI zip file and run the vcocli-gui bat file. This should open up the vCO CLI GUI tool.

Screen Shot 2015-03-08 at 19.16.26

Click on the attach button and a window will appear listing all the open sessions that are available to connect to and you should see the one you started when you ran the vCO CLI Start Session workflow.


This should now open the vCO CLI GUI tool. (click to enlarge)

Screen Shot 2015-03-08 at 20.03.41

Using vCO CLI

So now we have a vCO CLI client running, we can see how the nested dot notations work. Take this code for example:

var catItems = Server.findAllForType("vCACCAFE:CatalogItem");

for each (var catItem in catItems){
catItem.name + " " + catItem.status.value();

When using the vCO CLI tool, we get auto complete on the available attributes and methods. Here’s a screen shot showing an example with the code above:

Screen Shot 2015-03-08 at 19.43.24

auto complete of catItem

Screen Shot 2015-03-08 at 19.44.16

auto complete on catItem.status

If you look at the API browser, you’ll see the same methods and attributes.

Also,  check the output of the code when I run it. This appears in the output window in the vCO CLI GUI.

Screen Shot 2015-03-08 at 19.46.43

You can see that is outputs the results without having to use the System.log() method.

If I try to use auto complete on catItem in vRealize Orchestrator like I have done in vCO CLI, I just get the old familiar error message:

Screen Shot 2015-03-08 at 19.48.07


So my conclusion is that the vCO CLI tool is really good if you want to write code quickly without having to browse the API explorer or keep using System.log() to see the output. What this can do is make writing code quicker, however it’s not a substitute to vRealize Orchestrator and you have to cater when using the object types by using Server.findAllForType(“vCACCAFE:CatalogItem”), where in vRealize Orchestrator we can use inputs or attributes and specify our type there and we do get auto complete on these object types and scripting classes in vRealize Orchestrator, but only at the top level. So having said that, I would love to see this type of auto complete feature that is offered vCO CLI in the vRealize Orchestrator client and then everyone’s a winner, well apart from the vCO CLI GUI 🙂