vRealize Automation Property Groups Enhancements - VMware Cloud Management

As it was described at the Introducing vRealize Automation Property Groups blog by Vincent Riccio , Property Groups make it easy to set custom properties and reuse them in  vRealize Automation’s Cloud Templates.

Today I will walk you through the newly added features around Property Groups, such as:

• Show the associated Cloud Templates where the property groups are used.
• Project Scope to make property groups available to any project or specific projects.
• Use vRealize Orchestrator Actions for dynamic external values to define properties.
• Bind Secrets to property groups to re-use multiple secrets.
• Role Based Access Control (RBAC) permissions to create custom roles for extending property groups management.

Let’s get started, as Administrator or power user, whenever you access the Property Groups option, you will find the listing of property groups per type, Input Values and Constant Values, besides the number of associated properties, however, now you also get the number of associated Cloud Templates , that includes or uses those property groups.

Furthermore, if you click on it, it will show you which those Cloud Templates are, as example, for the property group “cloud_type“, these are the 4 X Cloud Templates associated to it:

Now, you probably noticed in the image above, that those Cloud Templates belong to different Projects and yet, they can share the same property groups, this is possible because whenever you create a new property group, whether they are, Input Values or Constant Values, you can define the Scope , that by default it is disabled, meaning that is available for a single project that you need to explicitly assign.

Of course, if you enabled the scope, the property group would be available in any project. Please note that once you create the property group, you cannot change the scope.

Switching gears, if you are familiar with the Custom Forms, you know that their input fields could be mapped to external data sources via vRealize Orchestrator Actions for dynamic input, well the same functionality is now available with property groups.

As an example, I created a new property group – input type, then added 3 X properties as follows:

Inspecting the property “name”, you could see that I have the option to define a constant value but also an external source that will allow me to select any Action available at vRealize Orchestrator I would like to designate.

If you click “Select”, you will be able to search for the vRealize Orchestrator Actions then bind the action parameters to another available property in our property group.

When you launch the Cloud Templates this specific property group will look like below, you could observe how the “Server Name” input gets calculated by the vRealize Orchestrator Action which has as input the “Server Type” selected value.

By the way, in case you wonder, these Actions could be Python, Powershell JavaScript or NodeJS, in fact, when writing this blog for my testing I mixed different Scripting Engines with my external source properties, some of them query an API to obtain the name, others just manipulate the data locally and generate a name pattern, etc.

What about Cloud Assembly Secure Properties (Secrets)?

For that, I created a new property group – constant yype, then added 2 X properties, one named “code” (string) , which it is going to hold my Application License that you could imagine is sensitive data and must be protected but at the same time, this is information is going to be needed by multiple Cloud Templates.

If we inspect this property “code”, once again you have the option to define a constant value but now you can search, then select a Cloud Assembly Secure Properties (Secrets) from your project.

In this example, for my project B, I have a couple of Cloud Assembly Secure Properties (Secrets), one of them is the Application License, (licenseWebB-Secret), that I just need to select to make it available via the property groups. Please note that this option is available for string type data.

And finally, let’s say that you could ask a couple of “power users” to define the organization property groups but you don’t want to give them access from the “Administration” point of view to any other vRealize Automation configuration areas, in that situation, you could leverage custom roles and most importantly, the newly added Role Based Access Control (RBAC) permissions for property groups management.

This will enable the “New” and “Delete” option under the Design Property Group Section

Conclusion:

You can quickly add a property group to Cloud Templates which saves the time of adding the same multiple properties one by one, these new capabilities improves further the re-usability, operation, management for the property groups and it expands the Cloud Templates features.

Related Links:

Introducing vRealize Automation Property Groups

Custom User Roles with vRealize Automation

Cloud Assembly’s Single Secret Store.

vRealize Automation Cloud Assembly’s new feature Secure Properties

Custom User Roles with vRealize Automation

Extending vRealize Automation Custom Forms with vRealize Orchestrator

Announcing VMware vRealize Orchestrator 8.4

Announcing What’s New in vRealize 8.4