Decoupling Configuration From Code
When creating vRealize Orchestrator workflows, usually the development process will require the consumption of environmental configuration, for an operation / task / process to be completed. This configuration can be defined in various locations within vRO, such as; a Plugin Endpoint, Workflow Attribute, Configuration Element or Resource Element.
There are a variety of ways to access objects using these types. However I want to dive into an approach that requires a small amount of work upfront, but allows for easy access to these objects automatically going forward.
The reason why this is important to consider whilst in the development phase is, you don’t want to update workflows with environment specific configuration every time you move code between multiple vRealize Orchestrator platforms.
Most customers I work with have multiple vRealize Orchestrator environments for Developing, Testing, Staging and finally releasing automated processes into Production, for their internal customers to consume. These environments usually require connectivity to their counterpart Development, Test, Stage and Production infrastructure that make up a ecosystem.
The example I will show below is for accessing a Configuration Element (aka Global Attributes) that is used to identify the NSX:Connection that an environment is setup to consume.
So lets begin…
Lets say I need to start building out a bunch of Workflows where the common requirement between them all, is the use of my NSX Connection Manager Endpoint (NSX:Connection) for querying NSX data. Rather than manually linking my NSX Connection as a Workflow Attribute in every workflow that I develop.
Wouldn’t it be nice to define a Action once, where it’s core function is to just simply return a NSX Connection Object. This Action could now be dragged and dropped onto any Workflow whenever it’s needed, to dynamically retrieve the correct NSX Connection for the environment the Action is being executed in. This would save me a massive amount of time, during development as well as not having to manually update any workflow, every time I move code into different vRealize Orchestrator platforms.
To do this, I will create a Attribute called “nsxConnection” in a Configuration Element, that is a NSX:Connection Type, and assign the value as my NSX Manager Endpoint.
Note: You’ll want to have a consistent folder structure across all vRealize Orchestrator Platforms when accessing these Attributes.
Now to begin coding…
I need to create an Action that returns this object. This is where the API Explorer makes developing easy. There is an API Method to retrieve Configuration Element Categories that match a given path:
Server.getConfigurationElementCategoryWithPath(pathAsString)
In the example above, the “pathAsString” variable would be the “Configuration/NSX” folder path, and this method would return a ConfigurationElementCategory object. This object has an Attribute called configurationElements, which so happens to return an Array of ConfigurationElement objects. It’s just a matter of looping through these objects and finding the right Configuration Element by name.
Once this has been identified, we just grab the value of the “nsxConnection” Attribute. Again the API Explorer shows us, there is a Method called .getAttributeWithKey(key) which returns an Attribute associated to the Configuration Element with a specified Key.
This is what the code for the Action should end up looking like:
//Path of Configuration Element and Names
var configurationElementPath = "Configuration/NSX";
var configurationElementName = "Endpoints";
var attributeName = "nsxConnection";
var category = Server.getConfigurationElementCategoryWithPath(configurationElementPath);
var elements = category.configurationElements;
for each ( var element in elements) {
if (element.name == configurationElementName) {
var configurationElement = element;
}
}
return configurationElement.getAttributeWithKey(attributeName).value;
The last part for setting up the Action is to simply set the Return type to be NSX:Connection.
The Action, can now be dropped into any workflow that requires the NSX:Connection and it will be returned dynamically, with no changes required when moving code between environments.
Finally, decoupling environment configuration from the code. Happy Days.