There's been a ton of buzz around vRealize Automation 7's Event Broker since vRA7's release in December, with good reason. The Event Broker really takes vRA's extensibility capabilities to a whole new level. I though I would give you an overview of what the EB can do for you and the basics of how to use it.
The main purpose of the Event Broker is to run a vRealize Orchestrator workflow when a given event occurs. The enormous flexibility of the EB comes from the fact that you can select from a huge amount of events (or combination of events) to kick off the workflow of your choice. Also, the EB finally gives vRA a new (sort of) standard way of passing information to an Orchestrator workflow. Let's get started!
Event Topics
There are different "Event Topics" that you can chose from, you can see the list in the screenshot below, located in the green box. Each of these Event Topics has its own distinctive list of properties that will be given to Orchestrator as part of the payload. These properties are listed as part of the "Schema", take a look at the blue box in the screenshot. My guess is that most of the use you get out of Event Broker subscriptions will be for when you are requesting a Machine Provisioning blueprint. That seems to be where the most flexibility is and where I believe most of you will find the Event Broker's true value. For that reason, I'll mostly refer to this use case in this article.
So what's a payload?
The payload is the list of properties that vRealize Automation 7's Event Broker passes on to vRealize Orchestrator as Input when it kicks off a workflow. More specifically, you NEED to configure a parameter of type "Properties" as an INPUT parameter for your vRO workflow. You can either configure one parameter of that type and give it a general name like "payload", or you can configure your workflow to accept multiple "Properties" objects that match the exact name of one of those properties inside the payload. My personal preference is to just use one parameter called "payload", it keeps things simple and uniform across all the workflows that are called by the EB. Again, you can refer to the "Schema" of the properties that is shown when you are selecting your Event Topic. (See the blue box in the screenshot above)
To use the Event Broker's capabilities to the fullest, you're going to want to include some of your Custom Properties into the payload as well, because that doesn't happen by default. Luckily enough, that's pretty easy to do. You just need to specify which Custom Property you want included in the payload. You do that by applying ANOTHER Custom Property that specifies which Master Workflow will receive it. Confused yet? Here's an example to help you understand : Let's say I want to include a Custom Property called "SERVERTYPE" into a workflow that runs when the "VMPSMasterWorkflow32.Requested" Master Worfklow is done running, I would apply a Custom Property called "Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.Requested" and give it the value of "SERVERTYPE". It's that simple! Of course, to use this, you'll need to be familiar with what a Master Workflow is and for that, I encourage you to give the Lifecycle Extensibility Guide a quick read (Start at Page 33, "VMPS Master Workflow Life Cycle States"). Also, you can use the "*" symbol as a wildcard to include ALL the properties into the payload. If you want to add a hidden property to the payload, you can specify it by name, preceded with the double underscore prefix "__" (which is used to designate a hidden Property) or to include ALL hidden properties, you can use the double-underscore followed by a "*", like so : "__*". Finally if you want to go all out and include ALL hidden and non-hidden properties, use this : "*,__*". (You can use the comma to separate the properties)
Unconditional (Orchestrator) Love
Configuring the conditions for which your workflow will run is a pretty straightforward process. Depending on which Event Topic you selected at the previous screen, the choice of conditions will vary. The premise here is that you will want to attach your workflow to something, whether you tie it to one of the existing "Master Workflows" that runs every time a VM is provisioned, or to a very specific event, you'll need somewhere to anchor your workflow, so vRA knows when it needs to run it. One important thing you'll want to keep in mind is that every Master Workflow has 3 stages, PRE, EVENT and POST. With these stages, you can choose to configure your workflow to run BEFORE, DURING or AFTER a specified Master Workflow has/is executing. If you don't specify an Lifecycle Stage in your conditions, you can be sure that your workflow will be run THREE TIMES, one for each stage!
Here is an example of conditions I use to run one of my workflows, I'll give you the details below :
(I'm really not sure why the dropdown list fields are so small in the vRA GUI… but let's move on…)
Basically, what I'm doing here is telling vRA that I want to execute my workflow under these 3 conditions :
1. When the "VMPSMasterWorkflow32.Requested" Master Workflow is running.
2. At it's "POST" state, which means "right after it is done executing"
3. And when the Custom Property XYZ that I defined in my blueprint is set to true. P.S.: Being able to integrate Custom Properties at this level is AWESOME.
If you have questions about the different lifecycle stages, you can refer to the Lifecycle Extensibility Guide, which has some info about that. But you'll really need to experiment with these conditions to get familiar with them. Go ahead and get creative, this is where you can really see the versatility of the Event Broker.
Next, simply select a workflow…
So now that we know WHEN and WHICH workflow will run, let's determine HOW it will do it.
P.S.: Credit to DailyHypervisor.com for an awesone Custom Hostname Workflow.
To Block, or not to Block
The last thing you'll need to decide about your workflow subscription is if you want to make it "blocking". Doing so will make your workflow run in "Synchronous" mode, which means that it will prevent your provisioning task from moving on to the next lifecycle stage, until your workflow is done executing. This is a welcome addition and will be quite useful is some cases. One example I could give is if you're using a workflow to rename VMs, you definitely want to make the workflow "Blocking", otherwise, let's say your workflow takes too long to run, your machine could already be far enough along the provisioning process for it to be problematic to rename it without causing errors. If it's blocking, you'll ensure that nothing else is running in parallel to your workflow and vRA will wait for your VM to be renamed before moving on to the next step.
You can also specify a Timeout value and a Priority for each of the workflows you run (a lower number = higher priority). If you specify multiple workflows with the same priority, they will simply run in alphabetical order.
Here a screenshot of what it looks like when configuring that:
Event Broken?
There's nothing really broken about the Event Broker, I just felt the need to use that pun, it was too tempting. But if there was one thing on my wish list for the EB, it would be for VMware to make the documentation a little more detailed than it currently is. There is an existing Lifecycle Extensibility Guide available, but the info in that guide is very theoretical and won't get you up and running with the Event Broker right out of the gate.
Also, I find it a little annoying that there is still 2 different ways that vRA passes a payload to Orchestrator, there's the Event Broker method described in this article and there is still the "Resource Actions" that can use a specific type of object (VC:VirtualMachine, for example) and pass that to Orchestrator. I know the context of using a Resource Action (which is a Day 2 operation) is slightly different than using the Event Broker to call a workflow during a VM provisioning event, but can't we all get along and always use the same input parameters, no matter the context?
The Bottom Line
All in all, the Event Broker is a huge improvement in the way vRealize Automation organizes workflow executions. It allows you to visualize all the workflow subscriptions in one single view, which is a welcome change. With vRA7, you still have the option of using the old way of doing things, by using a vRO workflow to tie your custom workflow to a specific blueprint's provisioning lifecycle stage. But you REALLY don't want to be doing that anymore. The simplicity of the "payload" method makes it worth your while to adapt your existing workflows to the Event Broker's way of doing things.
The Event Broker is here to stay, so embrace it, you'll be glad you did!