This step lets you send and receive messages over RabbitMQ.
The following graphic shows the step editor. The advanced parameters are not shown.
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.
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.
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.
The RabbitMQ Send Receive step lets you specify the message content. The following types are supported:
The following correlation schemes are available:
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.
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.
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.
Like JMS and MQ, we have payload-based correlation with RabbitMQ. This scheme works exactly like it does with the other providers.
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:
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: