Tag Archives: JavaScript

vRO Code – Calculate CIDR notation

Recently I ran into situations where I needed to supply a network address in CIDR notation to external systems (infoblox and the oracle GRID installer in my case) from a vRealize Orchestrator workflow.

CIDR notation looks like this: So instead of specifying the subnet mask using the 4 bytes separated by dots it just tells how many bits are used for the network number.

The thing is, all you can get from vRA is the regular subnet mask ( in this example). Sometimes you can get away with a solution as simple as a few ifs or a switch/case but that’s not really the way to properly fix this.  I wanted to solve this once and for all so I wrote some JavaScript code for vRealize Orchestrator that calculates the number of bits in the mask and creates the CIDR network notation for you. Here it is:

  • Inputs for the script object or action:
    • gateway (String)
    • subnetMask (String)
  • Output:
    • cidr (String)

This script generates the network number but it can easily be adapted to return the ip address itself in CIDR notation.



Orchestrator JavaScript speed test: .map()

A while ago I wrote a blog post in which I showed the performance difference between the array prototype function .indexOf() and a for each loop. Now it’s time for the second part of the series: Orchestrator Javascript speed test: .map()

Test setup

The test setup is identical to the setup I described in the previous post. Same machine, same vCO appliance. I did change the script that generates the test array slightly. Instead of a string I now store an object in each array elemen. Here is the script:

Both tests are done in the same workflow so they are as close together as possible to get the same circumstances of the tests.

map vs for each workflow

 Mapping an Array

Mapping an array into an other array means running some action on every element of the array and returning the value of that action into a new array. What I will do in this test is taking one attribute of the object that is stored in each array element and create a new array that only consists of that one attribute. This makes it easier to  search for the right index number later on using .indexOf()

  • So here the content of one array element: { number: “1”, value: value=1 }
  • And what we want as an end result is an array where each element just contains “value=1” for example.

There are basically two ways to do this. You can either use the prototype function .map() or create your own loop. Let’s try the prototype function first.  map() takes takes a function as an argument. Whatever the function returns is stored in the active element of the target array.

Below is the result of this test:

So the map action took 94 milliseconds. But over a couple of test runs I did get different results. Ranging from 119 to 86mS. Now let’s try a for each loop to see how long that takes:

And here are the results:

So this particular run took 106 milliseconds. But again as with the .map I don’t get consistent results. I’ve seen values everywhere between 82 and 139 mS.

I run both test sequentially in the same workflow. And even the difference between both methods is not the same. Sometimes the map() is faster, sometimes the loop is faster.


I cannot definitively say which method is faster. The only thing I can say for sure that they are about the same speed. But if you ask me which method I prefer the answer is: .map()! Why?  Because if I read somebody elses code and I see the .map being used I know something is being mapped. But if I see a pof each loop I have to go through the whole loop to understand what’s going on. In the example above the loop might be simple but in real life it can get complicated pretty quick.


Orchestrator Javascript speed test: IndexOf()

As you might know Javscript is the scripting language used in vRealize Orchestrator. So while I’m not a web developer  I  use a lot of Javascript. When handling arrays in my scripts I tend to use a lot of prototype functions like .map, .forEach, indexOf and a couple others. But when I go through the library workflows I see a lot of of for each loop with some ifs and a break instead of the prototype functions being used. I have some opinions on this which I will share later. For now I was just wondering which method is faster, using the prototype functions or using your own loops. To answer this question I decided to do some speeds tests. This is the first post about these tests: the Orchestrator Javascript speed test: indexOf()

Setting up the test

To be able to measure a difference in performance I needed a significantly large array. I settled on an array with 100.000 elements as this seemed to take enough time to loop through to see some actual performance difference between different methods. I executed the tests on a vCO 5.5.2 Virtual Appliance running on my laptop. So if you run the appliance on a faster machine you might need a bigger array.

I used this script to create the array:

The actual speed tests are in the same workflow as the array generation script. This way both tests are ran as close together as possible to ensure the same circumstances for both tests.


Finding the index of a value

Imagine you have an array and you want to figure out in which element a certain value is stored. There are two ways to do this. The easiest is using the .indexOf() prototype method. Alternatively you could use a for each (..) loop. To find out which method is the fasted I generated an array with 100k elements. the value in each element is the string representation of the index number. On the array I executed the code below:

This piece of code searches for the value “99999” in the array elements. We already know that is the very last element of the array so this measures how long the function takes to loop through the whole array while still validating that the actually works correct.

Below is the result of this script.

So the total time elapsed for the indexOf() method is 52 milliseconds.

Let’s compare this to a for each loop.

And here are the results:

So this run took 166mS. Which is more than 3 times slower than the .indexOf() prototype method.


Not only did I have to write more code to achieve the same result, the execution of the code also takes more than 3 times longer to execute the code. Obviously if you hit the target earlier in the array or use a smaller array the difference would be smaller. Still, It doesn’t make sense to write more code that is slower, harder to understand and not maintained by the software vendor.

So please: use the .indexOf array prototype method when searching the index for a specific value.