Type to start searching...
Abstract integration endpoint representing a Message Queue.
acknowledgement
Message acknowledgement: transacted - upon successful commit, auto - as soon as the message is received, lazy - automatic with possible duplicate messages.
| Valid values based on“string”. | |
|---|---|
| transacted |
This is the default. If the associated transaction is committed, the consumed messages are acknowledged, and any produced messages are sent. If it is rolled back, the produced messages are destroyed, and consumed messages are recovered. |
| auto |
Follows the policy of delivering the message once-and-only once but this incurs an overhead on the server. For each message, the session automatically acknowledges that a client has received a message as soon as the message is received. If a JMS provider or the message consumer crashes while it is processing a message, the message is subject to either re-delivery or loss. |
| lazy |
The session acknowledges message lazily, which provides faster message processing, with the penalty that some duplicate messages may be delivered multiple times if JMS fails. Only applications that are tolerant to message duplicates should use this acknowledge mode. |
alias : alias
Alias used for JNDI lookup.
Set manually based on the existing or desired server configuration of JNDI queue/topic names. During "Configure Server", any unknown queues or topics are created.| Valid values based on“string”. | |
|---|---|
| [\p{L}_][\p{L}\p{N}\-_]* | |
broadcast : boolean
True if the MessageQueue broadcasts messages to a topic (i.e. it is a publish/subscribe topic, not a P2P queue).
True if the channel is bound to a publish/subscribe topic and false if the channel is bound to a P2P queue. During "Configure Server", any JNDI resourse that is unknown, based on the alias name, will be created as a queue if broadcast is false or as a topic if it is true.category : string
The category of the channel.
clientId : string
Client identifier for durable broadcast (topic) subscriptions.
This property only applies to topics (broadcast=true).
Although both message models use a client ID, only the Pub/Sub actually uses it. You will see a client ID for a QueueConnection, but JMS does not currently use them. Some vendors might be using client IDs for something internal to their JMS server for queues. Check with your vendor's documentation to be safe.
combine
Resolution algorithm for multiple bound services processing the same message. (Default none - meaning multiple services with the same message is not supported)
| Valid values based on“string”. | |
|---|---|
| none |
Multiple services declaring the same message in their associated Interface Request messages are not supported. (Default) |
| first |
Only the first one among the bound services with a matching message in their Interface Request messages is invoked. |
| all |
All the services with a matching message in their Interface Request messages are invoked. When multiple services are bound to a channel and a message is forwarded to more than one of those services, the initial "this" variable in those services refers to the same object. This should be taken into account if the original message object can be updated in any of the services – you might want to modify a copy of the message instead. |
defaultUser : string
User account for processing the queue messages.
description : string
Channel description.
errorCount : nonNegativeInt
Maximum count of attempts at transacted processing of a message before forwarding it to the error queue (0 for unlimited).
The error count is always 1 for auto and lazy acknowledgement. Unlimited error count (0) combined with transacted acknowledgement can result in indefinitely retried processing, which can block delivery of other messages, consume significant system resources and pollute the log files. This situation is also known as "queue poisoning".| Valid values based on“int”. | |
|---|---|
| 0 (minInclusive) | |
errorQueue : string
Queue to which to forward the message if the processing fails.
idle : boolean
True to disable the channel if it is not used by an enabled channel.
loopback : boolean
Only valid for broadcast queues (publish/subscribe topic). True to allow processing of messages originating in the local node, false to skip them.
Only applicable to broadcast queues (JMS Topics). If false, outgoing messages are tagged with a 'node' property unique to this server. Incoming messages from the topic are checked for this property and are discarded if the message originated from this server. If loopback is true (or the queue is P2P and not publish/subscribe), messages originating from this server are not filtered. The loopback protocol is cooperative, i.e. both the sender and the receiver should refuse loopback messages in order to actually disable them; this is done so that one could deploy different metadata and change one's mind for unconsumed messages.maxReceivers : nonNegativeInt
Maximum queue receiver threads per server.
| Valid values based on“int”. | |
|---|---|
| 0 (minInclusive) | |
maxSenders : nonNegativeInt
Maximum queue sender connections per server.
| Valid values based on“int”. | |
|---|---|
| 0 (minInclusive) | |
persistent : boolean
True if the messages are persisted when sent.
Persistent messages are stored so that they can survive a failure in the messaging engine, when non-persistent messages can be lost.priority
Default message priority on sent messages, 0 is the lowest, 9 is the highest.
| Valid values based on“unsignedByte”. | |
|---|---|
| 9 (maxInclusive) | |
receive : boolean
True if the channel can receive messages.
replyQueue : string
JMS Message Queue on which the response message is expected.
If set, the JMSReplyTo attribute on javax.jms.Message is set to the Destination of the given channel. The receiving party of the JMS message then knows where to send the response, if any. The "replyQueue" attribute may be overridden at runtime by specifying the "replyTo" property on the message being sent.selector : string
JMS message selector.
A message selector allows a JMS consumer to be more selective about the messages that it receives from a particular topic or queue. It uses message properties and headers as criteria in conditional expressions. These expressions use Boolean logic to declare which messages should be delivered to a client, such as the JMSInput node.
For comprehensive documentation of the selector, refer to the J2EE API documentation for the interface javax.jms.Message.
The following demonstrates the construction of a message selector.
It comprises an identifier, such as the JMSPriority header, or an application controlled property myProperty1.
The selector string must specify an operator followed by a literal.
Identifiers
* Property or header field reference (such as JMSPriority, myProperty1)
* The following values are not possible: NULL, TRUE, FALSE, NOT, AND, OR, BETWEEN, LIKE, IN, IS
Operators
AND, OR, LIKE, BETWEEN, =, <>, <,>, <=, >=, IS NULL, IS NOT NULL
Literals
* The two Boolean literals, TRUE and FALSE
* Exact number literals that have no decimal point; for example, +25, -399, 40
* Approximate number literals. These literals can use scientific notation or decimal; for example, -21.4E4, 5E2, +34.4928
send : boolean
True if the channel can send messages.
stealth : boolean
True to supress the debug logging, unless nexj.system.core.meta.integration.Channel.<name> category dump logging is enabled.
subscription : string
Subscription name for durable broadcast (topic) subscriptions.
This property only applies to broadcast channels (topic) and is only applicable for services receiving messages. If the channel is defined with broadcast=true and has a subscription name, then the subscription will be durable.
Durability describes whether or not the server will hold onto a message if a subscriber is temporarily inactive. Message durability is different from message persistence. Durability is defined by the relationship that exists between a Topic subscriber and the server. A subscriber that is set up as durable will have messages sent to it held by the server if the subscriber is temporarily distracted doing something else or its session becomes inactive for some reason. Durability can only be established for the Pub/Sub (Topic) message model.
transactionTimeout : nonNegativeInt
The timeout (in seconds) for transactions started on the J2EE component. Applies only to incoming transactional channels.
Set to 0 to use server default transaction timeout.| Valid values based on“int”. | |
|---|---|
| 0 (minInclusive) | |
trusted : boolean
True if the queue can pass the authenticated user information.
User Propagation
When a JMS message is received, if the trusted flag is true then the framework will process the message as the user specified in the "user" JMS message property.
When a JMS message is sent, the current user principal name is stored in the JMS message property "user".
Visibility Protection Propagation
When a JMS message is received, if the trusted flag is true then the framework will process the message in an invocation context for which the protected flag is set to the value of the "protected" JMS message property. If the trusted flag is false, then the invocation context's protected flag will be true.
Unit of Work Property Propagation
When a JMS message is received, if the trusted flag is true then the framework will add the serialized property map in the "state" JMS message property to the current Unit of Work. These properties are the Unit of Work properties from the sender Unit of Work.
Unit of Work properties are set using the setValue and getValue methods on UnitOfWork.
ttl : nonNegativeLong
Default message time-to-live on sent messages in milliseconds (0 for unlimited).
| Valid values based on“long”. | |
|---|---|
| 0 (minInclusive) | |
warningTimeout : nonNegativeLong
Timeout in milliseconds before a warning is generated, 0 for infinite timeout.
| Valid values based on“long”. | |
|---|---|
| 0 (minInclusive) | |
Sequence of:
SenderProperties [0..1]
ReceiverProperties [0..1]
ServiceBindings [0..1] - Services bound to the incomming traffic on the channel.