In vRealize Automation 7 a new concept was introduced called a “Subscription.” A subscription is a way to allow you to execute a vRealize Orchestrator workflow based on some sort of event that has taken place in vRA. Simple idea huh? Well some of you might be thinking to yourself, “Yeah, this is called a stub, Duh!” The truth is that stubs are still available in vRealize Automation 7 but are clearly being phased out and we should stop using them soon because they are likely to not be around in future versions. The idea of an event subscription is a lot like a stub when in the context of machine provisioning, but there are a lot more events that can be triggered than the stubs that have been around in previous versions. Let’s take a look.

To being we will go to the Administration Tab –> Events –> Subscriptions. Here we can add a new subscription by click the “New” button with the plus sign.

The first screen that shows up is the “Event Topic” screen. An event topic describes the type of event that we’re going to watch for. You can see that we can trigger an action from a variety of different types of events. It’s important to note that the machine provisioning events are similar to stubs, but the other events would be new concepts and can be triggered by vRA reconfigurations like changing a blueprint.  Maybe you trigger an email from vRO every time a business group is changed or something. For the purposes of this post, I’m using the “Machine Provisioning” event which would be very similar to a “Stub.” If you’d like to see what the other Event Topics are for, please check the official VMware vRealize Automation Documentation for Event Topics.

Once you’ve selected an Event Topic, you’ll notice that the schema will be displayed on the right hand side of the screen. This explains the data that will be passed to vRealize Orchestrator during the event. Once you’ve selected an Event Topic, click Next.

Now we get to the conditions tab. By default, the “Run for all events” option is selected. I encourage you to leave this alone and run it one time with some really basic “Hello World” type workflow just to see what it does but in the rest of this post we’re going to set some specific conditions.

Change the radio option to “Run based on conditions” and then choose “All of the following.” This will allow us to enter a list of conditions and every one of them must be met before the action is triggered.

Next click the drop down and select “Lifecycle state name”.

In the next box choose “Equals”.

And in the last box leave the radio button on “Constant” and the select the “VMPSMasterWorkflow32.BuildingMachine.” This building machine lifecycle state should be familiar because its the same name as a stub in vRealize Automation 6 but if you’re new to this, it just means that this is the stage of the provisioning lifecycle where the machine is actually being built.

To recap what we’ve done in the past few steps, we said we only want our workflow to trigger when the lifecycle state = WMPSMasterWorkflow32.BuildingMachine.

We’re not finished yet, we’re going to add one more condition here. Click the “Add expression” link to add another condition.

This time select “state phase” and then “equals”.

Then in the last dropdown leave the radio button on “Constant” and select “Event”.

Ok, so what is a state phase? Well, in version 7 of vRealize Automation, we don’t have just one “Building Machine” option, but rather three! A pre-building machine, a post-building machine and the actual building machine event. If you didn’t specify the state phase and you build a new virtual machine from a blueprint, the “Building Machine” event subscription would trigger 3 times! One for each phase.

If you need to know more information about the lifecycle states, please check out the official VMware vRealize Automation Documentation on lifecycle states.

Once we’ve added all of our conditions, click next to go to the “Workflow” tab. Select the vRealize Orchestrator workflow that you want to run when the event occurs. Then click Next.

On the details tab, enter a name for the subscription, and a description.

There is also an option for blocking, which means that workflows have to wait on this workflow to finish before running. If you don’t click the “blocking” checkbox then any other subscriptions may run simultaneously. To determine what order blocking tasks run in, you will then have to enter a priority. You’ll also be able to put in a timeout period to move on to the next workflow if your first one seems to have taken too long to execute.

Once you’ve finished setting up your event, be sure to click on the subscription in the list and then click “Publish.” I always forget to do this piece. 🙂

Summary

Subscription events should be a pretty quick concept to grasp if you’re familiar with stub workflows in previous versions. They can be very powerful and there are many more opportunities to jump out of vRA and execute a task via Orchestrator now and that is a very good thing. More options are better but we need to take a few minutes to learn the new lifecycle states and phases before we can use them effectively.