“The property dictionary feature, introduced in release 4.5, enables an enterprise administrator to provide a more robust user interface for custom properties that a machine owner enters at request time.
Properties are used throughout the product to provide settings for many features. When users request new machines they are prompted for any required properties. Enterprise administrators or provisioning group managers designate which properties are required by selecting the Prompt User option on the blueprint or build profile. By default, the Confirm Machine Request page displays the literal name of the property as a required text box and does not provide any validation other than that a value has been entered.
The property dictionary allows you define characteristics of properties that are used to tailor the behavior of the request user interface…”
(give the “what’s-new” guide a read if you haven’t done so already)
You use the Property Dictionary function to build a Property Definition, which is the logic behind each action. Property definitions can be created for custom properties that require user input during the service request process and, for example, will trigger an external action (e.g. workflow) to complete a given set of tasks that respond back to vCAC when completed. Can you say “Software-Defined Datacenter”?
Some additional uses of the Property Dictionary include:
- Allowing users to select specific resources that are otherwise hidden (e.g. overriding resource reservation policies to allow users to select a specific datastore, network, or cluster)
- Creating property names and descriptions that make sense and can be read in plain english
- Adding pop-up tool tips to explain each required item
- Customizing the order in which required fields are displayed
- Making an otherwise required field no longer required
You can also create property definition that utilizes vCAC’s built-in reserved custom properties, which can take the user’s input (or selection) and apply that to the existing custom property as an answer file of sorts. For example, you can define a drop-down menu that lists all the networks available to a given Provisioning Group (via that group’s resource reservation) and allow the user to select a preferred network. Once the request is approved, that application is deployed to the selected network. You can also build relationships between parent and child definitions to provide a more dynamic and nested functionality — the user selects a datacenter (“Datacenter A”, parent) and, based on that selection, only appropriate networks (“NetA”, “NetB”, “NetC”, children) dynamically become available. The result is an application that gets deployed to Datacenter A using Network B. Throw a storage selection option in there with the same Datacenter relationship rule and now you’ve got a fine balance of policy-based controls and a dynamic user-experience.
Sounds like a good use case to me! — my next post will provide detailed configuration steps for enabling this exact scenario. Stay tuned…