Retrieve destination information in JMS Connector
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}.
Comments
-
If I am understanding your question, you are asking about publishing to a dynamic destination using the JMS Connector as a target/publisher?
scst_targetDestinationis a header that, when set, overrides the value you put injms_destination. So you're on the right track.Here is a simple example of a dynamic destination which goes in your
transform-headerssection of yourapplication.ymlscst_targetDestination = "my/destination/prefix" + headers.foo + "/" + headers.bar
In this example, without explicitly setting it,
jms_destinationat runtime, will be set tomy/destination/prefix/<source message value for custom header foo>/<source message value for custom header bar>0 -
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?
0 -
Hi,
I am looking into this. The reason we removed the
jms_destinationwas 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.
0
