🎄 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.
How to get SDTMap properties in Spring Cloud Stream
We are using SDTMap to set custom application properties in one service which produce message..which uses normal springboot service. We access solace message api and create SDTMap.
In Consumer we use spring cloud stream to receive and process.
How to get SDTMap properties in Spring Cloud Stream?
Comments
-
Hi @anan1401,
User properties can be directly accessed as Spring message headers.
For example, suppose you published a message containing a string user property called
some-user-property
, you can then get it in your consumer as follows:@Bean public Consumer<Message<?>> sink(){ return message -> { message.getHeaders().get("some-user-property", String.class); // other message processing }; }
On the other hand, if what you're asking about are
SDTMap
payloads, then you can get that as-if you're getting any other type of message payload.e.g.:
@Bean public Consumer<SDTMap> sink(){ return payload -> { // Do something with this SDTMap payload }; }
4 -
Thanks Team for your support.
We tested and see the output. Any way to differentiate SDTMap header with other headers?Example:
Set SDTMap:SDTMap map = JCSMPFactory.onlyInstance().createMap();
try {
map.putString("Test", "Vishwa");
map.putString("Test1", "Vishwa1");
map.putString("Test2", "Vishwa2");
} catch (SDTException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
message.setProperties(map);Spring cloud response:
headers={solace_expiration=0, deliveryAttempt=1, solace_destination=GRACE/VCA/Initializer, solace_timeToLive=0, solace_receiveTimestamp=0, Test2=Vishwa2, target-protocol=kafka, Test1=Vishwa1, acknowledgmentCallback=com.solace.spring.cloud.stream.binder.util.JCSMPAcknowledgementCallbackFactory$JCSMPAcknowledgementCallback@422641b8, solace_discardIndication=false, Test=Vishwa, solace_dmqEligible=false, solace_priority=-1, solace_redelivered=false, solace_correlationId=25151c30-e629-47f5-b340-20f7f2397560, id=8be4f1ec-da0e-d9b9-6477-9f8cde2a04e7, contentType=application/json, timestamp=1631869287739}]
0 -
Hi @as63010,
The short answer is to do that you'd want to include your
SDTMap
in the payload of your message so it's kept separate OR to use a naming convention that allows you to separate the ones you want. Note that all of the Solace Message Headers start with "solace_" so you could easily filter those out.The longer answer:
When you useJCSMPProperties.setProperties
you are essentially setting a bunch of "User Properties" on the outgoing SMF message as defined in the javadocs. The user properties section of the SMF message is where custom headers are stored so your headers will be intermingled with custom headers added by the framework itself. When a SMF message arrives at the Solace binder we essentially read out the defined Solace headers and assign them as defined in that link and then any other user properties are just added to the Spring Message as headers as well so you can use them as desired. This is why they are all bundled together.@Jeff please feel free to chime in if I'm missing something here
1 -
As an alternative solution to what @marc suggested, you could also publish messages that have a single user property of type
SDTMap
and set all your custom properties in there. That way when its consumed by a Spring Cloud Stream application, those would all be grouped up under a single Spring message header.2 -
@Jeff said:
As an alternative solution to what @marc suggested, you could also publish messages that have a single user property of typeSDTMap
and set all your custom properties in there. That way when its consumed by a Spring Cloud Stream application, those would all be grouped up under a single Spring message header.Nice, I like that idea!
1