Step by Step, define vCenter customization spec with vRealize Automation 7.x Event Broker

The Event Broker is a great new feature in vRealize Automation 7.x. In this post we’ll show you, step by step, how to define which vCenter customization specification must be applied to a Virtual Machine based on specific conditions.

This article covers:

• How to create an event-broker subscription
• Set conditions to the subscription
• Set a condition based on a custom property
• Show payload info in vRealize Orchestrator
• Get data from payload
• Get tenant name from environment variable
• Update a Virtual Machine custom property

Scenario

We have several Customization Specs defined in vCenter (don’t ask me why) that must be applied to some Virtual Machines depending on information from a Custom Property and the Tenant name.

Create the Workflow in vRealize Orchestrator

The subscription will execute a vRealize Orchestrator Workflow so we must to create it first. Lets start with a very simple version and then we will add more attributes later.

Create a new Workflows called “Set Customization Spec” with only one “Input Parameter” called “payload” with type “Properties“. The name of the parameter is very important, otherwise this wont work.

Go to the “Schema” tab, add a “Script Task” and name it “payload info” and set the payload as an Input Parameter of the script. To show the information from the payload, add the following code to the script:

function printProperties(props, depth) {
   depth = (depth)?depth:0;
   var indent = Array(depth*5).join(".");

  for each (var p in props.keys) {
    var propValue = props.get(p);
    if (System.getObjectType(propValue)=='Properties') {
      System.log(indent + p);
      printProperties(propValue, depth+1);
    } else {
      System.log(indent + p + ': ' + propValue);
    }
   }
}

printProperties(payload);

Creating the subscription

1. In vRealize Automation, go to Administration tab -> Events -> Subscriptions and create a new subscription.
   In “event topic” select “Machine Provisioning”. The schema on the right side of the screen represents the data that the “payload” could have. Click next.
2. In “Conditions” tab let the option “Run for all events” selected for now. Click next.
3. On “Details” tab set the name of the subscription and check “Blocking” option. This is very important. If a subscription is “non blocking”, vRealize Automation will call the workflow in an async way and moves on. The rest of the process will not be affected by the result of the workflow. If a subscription is “blocking”, vRealize Automation will wait until the workflow finishes his execution. Then vRA will search for the output of the workflow to modify the Virtual Machine Entity.  This option cannot be edited once the subscription is created.
   Once you check the “Blocking” option you can set the time out. Put this option in 1 minute (or what you think is needed for the workflow to complete the execution). Click finish.
4. Publish the subscription

Test the subscription

Deploy a Virtual Machine blueprint to see the workflow execution. If everything is OK, you will see a lot of executions, one for each event in the “Machine Provisioning” process.

If we check the execution log tab, we’ll see something like this:

Notice that there is no much data in the payload. This is because vRealize Automation doesn’t send all available information unless we explicitly ask for it.

Each event has a state (name of the event) and a phase (PRE, EVENT, POST). We need to decide in which state and phase we want to execute our workflow to set the name of the Customization Spec.

In this case we choose the state “VMPSMasterWorkflow32.BuildingMachine” and phase “PRE” so we need to tell vRA to send all information for that state. To do this, we need to add a Custom Property to the blueprint with name “Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.BuildingMachine” and value “*“.

Deploy the Virtual Machine again and you will notice that in the workflow run corresponding to “VMPSMasterWorkflow32.BuildingMachine” there is much more information than in the others. We can see the Virtual Machine custom properties now.

Define a custom property with the needed info

At the beginning of this article we said that we will use a value in a Custom Property to define the Customization Spec name. We need to add that Custom Property in the VM component of the blueprint. Lets call the property “mycompany.vm.customspec.info” and the value could be something like “some value“.

Establish subscription conditions

Go to Administration tab -> Events -> Subscriptions, edit your subscription and in the Conditions tab, select “Run based on conditions”.

We have four conditions so, in “Clause” select “All of the following”. This means that all the following conditions must be accomplished to run the workflow.

In the new “Clause”, select Data/Lifecycle state/Lifecycle state name, Equals, “VMPSMasterWorkflow32.BuildingMachine“.

Click on “Add Expression”, Clause = Data/Lifecycle state/Lifecycle state/State phase, Equals, PRE.

Click on “Add Expression”, Clause = Data/Machine/Machine type, Equals, “Virtual Machine“.

Click on “Add Expression”. In the Clause dropdown, just below “Not the following” there is a text box. In this textbox write exactly the following: ${data~machine~properties~mycompany.vm.customspec.info} and click on the green button. Notice that the first part (data~machine~properties~) points to custom properties, and the last part (mycompany.vm.customspec.info) is the name of our custom property. If you change the name of the custom property, you need to change only the last part. Select “Does not equal” and let the last box emtpy. This means that in order to this subscription to be fired, the blueprint must have this custom property with a non empty value.

Click finish

Test our subscription again

Deploy the Virtual Machine one more time. Hopefully, the workflow is executed only once now. If we check the execution log tab, we’ll see something like this:

We can see our custom property there!

If we look at the Variables tab we will see more information, we are interested on the tenant name:

Defining the Customization Spec name

In order to get the information we’ve stored in the custom property and the tenant name, we add a new Script Task, set payload as an input parameter and two output parameters: “customspecInfo” and “tenantName” both of type String.

The code is the following:

customspecInfo = payload.get("machine").get("properties").get("mycompany.vm.customspec.info");
tenantName = System.getContext().getParameter("__asd_tenantRef");

Add a new custom script to define the customization spec name. I’m not iterested in this code right now, but let’s say that has an output parameter called “CustomSpecName” of type String.

Sending data back to vRealize Automation

When a subsription is set to “Blocking”, vRA looks for an output parameter called “virtualMachineAddOrUpdateProperties” of type “Properties“. Any property in this parameter will be used by vRealize Automation to update the Virtual Machine entity. Go to the Output tab of the Workflow and add that output parameter

Go back to the Schema tab and add a new Custom Script, set “CustomSpecName” as input parameter and “virtualMachineAddOrUpdateProperties” as an output parameter. Put the following code on it:

var MyProperties = new Properties();
MyProperties.put('CloneSpec', CustomSpecName);
virtualMachineAddOrUpdateProperties = MyProperties;

Final test

Deploy the Virtual Machine one last time. The Customization Specification must be applied to the Virtual Machine.

Let us know if you have any comment or question about vRealize Automation 7.x event-broker.