Login
Register
Contact- This topic has 1 reply, 2 voices, and was last updated 8 years ago by
.
-
Posts
-
-
We presently are sending XML based MQ messages to an internal Topic Queue using a custom service we have written. The consumer of the message would like us to set a custom JMS property, so that they can utilize a message selector to filter only the messages they are interested in receiving.
This is the current XML message before submission using the “SEND” action (send a message through a channel).
<pre title=”QAPB_Product.message” class=”lang:xhtml decode:true “><Message aggregation=”sequential” format=”XML”>
<XMLMapping namespace=”ns0″ node=”Product” type=”element” uri=”http://schema.amfam.com/apex/qapb”/>
<Parts>
<Value maxCount=”1″ minCount=”1″ name=”ProductState” type=”string”>
<XMLMapping namespace=”ns0″ type=”element”/>
<Enumerations>
<Enumeration value=”Application”/>
<Enumeration value=”Policy”/>
<Enumeration value=”Billing Account”/>
<Enumeration value=”Quote”/>
</Enumerations>
</Value>
<Value maxCount=”1″ minCount=”1″ name=”DestinationSystem” type=”string”>
<XMLMapping namespace=”ns0″ type=”element”/>
<Enumerations>
<Enumeration value=”Legacy”/>
<Enumeration value=”New Product”/>
</Enumerations>
</Value>
<Value maxCount=”1″ minCount=”1″ name=”productNumber” type=”string”>
<XMLMapping namespace=”ns0″ type=”element”/>
</Value>
<Value maxCount=”1″ minCount=”1″ name=”changeEffDate” type=”timestamp”>
<XMLMapping namespace=”ns0″ subtype=”date” type=”element”/>
</Value>
<Value maxCount=”1″ minCount=”1″ name=”messageTimeStamp” type=”timestamp”>
<XMLMapping namespace=”ns0″ subtype=”dateTime” type=”element”/>
</Value>
<Message maxCount=”0″ minCount=”0″ name=”Risk” ref=”QAPB_RiskType”>
<XMLMapping namespace=”ns0″ type=”element”/>
</Message>
</Parts>
</Message>
0 -
Roland,
This is a great question and the platform has some nice features to allow any level of control for what we call “raw” or “protocol” messages. I’ve pulled a bunch of documentation here to answer your question. We will be adding some of this source documentation to the community site with the Ruby documentation update coming soon.
“How do I add JMS properties to MessageQueue messages”
High-Level
Messages are sent and received over a channel of a specific type e.g. HTTP, FILE, MessageQueue, UDP, TCP, etc. These channel types represent the various protocols that the NexJ Enterprise Application Platform supports. If you just send your payload message over a Send step, Send/Receive step, or the (integration-send-receive function to a channel, you are getting the settings for that channel as defined in the channel itself with any overrides in the connections section of your environment file. If you want to override channel “protocol” settings on a message-by-message basis, such as HTTP headers or JMS properties, you can wrap your payload in a Protocol message (also known as a Raw message). This is done by placing your formatted payload in the body part of a Protocol message, then sending the combined message over your channel.
Note: whenever you receive a message over a channel, you are receiving a Protocol message. This is why your payload is always in the “body” part and other protocol specific properties are available.
Details
To programmatically create a message use the (message… function. A message’s format defines how it is marshalled between external and internal format. e.g. between canonical form and XML. So, as you have already done, your payload will be defined as a QAPB_Product message. (see attachment)
Raw, or Protocol, messages are special types of system messages that vary by the type of channel on which they are received or sent. All raw messages have the following parts:
- channel – the channel name that the message was received on
- body – the body of the message. (not applicable to an HTTP Get)
- correlationId – an identifier used to correlate messages. Useful in asynchronous settings.
Additional parts are available by channel type. These may be inspected in the Integration/Messages tab of your model as HTTP, Mail, MessageQueue, UDP, TCP, File, ObjectQueue. They are all based on the Raw message type. The MessageQueue message structure may be viewed here. The properties available on the MessageQueue protocol message are:
- properties (jmsErrorCount, jmsMaxErrorCount, jmsBackoffDelay, jmsOldMessageId, jmsOldDestination)
- priority – message priority 0..9
- persistent – boolean
- ttl – time-to-live
- type
- replyTo – reply-to destination name
- node – source node
- user
- protected
So your code would look something like:
12345678910111213(define payload (message (: :class "QAPB_Product")(: productNumber "12345")(: DestinationSystem "DestSys");...))(define msg (message (: :class "MessageQueue")(: body (format-message payload))(: priority 9)(: properties(message (: myCustomProperty "productSelector"))))); send msg via step or function hereI’ve included stripped-down documentation for the standard MessageQueue Channel properties here for your information as well.
Integration Channels are abstract representations of the Network Transport Layer. MessageQueues represent JMS Queues and Topics to support P2P and publish/subscribe communication. MessageQueues are bound to JNDI JMS resources.
Properties
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.
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.
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.
Example:
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) 1
-
- You must be logged in to reply to this topic.