Adventures with the vCO AMQP Plugin

*** This is a Guest Article, written by Mathew Quinn – Thanks, Mat! ***

Having had some experience with a variety of plugins for vCO that range in quality, I was wondering what to expect from the AMQP plugin. I approached the plugin with a good deal of skepticism – which did turn out to be completely unfair!

Having had no prior experience with message queues, my first task was to learn about all things queue.

Selecting RabbitMQ to experiment with was the obvious choice. I believe VMware now own this product which can be used in a free edition or as part of the larger vFabric suite. The Plugin also comes with a little rabbit icon, so I’m guessing this is what they’re suggesting. The plugin can however work with any AMQP-based message broker.

Now there were some AMQP concepts to learn, which turned out to be very simple and well presented. I would recommend a read through the following documentation if you are new to AMQP or RabbitMQ: http://www.rabbitmq.com/tutorials/amqp-concepts.html

Next I provisioned a CentOS 6 VM and installed RabbitMQ which was ridiculously easy. In order to get moving faster, I also installed the RabbitMQ management plugin that presents a convenient web interface where you can define exchanges, queues and bindings, and also publish and retrieve messages.

Get Started with AMQP in vCenter Orchestrator

Installation of the AMQP plugin for vCO was easy so I’ll skip that part. It installs the same as any other Plugin for vCO.

Upon installation, some new workflows are now present in the vCO Client

Right, very straightforward. There appeared everything I needed to get started.

A good place to start is running the ‘Add a Broker’ workflow which adds a broker (AMQP server) to the vCO inventory. This is the root object from the point of view of the plugin’s inventory. Once you have a broker in your inventory you’re free to begin receiving and publishing messages, which works quite nicely.

On the AMQP Broker I added a queue called ‘Inbox’ and a queue called ‘Outbox’, the intention being to both receive a message in vCO, and publish a message back.

And published a message to the inbox, ready to receive.

Now the moment of anticipation. Will this work first go? I run the ‘Receive a text message’ workflow in vCO client.

Presto! Success! My message has been received in the vCO client perfectly. I’m starting to like this.

Now let’s send a message back to the outbox.

The workflow runs successfully, and looking at the broker, there is indeed a message sitting in the queue to be fetched.

Nice! The reply was received successfully too. Already things are starting to look very nice indeed.
Now to step things up a notch. What I’m really interested in with the AMQP plugin are the event-driven possibilities. I want to be able to trigger a workflow from an inbox message, do some processing, and respond to the outbox.

Event-driven Message Handling

Rather than reinvent the wheel, I decided to check online for examples of just this operation and stumbled across some workflows published on the subject:
http://communities.vmware.com/docs/DOC-18002
The example was focused around handling vCloud Director message notifications. I imported the package and took a look.

The author achieves this by utilising a policy connected to an AMQP subscription that triggers a scripting event. When a message arrives in the queue that is subscribed to, the event fires and the script runs. Neat.

The script that runs operates by firing up a workflow – but this is where things start to get messy.

Oh no – is that a hard coded workflow ID in the script? It sure is. If beings greater than myself have found that this is the best way to do things, we’re in trouble. I just can’t do things like this when coding and enterprise-grade solution.

Investigating policies a bit further, it turns out that it is possible to directly trigger a workflow from an event rather than run a script. I decide to give this a try.

Firstly I must create a subscription to my inbox queue, and workflow that I intend to run. Subscriptions are for the sole intent of receiving messages from a queue and they live in the vCO inventory. You can create one by running the ‘Subscribe to queues’ workflow.

I also create an empty workflow to trigger on receiving a message. Now I have all the components I need to build my policy.

This is all well and good, but I need some input to my workflow. I want the workflow to be able to inspect the message received. I create a new parameter to the workflow of type ‘Any’.

Now to hook this up to the policy. I will gloss over the details a bit here but, suffice to say, I found passing in the ‘self’ object of type AMQP:Subscription the most reliable way to get all the details of the message received and, additionally, the subscription that received the message, into the workflow using only one input. The other possible inputs, event key headers, properties, and body, achieve this only in part, and with varying degrees of success.

In the workflow itself, I add a scripting object to log the message, and nest a ‘Send text message’ workflow to reply to the outbox.

Now I am all ready for the big test. I should be able to send a message to the inbox queue, Orchestrator will log this, and send a reply to the outbox. With the policy started, I send a message to the inbox.

Fantastic, I can see the message body logged in the workflow run.

And the reply is present in the outbox queue!

In Summary, the vCO AMQP plugin offers an exciting range of possibilities. It interfaces simply and reliably with AMQP Brokers and could be used for a variety of purposes.