Intro

Aria Automation 8.x (or vRA) is an all-rounder when it comes to Hybrid Cloud Automation and at the same time, Aria Automation Orchestrator (or vRO) is a powerful automation engine which works in harmony with Aria Automation or can be used as a Standalone system with other VMware products like vSphere, Cloud Director, etc.

Both these tools share a common name and obviously, when used with Aria Automation, Aria Automation Orchestrator acts as a subsystem to it which stretches the capabilities of vRA at many different levels. In this post, I will be covering how Orchestrator adds value to the Aria Automation and how you can better use it.

I have figured out that Orchestrator can be utilized in following areas:

• Resource based Custom Actions (Day-2 operations)
• Deployment based Custom Actions
• WBX (Extensibility via Orchestrator WFs)
• Dynamic Enums
• Service Broker form extensibility
• Custom Datatypes & Dynamic Datatypes
• XaaS (Anything as a Service)
• Automation Pipelines Workflows

Resource based Custom Actions (Day-2 operations)

In addition to the Day-2 actions that are already available for Resource Types within Aria Automation, you can configure custom Day-2 actions that make changes to your deployed resources. These custom day-2 actions are referred to in Aria Automation as Resource Actions.

You can utilize Orchestrator workflows as a custom Day-2 Operation to the resources that you have just provisioned using Service Broker. Here you can see an example of custom action change VM CPU and RAM.

To add a new action, simply go to Assembler -> Design -> Resource Actions and provide action related details like Name, Description, Resource Type, Orchestrator Workflow etc. and map the inputs.

Learn more about it here.

Deployment based Custom Actions

After you deploy a cloud template, you can run day 2 actions that can perform operations on the deployment. Automation Assembler includes many day 2 actions, but you might want to provide others. You can create custom deployment actions and make them available to users as day 2 actions. The availability of these actions will depend on the type of resource is in picture.

The process is exactly the same as it is for Resource based custom actions. Learn more about it here.

WBX (Extensibility via Orchestrator WFs)

What is Extensibility subscription?

A Subscription indicates that a subscriber is interested in being notified about an event by subscribing to an event topic and defining the criteria that triggers the notification. Extensibility subscriptions allow you to extend Aria Automation by triggering ABX extensibility actions or vRealize Orchestrator Workflows at specific life-cycle events also known as Event Topics .Using Orchestrator Workflows has 1 main advantage, the ability to write code in native JavaScript.

To add a new subscription, simply go to Assembler -> Extensibility -> Subscriptions and provide action related details like Name, Event Topic, condition, Orchestrator Workflow etc.

How does workflow get aware of the new data coming from Aria Automation?

Orchestrator workflows that are used for extensibility event subscriptions require a workflow input titled inputProperties of type Properties. Whenever the workflow is executed from Aria Automation, it will populate this particular input with all the properties provided by the Event Topic selected in your Subscription. The properties that are provided can be seen by expanding the “Schema” of the event as shown:

Learn more about creating your first Orchestrator Extensibility WF here.

Dynamic Enums

Dynamic Enumeration is simply the population of Aria Automation Template input using an Orchestrator Action.

Create a new input and select external source and select Orchestrator action and bind it.

it will be shown automatically in the template as $dynamicEnum.

formatVersion: 1
inputs:
  vroAction:
    type: string
    $dynamicEnum: /data/vro-actions/com.form.service.test/returnSimpleAction

Learn more about it here.

Service Broker form extensibility

Inside the Custom form Designer in Service broker, when working with a request form, you can base the behavior of some fields on the results of a Orchestrator action which provides capability to process data at a level before the actual execution of the deployment.

Note Do not confuse it with Dynamic Enums. Both of them works at input level but Dynamic Enums is for Aria Automation Templates and this works on Aria Automation Service Broker and provides much more flexibility than the former.

To add a external source to a form input, go to Service Broker, open a template custom form and select a field and Click Values and select source to be external source where you can pick an action which is compatible with input type that you’ve selected.

Learn more about it here.

Custom Datatypes & Dynamic Datatypes

When you create a cloud template in Assembler, the resource type palette includes resource types for the supported cloud account and integration endpoints. You might have use cases where you want to create cloud templates based on an expanded list of resource types. You can create custom resource types, add them to the design canvas, and create cloud templates that support your design and deployment needs. By doing so, you can also manage the lifecycle of any object type inside Aria Automation by defining “Create“, “Destroy“, “Update” & Read” operations. The possibilities are limitless, you can create SSH Host, AD User, Tanzu Objects and what not.

Custom Dataypes

Each vRealize Orchestrator custom resource is based on a SDK inventory type and is created by a vRealize Orchestrator workflow that has an output which is an instance of your desired SDK type. Primitive types, such as Properties, Date, string, and number are not supported for the creation of custom resource types.

The resource type of a custom resource must begin with Custom. and each resource type must be unique. For example, you might set Custom.ADUser as a resource type for a custom resource that adds Active Directory users. Although the inclusion of Custom. is not validated in the text box, the string is automatically added if you remove it.

Dynamic Dataypes

There is a small difference in Dynamic Dataypes from Custom Datatypes which is that they are based on Orchestrator’s Dynamic Types Plug-In. When creating custom workflows that use the dynamic type plug-in, verify that their variables are defined by using the DynamicTypesManager.getObject() method. The resource type of a dynamic resource must begin with DynamicTypes.

ProTip You can also use ABX to define custom datatypes. https://blogs.vmware.com/management/2021/09/cr-abx.html

Learn how to create a AWS Dynamic Datatype and utilize it in the Cloud Assembly template here.

XaaS (Anything as a Service)

Using Service Broker, we cater a set of Catalog items to our customers to avail the services that we provide.It includes Assembler Published Templates, Pipelines, as well as Orchestrator Workflows. You can use the built-in workflows in vRealize Orchestrator, or you can create your own. Using vRealize Orchestrator to create anything-as-a-service/XaaS workflows means that you can create a cloud template that adds an Active Directory user to machines at deployment time, or add a custom F5 load balancer to a deployment etc.

To setup XaaS items, make sure you have the Orchestrator integrated with Aria Automation and then go to Content and Policies > Content Sources. -> Content and Policies -> Content Sources and click New and click Orchestrator Workflow and import it.

Learn more about it here.

Workflows inside Automation Pipelines

Automation Pipelines can integrate with Aria Automation Orchestrator (Orchestrator) to extend its capability by running Orchestrator workflows. VMware Aria Automation Orchestrator includes many predefined workflows that can integrate with third-party tools. These Using Automation Pipelines workflows help to automate and manage your DevOps processes, automate bulk operations, and
more.
For example, you can use a workflow in an Orchestrator task in your pipeline to enable a user, remove a user, move VMs, integrate with test frameworks to test your code as the pipeline runs, and much more.
With a VMware Aria Automation Orchestrator workflow, your pipeline can run an action as it builds, tests, and deploys your application. You can include predefined workflows in your pipeline, or you can create and use custom workflows. Each workflow includes inputs, tasks, and outputs.
To run an Orchestrator workflow in your pipeline, the workflow must appear in the list of available workflows in the Orchestrator task that you include in your pipeline.
Before the workflow can appear in the Orchestrator task in your pipeline, an administrator must perform the following steps in VMware Aria Automation Orchestrator:

• Apply the PIPELINES tag to the Orchestrator workflow.
• Mark the Orchestrator workflow as global.

Learn more about the integration steps here.