How to Send a Request Message and Wait for a Reply
The following describes the general steps you take to build a service that sends a request message and then waits for a reply.
1. Create an empty flow service.
2. Create the message body.
For more information about creating content for the body of a JMS message, see step 2 in the section
How to Send a JMS Message.
3. Invoke pub.jms:sendAndWait.
This service creates a JMS message (javax.jms.Message) based on input provided to the service or takes an existing JMS message and sends it to the JMS provider.
4. Specify the JMS connection alias.
The JMS connection alias indicates how Integration Server connects to the JMS provider.
Name | Description |
connectionAliasName | Name of the JMS connection alias that you want to use to send the message. |
5. Specify the destination to which you want to send the message.
If the JMS connection alias you specified in step 4 uses the native webMethods API to create the connection directly on the webMethods Broker, you need to specify the destinationName as well as the destinationType.
Name | Description |
destinationName | Name or lookup name of the Destination to which you want to send the message.  Specify the lookup name of the Destination object when the JMS connection alias uses JNDI to retrieve administered objects. Specify the provider-specific name of the Destination when the JMS connection alias uses the native webMethods API to connect directly to the webMethods Broker. |
destinationType | Specifies whether the Destination is a queue or a topic. The default is queue. |
6. Specify the destination to which message recipients should send the reply message. (Optional)
If you do not specify a destination for reply messages, Integration Server uses a temporaryQueue to receive the reply. A temporaryQueue is a queue object created for the duration of a particular connection.
When using pub.jms:sendAndWait to issue a request/reply, you must specify a queue as the value of the destinationNameReplyTo parameter. In a request/reply scenario, it is possible that the message consumer created to receive the reply might be created after the reply message is sent. (In a synchronous request/reply, the pub.jms:sendAndWait service creates the message consumer. In an asynchronous request/reply, the pub.jms:waitForReply service or a custom solution, such as a JMS trigger, creates the message consumer.) If the reply destination is a queue, a message consumer can receive messages published to the queue regardless of whether the message consumer was active at the time the message was published. If the destination is a topic, a message consumer can receive only messages published when the message consumer was active. If the reply is sent to a topic before the message consumer is created, the message consumer will not receive the reply. Consequently, when creating a request/reply, the destinationNameReplyTo parameter should specify the name or lookup name of a queue.
Name | Description |
destinationNameReplyTo | Name or lookup name of the Destination to which you want the reply message sent. Specify the lookup name of the Destination object when the JMS connection alias uses JNDI to retrieve administered objects. Specify the provider-specific name of the Destination when the JMS connection alias uses the native webMethods API to connect directly to the webMethods Broker. |
destinationTypeReplyTo | Specifies whether the Destination is a queue or a topic. The default is queue. |
7. If this is a synchronous request/reply, set the request timeout.
The timeout indicates how long Integration Server waits for a reply message. The timeout parameter only applies to synchronous send and wait requests.
Name | Description |
timeout | Time to wait (in milliseconds) for the response to arrive. You must set this to a value greater than 0 (zero). If no timeout value is specified, the service does not wait and returns a null document. |
8. Populate the JMS message.
9. Indicate whether the request is synchronous or asynchronous.
The pub.jms:sendAndWait provides a parameter that you can set to indicate whether the request is synchronous or asynchronous. By default, the request is synchronous.
Name | Description |
async | Flag specifying whether this is an asynchronous or synchronous request/reply. True indicates that this is an asynchronous request/reply. After sending the message, Integration Server executes the next step in the flow service immediately. Integration Server does not wait for a reply before continuing service execution. False indicates that this is a synchronous request/reply. After sending the message, Integration Server waits for a reply before executing the next step in the flow service. The default is False. |
10. Specify whether the client side queue should be used.
When the client side queuing is in use, Integration Server places messages in the client side queue if the JMS provider is not available at the time the pub.jms:sendAndWait service executes. If you want to use the client side queue with this implementation of the pub.jms:sendAndWait service, the JMS connection alias specified for connectionAliasName must be configured to have a client side queue. A JMS connection alias has a client side queue if the Maximum CSQ Size property for the alias is set to a value other than 0 (zero).
The client side queue can be used with asynchronous requests only.
If the client side queue is in use, the reply destination must be a queue that is not temporary. Consequently, if useCSQ is set to true, values must be specified for the destinationNameReplyTo and destinationTypeReplyTo input parameters.
Name | Description |
useCSQ | Indicates whether Integration Server places the sent message in the client side queue if the JMS provider is not available at the time the message is sent. True specifies that Integration Server writes messages to the client side queue if the JMS provider is not available at the time this service executes. When the JMS provider becomes available, Integration Server sends messages from the client side queue to the JMS provider. False indicates that Integration Server throws an ISRuntimeException if the JMS provider is not available at the time this service executes. The default is False. Note:
If the specified connectionAliasName uses a cluster connection factory to which the multisend guaranteed policy is applied, set useCSQ to False. For more information about the multisend guaranteed policy, see
Working with the Multisend Guaranteed
Policy. |
11. Invoke pub.jms:waitForReply.
If you configured pub.jms:sendAndWait as an asynchronous request/reply, you need to invoke the pub.jms:waitForReply service to retrieve the reply message.
Specify the following input values for the pub.jms:waitForReply service.
Name | Description |
correlationID | A unique identifier used to associate the reply message with the initial request. Integration Server uses the value of the uuid or JMSMessageID fields in the requesting JMS message to correlate the response to the request. If you set the uuid in the JMS message request, you can link the value of the uuid field from the JMSMessage produced by pub.jms:sendAndWait to the correlationID. If you did not specify a uuid, you can link the JMSMessageID field from the JMSMessage produced by pub.jms:sendAndWait to the correlationID. |
timeout | Optional. Time to wait (in milliseconds) for the reply to arrive. If timeout is greater than 0 (zero) and a reply is not available at the time the pub.jms:waitForReply service executes, the service continues to wait for the document until the time specified in the timeout parameter elapses. If the service does not receive a reply by the time the timeout interval elapses, the pub.jms:waitForReply service returns a null document. If timeout is set to 0 (zero), the pub.jms:waitForReply service waits indefinitely for a response. Software AG does not recommend setting timeout to 0 (zero). If timeout is not set, the pub.jms:waitForReply service does not wait for a reply. The pub.jms:waitForReply service always returns a null document. The service returns a null document even if the reply queue contains a response for the request. |
Note:
The pub.jms:waitForReply service cannot be used to retrieve a response to requests that were routed through the client side queue. To retrieve the response, create a JMS trigger that subscribes to the reply queue.
Note:
If the pub.jms:sendAndWait service executes and the message is sent directly to the JMS provider (i.e., it is not sent to the client side queue), the JMSMessage\header\JMSMessageID contains a unique identifier assigned by the JMS provider. If the JMSMessageID field is null, after the service executes, the JMS provider was not available at the time the service executed. Integration Server wrote the message to the client side queue.
12. Process the reply message.
The pub.jms:sendAndWait (or pub.jms:waitForReply) service produces the output parameter JMSReplyMessage, which contains the JMS message received as a reply.
If Integration Server does not receive a reply before the specified timeout value elapses or if a timeout value was not specified, the JMSReplyMessage is null. Be sure to code your service to handle this situation.