vRealize Automation provides pre-defined application and services life cycles operations which require customizing this life cycle via extensibility. This lifecycle extensibility is applied through the Event Broker Service (EBS).

vRealize Automation 8.x provisioning event topics are designed with a set of high level topics calling deployment resources topics. Event topics trigger when particular events occur in vRealize automation; examples are:

  • When a cloud template is deployed
  • When the resources in a deployment are allocated
  • During a life cycle state and entity change
  • When an approval policy is triggered
  • When Day-2 operations are requested

The following event topics are defined in vRA for the provision lifecycle phase (image taken from the official VMware documentation):

In this example we’re going to have a more detailed look on the lifecycle of a virtual machine during the provisioning.

vRA Event Broker Service 101

We can inject custom logic into the above mentioned predetermined stages of the virtual machine lifecycle by creating a runnable item, that can be custom vRO workflows or ABX actions.

One possibility of using vRO workflows and ABX actions for extensibility in Cloud Assembly is by creating a so-called event subscription. By configuring a subscription, we can instruct vRA to invoke a specific runnable item when a particular event topic triggers.

Each event topic sends a payload of information from the vRealize Automation Event Broker to the runnable item that you specify in your subscription. Typical information contained in the payload include:

  • the ID of the cloud template being deployed
  • the project that the end user belongs to
  • an array of the IP addresses that vRA is assigning to the vNICs of the deployed VM(s)
  • custom properties defined in the cloud template

The exact payload of an event topic is defined in its schema. Below is an example of the schema of the Compute allocation event topic:

The communication between vRA and the vRO workflow (or the ABX action) is bidirectional. vRA not only sends a payload to runnable item, the runnable item can also send a payload back to vRA.

Creating the vRO EBS subscription workflows

A good practice is to create a subscriber workflow for each event topic of the lifecycle with the same name.

In our example, dring a typical virtual machine provisioning the following lifecycle states will be used to accomplish specific tasks:

  1. Compute Allocation: set VM hostname
  2. Network Configure: request IP address from an IPAM system
  3. Compute Provision: determine VM folder in vCenter
  4. Compute Post Provision: run after the VM has been provisioned, e.g. perform guest OS customization tasks

To reflect this in our vRO workflow setup, we’ll create the following folder structure in vRO:

  • vRA
    • Subscriptions
      • Compute Allocation
      • Network Configure
      • Compute Provision
      • Compute Post Provision

We now put the EBS subscriber workflows for each of these vRA event topics into these folders.

As a best practice the following workflow design could be used:

We create two workflows, one being the “controller” which is responsible for general tasks, such as setting the deployment name, and calling a so-called “worker” workflow, which is setting its run name to the hostname of the deployed VM for better traceability. All subsequent workflows, which would do the actual work for each lifecycle phase are being done by the worker (either directly in the workflow or by calling other sub workflows).

The controller workflow looks as follows (example for compute allocation):

vRA passes data to vRealize Orchestrator in the form of a complex object known as inputProperties. We must bind the inputProperties input to a schema element in the vRO controller workflow to use it.

Note, that we set the variable __tokenName to inputProperties.externalIds[0] in the init scriptable task of the EBS network configure controller workflow instead of inputProperties.resourceNames[0].

The worker workflow looks as follows (example for compute allocation):

In this example the worker is executing a single scriptable task called out, which simply dumps the vRA playload, e.g.:

System.log("vRA event ID: " + System.getContext().getParameter("__metadata_eventTopicId"));

System.log("Parameters:");
var parameterNames = System.getContext().parameterNames();
for each (var parameter in parameterNames) {
	System.log("   " + parameter + " : " + System.getContext().getParameter(parameter));
}

System.log("inputProperties:");
System.log(JSON.stringify(inputProperties, null, 2));

You can download the workflow template along with the required actions from my Github repository.

Creating the subscriptions in Cloud Assembly

The event subscriptions are created in Cloud Assembly under Extensibility > Subscriptions. We will configure a subscription for each of the above noted lifecycle topics:

  • Each subscription subscribes to the referenced topic id
  • Each subscription has a condition define in our example, that it should be triggered for a specific cloud template (event.data.blueprintid)
  • Each subscription calls the specific vRO controller workflow for the given lifecycle topic
  • Each subscription is set to be blocking, which means the runnable item must complete before vRA will move on to the next event subscription

The subscription for the Compute allocation event topic looks as follows:

The other subscriptions must be configured accordingly, in the end we will have four subscriptions:

Deploying a virtual machine

To demonstrate the extensibility setup, we deploy a basic VM. Let’s say we have defined the following simple cloud template in Cloud Assembly:

The YAML code for this template is defined as follows (note that I’ve defined two Linux images, and a network profile with the tag net:vmw-production):

_formatVersion: 1
inputs:
  osFlavor:
    type: string
    title: OS flavor
    oneOf:
      - title: Ubuntu 20.04 LTS
        const: VMW-Ubuntu
      - title: Photon OS 4.0
        const: VMW-PhotonOS
    default: VMW-Ubuntu
  vCPU:
    type: integer
    title: Number of CPUs
    enum:
      - 1
      - 2
      - 4
    default: 1
  vRAM:
    type: integer
    title: Memory in MB
    enum:
      - 1024
      - 2048
      - 4096
    default: 1024
resources:
  Cloud_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      image: ${input.osFlavor}
      cpuCount: ${input.vCPU}
      totalMemoryMB: ${input.vRAM}
      folderName: vRA-Lab-VMs
      networks:
        - network: ${resource.Cloud_vSphere_Network_1.id}
          assignment: static
  Cloud_vSphere_Network_1:
    type: Cloud.Network
    properties:
      networkType: existing
      constraints:
        - tag: net:vmw-production

Now let’s deploy the VM with Ubuntu 20.04 LTS as the operating system:

After the successful deployment of a VM called VMW-ENG-000622, let’s check the triggered workflow runs for each event topic subscription in vRO:

And the following variables have been defined for the workflow run, in this example for the compute allocation subscription:

That’s all for now 🙂