Using Custom Resources
One of the primary features of using XaaS in VMware Aria 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 Automation Orchestrator workflow from VMware Aria 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 theItemstab (for versions earlier than vRealize Automation 7.6) orDeploymentstab (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 VMware Aria Automation 8.x, custom resources offer similar capabilities in comparison to vRealize Automation 7.x. A custom resource in VMware Aria Automation 8.x has the following mandatory requirements:
- You must have a provisioning workflow that must output an Automation Orchestrator plug-in type that matches the type defined in the custom resource
- You must have a decommission workflow.
VMware Aria Automation 8.x custom resources allow you to use a specific Automation 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.
VMware Aria 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 Automation Orchestrator action parameters in the request form.
A core difference is that the availability of the resource action in VMware Aria 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.