Most of the scenarios in this guide require access to the objects of the vRealize Automation services. This process is required so you can access and configure object properties or run operations on the objects.

You can access the vRealize Automation 8.x services through the REST API by using a REST Client, or through the vRealize Automation plug-in for vRealize Orchestrator.

The vRealize Automation REST APIs are documented in:

The vRealize Automation plug-in for vRealize Orchestrator 8.x is documented in Using VMware vRealize Orchestrator 8.x Plug-ins and the API Explorer built into the vRealize 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 vRealize 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 vRealize 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 vRealize Automation 8.1. However, the functionality is available in vRealize Automation 8.2. In the user interface, it was always available in vRealize Automation 8.1.
  • The response payload might be different as some properties might be missing.

The vRealize Automation 7.x user interface uses the public API fully and has more options to access service APIs, including software development kits (SDKs) for different languages. In vRealize Automation 7.x, 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 vRealize Orchestrator workflows. Custom forms leverage vRealize Orchestrator actions.

For many use cases in vRealize Automation 7.x, this vRealize Orchestrator based extensibility requires access to vRealize Automation to get further information from the payload passed from vRealize Automation to vRealize Orchestrator. The services also list vRealize Automation objects, so these objects can be used in extensibility. The most common approach to accessing vRealize Automation 7.x objects is from the vRealize Automation plug-in for vRealize Orchestrator. This plug-in can be accessed either from the built-in REST client or through plug-in objects.

The vRealize Automation 7.x plug-in provides:

  1. A way to persist and manage vRealize Automation orchestrated hosts with their credentials.
  2. The ability to pass host and credentials from a vRealize Automation user to the vRealize 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 vRealize Automation plug-in for vRealize Orchestrator (available in the marketplace for vRealize Automation 8.4 and built-in from vRealize Automation 8.5 and later) provides:

  1. A way to persist and manage vRealize Automation orchestrated hosts with their credentials.
  2. The ability to pass host and credentials from a vRealize Automation user to vRealize 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 vRealize 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 vRealize Automation 8.x.

Many of the workflows triggered by vRealize Automation 7.x leverage the vRealize Automation plug-in to access vRealize Automation services. The workflow elements making use of these plug-ins and those using the vRealize Automation 7.x REST API must be rewritten.

To identify the workflow elements that require a rewrite after migrating to vRealize Automation 8.x, please use the vRealize Automation Migration Assistant. The migration assistant is available from https://your_vRA_FQDN/migration-ui. For more information on migrating to vRealize Automation 8.x, see the vRealize Automation 8 Transition Guide.

Another way to identify workflow elements that require a rewrite is to import the extensibility workflows in vRealize 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 vRealize Orchestrator 8.x environment, you might want to avoid importing the vRealize Automation 7.x 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 vRealize Orchestrator 8.x server.