Skip to content
DevTest Solutions - 10.3
Documentation powered by DocOps

RabbitMQ Send Receive Step

Last update June 24, 2016

This step lets you send and receive messages over RabbitMQ.

The following graphic shows the step editor. The advanced parameters are not shown.

Screen capture of RabbitMQ Send Receive step.

Each parameter has a tooltip that describes the purpose of the parameter.

Some parameters include the value Automatic as an option. This value indicates that the actual setting is taken from another parameter. If you click the drop-down arrow and you place the mouse pointer over the value Automatic, a tooltip displays the name of the other parameter.

For more conceptual information about RabbitMQ and the corresponding assets, see RabbitMQ Assets.


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.

Send and Receive

The RabbitMQ Send Receive step has separate areas for configuring the send operation and the receive operation.

Specify two queues in the step editor: one for the send operation, and one for the receive operation. The lists are populated with the RabbitMQ queue and temp queue assets from the active configuration.

Each asset has a runtime scope. The RabbitMQ Send Receive step lets you specify a minimum runtime scope for the send and receive operations. The scope parameters are advanced parameters.

Message Properties

RabbitMQ has messages, which consist of header data and a payload.

Like JMS, you can add custom properties to the header data.

Like WebSphere MQ, the payload is text or binary. Internally, the payload is stored as binary.

Like JMS and WebSphere MQ, header fields are available for Message ID, Correlation ID, and ReplyTo.

Unlike JMS and WebSphere MQ, RabbitMQ does not specify anything about the Message ID, Correlation ID, and ReplyTo fields. These fields are provided as a convenience. RabbitMQ itself does not care how, or if, the fields are used.

With Message ID, this means that a message is not assigned a Message ID automatically. The application must fill in this field before sending the message, if it wants to. The application also determines the uniqueness of the Message ID.

With ReplyTo, it is again up to the application to determine how this this field is populated on the client side and interpreted on the service side. The field might contain the name of a response queue, or a routing key, or something completely different.

Message Contents

The RabbitMQ Send Receive step lets you specify the message content. The following types are supported:

  • XML document
  • DevTest property reference
  • Text
  • Graphic image
  • Binary
  • IBM RFH2 header
  • IBM MQMD header
  • JSON document
  • EDI document

Correlation Schemes

The following correlation schemes are available:

  • Default ReplyTo
  • RabbitMQ Direct
  • RabbitMQ Topic
  • RabbitMQ Headers
  • RabbitMQ Payload

Default ReplyTo

The simplest correlation scheme is not technically called that. It is the default behavior of the RabbitMQ Send Receive step.

The ReplyTo field of the request message is filled in with the name of the response queue, whether it is a temp queue or not, and it is assumed that the service will use the default exchange to send a response directly back to that queue. This corresponds to the typical ReplyTo scheme in other messaging providers.

RabbitMQ Direct and RabbitMQ Topic

In this correlation scheme, the request message's ReplyTo field contains the exact routing key that was used to bind the response queue to some direct or topic exchange. It is assumed that the service will copy the routing key used for its response from the ReplyTo field of the request. It is also assumed that the service knows which direct or topic exchange to use when sending the response.

For the purposes of RPC, we assume that direct and topic exchanges work basically the same. That is, the routing key is matched exactly between the response queue's binding and the response message.

If no explicit exchange is provided on the response queue, it will use amq.direct or amq.topic by default. It also can generate a routing key, and will set up the message and queue binding parameters automatically. This overrides the default ReplyTo behavior because it uses the same ReplyTo field on the request message.

Direct and Topic are two separate correlation schemes in the RabbitMQ Send Receive step, but that is just to avoid confusion. The schemes are almost identical, with the exception of the default exchange name.

RabbitMQ Headers

In this correlation scheme, the request message contains one property used for correlation. It is assumed that the service will copy the property value verbatim to the response message. It is also assumed that the service knows which headers exchange to use when sending the response.

If no explicit exchange is provided on the response queue, it will use amq.headers by default. It also can generate a value, and will set up the message and queue binding parameters automatically. This overrides the default ReplyTo behavior because headers exchanges do not use routing keys.

You only need to provide the name of the property, and the name of the property on the response message if different from the request.

RabbitMQ Payload

Like JMS and MQ, we have payload-based correlation with RabbitMQ. This scheme works exactly like it does with the other providers.

Test the RabbitMQ Send Receive Step

You can verify the functionality of the RabbitMQ Send Receive step in the editor.

The execution log provides a high-level view of the activity that happens behind the scenes.

Follow these steps:

  1. Click the green Execute button in the step editor.
  2. To cancel the step while it is executing, click Cancel.
    The Response tab shows the response that was received when the operation finishes.
  3. To view the step activity, click Execution Log.
  4. To monitor the asset instances, click Runtime Monitor.
  5. To view the request that was sent, click the Request tab.

Monitor and Close Cached Asset Instances

When you test the RabbitMQ Send Receive step, a runtime monitor in the Response tab lets you monitor asset instances. You can also manually close the assets.

By default, the runtime monitor automatically removes assets that are closed. In the following procedure, you disable this behavior.

Follow these steps:

  1. In the Response tab, click Runtime Monitor.
  2. Clear the check box that appears inside the Clear button.
  3. Execute the step again.
    The runtime monitor displays the assets that were created during the execution of the step.
  4. View the following information:
    • Name: The name of the asset.
    • Type: The type of asset.
    • Scope: The name of the test step, test case instance, test case, or DevTest component that corresponds to the runtime scope of the asset. The value has a tooltip that shows the scope.
    • Status: The color green indicates that the asset is active. The color yellow indicates that the asset is idle. The color gray indicates that the asset is closed.
  5. To display more information about an asset, click the status icon.
  6. To close an asset immediately, click the status icon and select Close or Force Close.
  7. To close a set of assets, click Force Close.
Was this helpful?

Please log in to post comments.