A key functionality of vRealize Automation is requesting catalog items.

A common scenario seen in vRealize Automation 7.x includes an XaaS catalog item requesting a composite blueprint. While it is still possible to request a catalog item with the API service, this scenario focuses on achieving the same result through customizing the request at runtime using custom forms with dynamic selection of tags.

In vRealize Automation 8.x, form constructs are standardized around the vRealize Automation custom forms designer. Given the change in vRealize Automation APIs with 8.x, this is a good opportunity to remove previous technical debt as you transition and also standardize cloud template deployment by using custom forms.

The below table summarizes some of the common patterns used for placement selection to contrast the options and changes now available in vRealize Automation 8.x.

vRA 7.x - placement (custom logic) vRA 8.x – placement (standardized on tags)
  • XaaS, custom forms, or IaaS forms
    • API - Compute population of reservation policy name and ID selection in code.
    • API - Network – Based on naming conventions and reservations population of applicable network profiles.
    • API -Storage – Storage reservation population through code.
  • Custom forms with tag based inputs
    • API - Dynamic Tag selection based on keys and filters
    • Alternatively. using Event Broker read or write properties.

In vRealize automation 8.x, placement logic is standardized by using tags, resources are tagged with capabilities and constraints are applied to a cloud template for the placement engine to select the relevant downstream resources.