Skip to content
DevTest Solutions - 10.3
Documentation powered by DocOps

RabbitMQ Assets

Last update June 24, 2016

You can create the following types of assets for RabbitMQ:

  • RabbitMQ Connection
  • RabbitMQ Queue
  • RabbitMQ Exchange
  • RabbitMQ Temp Queue
  • RabbitMQ Channel

In the editor for each asset, each parameter has a tooltip that describes the purpose of the parameter.

 

Prerequisites: Using DevTest with this application requires that you make one or more files available to DevTest. For more information, see Third-Party File Requirements.

Connection

The connection asset lets you establish a connection to the RabbitMQ server.

Specify the following information:

  • Host name and port number of the RabbitMQ server
  • User name and password for accessing the RabbitMQ server

When you configure the connection asset, you can use the green Verify button to confirm that the server can be reached.

The following graphic shows a connection asset.

Screen capture of connection asset.

Queue

A queue represents a location where a message can wait to be picked up by a consumer.

Like JMS and WebSphere MQ, more than one client can listen on the same queue. Each message is delivered to only one consumer.

Like JMS and WebSphere MQ, a client can create a temporary queue on demand.

Like WebSphere MQ, a client can specify the name of the temporary queue or let RabbitMQ generate a name.

Unlike JMS, WebSphere MQ, and most other messaging providers, you cannot publish a message directly to a queue. Instead, you publish to an exchange.

The following graphic shows a queue asset.

Screen capture of queue asset.

The Channel field must be set to a channel asset or a connection asset.

Exchange

An exchange is an additional routing layer that exists between publishers and queues.

RabbitMQ components

A consumer binds the queue it is listening on to an exchange using a routing key. This routing key tells the exchange which messages should be routed to the queue. The exact interpretation of the routing key depends on the type of exchange.

A publisher sends a message to an exchange along with its own routing key. This routing key tells the exchange how to route the message to one or more destination queues. Again, the exact interpretation of the routing key depends on the type of exchange.

The routing key used by the publisher to send a message to the exchange and the routing key used by the consumer that receives the message on its queue are usually matched in some way, but they are not necessarily equal.

If a message is published to an exchange with a routing key that does not match any currently bound queues, the message is discarded. So while the queue side is like a JMS queue, where a message waits to be consumed, the exchange side is like a JMS topic, where a queue has to be bound to the exchange with a matching routing key at the time the message is published in order to receive it. Also like a topic, if more than one queue has binding parameters that match a given message according to the exchange's routing rules, the message is forwarded to all of those queues at the same time.

The exchange types have different routing strategies:

  • Default
    If you do not specify the name of an exchange when publishing a message, the default exchange is used. Each queue created on a RabbitMQ server, including temp queues, is automatically bound to the default exchange with a routing key equal to the queue name. Therefore, publishing with an empty exchange name and the queue name as the routing key is the closest you can get to publishing directly to a queue.
  • Direct
    With a direct exchange, each consumer's queue is bound to the exchange with a unique string as its routing key. The routing key might be the name of the queue or something completely different. Publishers send a message to the exchange with a routing key. The message is routed to every queue that is bound with the same routing key.
  • Topic
    Topic exchanges are almost the same as direct exchanges. However, with a topic exchange the routing key used to bind a queue can be a routing pattern that can match more than one message routing key. Basically, routing patterns are dot-delimited strings where the text between each dot can be a literal string or one of two wildcards. The star wildcard (*) matches one string. The hash wildcard (#) matches zero or more dot-delimited strings.
  • Headers
    Rather than routing based on the routing key, a headers exchange routes based on one or more custom message properties. A queue is bound to the headers exchange with one or more custom bind properties that must match the custom properties on a message sent to that exchange. By default, to be routed to a queue a message must have properties that match all the properties that the queue was bound with. An additional bind property can change this behavior so that only one of the message's properties must match.
  • Fanout
    A fanout exchange routes every message to every queue bound to it. It does not use the routing key or any other routing logic.

The Channel field must be set to a channel asset or a connection asset.

Temp Queue

Temp queues are probably much more prevalent with RabbitMQ RPC-style services than they are with other messaging providers. The reason is that message filtering is not done at the queue level. All the filtering is done at the exchange level with routing rules. Once a message is passed on to a particular queue, then there it is going to be delivered to one of the consumers on that queue. Basically, a one-to-one correspondence exists between consumers and queues. The only reason to have more than one consumer on the same queue is to load balance or parallelize the processing of messages from that queue; all of those consumers must necessarily do the same processing.

Because each consumer needs its own queue and temp queues are so easy to create, it makes sense to use temp queues for the response side of most RPC applications as a standard practice. Temp queues also work well with the exchange-based correlation schemes. An exchange does not care whether the queue that it is routing messages to is a temp queue or not.

The following graphic shows a temp queue asset.

Screen capture of temp queue asset.

The Channel field must be set to a channel asset or a connection asset.

Channel

The channel asset represents a RabbitMQ channel. Typically, you do not need to create this type of asset.

Was this helpful?

Please log in to post comments.