XaaS blueprints are vRealize Orchestrator workflows that can provision resources, make changes to provisioned resources, or behave as a service that performs a task in your environment. The blueprints and the resource actions have several nuances that you must understand when you design blueprints for your service catalog users.

The following definitions help you understand the terms used when working with XaaS blueprints.

Custom resource

A vRealize Orchestrator object type that is exposed as a resource through the API of a vRealize Orchestrator plug-in. You create a custom resource to define the output parameter of an XaaS provisioning blueprint and to define an input parameter of a resource action.

XaaS blueprint component

A provisioning or non-provisioning blueprint that you can use in the blueprint design canvas. This blueprint might also be a standalone XaaS blueprint.

Standalone XaaS blueprint

A provisioning or non-provisioning blueprint that is published and entitled directly to the service catalog.

Provisioning blueprint

A provisioning blueprint that runs a vRealize Orchestrator workflow to provision resources on the target endpoint using the vRealize Orchestrator plug-in API for the endpoint. For example, add virtual NICs to a network device in vSphere. To create a provisioning blueprint, you must have a custom resource that defines the vRealize Orchestrator resource type.

When a service catalog user requests this type of catalog items, the workflow provisions the item and the deployed item is stored on the Items tab. You can define post-provisioning operations for this type of provisioned resources. You can also make the blueprints scalable by adding or removing instance when needed.

Non-provisioning blueprint

A non-provisioning blueprint runs a vRealize Orchestrator workflow to perform a task that does not require the API to make changes to an endpoint. For example, the workflow that runs builds a report and then emails it or posts it to a target communication system.

When a service catalog user requests this type of catalog item, the workflow runs to perform the scripted task, but the item is not added on the Items tab. You cannot perform post-provisioning operations on this type of blueprint. You can use non-provisioning blueprints as supporting workflows in scalable blueprints. For example, you can create a blueprint to update a high availability load balancer.

Composite blueprint

A blueprint that was created using the design canvas. The composite blueprint uses one or more components. For example, a machine component, a software component, or an XaaS component. When you add it to a service, it is listed as a Deployment. When you add it to an entitlement to make it available to the service catalog users, it is listed as a Composite Blueprint. A composite blueprint can have one blueprint component, or it can include an entire application with multiple machines, software, and networking.

Resource action

A workflow that you can run on a deployed provisioning blueprint. The deployed blueprint can be an XaaS blueprint or blueprint component, or it can be a machine type that you mapped to a vRealize Orchestrator resource type.