Harness the Power of vRA with the SovLabs Property Toolkit and Template Engine – Part 1

Ever wish you were able to set more than one value from a single vRealize Automation (vRA) request input?  Have you ever wished you could make some aspects of vRA more dynamic and flexible? Wish you could simplify the vRA request form?  In this article I’m going to let the genie out of the bottle. All your wishes are about to come true. But before we summon our genie, let’s first dive into what it is that we are going to be wishing for.  My wish is to have a simple vRA request page with only three inputs that can drive the outcome of every aspect of my request. Sounds too good to be true doesn’t it? We will find out soon enough.

Finished Result

Determine the needed Inputs

Determining what our inputs are going to be.  For my scenario I need to the following three inputs:

1. The Environment (Production, Development, or Test)
2. The Application (WordPress or Microsoft SQL)
3. Compliance Needs (SOX or Non-SOX)

In my example, these are the only three items I need to know from the requester to build a server in my environment.  The remaining info I can gather from the business group they belong to, what resources the workload is placed on, etc. I know every environment is different and many will require more than three inputs.  Once you have read this entire 3-Part series, you will realize the number of inputs doesn’t matter. It’s how we use them that’s key.

Determine the outcome

What outcomes do we need to drive based on these inputs?  Or, how will these help determine the outcome of the overall deployment?  Will they influence items such as the machine hostname, Active Directory OU placement, vCenter Folder placement, vSphere tagging, application installation, etc?

Determine the Impact

We need to determine the impact that each selection will have on the request.  For example, if a requester chooses production as the environment, what impact will that have as opposed to development or test? We can do determine the impact by templatizing what the input means. Wait is “templatizing” even a word? Spell check thinks it is! Templatize? Honestly, I’m not sure but it is now.  What do I mean by “templatize the input”?  Well let’s look at the following example and how the selected environment affects different aspects of the deployment.

Let’s examine all three inputs and what those selections will be:

Table 1

Templatization allows us to define what the selected option means to the relative aspects of the deployment instead of impacting just one.  

Building Out the Template

There are two options for building out your templatization of inputs:

• Create a property group and use the SovLabs Property Toolkit to assign the five needed properties.
• Use the SovLabs Template Engine to dynamically determine the values we need.

Option 1 – Create a property group and use the SovLabs Property Toolkit to assign the five needed properties.

Inputs in vRA traditionally result in a single property with a value. Using the SovLabs Property Toolkit we can configure an input to attach a vRA property group to the request, resulting in multiple properties rather than just one.  Once we have figured out what properties and values we need, we simply create a property group that holds all the properties and values.

Creating my production property group

Now we need to create a property definition that will provide the requester with the possible selections for the inputs at request time. For this task, we will use a name that starts with SVL_{property name}.  This naming convention tells the SovLabs Property Toolkit that we are naming a property toolkit property.  Try saying that three times really fast! Then, for each of the values in our static list, we will specify the name of the property group we created to represent it.  

You will notice the property group name is also prepended with SVL_{property group name}.  As a result, the appropriate property group and all of its properties will be assigned to the request based on what value the requester chooses from the list.  It’s important to note that the property group name and the ID must match.

Option 2 – Use the SovLabs Template Engine to dynamically determine the values we need.

Yes there is another option!  What I’m about to demonstrate is a way to take the above example and streamline it even further using the SovLabs Template Engine.  Now, this option applies itself very well to this example, but, as you will see, it may not apply to every situation.

For this example we are going to use the same information provided in Table 1 above.  The main difference is that, instead of creating three individual property groups as needed in the above example, we will now only need a single Dynamic Property Group to accommodate all three options.  Also, our input value will not be assigning the property group. Rather, it will simply be setting a single property with a single value, as demonstrated below.

Let’s look at an example of a Dynamic Property Group.  In the example below, the values are dynamically calculated based on the value selected by the requester at the time of the request.

Input Property: Environment  Value: Production, Development or Lab

In this example, our dynamic property group will look something like the chart below.

Notice what I did there? Instead of statically defining the values across three different property groups, I’m now using logic within one dynamic property group to determine the property values.  When we take in a single property value, we can use that value to determine the value of the five resulting properties.

If you’re worried about having to run 50 test deployments to test your logic, worry no more.  SovLabs has included another tool within this swiss army knife. It’s called the Template Tester.  The Template Tester allows you to test this logic without ever running a single test deployment, so you know for sure what the resulting value will be.  Check it out below.

Now that all of our logic has been tested we can create our Dynamic Property Group.  This Dynamic Property Group is very similar to property group we created in the previous example, except that we are inserting logic into the value field as opposed to static values.

Next, we need to somehow attach our Dynamic Property Group so it will impact the deployment.  We can accomplish this task a few different ways. We can simply attach the property group to the blueprint and it will be applied, or we can use our property toolkit feature that allows us to attach property groups to any entity in vRA that accepts custom properties, and attach it outside the blueprint so it’s always applied.  

To attach it via a custom property, we simply add the following property and value where we want to assign it:

Property Name:  SVL_Environment  Property Value: SVL_Environment_Group

That wraps up Part 1 of this multi-part series.  Stay tuned for Part 2, in which I will walk through creating our inputs for the application selection.  I’m going to cover how we can use the application selection to templatize what we deploy from the template all the way through to sizing and more.