To Publish Messages
This operation allows you to create a new JMS Message and send it to the specified destination, be it a Queue or a Topic. With it, you can configure not only the content of the message, but also all the headers that may be need.
Sending a Message to a Queue
When used in its default form, the connector will publish whatever is in the message payload:
<jms:publish destination="invoiceQueue" config-ref="JMS_config"/>But what happens if the payload is not in the correct format, and you actually need to make a transformation? You could place a DataWeave transformation before the publish operation, but that would cause the message payload to change and impact the operation placed after the publish operation.
To avoid this undesired impact, you can now place the transformation inside the publish operation:
<jms:publish destination="invoiceQueue" config-ref="JMS_config">
<jms:message>
<jms:body>#[%dw 2.0
output application/json
---
payload.payments
]</jms:body>
</jms:message>
</jms:publish>Now, the transformation can be used for generating the content that will be published, without producing a side effect on the message in transit.
Publishing a Message to a Topic
The publish operation can be used also to publish a Message to a given Topic destination.
All the configurations of the operation and the Message are identical, but the destinationType parameter has to be declared as a TOPIC destination:
For the same example seen before, if instead of sendin a message to the Queue we want to publish it to a Topic, we`ll do:
<jms:publish destination="invoiceEvents" destinationType="TOPIC" config-ref="JMS_config">
<jms:message>
<jms:body>#[%dw 2.0
output application/json
---
payload.payments
]</jms:body>
</jms:message>
</jms:publish>Customizing Message Delivery
Each JMS Message has a set of headers that enables you to communicate metadata like the time to live, or the priority of the Message. This kind of metadata regarding the Message being published can be configured from the publish operation parameters.
Implementing a Priority Queue
In order to implement a priority queue, we need to assign a priority different than the default to some messages. We can do so using the priority parameter in the operation:
<jms:publish priority="#[attributes.queryParams.priority]" destination="priorityQueue" config-ref="JMS_config"/>How to Control Message Time To Live
Every JMS Message being published is sent with a timeToLive header that declares for how long the Message should be available for someone to consume it before it evicts. The timeToLive and timeToLiveUnit parameters in the publish operation allow you to configure the value of that JMS header for each Message published:
<jms:publish timeToLive="#[vars.timeToLive]" timeToLiveUnit="SECONDS"
destination="#[vars.destination]" config-ref="JMS_config"/>If you are using JMS 2.0, you can also control the deliveryDelay of the Message, which is how long to wait before making the Message available to consumers:
<jms:publish deliveryDelay="${msgInitialDelay}" deliveryDelayUnit="MILLISECONDS"
destination="#[vars.destination]" config-ref="JMS_config"/>Declaring a Reply Destination
For the cases where you need an asynchronous reply to the Message being sent, the JMS publish operation allows us to declare any reply-to destination. This destination will be communicated as a JMS Header to the consumer of the Message, and is the destination were we should expect a reply to be sent.
To declare the reply-to destination, we add it to the Message definition:
<jms:publish config-ref="JMS_config" destination="#[vars.invoiceProcessorDestination]">
<jms:message>
<jms:reply-to destination="${completionEventsDestination}" destinationType="TOPIC"/>
</jms:message>
</jms:publish>Propagating The Correlation ID
The publish operation allows you to configure what is the correlationId for the outgoing Message.
First you need to configure whether or not you want to send the correlationId when publishing the Message using the sendCorrelationId parameter. This parameter can be set to ALWAYS (always send the header), NEVER (never send the header) or AUTO (the default, use the application configuration).
Then, you can either use the correlationId of the Event that is sending the Message, or you can configure your own custom correlationId in the message builder:
<jms:publish config-ref="JMS_config" sendCorrelationId="ALWAYS" destination="#[attributes.headers.replyTo.destination]">
<jms:message correlationId="#[attributes.headers.correlationId]"/>
</jms:publish>Configuring Message Properties
Every JMS Message can have a set of properties, which can be used in many different ways, like to provide compatibility with other messaging systems or create custom message selectors.
Some of these properties are well-known JMS standards, but others depend on the implementation or custom user configurations. The publish operation allows you to configure all these properties directly in the Message.
Setting User Properties
Whenever you need to set a property for an outgoing Message, all you have to do is use the properties element in the Message and do an inline declaration of a Map using DataWeave:
<jms:publish config-ref="JMS_config" destination="${bridgeDestination}" destinationType="TOPIC">
<jms:message>
<jms:body>#["bridged_" ++ payload]</jms:body>
<jms:properties>#[{
AUTH_TYPE: 'jwt',
AUTH_TOKEN: attributes.queryParams.token
}]</jms:properties>
</jms:message>
</jms:publish>Setting JMSX Properties
The JMSX properties are a set of well-known properties defined in the JMS spec, containing metadata regarding the Message. In order to configure this properties, you can declare them inline as part of the Message element:
<jms:publish config-ref="JMS_config" destination="${bridgeDestination}" destinationType="TOPIC">
<jms:message>
<jms:body>#["bridged_" ++ payload]</jms:body>
<jms:jmsx-properties jmsxGroupID="#[vars.currentGroup]" jmsxUserID="${username}"/>
</jms:message>
</jms:publish>