Counting Custom Code in vRealize Orchestrator

Introduction

One of the things I had always found difficult in translating to upper levels of management was the level of effort required to get vRealize Automation up and running in an environment. It was always a tough sell to add additional developers to staff to work on what is technically a COTS product, and being able to quantify that level of effort in a way that is also meaningful to the upper echelons of management (and not just us technically oriented folks) can be difficult. To be fair, this challenge is certainly not unique to vRealize Automation, but is common with all of the CMP platforms that I have encountered, as well as many other enterprise grade applications. That being said, going back several years now, I have toyed with the idea of counting the number of lines of code (or even the total number of characters of code) used in vRealize Orchestrator workflows and actions in an attempt to somehow quantify the level of effort required to stand up, support, and maintain the solution. However, it always seemed that as soon as I started to investigate ways to gather the required information that I would get pulled in five different directions and was never able to make much headway. 

SovLabs Optimization Assessment Tool 

At SovLabs, we recently released the SovLabs vRealize Automation Optimization and Upgrade Assessment in an effort to provide our customers meaningful insights into their existing vRealize Automation environments to help assist in showcasing areas that are ripe for optimization. Following the recommendations output from this tool can lead to a substantial decrease in the management and operational overhead that we typically encounter in early stages of customer engagement prior to implementing the SovLabs modules, as well as better prepare their environments for a simplified migration to vRA 8. As part of developing this tool, my co-worker Mads (https://hazenet.dk/, https://twitter.com/hazenet) cracked the line and character count problems I had encountered (not to mention it took him less than 24 hours to my 4 years or so), so I re-purposed his ideas to provide something that can provide custom code counts in vRealize Orchestrator. The key differences between the two tools follow: 

Capabilities	vRO Custom Code Counter	SovLabs Optimization Assessment Tool
Count lines and characters of custom code present in vRealize Orchestrator
Count lines and characters of custom code that are specifically invoked from vRA via XaaS workflows, day 2 actions, EBS, and custom form actions
Identify areas of blueprint sprawl that can be reduced
Deliver key insights into reservation architecture and resource allocations
Identify areas where software components and script execution can be streamlined
Simplify network architecture in vRA, eliminate reliance on network profiles
Analyze vRA 7 design principles for migration optimization
Consolidated reporting across multiple tenants
Provide executive level report detailing all findings and recommendations for vRA optimization

Capability Comparison

If you would like to request the FREE assessment, you can do so here. 

Uses

Just a few of the use cases that I have run across for a tool like this:

1. Useful to produce metrics as part of an initiative to minimize custom code
2. Quantification of the amount of custom code (or amassed technical debt) in the environment
3. Show back the level of effort required to implement the solution

Compatibility

The current iteration of the tool was developed and tested against vRealize Orchestrator versions 7.6, 7.5, and 7.4. It is possible that it may be compatible with some older versions as well. If using an older version, you may not be able to use the feature that gathers the presentation information depending on whether or not the vRO REST API included the call I am using to gather the workflow content. At some point, I hope to test it with vRO 8.1+ as well.

Execution

You can download the vRO package from: https://github.com/mbomb67/vroCustomCodeCounter

From the vRO Design View, navigate to the Packages tab and then select “Import Package…”

To run the workflow, navigate to vBombarded > Custom Code Counter > Custom Code Counter, and “Start Workflow”

Select whether you would like a detailed JSON formatted report showcasing all of the workflows and actions found. If you select no, the workflow will only output the total lines of custom code, and total characters of custom code found. 

Select any of the following elements that you would like to report on. You can select a single workflow, folder, action, etc. or you can select multiples of each. The workflow is designed to only collect on unique items, so even if you input the same workflow, or the same action is called from multiple workflows, they will only be counted once. If you wanted to call the workflow programmatically, you can even pass the Workflow IDs and Action IDs (in moduleName/actionName format) into the workflow. 

The next selection is very important as it defines what is considered “custom” code or not. I have a couple of the most common workflow folders and action modules defined as default values, but the basic idea here is if you do not want workflows under a folder to be counted towards your custom code counts, you need to define them here. If you are writing code under the Library folder for example, none of this code will be counted by default. If you are writing code under the library folder, the best thing to do to verify only custom written code is counted is to remove the Library folder from the folders to be ignored and then select all of the default (think VMware and third party plug-ins) sub-folders under Library. For the modules to ignore section, you can just enter the prefix that you want ignored. Any module prefixed with com.vmware. In the example below will be ignored. 

Finally, if you are doing a lot of work with actions in your vRO workflow presentation (dynamic dropdowns, conditional validators, etc.) the only way I could find to gather this data was with the vRO REST API. If you want to gather presentation data, you will need to specify the credentials needed to create a transient REST host (this gets deleted once the data is pulled). The account specified must have at least read permissions on all of the workflows you are gathering data for. 

Once the workflow run is complete, a user interaction window will pop up, the resulting JSON will be attached. You will want to select the download button, and after downloading the file, press submit on the user interaction window. 

The Report

Once you have the report file downloaded you can open it up to see the results. There are four different sections, the first two summarize the total lines of code found, and the total character count found. The second two sections show what workflows and actions were collected, each with their unique line and character counts. 

Each workflow reported on has an elements section where you can see what the linked elements are. If the linked element is another workflow or an action, counts will not be tallied under the workflow from where they are called, but rather, that workflow or action element will be captured and counted under its own section. So the total lines of code count for a workflow only applies to lines of code that are unique to that workflow itself, this would be items like scriptabler tasks or decision elements. 

Summary

In closing, the vRO Custom Code Counter will help you to quantify the custom code written inside of your vRO environment. If you need more granular and detailed reporting, or consolidated results across multiple tenants, the SovLabs vRealize Automation Optimization and Upgrade Assessment can help. The Assessment tool gathers targeted custom code called from vRA itself; to include elements like XaaS blueprints, custom event broker subscriptions, and dynamic drop downs specified in a vRA custom form, but it also gives a more holistic view of the entire vRA solution itself.