Accessing VMware Aria Automation Objects and Properties

Most of the scenarios in this guide require access to the objects of the VMware Aria Automation services. This process is required so you can access and configure object properties or run operations on the objects.
You can access the
VMware Aria Automation
8.x services through the REST API by using a REST Client, or through the
VMware Aria Automation
plug-in for
Automation Orchestrator
.
The
VMware Aria Automation
REST APIs are documented in:
The
VMware Aria Automation
plug-in for
Automation Orchestrator
8.x is documented in
Using VMware
Automation Orchestrator
8.x Plug-ins
and the API Explorer built into the
Automation Orchestrator
Client.
Different services can have different API behavior such as:
  • The Infrastructure as a Service (IaaS) service has a different query service syntax and paging syntax from the other services.
  • The IaaS service returns a payload of the object created on POST. Other services returns the object ID in the location header.
You can enable the developer view to capture calls to the VMware Aria Automation services to receive more information about:
  • Operations (GET, PUT, POST, PATCH, DELETE)
  • Base URL (/service/api/resource)
  • Parameters (paging, sorting, queries)
  • Request payload (The JSON information passed to create / update objects)
  • Response payload (The JSON information returned to describe the object and their properties)
However, there are some considerations and differences regarding the
VMware Aria Automation
API services:
  • The user interface uses some proprietary service endpoints. These are not documented or supported and might be changed or become inaccessible outside the user interface in following product releases without notice.
  • The enabled operations are different. For example, it is not possible to update machine custom properties in
    VMware Aria Automation
    8.1. However, the functionality is available in
    VMware Aria Automation
    8.2. In the user interface, it was always available in
    VMware Aria Automation
    8.1.
  • The response payload might be different as some properties might be missing.
The
VMware Aria Automation
user interface uses the public API fully and has more options to access service APIs, including software development kits (SDKs) for different languages. In
VMware Aria Automation
, all extensibility functions include Event Broker subscriptions, Anything as a Service (XaaS) cloud templates, custom resources, and resource actions. XaaS cloud template components, such as custom resources, leverage
Automation Orchestrator
workflows. Custom forms leverage
Automation Orchestrator
actions.
For many use cases in
VMware Aria Automation
, this
Automation Orchestrator
based extensibility requires access to
VMware Aria Automation
to get further information from the payload passed from
VMware Aria Automation
to
Automation Orchestrator
. The services also list
VMware Aria Automation
objects, so these objects can be used in extensibility. The most common approach to accessing
VMware Aria Automation
objects is from the
VMware Aria Automation
plug-in for
Automation Orchestrator
. This plug-in can be accessed either from the built-in REST client or through plug-in objects.
The
VMware Aria Automation
plug-in provides:
  1. A way to persist and manage
    VMware Aria Automation
    orchestrated hosts with their credentials.
  2. The ability to pass host and credentials from a
    VMware Aria Automation
    user to the
    VMware Aria Automation
    plug-in to make API queries as this user.
  3. An inventory of 92 objects allowing users to select objects by their name or properties in drop-down menus or tree-view.
  4. Over 800 JavaScript scripting objects and their documentation (API explorer).
  5. Hundreds of library actions and workflows supporting common operations.
The updated
VMware Aria Automation
plug-in for
Automation Orchestrator
(available in the marketplace for
VMware Aria Automation
8.4 and built-in from
VMware Aria Automation
8.5 and later) provides:
  1. A way to persist and manage
    VMware Aria Automation
    orchestrated hosts with their credentials.
  2. The ability to pass host and credentials from a
    VMware Aria Automation
    user to
    VMware Aria Automation
    plug-in to make API queries as this user.
  3. An inventory of 11 objects allowing users to select objects by their name or properties in drop-down menus or tree-view. These objects automatically manage
    VMware Aria Automation
    API paging capabilities.
  4. Over 40 JavaScript scripting objects and their documentation available in the API Explorer.
  5. Close to a hundred library actions and workflows supporting common operations.
This section of the guide discusses the implementation of the above use cases in
VMware Aria Automation
8.x.
Many of the workflows triggered by
VMware Aria Automation
leverage the
VMware Aria Automation
plug-in to access
VMware Aria Automation
services. The workflow elements making use of these plug-ins and those using the
VMware Aria Automation
REST API must be rewritten.
To identify the workflow elements that require a rewrite after migrating to
VMware Aria Automation
8.x, please use the VMware Aria Automation Migration Assistant. The migration assistant is available from https://
your_vRA_FQDN
/migration-ui. For more information on migrating to
VMware Aria Automation
8.x, see the
VMware Aria Automation
8 Transition Guide
.
Another way to identify workflow elements that require a rewrite is to import the extensibility workflows in
VMware Aria Automation
8.x and use the workflow validation tool which identifies errors in each workflow item. Additionally, when importing content from a vRealize Orchestrator 7.6 environment to a
Automation Orchestrator
8.x environment, you might want to avoid importing the
VMware Aria Automation
plug-in library workflows. These workflows are in a read-only state and after importing them, you will be unable to delete them from the
Automation Orchestrator
8.x server.