7.0

It can also be beneficial to expose entirely new services in the service catalog, so that users can
automate other initiatives directly via the portal. Service architects can create XaaS blueprints for storage-
as-a-service, networking services or virtually any kind of IT service by using XaaS.
For details about how to create new catalog items, see Configuring vRealize Automation.
Calling vRealize Automation Services from External Applications
In some cases, organizations may want to interact with vRealize Automation programmatically rather than
via the vRealize Automation console.
For such scenarios, the vRealize Automation API provides a standardized, secured RESTful interface for
cloud access and interaction, controlled through business-aware policy for consumers such as users,
infrastructure, devices, and applications.
All blueprints, including the ones created via the XaaS, are automatically exposed through the
vRealize Automation API. For more details, see the REST API Reference.
Distributed Execution
All core vRealize Automation workflows are executed in a distributed execution environment.
The vRealize Automation runtime environment consists of one or more DEM Worker instances that can
execute any workflow installed in the core engine. Additional Worker instances can be added as needed
for scalability, availability and distribution.
Skills can be used to associate DEMs and workflows, restricting execution of a given workflow to a
particular DEM or set of DEMs with matching skills. Any number and combination of skills can be
associated with a given workflow or DEM. For example, workflow execution can be restricted to a specific
datacenter, or to environments that support a specific API the workflow requires. The vRealize
Automation Designer and the CloudUtil command-line tool provide facilities for mapping skills to DEMs
and workflows.
For more information about distributed execution and working with skills, see Life Cycle Extensibility.
Foundations and Concepts
VMware, Inc. 38