vRA 7 introduced a number of new and very useful features such as unified blueprints, software components, event broker, and others. The event broker however has proven itself to be one of the most power new features we have seen in some time. How so you ask? Well if you have been working with vRA for any period of time you will remember the old way of triggering external workflow executions such as those run by vRO. If you have been using vRA for a really long time you will remember back before vRO when vRA wasn’t even vRA and run nothing but .Net workflows, but we won’t go back that far.
Let’s look at vRA 6.x and how workflows were executed. vRA has what we refer to as a master workflow that defines the states at which all requests will go through. The workflow process was commonly demonstrated as Request, Approved, Provision, Manage, Retire, and Archive. If you worked with the product creating workflows you know that translates to Machine Requested, Building Machine, Machine Provisioned, Managed Machine, Machine Expired, and Machine Destroyed. These are the states you could execute workflows at in vRA 6.x and earlier. If you got familiar enough you were able to choose if you wanted to execute pre or post state as well as change priorities and a number of other items that were convoluted and required edited xml files.
To make things easier a vRO plugin was created that allowed you to easily run multiple workflows at each of these states and determine if they were to be run by the use of a custom property. You know what I’m talking about. The one where you had to plug the GUID in as the property value. This was great until you downloaded and installed vendor plugin like the Infoblox IPAM plugin and it completely overwrote the building macnine workflow stub and everything ended up breaking. Yes you know exactly what I’m talking about.
Fast forward to vRA 7 and the event broker
In vRA7 the event broker aims to bring more flexibility and simplicity to executing custom workflows and external integrations. How is that you ask? The event broker greatly simplifies the process of executing vRO workflows by allowing you to create what is called a subscription. Using the subscription you determine the events that trigger the workflow to run. The event could be a machine is powered on, or a machine is in the building machine state. In the vRA web UI you create theis subscription, select the vRO workflow that will be execute and that is it. No running a vRO workflow to install the workflow you want to run, no editing xml files none of that.
The event broker also opens up more states at which you can run workflows. You are no longer limited to running workflows at the 6 pre-defined stubs. This is a huge step forward. Imagine you want to run a specific workflow anytime a machine with “WIN” in it’s name is powered on. You don’t have to imagine anymore because it’s possible with the event broker. Imagine you want to run a workflows anytime a user in the “DEV” business groups provisions a machine, any machine. Imagine anytime NASA launches a space shuttle you can execute a workflow to make you a moon pie…..ok you caught me I was just making sure you were paying attention. The point is with the event broker you have the flexibility and options to make almost anything a reality.
I know what your thinking. This sounds great, how do I start using it? Well I’’ was going to write an article on how to use event broker, but it seems GAry Coburn at Extendingclouds.com beat me to it. So if you want to learn how to configure and use the event broker to go extendingclouds.com and read the great article Gary put together.