7.4
Table Of Contents
- Foundations and Concepts
- Contents
- Foundations and Concepts
- Foundations and Concepts
- Using Scenarios
- Using the Goal Navigator
- Introducing vRealize Automation
- Tenancy and User Roles
- Service Catalog
- Infrastructure as a Service
- XaaS Blueprints and Resource Actions
- Common Components
- Life Cycle Extensibility
- vRealize Automation Extensibility Options
- Leveraging Existing and Future Infrastructure
- Configuring Business-Relevant Services
- Extending vRealize Automation with Event-Based Workflows
- Integrating with Third-Party Management Systems
- Adding New IT Services and Creating New Actions
- Calling vRealize Automation Services from External Applications
- Distributed Execution
- Foundations and Concepts
XaaS Blueprints
An XaaS blueprint is a complete specification of a resource.
With XaaS blueprints, you publish predefined and custom vRealize Orchestrator workflows as catalog
items for either requesting or provisioning. Blueprints for requesting run workflows with no provisioning
and provide no options for managing a provisioned item. Before you create a blueprint for provisioning,
you must map the workflow output parameter as a custom resource. Then you can assign resource
actions that define post-provisioning operations.
Resource Actions
You can create custom resource actions to configure the post-provisioning operations that the consumers
can perform.
To create post-provisioning operations, you must publish vRealize Orchestrator workflows as resource
actions. To create a resource action for an item provisioned by using XaaS, you use a custom resource
as an input parameter for the workflow. To create a resource action for an item that is provisioned by a
source different from XaaS, you use a resource mapping as an input parameter for the workflow. When
you entitle the resource actions, they appear in the Actions drop-down menu of the provisioned items on
the Items tab.
Common Components
vRealize Automation includes several common components in addition to the service catalog and catalog
item sources such as Infrastructure as a Service and XaaS.
Notiļ¬cations
You can send automatic notifications for several types of events, such as the successful completion of a
catalog request or a required approval.
System administrators can configure global email servers that process email notifications. Tenant
administrators can override the system default servers, or add their own servers if no global servers are
specified.
Tenant administrators select which events cause notifications to be sent to users in their tenants. Each
component, such as the service catalog or IaaS, can define events that can trigger notifications, but none
of them are selected by default.
Each user can choose whether to receive notifications. Users either receive all notifications configured by
the tenant administrator or no notifications, they do not have fine-grained control over which notifications
to receive.
Some emails have links that users can use to respond to the notification. For example, a notification
about a request that requires approval can have one link for approving the request and one for rejecting
it. When a user clicks one of the links, a new email opens with content that is automatically generated.
The user can send the email to complete the approval.
Foundations and Concepts
VMware, Inc. 39