JMS Adapter Reference

Specify the message acknowledge mode.
We recommend using acknowledge mode transacted.

Each single message sent to a JMS provider will be acknowledged by the JMS provider (not the recipient) after recipience.
Messages received from a JMS provider within an activity are acknowledged irrespective of subsequent activities. Consequently, if an error occurs during the execution of the activity diagram after message receipt, no rollback occurs.

Using Auto acknowledge mode in a model, a client must be prepared for possible loss of messages.

Duplicate acknowledge mode corresponds to Auto acknowledge mode. Additionally, the JMS provider may send the message more than once to the same destination.

The receiving application must be tolerant of receiving duplicate messages.

Messages sent to or received from a JMS provider within an activity are acknowledged explicitly after processing. Thus, the activity plays the role of a transactional lock.

If the acknowledgeMode is specified as Transacted , a Bridge JMS client acknowledges a consumed message only after the activity diagram that implements the JMS adapter functionality completes without throwing an exception.
This holds even if the activity diagram receives more then one message from, and/or sends messages to the queue during its execution.

Specify the expiration time of a sent message (refer also to the description of JMSExpiration in the JMS headers/properties).

Specify a selector to filter the received messages.

Refer to the official Java Message Service Specification for the selector statement syntax.

Specify the name of the queue or topic.

Specify a list of comma separated options in form of <name>=<value>. These options will be interpreted as native options.

The available options depend on the JMS provider.

Specify the JMS credentials in form of <user>/<password>.

Specify the port the JMS provider is listening to.

Protocol used to communicate with the JMS provider. The protocol normally is set automatically.

Specify a path to the JNDI file (.bindings), if a JNDI provider is used and protocol is file.

Specify the host name of the JMS provider.

Specify whether the JMS provider is also a JNDI provider. Default is false if not specified.

The JMS provider is a JNDI provider.

The JMS provider is not a JNDI provider (default).

Specify the name of the JMS connection factory.

This parameter returns the JMS message content, if it contains a String.

One of messageString, messageBlob, jmsStringMessage or jmsBlobMessage must be specified.

This parameter returns the JMS message including all message properties, if it is a String message.
See type JMSStringMessage for more details.

One of messageString, messageBlob, jmsStringMessage or jmsBlobMessage must be specified.

This parameter returns the JMS message, if it contains a Blob.

One of messageString, messageBlob, jmsStringMessage or jmsBlobMessage must be specified.

This parameter returns the JMS message including all message properties, if it is a Blob message.
See type JMSBlobMessage for more details.

One of messageString, messageBlob, jmsStringMessage or jmsBlobMessage must be specified.

This parameter contains the JMS message to be send, if it contains a String.

One of messageString, messageBlob, jmsStringMessage or jmsBlobMessage must be specified.

This parameter contains the JMS message to be send including all message properties, if it is a String message.
See type JMSStringMessage for more details.

One of messageString, messageBlob, jmsStringMessage or jmsBlobMessage must be specified.

This parameter contains the JMS message to be send, if it contains a Blob.

One of messageString, messageBlob, jmsStringMessage or jmsBlobMessage must be specified.

This parameter contains the JMS message to be send including all message properties, if it is a Blob message.
See type JMSBlobMessage for more details.

One of messageString, messageBlob, jmsStringMessage or jmsBlobMessage must be specified.

A client can use this header field to link one message with another. A typical use is to link a response message with its request message.
You can override JMSCorrelationID with a custom value.

This header field contains the delivery mode specified when the message is sent.

The JMS provider has to take extra care to ensure that the message is not lost in transit due to a JMS provider failure (default).

The JMS provider must deliver the message once and only once.

The JMS provider may lose the message due to a JMS provider failure.

This header field contains the destination, to which the message is sent.

When a message is sent, its expiration time is calculated as the sum of the time-to-live value specified on the send method and the current GMT value. On return from the send method, the JMSExpiration header field of the message contains this value. When a message is received, its JMSExpiration header field contains the same value.

The JMS does not expire.

The JMS message expires after the given period of time.

This header field contains a value that uniquely identifies each message sent by a provider. A JMSMessageID is a string value, which should function as a unique key for identifying messages in a historical repository. A provider defines the exact scope of uniqueness.

Combined with JMSCorrelationID , this header field is used to link messages, and thus to implement synchronous messaging.

This header field contains the message’s priority. JMS defines a ten-level priority value, with 0 as the lowest priority and 9 as the highest.

The JMS message has a normal priority (4 is the default value).

The JMS message has an expedited priority.

If a client receives a message with the JMSRedelivered indicator set to true, it is likely, but not guaranteed, that this message was delivered, but not acknowledged, in the past. In general, a provider must set this message header field to true whenever he redelivers a message.

The JMS message has been redelivered.

This is an indication to the consuming application that the message may have been delivered in the past and that the application should take extra precautions to prevent duplicate processing.

The JMS message has not been redelivered.

This header field contains the name of a destination, to which the recipient of the message should send a reply. The client sending the message specifies the JMSReplyTo field value.

This header field contains the time a client passes the message to a provider to be sent. The time is not the actual transmission time of the message; the actual send may occur later due to transactions or other client side queuing of messages.

This header field contains a message type identifier supplied by a client when the message is sent. Some messaging systems require that a message type definition is created for each application message and that each message specifies its type. In order to work with such JMS providers, JMS clients should assign a value to JMSType whether the application makes use of it or not. The assignment of a value ensures that the field is set properly for those providers that require a JMSType value.

This custom JMS header field contains the sender host.

This custom JMS header field contains the sender service.

This custom JMS header field contains a unique transaction ID (see Transaction ID).

Message acknowledge mode.
We recommend using acknowledge mode transacted.

Each single message sent to a JMS provider will be acknowledged by the JMS provider (not the recipient) after recipience.
Messages received from a JMS provider within an activity are acknowledged irrespective of subsequent activities. Consequently, if an error occurs during the execution of the activity diagram after message receipt, no rollback occurs.

Using Auto acknowledge mode in a model, a client must be prepared for possible loss of messages.

Duplicate acknowledge mode corresponds to Auto acknowledge mode. Additionally, the JMS provider may send the message more than once to the same destination.

The receiving application must be tolerant of receiving duplicate messages.

Messages sent to or received from a JMS provider within an activity are acknowledged explicitly after processing. Thus, the activity plays the role of a transactional lock.

JMS user.

Specify a path to the JNDI file (.bindings), if a JNDI provider is used and protocol is file.

Protocol used to communicate with the JMS provider. The protocol normally is set automatically.

Specify the host name of the JMS provider.

Specify the port the JMS provider is listening to.

JMSMessage

A client can use this header field to link one message with another. A typical use is to link a response message with its request message.
You can override JMSCorrelationID with a custom value.

The JMS provider has to take extra care to ensure that the message is not lost in transit due to a JMS provider failure (default).

The JMS provider must deliver the message once and only once.

This header field contains the destination, to which the message is sent.

When a message is sent, its expiration time is calculated as the sum of the time-to-live value specified on the send method and the current GMT value. On return from the send method, the JMSExpiration header field of the message contains this value. When a message is received, its JMSExpiration header field contains the same value.

The JMS does not expire.

The JMS message expires after the given period of time.

This header field contains a value that uniquely identifies each message sent by a provider. A JMSMessageID is a string value, which should function as a unique key for identifying messages in a historical repository. A provider defines the exact scope of uniqueness.

Combined with JMSCorrelationID , this header field is used to link messages, and thus to implement synchronous messaging.

This header field contains the message’s priority. JMS defines a ten-level priority value, with 0 as the lowest priority and 9 as the highest.

The JMS message has a normal priority (4 is the default value).

The JMS message has an expedited priority.

The JMS message has been redelivered.

This is an indication to the consuming application that the message may have been delivered in the past and that the application should take extra precautions to prevent duplicate processing.

This header field contains the name of a destination, to which the recipient of the message should send a reply. The client sending the message specifies the JMSReplyTo field value.

This header field contains the time a client passes the message to a provider to be sent. The time is not the actual transmission time of the message; the actual send may occur later due to transactions or other client side queuing of messages.

This header field contains a message type identifier supplied by a client when the message is sent. Some messaging systems require that a message type definition is created for each application message and that each message specifies its type. In order to work with such JMS providers, JMS clients should assign a value to JMSType whether the application makes use of it or not. The assignment of a value ensures that the field is set properly for those providers that require a JMSType value.

Message acknowledge mode.
We recommend using acknowledge mode transacted.

Each single message sent to a JMS provider will be acknowledged by the JMS provider (not the recipient) after recipience.
Messages received from a JMS provider within an activity are acknowledged irrespective of subsequent activities. Consequently, if an error occurs during the execution of the activity diagram after message receipt, no rollback occurs.

Using Auto acknowledge mode in a model, a client must be prepared for possible loss of messages.

Duplicate acknowledge mode corresponds to Auto acknowledge mode. Additionally, the JMS provider may send the message more than once to the same destination.

The receiving application must be tolerant of receiving duplicate messages.

Messages sent to or received from a JMS provider within an activity are acknowledged explicitly after processing. Thus, the activity plays the role of a transactional lock.

Each single message sent to a JMS provider will be acknowledged by the JMS provider (not the recipient) after recipience.
Messages received from a JMS provider within an activity are acknowledged irrespective of subsequent activities. Consequently, if an error occurs during the execution of the activity diagram after message receipt, no rollback occurs.

Using Auto acknowledge mode in a model, a client must be prepared for possible loss of messages.

Duplicate acknowledge mode corresponds to Auto acknowledge mode. Additionally, the JMS provider may send the message more than once to the same destination.

The receiving application must be tolerant of receiving duplicate messages.

Messages sent to or received from a JMS provider within an activity are acknowledged explicitly after processing. Thus, the activity plays the role of a transactional lock.