As most of you guys know, I am a big fan of vRO (vRealize Orchestrator). I didn’t do any of the configuration in Rabbit MQ using the management interface, I configured everything using vRO but the graphical UI is very useful to verify what the workflows did.
After the installation of Rabbit MQ, I used the documentation (official RMQ documentation: https://www.rabbitmq.com/documentation.html) and some blogs I found, I needed to configure RMQ, but how? Now vRO comes into play, because it is shipped with a preinstalled AMQP plugin, containing all needed workflows to configure the message broker.
Now the mess started, because I had no clue what an exchange or a queue is or what they are used for. Basically, an exchange receives messages from a producer (a message generating system) and pushes them to queues based on the exchange configuration and routing keys. Now everything is perfectly clear. I am not going to do a deep dive on the different exchange configuration options we have and what they are used for.
Back to our main topic. vRO contains all workflows we need to create a basic RMQ configuration to get everything up and running to exchange messages between vCloud Director and Orchestrator.
Execute the workflows in the given order:
- Add a broker
- Declare an exchange
- Declare a queue
- Bind
It took me a while to find out that the Bind workflow does the trick, because it adds the routing key. Easy speaking, the routing key defines which messages are pushed from the exchange into the queue where it can be received by a consumer.
If we take a closer look into RMQ, let’s see what happens in the configuration. After running the first three workflows, the configuration looks like this:
As we can see, there is currently no binding configured. That means, that the messages are kind of stuck in the exchange because we didn’t tell RMQ what to do with the messages. As we’ve already said, the messages need to be forwarded to a queue where they can be received by a consumer. If we look at the queue, we see that there is no binding configured.
If we run the Bind workflow we add “the link” between the Exchange and the Queue thus telling RMQ to forward messages to the Queue. After adding the routing key, the configuration looks like this:
We told RMQ to forward all messages from the vcdExchange, which is obviously used by vCloud Director, to the queue used by vRealize Orchestrator to receive the messages. I have to say, that this configuration is only valid if the Exchange is exclusively used by vCD, because the routing key ‘#’ tells RMQ to forward all messages to the specified Queue. This is done be intend, because we use vRO to filter and decide what to do on specific messages (events).
To enable vRO to receive messages we need to subscribe to a Queue and create a policy based on the subscription and start the policy. In this case we use the OnMessage handler to receive all messages placed in the queue.
In the configuration of the policy we can either add JavaScript code directly or provide a workflow to do all the filtering. I am not going to discuss advantages and disadvantages of these two methods here. For this example, I decided to use a workflow.
As we can see, we receive many messages and the workflow is triggered for each single message.
Let’s take a closer look into the code and data we get. I started with some basic code to display the information we get.
We add the AMQP:Subscription as an input parameter. The log entries are shown below.
Based on that information we can filter on specific events and trigger additional workflows to configure additional stuff we need. This example is a starting to reconfigure the distributed port groups in vSphere created by vCloud Director during the deployment of a new vApp. The output contains all needed ID’s to collect the objects for reconfiguration.
This approach can also be used if you would like to use Blocking Tasks from vCloud Director.
This blog article covers only the basic vRO and RabbitMQ parts.
