pub.jms:sendAndWait
WmPublic. Sends a request in the form of a JMS message to the JMS provider and optionally, waits for a reply.
Input Parameters
connectionAliasName | String Name of the JMS connection alias that you want to use to send the message. The JMS connection alias indicates how Integration Server connects to the JMS provider. A JMS connection alias can specify that Integration Server use a JNDI provider to look up administered objects (connection factories and destinations) and then use the connection factory to create a connection. Alternatively, a JMS connection alias can specify that Integration Server uses the native webMethods API to create the connection directly on the webMethods Broker. |
destinationName | String 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 | String Optional. Type of destination to which you want to send the message. Specify one of the following:  QUEUE to send the message to a particular queue. This is the default. TOPIC to send the message to a topic. Note:
You need to specify a destinationType only if you specified a connectionAliasName that uses the native webMethods API. |
destinationName ReplyTo | String Optional. 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. 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. It can only be consumed by the connection from which it was created. If you want to use a dedicated listener (MessageConsumer) to retrieve replies to all requests sent using a particular JMS connection alias, do not specify a value for destinationNameReplyTo. A dedicated MessageConsumer can retrieve replies for a synchronous request/reply only. If you want to use the client side queue with an asynchronous request-reply, you must specify a queue that is not temporary as the destinationNameReplyTo value. |
destinationType ReplyTo | String Optional. Type of destination to which you want the reply to be sent. Specify one of the following: QUEUE to send the reply message to a particular queue. This is the default. TOPIC to send the reply message to a specific topic. |
timeout | java.lang.Long Optional. Time to wait (in milliseconds) for the response to arrive. If no value is specified, the service does not wait for a reply and returns a null document. You must specify a value greater than zero. The timeout value only applies for a synchronous request/reply. If async is set to true, Integration Server ignores the timeout value. |
JMSMessage | Document A document representing the JMS message you want to send. |
| Key | Description |
| header | Document Optional. A document containing the header of the JMS message. |
| | Key | Description |
| | deliveryMode | String Optional. Specifies the message delivery mode for the message. Specify one of the following: PERSISTENT Default. Provide once-and-only-once delivery for the message. The message will not be lost if a JMS provider failure occurs. NON_PERSISTENT Provide at-most-once delivery for the message. The message has no guarantee of being saved if a JMS provider failure occurs. |
| | priority | java.lang.Integer Optional. Specifies the message priority. The JMS standard defines priority levels from 0 to 9, with 0 as the lowest priority and 9 as the highest. The default is 4. |
| | timeToLive | java.lang.Long Optional. Length of time, in milliseconds, that the JMS provider retains the message. The default is 0, meaning that the message does not expire. |
| | JMSType | String Optional. Message type identifier for the message. Integration Server expects the reply message to be of this type. |
| properties | Document Optional. A Document containing optional fields added to the message header. You can add a custom property to a JMS. C lick  on the Pipeline view. Select a data type for the property and assign it a name. Assign a value to any custom properties that you add. Note:Integration Server reserves use of a message property named wm_tagfor internal purposes. Do not add a property named wm_tag to the JMS message. Integration Server may overwrite a supplied value for wm_tag. Integration Server adds the following properties to JMS messages it sends. |
| | Key | Description |
| | JMS_WM ClusterNodes | String Optional. Name of the Broker in a Broker cluster that you want to receive the message. The specified Broker effectively overrides the policy applied to the cluster connection factory used by the JMS connection alias. If the applied policy is multisend guaranteed or multisend best effort, the JMS_WMClusterNodes value should contain multiple Brokers. |
| | | Important:Software AG requires that you specify the value for JMS_WMClusterNodes by mapping the contents of the service output parameter JMS_WMClusterNodes produced by a previous invocation of pub.jms:send or pub.jms:sendAndWait. Use this field to override a Broker cluster policy when all of the following are true: The Broker Server is the JMS provider. The JMS connection alias used to send the message ( connectionAliasName) uses a connection from a cluster connection factory. The cluster connection factory permits the applied policy to be overridden. Leave this field blank if the above conditions are not met or if you want the JMS message to be distributed according to the policy applied to the cluster connection factory. |
| | activation | String Optional. A unique identifier used to group together messages that will be received by a JMS trigger with a join. A JMS trigger can join together messages with the same activation. |
| | uuid | String Optional. A universally unique identifier for the message. Integration Server can use the uuid for exactly-once processing or for request/reply. |
| body | Document Optional. A Document containing the JMS message body. Integration Server supports the following formats for the JMS message body: |
| | Key | Description |
| | string | String Optional. Message body in the form of a String. |
| | bytes | primitive type Optional. Message body in the form of a one-dimensional byte array. |
| | object | Object. Optional. Message body in the form of a Serializable Java object. |
| | data | Document Optional. Message body in the form of a document (IData object). Note:
This message format can only be used when sending a JMS message from one Integration Server to another. When the JMS message is sent, the sending Integration Server encodes the IData into a byte array. When the receiving Integration Server receives the message, it decodes the byte array into IData. |
| | message | Object Optional. Message body in the form of an actual javax.jms.Message. |
async | java.lang.Boolean Optional. Flag specifying whether this is an asynchronous or synchronous request/reply. Set to: True to indicate that this is an asynchronous request/reply. After sending the message, Integration Server executes the next step in the flow service immediately. The Integration Server does not wait for a reply before continuing service execution. False to indicate that this is a synchronous request/reply. After sending the message, the Integration Server waits for a reply before executing the next step in the flow service. This is the default. |
useCSQ | java.lang.Boolean Optional. Flag indicating whether Integration Server places sent messages in the client side queue if the JMS provider is not available at the time the messages are sent. Set to: True to write 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. Note:
If you want to use the client side queue, 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). False to throw an ISRuntimeException if the JMS provider is not available at the time this service executes. This is the default. Note:Integration Server can write messages to the client side queue only for messages sent as part of an asynchronous request/reply. That is, if async is set to true (the default) and the JMS provider is not available at the time this service executes, Integration Server places the message in the client side queue. |
| Note:
The client side queue cannot be used if the reply destination is a temporary queue. Set useCSQ to False if destinationNameReplyTo is not specified or is a temporary queue. Note:
If the specified connectionAliasName uses a cluster connection factory to which the multisend guaranteed policy is applied, set useCSQ to False. |
Output Parameters
JMSMessage | Document. A Document containing the message sent to the JMS provider. |
| Key | Description |
| header | Document Conditional. A Document containing the header fields for the sent message. The JMS provider populates these fields after it has successfully received the message from Integration Server. |
| | Key | Description |
| | JMSCorrelationID | String Conditional. A unique identifier used to link messages together. |
| | JMSDeliveryMode | java.lang.Integer Delivery mode used to send the message. PERSISTENT indicates that the JMS provider provides once-and-only-once delivery for the message. The message will not be lost if a JMS provider failure occurs. NON_PERSISTENT indicates that the JMS provider provides at-most-once delivery for the message. The message has no guarantee of being saved if a JMS provider failure occurs. Note:
When sending a message, this value is obtained from the JMSMessage/header/deliveryMode input parameter. |
| | JMSDestination | Object Conditional. Destination (queue or topic) to which the message was sent. |
| | JMSExpiration | java.lang.LongOptional. Time at which this message expires. If the message producer did not specify a time-to-live, the JMSExpiration value is zero, indicating the message does not expire. Note:
When sending a message, this value is obtained from the JMSMessage/header/timeToLive input parameter. |
| | JMSMessageID | String Conditional. Unique identifier assigned to this message by the JMS provider. |
| | JMSPriority | java.lang.Integer Optional. Defines the message priority. The JMS standard defines priority levels from 0 to 9, with 0 as the lowest priority and 9 as the highest. Note:
When sending a message, this value is obtained from the JMSMessage/header/priority input parameter. |
| | JMSReplyTo | Object Conditional. Specifies the destination to which a reply to this message should be sent. The destinationNameReplyTo value determines the value of JMSReplyTo. |
| | JMSTimestamp | java.lang.Long Time at which the message was given to the JMS provider. |
| | JMSType | String Conditional. Message type identifier specified by the client when sending the message. |
| properties | Document Conditional. A Document containing optional fields added to the message header. Integration Server adds the following properties to JMS messages it sends. |
| | Key | Description |
| | JMS_WMCluster Nodes | String Conditional. Name of the Broker or Brokers in the Broker cluster that received the JMS message. The Broker Server acting as the JMS provider populates the JMS_WMClusterNodes parameter after it distributes the JMS message to the Broker or Brokers in the Broker cluster. |
| | | The JMS_WMClusterNodes value will be null when: The JMS provider is not the Broker Server. The JMS connection alias used to send the JMS message does not use a cluster connection factory to obtain the connection to the Broker Server. The cluster connection factory does not permit a policy to be overridden. |
| | activation | String Conditional. A unique identifier assigned by the sender. A JMS trigger can join together messages with the same activation. |
| | uuid | String Conditional. A universally unique identifier for the message assigned by the sender. Integration Server can use the uuid for exactly-once processing or for request/reply. |
| | Note:Integration Server adds a wm_tag property to a synchronous request message sent using a JMS connection alias that uses a dedicated MessageConsumer to retrieve replies.Integration Server reserves the use of a JMS message property named wm_tag for internal purposes. Integration Server may overwrite any user-supplied value for wm_tag. |
| body | Document Conditional. A Document containing the JMS message body. Integration Server supports the following formats for the JMS message body: |
| | Key | Description |
| | string | String Conditional. Message body in the form of a String. |
| | bytes | primitive type Conditional Message body in the form of a one-dimensional byte array. |
| | object | Object. Conditional. Message body in the form of a Serializable Java object. |
| | data | Document Conditional. Message body in the form of a document (IData object). Note:
This message format can only be used when sending a JMS message from one Integration Server to another. When the JMS message is sent, the sending Integration Server encodes the IData into a byte array. When the receiving Integration Server receives the message, it decodes the byte array into IData. |
| | message | Object Conditional. Message body in the form of an actual javax.jms.Message. |
JMSReplyMessage | | Document Conditional. Document containing the JMS message received as a reply. If this is a synchronous request/reply and Integration Server does not receive a a reply before the specified timeout value elapses or if timeout was not set, the JMSReplyMessage is null. If this is an asynchronous reply, the JMSReplyMessage is null. |
| Key | Description |
| header | Document Conditional. A Document containing the header fields for the reply message. |
| | Key | Description |
| | JMSCorrelationID | String Conditional. A unique identifier used to link the reply message with the initial request message. The replying Integration Server automatically sets this value when it executes the
pub.jms:reply service. |
| | JMSDeliveryMode | java.lang.Integer Conditional. Delivery mode used to send the message. PERSISTENT indicates that the JMS provider provides once-and-only-once delivery for the message. The message will not be lost if a JMS provider failure occurs. NON_PERSISTENT indicates that the JMS provider provides at-most-once delivery for the message. The message has no guarantee of being saved if a JMS provider failure occurs. |
| | JMSDestination | Object Conditional. Destination (queue or topic) to which the message was sent. |
| | JMSExpiration | java.lang.LongConditional. Time at which this message expires. If the message producer did not specify a time-to-live, the JMSExpiration value is zero, indicating the message does not expire. |
| | JMSMessageID | String Conditional. Unique identifier assigned to this message by the JMS provider. |
| | JMSPriority | java.lang.Integer Conditional. Defines the message priority. The JMS standard defines priority levels from 0 to 9, with 0 as the lowest priority and 9 as the highest. |
| | JMSRedelivered | java.lang.Boolean Conditional. Flag indicating the JMS provider delivered this message to the JMS client previously. True indicates the message may have been delivered in the past. False indicates the JMS provider has not delivered this message previously. |
| | JMSReplyTo | Object Conditional. Specifies the destination to which a response to this message should be sent. |
| | JMSTimestamp | java.lang.Long Conditional. Time at which the message was given to the JMS provider. |
| | JMSType | String Conditional. Message type identifier specified by the client when sending the message. |
| properties | Document Conditional. A Document containing optional fields added to the message header. Integration Server adds the following proprieties to JMS messages it receives. |
| | Key | Description |
| | JMSXDelivery Count | java.lang.Integer Conditional. Specifies the number of times the JMS provider delivered the message. Most JMS providers set this value. |
| | JMS_WMCluster Nodes | String Conditional. Name of the Broker or Brokers in the Broker cluster that received the JMS message. The Broker Server acting as the JMS provider populates the JMS_WMClusterNodes parameter after it distributes the JMS message to the Broker or Brokers in the Broker cluster. The JMS_WMClusterNodes value will be null when: The JMS provider is not the Broker Server. The JMS connection alias used to send the JMS message does not use a cluster connection factory to obtain the connection to the Broker Server. The cluster connection factory does not permit a policy to be overridden. |
| | activation | String Conditional. A unique identifier assigned by the sender. A JMS trigger uses the activation value to determine whether a message satisfies a join. |
| | uuid | String Conditional. A universally unique identifier for the message assigned by the sender. Integration Server can use the uuid for exactly-once processing or for request/reply. |
| body | Document Conditional. A Document containing the JMS message body. Integration Server supports the following formats for the JMS message body: |
| | Key | Description |
| | string | String Conditional. Message body in the form of a String. |
| | bytes | primitive type Conditional Message body in the form of a one-dimensional byte array. |
| | object | Object. Conditional. Message body in the form of a Serializable Java object. |
| | data | Document Conditional. Message body in the form of a document (IData object). Note:
This message format can only be used when sending a JMS message from one Integration Server to another. When the JMS message is sent, the sending Integration Server encodes the IData into a byte array. When the receiving Integration Server receives the message, it decodes the byte array into IData. |
| | message | Object Conditional. Message body in the form of an actual javax.jms.Message. |
Usage Notes
Thepub.jms:sendAndWait service creates a JMS message (javax.jms.Message) based on input provided to the service or takes an existing JMS message, sends it to the JMS provider and optionally, waits for a reply.
If a transaction has not been started, the transaction manager starts a transaction context for an implicit transaction when Integration Server executes a pub.jms:sendAndWait service that uses a transacted JMS connection alias. A JMS connection alias is considered to be transacted when it has a transaction type of XA TRANSACTION or LOCAL TRANSACTION.
You can add properties to a JMS message when building a flow service that invokes this service. In Designer, use the Pipeline view to add a new variable to JMSMessage/properties document.
If the JMS connection alias specified for connectionAliasName uses the native webMethods API, you need to specify destinationName and destinationType to indicate where the webMethods Broker should send the message.
If you specify a destination that does not exist in the JNDI namespace and the JMS connection alias specified for the
connectionAliasName input parameter is configured to create administered objects on demand,
Integration Server creates the destination when the service executes. The ability to create administered objects on demand applies only when is the JMS provider. For more information about creating administered objects on demand, see
Creating Administered Objects.Integration Server creates the output parameter JMSMessage because some of the header fields in a JMS message are populated by the JMS provider after the message is sent. For example, the header field JMSMessageID is not in the JMS message sent by Integration Server, but JMSMessageID is in the header after the JMS provider receives the message.
You can use the pub.jms:sendAndWait service to initiate a request/reply. The sending client sends a request for information to either a topic or queue. Clients that subscribe to the destination compose and send a reply document that contains the information requested by the sender.
A single request might receive many reply messages. Integration Server that sent the request uses only the first reply document it receives from the JMS provider. Integration Server discards all other replies. First is arbitrarily defined. There is no guarantee provided for the order in which the JMS provider processes incoming replies.
The pub.jms:sendAndWait service can be useful in situations where multiple sources contain the response data. For example, suppose that an enterprise uses one application for managing customer data, another for storing master customer records, and a mainframe system for saving customer lists. Each of these applications could answer a request for customer data. The requesting service will use the first reply message it receives.
The pub.jms:sendAndWait service can issue a request/reply in a synchronous or asynchronous manner.
In a synchronous request/reply, the service that sends the request stops executing while it waits for a reply. When the service receives a reply message, the service resumes execution. If the
timeout elapses before the service receives a reply,
Integration Server ends the request, and the service returns a null message that indicates that the request timed out.
Integration Server then executes the next step in the flow service.
In an asynchronous request/reply, the service that sends the request continues executing the steps in the service after sending the message. To retrieve the reply, the requesting flow service must invoke the
pub.jms:waitForReply service. If the
timeout value specified in
pub.jms:waitForReply elapses before the
pub.jms:waitForReply service receives a reply, the
pub.jms:waitForReply service returns a null document indicating that the request timed out.
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.
Note:
If you are using a dedicated listener (MessageConsumer) to retrieve replies to all of the requests sent using a particular JMS connection alias, do not specify a value for destinationNameReplyTo.
A service that contains multiple asynchronous send and wait invocations allows the service to send all the requests before collecting the replies. This approach can be more efficient than sending a request, waiting for a reply, and then sending the next request.
The replying
Integration Server uses the value of the
wm_tag,
uuid or
JMSMessageID in the requesting JMS message to correlate the request and the response. For more information, see
pub.jms:reply.
If you create a service that contains multiple asynchronous requests, make sure to link the JMSMessage field (uuid or JMSMessageID) whose value will be used as the reply message's JMSCorrelationID to another field in the pipeline. Each asynchronous request produces a JMSMessage document in the pipeline. If you do not link the uuid or JMSMessageID field from the JMSMessage document to another field, the next asynchronous request (that is, the next execution of the pub.jms:sendAndWait service), will overwrite the previous JMSMessage document. When you invoke the pub.jms:waitForReply service, the pipeline will contain only the input needed to retrieve the reply to the last request. The pipeline will not contain the information needed to retrieve replies to the previous requests. (That is, there will be nothing to map to the correlationID input parameter of the pub.jms:waitForReply service.)
Each JMS connection alias can be configured to have its own 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). If you want to use the client side queue with the pub.jms:sendAndWait service, the JMS connection alias specified for connectionAliasName must be configured to have a client side queue. If the JMS connection alias is configured to use a client side queue and useCSQ is set to true, 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. When the JMS provider becomes available, Integration Server sends messages from the client side queue to the JMS provider.
If the client side queue is not used (useCSQ is set to false or the JMS connection alias is not configured to have a client side queue), Integration Server throws an ISRuntimeException if the JMS provider is not available when this service executes. Make sure to code your service to handle this situation.
Integration Server can write messages to the client side queue only for messages sent as part of an asynchronous request/reply. That is, if async is set to true (the default) and the JMS provider is not available at the time this service executes, Integration Server places the message in the client side queue. The client side queue cannot be used for a synchronous request/reply.
The client side queue cannot be used if the reply destination is a temporary queue. Consequently, if useCSQ is set to true, values must be specified for the destinationNameReplyTo and destinationTypeReplyTo input parameters. If these parameters are not specified, Integration Serverthrows the following ServiceException when it executes the pub.jms:sendAndWait service: [ISS.0134.9082] The client side queue cannot be used with a send and wait request if the reply destination is a temporary queue.
The JMS provider populates the header fields in the JMSMessage output parameter after it successfully receives the sent message from Integration Server. If the JMS provider is not available at the time the pub.jms:sendAndWait executes and useCSQ is set to true, the header fields in the output JMSMessage will not be populated. Instead these fields will be blank or be set to 0 (zero).
The pub.jms:waitForReply service cannot be used to retrieve response to requests that were routed through the client side queue. To retrieve the response, create a JMS trigger that subscribes to the reply to queue.
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.
When sending a message as part of a transaction client side queuing cannot be used. That is, the useCSQ field should be set to false. If useCSQ is set to true, Integration Server throws a JMSSubsystemException when the pub.jms:sendAndWait service executes. A JMS message is sent as part of a transaction if the JMS connection alias specified in connectionAliasName:
Uses a transaction type of LOCAL_TRANSACTION or XA_TRANSACTION.
Connects to the
webMethods Broker using a cluster connection factory to which the multisend guaranteed policy is applied.
Integration Server uses an XA transaction to perform a two-phase commit when sending JMS messages.
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. It can only be consumed by the connection from which it was created.
To use a dedicated listener (MessageConsumer) to retrieve replies for a request, the pub.jms:sendAndWaitinvocation must specify the following:
The
connectionAliasName input parameter must specify a JMS connection alias that is configured to use a dedicated message consumer. Specifically, the
Create Temporary Queue and
Enable Request-Reply Listener for Temporary Queue check boxes must be selected for the alias.
The request must be asynchronous. The
async input parameter must be set to false.
There must not be a value specified for the
destinationNameReplyTo input parameter.
If you want more control over the actual javax.jms.Message that Integration Server sends to the JMS provider, you can create a Java service that calls the com.wm.app.b2b.server.jms.producer.ProducerFacade class, which will create a javax.jms.Message. See:
com.wm.app.b2b.server.jms.producer.ProducerFacade.createBytesMessage(String) com.wm.app.b2b.server.jms.producer.ProducerFacade.createMapMessage(String) com.wm.app.b2b.server.jms.producer.ProducerFacade.createObjectMessage(String) com.wm.app.b2b.server.jms.producer.ProducerFacade.createStreamMessage(String) com.wm.app.b2b.server.jms.producer.ProducerFacade.createTextMessage(String) The Java service calling this API must return an Object of type javax.jms.Message, which can then be mapped to the JMSMessage/body/message input parameter of the pub.jms:sendAndWait service.
When creating the javax.jms.Message with the com.wm.app.b2b.server.jms.producer.ProducerFacade, you can use the javax.jms.Message setter methods to set the values of the message headers and properties directly. You can also set the value of message headers and properties using the input parameters of the pub.jms:sendAndWaitservice that you use to send the message. If you set the message headers and properties both ways, the values provided to the pub.jms:sendAndWaitservice take precedence.
Software AG recommends that you use a pub.jms:sendAndWait service to create and send the JMS message. This method may provide better performance on average. However, if you want to send a StreamMessage or a MapMessage, you need to use the appropriate com.wm.app.b2b.server.jms.producer.ProducerFacade API.
To send a StreamMessage, create a Java service that calls com.wm.app.b2b.server.jms.producer.ProducerFacade.createStreamMessage(String).The Java service calling this API must return an Object of type javax.jms.Message. Map the javax.jms.Message object to the JMSMessage/body/message input parameter of the pub.jms:sendAndWait service.
To send a MapMessage, create a Java service that calls com.wm.app.b2b.server.jms.producer.ProducerFacade.createMapMessage(String).The Java service calling this API must return an Object of type javax.jms.Message. Map the javax.jms.Message object to the JMSMessage/body/message input parameter of the pub.jms:sendAndWait service.
If you use the input parameter JMS_WMClusterNodes to override the policy applied to the cluster connection factory, make sure to code the invoking service to handle any exception that the Broker Server throws when policy requirements are not or cannot be met. For more information about policy override scenarios that might result in an exception from Broker Server, see Using webMethods Integration Server to Build a Client for JMS.
When using Universal Messaging as the JMS provider, the JMS client can use synchronous or asynchronous publishing. To ensure delivery of a persistent JMS message (deliveryMode is set to PERSISTENT), Integration Server always uses synchronous publishing to send a persistent JMS message to Universal Messaging.
You can use the
pub.jms:send service to specify a destination for response messages when you do not need to wait for the response. The act of waiting for a response message comes with extra overhead for
Integration Server which is unnecessary if you merely want to specify a JMSReplyTo destination but do not want the sending service to wait for a reply. For more information, see the
JMSMessage/header/replyTo input parameter description and Usage Notes in
pub.jms:JMSMessage.
See Also