Updated Oct 2021
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 groups inputs ( this feature is also available for local inputs directly in your Cloud Template ).
- 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.
It is important to highlight that these Actions could be Python, Powershell JavaScript or NodeJS based, 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.
And in case you were wondering, yes you can also use Use vRealize Orchestrator Actions for dynamic external values for local inputs, in your Cloud Template
The set up is very similar to what I described lines above, with the only difference that instead of doing it at the “Property Groups” section, you can trigger the input assistance right there at the Cloud Template, then create a “New cloud template input”, which presents the option for “External Source”
Of course you could simply define the code as well.
What about Cloud Assembly Secure Properties (Secrets)?
For that, I created a new property group – constant type, 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
