One of the primary features of using XaaS in vRealize Automation is using custom resources.

In vRealize Automation 7.x, it is possible to create an XaaS service blueprint. The service blueprint can be used to define and use a vRealize Orchestrator workflow from vRealize Automation. The service blueprint can be published in the catalog service and entitled, and it can be used in the blueprint design canvas. In both cases, it can provision a custom resource as an option. This resource can:

  • Appear in the Items tab (for versions earlier than vRealize Automation 7.6) or Deployments tab (for vRealize Automation 7.6) when request from the catalog.
  • Appear as one of the components of the deployment when requested as part of a composite blueprint.

Provisioning a custom resource allows you to track the custom resource and its realtime properties from the user interface. It also enables you to perform day 2 operations known as resource actions.

In vRealize Automation 7.x resource actions can run a workflow in context of a custom resource for:

  • Delete operations (Using a disposal option)
  • Update operations (No option)
  • Copy operations (Using a provisioning option)
  • Move or stage operations (Using a provisioning & disposal option)

In vRealize Automation 8.x, custom resources offer similar capabilities in comparison to vRealize Automation 7.x. A custom resource in vRealize Automation 8.x has the following mandatory requirements:

  • You must have a provisioning workflow that must output an vRealize Orchestrator plug-in type that matches the type defined in the custom resource
  • You must have a decommission workflow.

vRealize Automation 8.x custom resources allow you to use a specific vRealize Orchestrator type once per project or having it shared with all projects once. It is not possible, for example, to use different provisioning workflows outputting the same custom resource type.

vRealize Automation 8.x resource actions have the following differences with vRealize Automation 7.x:

  • Provisioning and decommissioning options.
  • No capability to bind custom resources to vRealize Orchestrator action parameters in the request form.

A core difference is that the availability of the resource action in vRealize Automation 8.x can be defined programmatically based on the resource properties. For example some actions might not be available if the state of the element is "OFF". The equivalent feature in vRealize Automation 7.x has less options because it is user interface based.