Contact Us 1-800-596-4880
  1. Homepage
  2. JMS Connector (1.7)
  3. JMS Connector Examples

  4. Publish Messages and Listen for Replies

All Connectors

Publish Messages and Consume Replies Using the JMS Connector

Anypoint Connector for JMS (JMS Connector) Publish consume operation enables you to publish a message to any specified destination, and then consume the message reply on a different specified destination. Request and reply is a very common pattern between applications.

When using this operation, the JMSReplyTo header of the outgoing message contains the ID of the destination on which your application waits to consume a response. The destination might be a well-known destination or a temporary destination created with the purpose of receiving a single response message.

The result of the operation is the message received as a response, with the same structure as invoking the Consume operation.

Receive a Reply on a Temporary Queue

To set a temporary queue, you configure the message being sent, and the operation automatically waits for a response.

In the following example, you configure the Publish consume operation to publish a message with the following characteristics:

  • Current payload as its body

  • JMSReplyTo header configured to a temporary destination

  • Destination field set to targetDestination

Then, the operation automatically tries to consume the response from the temporary queue until a message is consumed or the Maximum wait is reached, in which case it fails with a JMS:TIMEOUT error.

To configure the operation follow these steps:

  1. In your Studio flow, select the Publish consume operation.

  2. In the connector configuration screen, set the Destination field to targetDestination.

  3. Scroll down to the Consume Configuration section and set the Maximum wait field to 20.

  4. Set the Maximum wait unit to SECONDS.

In the Publish consume configuration screen
Figure 1. Temporary Queue configuration

In the XML editor, the destination and <jms:consume-configuration> configuration looks like this:

<jms:publish-consume
doc:name="Publish consume"
config-ref="config"
destination="targetDestination">
	<jms:consume-configuration maximumWait="20" maximumWaitUnit="SECONDS" />
</jms:publish-consume>

Receive a Reply On a Known Queue

To set a known queue for replies, configure the Reply To field on the outgoing message.

In the following example, you configure the Publish consume operation to publish a message to the targetDestination with the following characteristics:

  • Current payload as its body

  • JMSReplyTo header configured to the known queue

  • Reply To field set to replyToDestination

Then, the operation automatically tries to consume the response from the known replyToDestination queue until a message is consumed or the Maximum wait is reached, in which case it fails with a JMS:TIMEOUT error.

To configure the operation follow these steps:

  1. In your Studio flow, select the Publish consume operation.

  2. In the connector configuration screen, set the Destination field to targetDestination.

  3. In the Message section, set the Reply To field to Edit inline.

  4. Set the Destination Name field to replyToDestination.

  5. Scroll down to the Consume Configuration section and set the Maximum wait field to 20.

  6. Set the Maximum wait unit to SECONDS.

In the Publish consume configuration screen
Figure 2. Known Queue configuration

In the XML editor, the destination and <jms:reply-to> configuration looks like this:

<jms:publish-consume config-ref="config" destination="targetDestination">
    <jms:message>
        <jms:reply-to destination="replyToDestination"/>
    </jms:message>
			<jms:consume-configuration maximumWait="20" maximumWaitUnit="SECONDS" />
</jms:publish-consume>

Configure Request and Reply Patterns

JMS uses two well-known request and reply patterns that help you understand how request and reply messages are correlated. In the Request-Reply Pattern field of the operation, you can configure the CORRELATION_ID (Default) and MESSAGE_ID patterns. Both ensure that an incoming message is the correct reply to an outgoing message. You can also configure the field to NONE, causing the consumer to try to consume from the reply queue without using any selector to correlate messages. This option is useful when working with temporal queues that ensure that the queue has only one message.

Configure the Correlation ID Pattern

The CORRELATION_ID (Default) pattern implies that the operation, after publishing a message to the destination queue, consumes a message using a selector that expects a message with the same correlation ID that was used to publish the request message. The message correlation ID is a value used to link one message with another.

In the first flow of the following example, you configure the Publish consume operation to publish a message to the targetDestination with the following characteristics:

  • Current payload as its body

  • JMSReplyTo header configured to the known queue

  • Reply To field set to replyToDestination

  • Request-Reply Pattern field set to CORRELATION_ID (Default)

Then, in the second flow, an On New Message source reads the published message and responds using the same correlation ID pattern. A Logger component, logs the message response.
Back in the first flow, the Publish consume operation consumes the response received and then another Logger component, and logs the final message.

To configure the operation follow these steps:

  1. In your Studio flow, select the Publish consume operation.

  2. In the connector configuration screen, set the Destination field to targetDestination.

  3. Set the Request-Reply Pattern to CORRELATION_ID (Default).

  4. In the Message section, set the Reply To field to Edit inline.

  5. Set the Destination Name field to replyToDestination.

  6. Drag a Logger component to right of the Publish consume.

  7. Set the Message field to Received message from 'replyToDestination' with Correlation ID: #[attributes.headers.correlationId].

  8. Drag a JMS On New Message source below the first flow.

  9. Set the Destination field to targetDestination.

  10. Scroll down to the Response section and set the Request-Reply Pattern to CORRELATION_ID (Default).

  11. Drag another Logger component to right of On New Message.

  12. Set the Message field to About to reply to 'targetDestination' with Correlation ID: #[attributes.headers.correlationId].

Set the Request-Reply Pattern to CORRELATION_ID (Default)
Figure 3. Correlation ID pattern implementation

In the XML editor, the requestReplyPattern configuration looks like this:

<flow name="publish-consume-correlation-id">
  <jms:publish-consume config-ref="config" destination="targetDestination" requestReplyPattern="CORRELATION_ID">
    <jms:message >
      <jms:reply-to destination="replyToDestination" />
    </jms:message>
  </jms:publish-consume>
  <logger message="Received message from 'replyToDestination' with Correlation ID: #[attributes.headers.correlationId]"/>
</flow>

<flow name="jms-listener-correlation-id" >
  <jms:listener config-ref="config" destination="targetDestination">
    <jms:response requestReplyPattern="CORRELATION_ID" />
  </jms:listener>
  <logger level="INFO" message="About to reply to 'targetDestination' with Correlation ID: #[attributes.headers.correlationId]"/>
</flow>

Configure the Message ID Pattern

The MESSAGE_ID pattern implies that the operation, after publishing a message to the destination queue, consumes a message using a selector that expects a message with a message ID of the same value as the message ID of the request message. The message ID is a value that uniquely identifies each message sent by a provider.

In the first flow of the following example, you configure the Publish consume operation to publish a message to the targetDestination with the following characteristics:

  • Current payload as its body

  • JMSReplyTo header configured to the known queue

  • Reply To field set to replyToDestination

  • Request-Reply Pattern field set to MESSAGE_ID

Then, in the second flow, an On New Message source reads the published message and responds using the same message ID pattern. A Logger component, logs the message response.
Back in the first flow, the Publish consume operation consumes the response received and then another Logger component and logs the final message.

To configure the operation follow these steps:

  1. In your Studio flow, select the Publish consume operation.

  2. In the connector configuration screen, set the Destination field to targetDestination.

  3. Set the Request-Reply Pattern to MESSAGE_ID.

  4. In the Message section, set the Reply To field to Edit inline.

  5. Set the Destination Name field to replyToDestination.

  6. Drag a Logger component to right of Publish consume.

  7. Set the Message field to Received message from 'replyToDestination' with Message ID: #[attributes.headers.correlationId].

  8. Drag a JMS On New Message source below the first flow.

  9. Set the Destination field to targetDestination.

  10. Scroll down to the Response section and set the Request-Reply Pattern to MESSAGE_ID.

  11. Drag another Logger component to right of On New Message.

  12. Set the Message field to About to reply to 'targetDestination' with Message ID: #[attributes.headers.messageId].

Set the Request-Reply Pattern to MESSAGE_ID
Figure 4. Message ID pattern implementation
<flow name="publish-consume-message-id">
  <jms:publish-consume config-ref="config"
    destination="targetDestination"
    requestReplyPattern="MESSAGE_ID">
    <jms:message >
      <jms:reply-to destination="replyToDestination" />
    </jms:message>
  </jms:publish-consume>
  <logger message="Received message from 'replyToDestination' with Message ID: #[attributes.headers.messageId]"/>
</flow>

<flow name="jms-listener-message-id" >
  <jms:listener config-ref="config" destination="targetDestination">
    <jms:response requestReplyPattern="MESSAGE_ID" />
  </jms:listener>
  <logger level="INFO" message="About to reply to 'targetDestination' with Message ID: #[attributes.headers.messageId]"/>
</flow>

See Also

Back to top
View on GitHub