You can manage vRealize Automation and vRealize Automation Cloud hosts by running the default workflows provided with the plug-in.
To access these workflows in the vRealize Orchestrator Client, navigate to , and enter the vra or vra-cloud tag in the workflow search box.
| Workflow | Description |
|---|---|
| Add vRA Host |
Adds a
vRealize Automation host to the plug-in inventory. See
Add a vRealize Automation host
Note:
If you use the plug-in in an embedded vRealize Orchestrator instance, a default host is created in the plug-in inventory. The logged-in user session is used to execute operations on the default host. When you perform operations on the default host from vRealize Automation Service Broker, the vRealize Orchestrator Gateway service token is used to execute the operation. |
| Add vRA Cloud Host | Adds a vRealize Automation Cloud host to the plug-in inventory. When running this workflow, you must select only a relevant region-specific cloud host. See Add a vRealize Automation Cloud host. |
| Update vRA Host Update vRA Cloud Host |
Updates a vRealize Automation or vRealize Automation Cloud host in the plug-in inventory. |
| Remove Host | Removes a vRealize Automation or vRealize Automation Cloud host from the plug-in inventory. |
| Validate Host | Validates the configuration of the vRealize Automation or vRealize Automation Cloud host. |
Multi-tenancy support
You can configure the vRealize Automation plug-in to work with your multi-tenant environment.
- For on-premises connections, you must add a dedicated vRealize Automation host for each tenant, using the tenant FQDN as the host name.
If you use the plug-in with a vRealize Orchestrator instance that is embedded in vRealize Automation, the default connection does not use a tenant-specific URL. Instead, it uses the default vRealize Automation host name.
- For cloud connections, the plug-in uses the API token to differentiate between the tenants.
Invoking REST operations on hosts
The vRealize Orchestrator plug-in for vRealize Automation supports generic REST operations on dynamically created hosts. You can run the default plug-in workflows to invoke any public vRealize Automation and vRealize Automation Cloud APIs.
| Workflow | Description |
|---|---|
| Get operation | Generic REST client support for HTTP GET operation. |
| Put operation | Generic REST client support for HTTP PUT operation. |
| Post operation | Generic REST client support for HTTP POST operation. |
| Patch operation | Generic REST client support for HTTP PATCH operation. |
| Delete operation | Generic REST client support for HTTP DELETE operation. |
Using the default vRealize Automation host in the plug-in inventory
If you use the default vRealize Automation host that is created in the plug-in inventory in an embedded vRealize Orchestrator instance, the logged-in user session is used by default to execute operations on the host.
In versions 8.10.1 and earlier, when you run operations on the default host from vRealize Automation Service Broker, the vRealize Orchestrator Gateway service token is used to execute the operation.
In versions 8.10.2 and later, the operations are run with the logged-in user token roles and permissions. If you want to keep the same behavior as in < 10.2, you can update the default host to use a Shared session with providing a user that has the same roles & permissions as the vRealize Orchestrator Gateway service user. If users need to keep the same behaviour they can create a new user and assign the required roles and permissions as vro-gateway user and start using “Shared Session".
For users who require their workflow/actions to use the roles and permissions of logged-in user, they can still use “Per User Session” to execute their vRA APIs.
