🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Java API: Working with the Topic String
Hello together,
we are currently starting with Solace development and want to build different use cases. First we created a topic hierarchy, where for example a source systems stores different data parts in the topic string like:${sourceSystem}/${stage}/${businessObject}/${objectId}
Now we want to extract different parts of this hierarchy on a message basis to build some business logic on top of it.
I saw an unsolved Github issue for the Spring Cloud Framework to store this destination string in the Message header.
In the core Java API you are getting the destination as a string and have to cut it manually in pieces.
public void onReceive(BytesXMLMessage message) { String[] levels = message.getDestination().getName().split("/");
What is your suggested way to deal with this problem ?
Furthermore, is this not a common use case for the topic hierarchy ?
For example based on the ${sourceSystem}
i want to route my messages to a different topic endpoint .
Thank you
Comments
-
Hi @Dominik,
I can't help but feel you're approaching this problem the wrong way. Don't do topic filtering in your business logic. Let the broker do that for you - that's what it's there for.
So, instead of having your application receive all messages and direct them to different topic endpoints, have the topic endpoints subscribe to different topics:
System1 endpoint subscription: system1/>
System2 endpoint subscription: system2/>
That way you have your sourceSystem directed to different applications without the application even being aware of this, or seeing messages for other systems. Even better, don't use topic endpoints, use queues with topic to queue mapping. Much better!2