VRA Forms

3 minute read


VRA or Vrealize Automation is a designer software where you build a form that is called a Blueprint that users will go to and fill out. This form, once completed allows your infrastructure to deploy VM’s at the push of a button. It does this by using Vrealize Orchestrator in the background to run workflows which then tie into multiple systems like Vcenter, SQL servers, IPAM, etc. If your company has a huge VMWare presence, it is fully worth investing your time into learning how this works because it can not only provision a server, but it can decom a server, rename a server, etc. This software can also connect your organization to AWS/Google Cloud/Azure so that your users can have a single form that provisions where ever you want.

This post will go over fields that you place on a form (blueprint) for your environment.

To Resolve:

  1. At least 90% of fields that you place on a form map to a ‘Property Definition’ on the back end. These values map one to one. So often if you update a Property Definition in VRA, you will then have to go your forms and update whatever fields are referencing them.

    • For example, if you have a property definition called Company.image
    • And you have the following string values as possible choices:
      • ValueSet.Windows2016
      • ValueSet.Windows2016DB
      • ValueSet.RHEL7
    • Then on your form, you can create a dropdown question like: ‘What OS would you like to use’ and it will map to these values on the backend like
    • ValueSet.Windows2016 | Windows Server 2016, ValueSet.Windows2016DB | Windows Server 2016 with SQL, ValueSet.RHEL7 | Redhat Linux 7

    • If you were to add ValueSet.Windows2019 to your Property Definition for Company.Image, you will need to then go to your form and add ValueSet.Windows2019 | Windows Server 2019 to the list for it to update.
  2. Next up is the fun part - Calculation Fields. These are where you form can start to have logic like:
    • ‘If a user selects 2016 DB as the OS, then remove the option for a Image.Size of small because all DB images are large’

    • This is really powerful and what is neat is that it updates in REAL TIME. So as a user moves down a form and makes selections, you can dynamically show and hide fields based on their choices!

  3. In support of calculation fields, I like to create ‘Helper Fields’. These are hidden fields at the bottom of a form that basically connect logic for calcuation fields.

    Example helper field = textField_49dae4ef
    Name = HiddenWhatOperatingSystem
    Type = Conditional
    Logic = If 'What Operating System?' equals 'ValueSet.Windows2016', set value 'w'
    If 'What Operating System?' equals 'ValueSet.RHEL7', set value 'l'
    • So you can create these fields which are pointers to other fields which can then be combined into a calculation field which will yield the final result.
  4. Remember when you are designing a form with VRA that all it is going to do is pass a huge JSON file over to VRO (vRealize Orchestrator) to execute things so the goal is to create as many fields as you can and combine them into meaningful data which can then be used to do various things in your environment. At the same time, you don’t want to overwhelm the user submitting the request so the form should include all important data as well as metadata that they never see but is still passed in the environment. You can start thinking of things like:
    • ‘If the user selects that they want a Windows OS: Grab it’s hostname, network, size, and the user who requested it and write that information to this database. At the same time, hide any fields asking for CNAMES because we don’t do CNAMEs for Windows Servers.’
    • ‘If the user selects that they want a Linux Database server, hide the option of it being a size of small because all database servers get the same setup’
    • and many more…