Wednesday, February 03, 2016

vRealie Automation 7 extensibility though vRealize Orchestrator using Event Broker Service (EBS)

Yesterday evening I sat down with some of my colleagues after an session around vRealize Automation 7 and we used our lab we had to get a bit more familiar with the new Event Broker Service. I would like to share with you what we figured out in two hours playing around in the lab:

With vRealize Automation 7 there is a new component which is internally responsible for all communication between all components: The Event Broker Service. The EBS is a messaging bus based on RabbitMQ. To create your own extensibility around vRealize Automation you can yourself subscribe to the message bus and run vRealize Orchestrator workflows out of it.

You can subscribe to the following event topics:
  • Post Approval
  • Pre Approval
  • EventLog Default Event
  • Blueprint configuration
  • Resource Reclamation Completion Event
  • Business group configuration
  • Orchestration server configuration (XaaS)
  • Machine lifecycle
  • Machine provisioning

With subscriptions to all of those events you should be unlimited in your extensibility. We will deep dive a little bit in to Machine provisioning which includes all events around provisioning and unprovisioning phase while Machine lifecycle now has all the events for day-2-operations.

To create such a subscription, you browse in vRealize Automation 7 to Administration --> Events --> Subscriptions.

After clicking + New, you can select to which kind of topic you want to subscribe (I selected Machine provisioning):

Click Next > and you can filter when exactly you want to subscribe to this event topic. So in example I only subscribe to events where the lifecycle state is BuildingMachine:

After clicking Next > you can choose the vRealize Orchestrator workflow which you want to run. In my case I choose my own created machine provisioning workflow template workflow:

The last step after clicking Next > is to set the subscription a name and to choose if this subscription should be a blocking or non-blocking subscription and then click Finish:

Blocking vs. Non-Blocking Subscriptions:

Workflow fails
Request fails
Request succeeds
Workflow return values
Returns are processed
Returns are discarded
Workflows run in sequence per request
Workflows run in parallel for multiple requests
Workflows run in parallel
To manipulate and edit stuff during events
To fire and forget tasks

Pre & Post Event States

For each event (e.g. Building Machine) subscription, workflows are triggered twice: Pre-Event and Post-Event. Create a condition for subscription based on "Data > Lifecycle state > State phase" to limit this:

Some more information around the pre and post states:

Workflow fails
Request fails
Request succeeds
Request succeeds
Request succeeds
Workflow return values
Returns are processed
Returns are discarded
Returns are discarded
Returns are discarded

Passing inputs to the workflow

To pass information to your workflow you have different ways on how to do this:
  • ·      One string which will contain all information as json
  • ·      One properties object which will contain all information
  • ·      Use the schema provided attributes as workflow input

You can see all the information which gets passed during the creation oft he subscription:

Here in my case I used the third way and created a workflow which has inputs for all the different information:

Cause the Event Broker Service in the backend is using the Advanced Service Designer to run the workflows, we also see familiar properties on the workflow which we could also define as input:

Passing outputs back to vRealize Automation

To pass information back to vRealize Automation you can use the following outputs on your workflow:

Manipulate properties which are on the virtual machine like:
Remove properties of the virtual machine
Force the virtual machine into an other workflow state than the normal following state