Skip navigation
2018

     Email is one of those things that most of us take for granted these days. We just expect email works, that it is flexible, and that it’s adaptable to our situation. Within vRA, we can also get email in and out based on a variety of scenarios. But when it comes to customizing how that looks and works, it’s a little tricky. As a result, many folks don’t even bother mucking around with it because of how complex it is what with manually uploading new email templates to the appliance, restarting services, customizing XML files, or writing vRO code and event broker subscriptions and doing all the plumbing work yourself. But thanks to the godsend that is SovLabsCustom Notifications module, all this is now a thing of the past. It not only makes it super simple to create your own custom notifications, but it’s actually kind of fun to see how quickly and easily you can give your CMP that extra edge with rich emails that can be your own HTML, include whatever custom properties you want, and go to basically anyone you want. In this article, I want to bring this module to attention and show you exactly how you can use it to extend your vRealize Automation platform to send custom email notifications to recipients of your choosing.

 

     In order to get email out of vRA for basic things like knowing if your provisioning request was successful, you need to setup a few things. First, there’s the outbound email server (Administration -> Notifications -> Email Server) so that you can connect the appliance to the mail relay. Next, there’s ensuring you have the scenarios you wish activated (Administration -> Notifications -> Scenarios) of which there are a whole host. And there’s also ensuring the email address is present in your Active Directory user profile.

 

Once you have all this, you should begin receiving some mail. But when you do, it comes to you only, and it’s just kind of bland.

 

 

You can see all of the basic information, but you don’t have any extra metadata that’s in the request (I have a couple in this catalog item) and also what if you need this to go to an operations team instead of yourself? It’s not really possible without some heavy lifting and running around. Changing what you see above in vRA is not a trivial task although there are some templates available that can assist. The latter use case of sending email upon provision and destruction to arbitrary recipients is even trickier with only some community code out there in vRO. This approach requires much more massaging.

 

     Now, let’s see how to accomplish this using the SovLabs Custom Notifications module. What’s nice about this and other SovLabs functionality is that you never have to leave the comforts of your vRA portal, never have to write and manipulate your own JavaScript, and never have to monkey with system files and services.

 

     In this scenario, we will configure notifications to send successful build and destroy emails to an operations team so they can be notified and make the appropriate changes to external systems of record. First, we add a Notifications Configuration through a simple catalog item which was published automatically for you when you added the license.

 

There’s a form we must fill out with all the conveniences you might expect, including which types of events we want to get (VMLIFECYCLE contains the provisioning aspects), but there are others including snapshot notifications and IPAM. We choose the states we want with simple check boxes. Then, we choose standard things like title and body. Oh, and as you can see, the HTML is already pre-built for you making it easy to copy and paste whatever you like!

 

 

Over on the Message Server Configuration tab, we can use an existing mail server definition as well as an existing email group definition. Let’s create a new one to see what’s here.

 

 

Everything you would expect to see, including the ability to set and save email server credentials if you enable authorization. And down on the Email Group configuration portion, here we can very easily add To, CC, and BCC addresses all in one profile! This ability makes it super simple to put whatever email(s) you like into a profile that can then be used on a per-blueprint basis if you like. Submit the configuration, check your requests to ensure it completes, and then go back to the SovLabs vRA Extensibility Modules service in the catalog. This time, select Add Notification Group.

 

Here, we’ll choose the profile we just selected giving it a label and type.

 

 

Once this is submitted and successful, you should now see a nifty new property group that was auto-created for you.

 

 

If you dive into this property group, you’ll see a number of system properties in addition to the main custom property called SovLabs_NotificationGroup and the value of which is the profile you created in the last step.

 

 

The SovLabs Notification module essentially checks to see if this property exists and, when it does, it matches the profile to the value and uses that to know what, where, and to whom to send notifications. You can then use this property anywhere in vRA you see fit, but in this demonstration we’ll consume this property group simply by attaching it to a blueprint.

 

In this blueprint, all I’ve done is found and attached this pre-created property group, then saved the blueprint. It’s really that simple and I’ve done absolutely nothing else.

 

 

Now, I’ll go to the catalog and request this item to see what happens.

 

 

You can see I have a couple of custom fields in the request. More on this in a second.

 

 

After the request succeeds, I check my email and find this.

 

 

And, bam, there it is! What you see is an HTML-formatted email that comes entirely out-of-the-box. It’s important to stress that what you see above is stock and I’ve made absolutely no modifications whatsoever to the body of the message. It’s pretty detailed already, right? And easy to read? Certainly. They’ve done a great job of putting this together, but also in making it easy to extend into whatever you’d like to see.

 

     Now that we have a basic email, how do we customize this easily to add additional things like custom properties that I had on the request form? If you scroll up, you’ll see I had a drop-down called CZAD.Users. I supplied a value for this field at request time. I now want to see that in my email that came across. Maybe this is something like an application owner or backup retention policy or other metadata to go into an asset tracking system. Whatever it may be, it’s simple to drop into these custom notifications. So let’s see that process.

 

     From your Items tab, go over to SovLabs Notification and find this profile you created earlier. We need to edit the body of it. Open the item and click the Update action item.

 

 

The body as well as the other fields become editable.

 

 

You have the choice of either editing it as-is here in the text area, or lifting it into an HTML editor of your choice. I’m going to choose the latter because I’m not a hardcore HTML programmer. I’ll just jump over to a simple online editor for demo purposes and paste in the code.

 

 

This may be a little difficult to see depending on how it gets published, but on the right I have pasted in the raw HTML, and on the left I have it rendered out.

 

I want to add a new row under the “Machine details” heading that shows my CZAD.Users custom property and its value. Now, you may notice I have a number of these words enclosed in double braces like {{ something }}. These are actually custom properties inside vRA that, thanks to the wonders of the SovLabs Template Engine, we can easily pick up and translate. Yes, really, it’s as simple as enclosing whatever custom property we want in double braces and it gets automatically translated, and it can be *any* custom property as well—even system properties!

 

 

Maybe it’s just me, but I find that AWESOME and waaay better than having to write any code to pick it up and interpret it myself.

 

So, getting back, let’s add that line underneath “Network name” so our code and, thus, the HTML gets rendered as shown.

 

 

Again, maybe difficult to see, but I’ve made the code change in the editor on the right (highlighted), and I can see the editions rendered on the left. Let’s copy and paste this entire block back into our notification definition and update it.

 

 

That was successful, now let’s re-request the same item and see what we get.

 

 

I’ve highlighted the field and its value, so we should hopefully see this now.

 

 

 

And, boom, there we go! The new email that came from the system has the custom property added and got the correct value. And, likewise, when we destroy this deployment, we get another email with the same information making it easy for an operations team to get all the info they need.

 

 

     Now, hopefully, you can see how huge this notification module is, how vastly powerful and flexible it can make your vRA infrastructure, and, above all else, how much easier it is to setup and administer versus everything else out there. This is a great way to add value to your CMP and can solve a whole variety of use cases. Now all that’s left is to go forth and see how you can use this in your organization!

     Custom properties (CPs henceforth) are the lifeblood of vRA, as many of those reading this know. They are a rich system of metadata which can influence not only the decisions made by vRA proper but also extensibility through vRO. CPs are life, effectively, and one of the biggest challenges is managing those CPs and having their values set simply and without too much complexity. A common problem arises in the face of this which amounts to CP sprawl in a request form. When CPs are used for most major decisions, the user in the request form may be bombarded with a whole array of them which can slow down provisioning time, increase adoptability, and lead to user error (by virtue of incorrect selection in the form). Property Toolkit can help eliminate almost all of these through transparent, background, silent assignment of other properties.

 

     Consider this scenario: Your vRA catalog requires users to select a number of values which steer the deployment in a variety of ways. For example, you ask the user to select the following: Application, Environment, Storage, and Network. But you require them to select the correct value based on an earlier selection, like where the application is “Oracle” they need to provision this to “Production” only as other environments are not licensed appropriately. And also, given the environment, there is a specific network associated with only that environment and so they have to pick the correct one. Now, this can be done with vRO actions, but wouldn’t it be nice if you could only ask them to choose *one* thing in the form and all other decisions were made automatically? Further, wouldn’t it be awesome if all that logic *didn’t* require you to design new workflows or actions in vRO or crunch new JavaScript? Well, if this is something you’re looking to do (or any variant thereof), then Property Toolkit is your savior because that’s exactly what it’s designed to do (plus more). Let’s see how to do this in a real life example.

 

We need to set several CPs to steer a deployment to the correct place. These are as follows:

  1. Environment. This sets the target cluster where the machine(s) will be built.
  2. Reservation Policy. Selects the right reservation policy (which can open up things like endpoint and datacenter).
  3. Network Profile. Sets the correct network on which the machine(s) will be attached.
  4. Name. Provides part of the name in our custom naming standard.
  5. Storage Reservation Policy. Sets the storage which will be consumed.

 

Now, we could list each of these individually in a request form and have the user select each and every one (after making sure to tell them how to complete the form). But even easier, let’s define only a single CP and have each of these 5 CPs get their value based on it. I’m going to create a CP called My.RequestForm.Prop and provide three possible values: A, B, and C.

 

 

I’ll show this as a dropdown in the form. These values can be whatever you like, but I’m just using simple letters in this case for illustration. For example, instead of A, B, and C these could be application names like Oracle, JBoss, and Apache.

 

Next, I want to set the first of the dynamic properties, Environment, based on the value of My.RequestForm.Prop. The Environment CP will be called CZ.MyProp.Environment and the choices I have are Prod, Dev, and QA. I’ll map them one-for-one to the values you see above in My.RequestForm.Prop. In other words, if a user selects A from the list, then the value of CZ.MyProp.Environment will be dynamically set to Prod. If the user chooses B then it’ll be Dev and so on. In order to do this, all we need to do is create a new property on the deployment and call it SovLabs_CreateProperties_<anything>. The <anything> portion can truly be whatever you want—it’s only a label for your organizational purposes. So long as the property begins with SovLabs_CreateProperties_ then it’ll invoke the Property Toolkit module. The value of this property can be a variety of things as explained in the documentation, but in this case let’s use an array of single objects. The value of this property becomes the value of another property. For example, if I wanted to define a new property in the simplest way, I could set the value to this:

 

[{"name" : "CZ.Cities", "value" : "Texas"}]

 

When the module ran, I would then get a new CP defined on the deployment with name of CZ.Cities and a value of Texas. But, because everything SovLabs does is templated, we have a whole host of operators at our disposal thanks to the templating engine. The one which we want to use here is the case/when operator. This will allow us to switch to a different value based on another value. So getting back to the new CP we want to set, the value of that property would get defined as such:

 

[{"name" : "CZ.MyProp.Environment", "value" : "{% case My.RequestForm.Prop %}{% when 'A' %}Prod{% when 'B' %}Dev{% when 'C' %}QA{% else %}UNKNOWN{% endcase %}"}]

 

It’s fairly straightforward. If the value set in My.RequestForm.Prop equals A then assign the value of Prod to CZ.MyProp.Environment. If that value is B then let it equal Dev and so on.

 

Now we have that one, let’s define the others with the same basic statement. To simplify this, you can put them all in a single property group and attach that property group to your blueprint. To save time, I’ve drawn up the following table which shows the combinations.

 

CP Name

CP Value

My.RequestForm.Prop

A

B

C

CZ.MyProp.Environment

Prod

Dev

QA

CZ.MyProp.ResPol

ReservationA

ReservationB

ReservationC

CZ.MyProp.NetProfile

NetworkA

NetworkB

NetworkC

SovLabs.Naming.App

TST

ORA

APA

VirtualMachine.Disk0.StorageReservationPolicy

Diskstation

vSAN

Diskstation

 

Effectively, then, the value of a single property (My.RequestForm.Prop) will influence the outcome of five other properties dynamically. Graphically, it can be represented as the following.

 

If the value of My.RequestForm.Prop equals A then all the following values are set below it. If B, then all those in that column apply, etc. In this demo, I built a single property group and stashed all these properties there, although they could be in just a single dynamic property definition if you wish.

 

 

The exception is the CP VirtualMachine.Disk0.StorageReservationPolicy as this must be set on the machine element in the canvas and not the blueprint level.

 

If we flip over to the request form, we can see how simple this can be when presented to the end user.

 

 

Let’s select A then deploy to see what happens.

 

 

 

Based on the value A the Property Toolkit then set the 5 CPs we were after, including SovLabs.Naming.App which I am then consuming in another SovLabs module for Custom Naming (which produced the “TST” portion of the hostname you see). It got the correct Environment, it got the correct Reservation Policy, Network Profile, and it also went to the correct storage because this property, while on the machine element, still was able to be set from the initial value of A.

 

 

Although I’ve obviously created a few of these properties myself to illustrate what you can do, you can use this module to set any CP, even reserved system properties such as the one that controls the storage reservation policy. Can you not see how incredibly flexible this can make your deployments? We can ask the user to make but a single decision, and based on that outcome we can then dynamically set any number of other CPs. That’s amazing if you ask me and something that, prior to the Property Toolkit, required a whole heap of complex JavaScript and vRO plumbing to get done.

 

So, this is cool, but let’s take it one step further. Let’s let My.RequestForm.Prop influence another CP, and then let’s let *that* value influence another CP. In this manner, we can create cascading dynamic property assignment. Here’s what I mean.

 

Let’s still ask the user to pick a value of My.RequestForm.Prop. The value they choose will still influence the Environment CP (CZ.MyProp.Environment if you recall). But, rather than basing the Reservation Policy CP on My.RequestForm.Prop, what if we could determine that from the Environment CP? Graphically, it’d be represented like this:

 

 

And to put that in context with the other properties, the altered flow chart would result as the following.

 

 

In order to distinguish, I’ll change the possible values of CZ.MyProp.ResPol from the table previously to be the following: ReservationPrd, ReservationDev, and ReservationQA. Now, let’s change the definition of CZ.MyProp.ResPol to key off of CZ.MyProp.Environment and not My.RequestForm.Prop.

 

[{"name" : "CZ.MyProp.ResPol", "value" : "{% case CZ.MyProp.Environment %}{% when 'Prod' %}ReservationPrd{% when 'Dev' %}ReservationDev{% when 'QA' %}ReservationQA{% else %}UNKNOWN{% endcase %}"}]

 

Let’s make the same request and see what happens this time.

 

 

Amazing! All we’ve changed is the definition for CZ.MyProp.ResPol in this case and nothing else. Can you imagine the possibilities this opens up? The freedom, flexibility, and power the Property Toolkit enables your vRA to have is limited only by your imagination.

 

     To recap, then, in part one of the Property Toolkit series, we showed how it can synthesize new CPs based on the value of others. This was illustrated with the vCenter Folder use case. In part two here, we are creating dynamic property sets in which the value of multiple different CPs get their values from other CPs. We did this in two ways. The first was to assign five separate properties based on the value of one reference CP. The second was to cascade this logic by letting one equal another which equals yet another. In both cases, we achieved a dynamic assignment of various CPs even in different places by exposing just a single decision in the request form.

 

     I really hope you’ve found this article to be helpful and that it has stirred your imagination with all the various ways you can use Property Toolkit to make your life simpler and your vRA much more powerful all while reducing complexity. It really is game-changing integration that opens so many doors all while eliminating the need to write, test, and maintain custom code. If you have any thoughts or comments about this article, please feel free to reach me on Twitter (@chipzoller).