Retrieve destination information in JMS Connector

dreamoka

May i know how to retrieve destination information using JMS Connector? Is jms_destination not longer accessible for us to use in transform header expression to put in scst_targetDestination?

Scenario : I would like to establish message bridge with my vendor using AMQP protocol.

I worried that the messages in the queue would have different jms_destination. As a result, I need to get destination information from the message and publish to my broker using solace protocol via topic address vendorA/{jms_destination}.

amackenzie

If I am understanding your question, you are asking about publishing to a dynamic destination using the JMS Connector as a target/publisher?

scst_targetDestination is a header that, when set, overrides the value you put in jms_destination . So you're on the right track.

Here is a simple example of a dynamic destination which goes in your transform-headers section of your application.yml

scst_targetDestination = "my/destination/prefix" + headers.foo + "/" + headers.bar

In this example, without explicitly setting it, jms_destination at runtime, will be set to my/destination/prefix/<source message value for custom header foo>/<source message value for custom header bar>

Dynamic Producer Destinations

dreamoka

yes i am asking about publishing to a dynamic destination using the Solace JMS Connector.

Based on my understanding, various message broker also support forward message from at Topic to a Queue which allowing messages that are published to a topic to be consumed by consumer (model of queue). Some messaging systems, like Solace, when the queue subscription is set up for a topic, the destination_name header of the message typically remains set to the topic name even through the message is delivered to a queue

May i know how can i get the topic name from the destination_name header?

amackenzie

Hi,

I am looking into this. The reason we removed the jms_destination was because it's an object, not a string. When propagated to Solace, it was fine, but once on the Solace broker and then published using another of our connectors to, say, SQS, the SQS connector has no way to deserialize this provider-specific object and messages would fail.

I understand your use case better having spoken with @yangsen and will report back here what our plans will be to address this. Sorry for the confusion.