When using an older vRO workflows (vRealize Orchestrator) I stumbled upon the problem that too many information needed to be entered manually. In this case it is easy to enter information incorrectly so I was looking for a possibility to avoid unnecessary inputs. During my researches I stumbled upon Configuration Elements. Reading two blog posts (here and here) I focussed on this and implemented appropriate functions in my home lab. This blog post describes the whole procedure a little bit more detailed than the sources mentioned above.

But… why?

Provisioning virtual machines is a real-world example. During this, various parameters need to be set – e.g.:

• IP address
• Network mask
• Gateway
• DNS server and search domains

If you add also those parameters in the presentation layer of a workflow, the user experience will get confusing and also errors will be more likely if you need to enter information manually. It would be more handy to store these information in a configuration file. In this case, selecting a template will be sufficient to apply all the settings – user experience will also benefit from this:

Procedure

First of all, network configurations need to be stored within vRO. It is recommended to create a dedicated configuration folder in the Configuration tab. I created a dedicated configuration file per network and assigned the required attributes:

I stored my network configurations in another sub-folder NetworkConfigs as I’m looking forward to create additional configurations in the future.

Afterwards, two “code snippets“, actions, are required to implement the following logic:

• getConfigurationElements – reading all configuration file names within a folder
• getConfigurationElementValue – retrieving a setting from a configuration file

The first function is used in the presentation layer of a workflow to make the configuration files selectable from a dropdown box (see also the second screenshot above). The second function can be used later in a workflow to retrieve the particular settings and use them – e.g. to assign network information to a cloned VM.

The first module

Before the particular actions are created, a module needs to be created. There is a convention for naming modules – it looks like this:

tld.company.name

I have chosen com.stdevel.generic for my module – generic because it contains very basic functions that could be used in a wide range of workflows. If you would plan to create additional actions for e.g. monitoring it would be a great idea to create another module for this – e.g. com.stdevel.monitoring. To create a module, the Design pane (gear wheel icon) needs to be selected. Clicking New module will open a window for entering the name.

getConfigurationElements

[label style=”yellow”]For easier reading, I will name Configuration Elements as configuration files in the following sections of this post.[/label]

 

In the new module, click Add action to create an action.

The first action, getConfigurationElements, will execute the following:

1. Reading the configuration category from the submitted path (Stankowic/NetworkConfigs in the example above)
2. Retrieving all configuration files within a category or aborting if the path is invalid
3. Reading all configuration file names and storing them in an array
4. Returning the array

The source code looks like this:

//get category
var category = Server.getConfigurationElementCategoryWithPath(categoryPath);

//die in a fire if non-existent
if (category == null) {
    throw "Configuration element category '" + categoryPath + "' not found or empty!";
}

//get _all_ the elements
var elements = category.configurationElements;
var result = [];

//retrieve names
for (i = 0; i < elements.length; i++) {
    System.log("Found configuration element '" + elements[i].name + "'");
    result.push(elements[i].name);
}

//return results
return result

By the way, the action source code is available on GitHub: [click me!]

To test this action, I created a workflow which prompts a path and lists all configuration files in the console:

This workflow can be downloaded on GitHub: [click me!]

getConfigurationElementValue

Listing all configuration files works – the next step is to retrieve a setting from a particular configuration file. The next action will do the following:

1. Reading the configuration category from the submitted path
2. Reading configuration files, selecting by the specified name
3. Reading the settings, selecting the value based on the specified setting name
4. Returning the value

The source code looks like this:

//get category
var category = Server.getConfigurationElementCategoryWithPath(categoryPath);

//die in a fire if non-existent
if (category == null) {
    throw "Configuration element category '" + categoryPath + "' not found or empty!";
}

//get _all_ the elements
var elements = category.configurationElements;
var result = [];

//retrieve names
for (i = 0; i < elements.length; i++) {
    if (elements[i].name == elementName) {
        //found required element
        var attribute = elements[i].getAttributeWithKey(attributeName);
        if (attribute != null) {
            System.log("Found attribute '" + attributeName + "' in '" + elementName + "' with value '" + attribute.value + "'");
            return attribute.value;
        }
        else {
            throw "Attribute '" + attributeName + "' not found!";
        }
    }
}

This action’s source code is also available on GitHub: [click me!]

For testing purposes it is a good idea to create another simple workflow which prompts for a configuration path, configuration file and setting before printing the value on the console:

This workflow is also available on GitHub: [click me!]

Conclusion

Like mentioned in the beginning of this post, provisioning virtual machines is an use-case for the implemented actions. In a future blog post I will focus on this. 🙂