hin255 - Fotolia
VMware vRealize Automation 7.4 adds detailed customization
VMware recently updated vRealize Automation to include a variety of detailed customization options that enable admins to shape the product to the needs of end-users.
VMware vRealize 7.4 has introduced a feature that customers have asked for since its earliest releases: the ability...
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
to modify the aesthetics and logic of service request forms.
Figure A below shows the page for requesting a Linux VM in vRealize Automation 7.4. It includes default fields, such as quantity, description, number of CPUs and amount of RAM. Previously, users couldn't hide or modify these fields, even if requesting the service didn't have any possibility of modifying the values.
Figure A also shows a field named Cost code that shows a drop-down menu with possible values. Before vRealize Automation 7.4, admins could access this field but had limited customization options. The vRealize Automation custom properties in 7.4 offer much more flexibility.
Previous versions enabled admins to change the order of fields as they added custom properties to a blueprint with the order index property, but these versions offered limited form customization beyond that.
There was also limited functionality for input validation using the property dictionary, such as setting the field type to text or integer and defining minimum or maximum lengths and values. The addition of software components to a blueprint can rapidly grow the number of fields, which makes input validation even more important.
In vRealize Automation 7.4, a request for a machine is as simple as the example in Figure B below. In Figure B, the only field left is the Cost code, and all the other fields are hidden. This makes the forms more user-friendly, which aids adoption, but vRealize Automation custom properties also enable better control over the creation of VMs. If admins can hide the less important fields, they can prevent the addition of incorrect data or the changing of parameters.
Create custom forms with vRealize Automation 7.4
To create a custom form, start by creating a normal blueprint. Go through the standard process of building and testing blueprints because it's much easier to have all the necessary fields defined and present before customizing the form. Any vRealize Automation custom properties should already be in the blueprint and the blueprint components.
To design the form, find the New button for custom forms at the bottom of the screen or in the Custom Forms menu under the Design tab. Either option will open the Custom Form Designer. Figure C below shows this new design canvas from the online documentation and contains some worthwhile examples.
All the vRealize automation custom properties and regular properties are available on the left-hand side of the screen. Admins can drag and drop these on the canvas. Admins can also create multiple pages or tabs to organize fields into one view. The fields don't have to be in a particular order, so organize them in whichever way makes sense for the end user requesting the machine.
Creating vRealize Automation 7.4 custom forms
After creating the form, don't forget to enable it with the switch in the upper-right corner. This toggle can help users troubleshoot the blueprint. If a normal request works, users might find that the form is the source of the problem.
There are options available in all of the fields to define the type of field, such as Decimal and Text, as well as the way they are displayed, such as the Drop-down and Password fields. This is similar to what was previously available, but there are many new features, such as the ability to provide the step size for a value. In Figure D, for example, the 1024 MB memory is the default, and the user can only select increments of 1 GB.
All the fields from the blueprint become available, including Custom Properties, except one. If the blueprint enables the Show Location in Request field, then that field won't be available in the list of fields. Unfortunately, vRealize Automation 7.4 doesn't allow the addition of the field to the form that would, for example, allow users to select a cluster.
Figure E shows a list of Generic Elements that users can choose from. Notice that there is also an Image field, which enables further customization of the form, including adding a logo and graphical instructions.
VRealize Automation 7.4 adds input validation options
VRealize Automation 7.4 also adds many forms of input validation. The older features of minimum and maximum values are still available, but there are now newer ones, such as regular expressions.
Another powerful feature is that, like with the form builder for anything as a service, the content of one field is available for use in the validation of another field, or it can be added as a default value to another field when the request form is processed.
Users can also perform external validation via an action with JavaScript-code in vRealize Orchestrator. Previous versions enabled the execution of external actions for fields from the property dictionary for purposes such as getting a default value for a field or getting a list of Cost codes. With vRealize Automation 7.4, users can use that for data validation, which enables the system to send meaningful messages to users when they enter invalid data.
VRealize Automation custom properties aren't automatically part of a blueprint when it's exported. Users can export a custom form in JavaScript Object Notation (JSON) or in YAML. Use the JSON format when importing the form into another blueprint that uses the same components, such as the same vSphere machine blueprint for a nested blueprint. The YAML format is for exchanging a form between vRealize Automation environments, such as from a test environment to a production environment.
