Cloud Management Platform Cloud Automation Cloud Operations vRealize vRealize Automation

vRealize Orchestrator 8.3 Integration in vRealize Automation Cloud.

One of the most anticipated vRealize Automation Cloud feature has become available with the December 2020 update, I am referring to the newly released Cloud Extensibility Proxy (CEXP), which among other things:

Overall Improving the deployment / Integration / Capabilities experience and enabling you to execute complex workflows that could be consumed as part of the extensibility process and/or as Stand-Alone Workloads via the vRealize Orchestrator UI and/or Service Broker’s Catalog, all at the very same appliance or distributed as per your tag strategy.

Things to consider:

  • CEXP’s vRealize Orchestrator Code base is derived from vRealize Orchestrator 8 and you should regard this service slightly different to the “On-Prem” vRealize Orchestrator counterpart versions , in the sense that this  CEXP’s vRealize Orchestrator edition will be updated whenever a new version is available in VMware Cloud Services, in fact, you may access new features before the latest “On-Prem” version available (which it is common expectation for any SaaS Solution).
  • Integration of new SaaS-enabled vRealize Orchestrator 7.6 instances is no longer supported. Existing vRealize Orchestrator 7.6 SaaS integrations will continue to operate, but you cannot update the configuration of these integrations. To migrate these vRealize Orchestrator 7.6 SaaS integrations to your new CEXP’s vRealize Orchestrator integration, see documentation for [ Migrating a vRealize Orchestrator 7.6 SaaS instance to the cloud extensibility proxy ].
  • You cannot integrate standalone vRealize Orchestrator “On-Prem” instances in vRealize Automation Cloud.
  • You can use Project Constraints to manage where CEXP’s vRealize Orchestrator should execute your Workflows, in fact, you could create a sort of “HA of endpoints“, by simply setting the same constraints on them, and in the unlikely case that one CEXP’s vRealize Orchestrator enters a failure stage, the workflow calls are directed to the next CEXP’s vRealize Orchestrator sharing the same tag capabilities, note that the availability management is based on an internal algorithm in vRealize Orchestrator gateway at the vRealize Automation Cloud.
  • vRealize Orchestrator’s roles cannot be leveraged directly in vRealize Automation Cloud, this means you cannot select vRealize Orchestrator’s roles : Administrator, Workflow Developer or Viewer. There is however a mapping for Cloud Services and vRealize Orchestrator’s roles which it is described in detail at the documentation, essentially user roles in the vRealize Orchestrator  integration are based on Cloud Assembly service roles, for a user to have administrator rights in the vRealize Orchestrator  integration, they need the Cloud Assembly Administrator role, for a user to have workflow developer rights in the vRealize Orchestrator integration, the need the vRealize Orchestrator User role. (see what I meant some lines before about small differences between editions).

Let me show you further:


If you have previously integrated vRealize Orchestrator in vRealize Automation Cloud then you remember that before creating your integration, you had to download and install the On-Prem SaaS-Enabled Orchestrator then you needed to have a Cloud Proxy also pre-deployed and available to reach out that vRealize Orchestrator, and yes, don’t forget that valid login credentials were required…

So here the good news, now all it takes to enable the New Cloud Extensibility Proxy, it is merely just deploying the Cloud Extensibility Proxy (CEXP) OVA (you got the option to pull it directly from its public S3 Bucket ) in any vSphere Endpoint (On-Prem or VMC based) at your disposal, feed the standard IP data, similarly to the standard Cloud Proxy, and let the appliance to initialize itself.

Please note that it may take some time to initialize the first time, but consider all the steps that are happening under the hood, such as, deploy vRealize Orchestrator services and Agents, configure itself for the CSP, trigger workflow collection among other things which are automated for you, then, once this is complete, you just provide the “vRealize Orchestrator URL” you assigned to appliance, and don’t forget to set up your capabilities tags (remember you can steer workflows traffic based on that and well it is a good practice anyway, even if you deploy a single node in your environment) , validate and off you go:

What about Action Based Extensibility (ABX) ? well that’s also very simple, just add a New Extensibility Actions On Prem Integration then select the very same Cloud Extensibility Proxy we previously deployed as part of the vRealize Orchestrator integration:

And that’s it, you now could see, under extensibility’s Library Workflow, the pre-packaged vRealize Orchestrator’s Workflows and Actions (note the Integration value at each Workflow, it indicates which CEXP’s vRealize Orchestrator the workflow is available from, in this case our vRO-CEXP-02.

At this point, you could start using these extensibility integrations from within vRealize Automation Cloud, and importing your own vRealize Orchestrator’s Workflow/Action Packages or install your plug-ins (all 8.x versions based, of course).

And about these last two topics, how do I do that? well, simply launch the same “vRealize Orchestrator URL” you defined during the integration in your browser, and yes, you won’t be prompted for credentials since you are already authenticated by VMware Cloud Service Platform (CSP) and from there you could access:

  • The Control Center: https://[ vRealize Orchestrator URL ]/vco-controlcenter/config 
  • The Orchestrator Client:  https://[ vRealize Orchestrator URL ]/orchestration-ui

Additionally you could start building Custom Resources and Resource Actions in vRealize Automation Cloud. and working with any other featured backed by vRealize Orchestrator.

As a matter of fact, let’s test a simple extensibility use case, combining vRealize Orchestrator and Action Based Extensibility (ABX), for that I created a couple of “Subscriptions“, both at the “Compute Allocation Event” that will call a vRealize Orchestrator‘s Workflow (a Polyglot one: Python, PowerShell and NodeJs) and a Action Based Extensibility (ABX)‘s NodeJs Action.

When I deploy my workload, the extensibility for ABX is executed first (I set a higher priority):

Then I see my vRealize Orchestrator Polyglot Workflow being executed:

Please note, at both cases, the same endpoint, CEXP-02 ,is selected, as well as the appropriate Extensibility Runtime Engines and that the Polyglot Workflow (which support is only available in vRealize Orchestrator 8.1 and greater) is executed as instructed.

Now as a bonus:

With the release of this CEXP’s vRealize Orchestrator edition, there’s a new feature that allows you to discover any content usage and dependencies.

Simply put, you will be able to find where a workflow/action/resource/configuration content is used within vRealize Orchestrator.

As an example, I am curios to know where the “removeOldestSnapshotOfVM” Action is being used and/or their dependencies, all I need to do is, search for the Action then I will have access to “Find Usages” & “Find Dependencies” options.

that will give me the details I am looking for

Find Usages:

Find Dependencies:


With the introduction of this awaited capability, we can now take full advantage of the latest exciting vRealize Orchestrator 8.3 version features (and more), making vRealize Automation Cloud’s Extensibility robuster whilst simplifying its integration and operation.

More Resources:

Announcing VMware vRealize Orchestrator 8.1

vRA Action placement

Extending vRealize Automation Custom Forms with vRealize Orchestrator

vRealize Automation ABX Flows

Self-Service Hybrid Cloud – Part 2 – Using vRealize Automation ABX to make API calls to VMware Cloud on AWS


Leave a Reply

Your email address will not be published. Required fields are marked *