@StreamListener(target = Sink.INPUT, condition = "headers['eventType']=='EmployeeTransferredEvent'"

General Discussions
8

Hi @ajinkyasagar,

Hope you had a great weekend!

I think there are multiple options and the option you choose really depends on how complex your filtering rules are, how important it is to be able to scale up/down the individual handlers, and how important it is for you to use spring cloud stream.

Here are the options as I see them:

  1. Create a topic republisher that reads all the messages and publishes them back out on more detailed topic hierarchy which includes the name or whatever fields you want to filter on. This would then allow you to have each microservice subscribe using solace topic wildcards * and > to filter on what you want.
    The upsides of this option: From a broker performance perspective this is great as the broker excels at topic routing. It also makes the messages available for other apps to consume them on a more well-defined topic hierarchy if necessary and allows you to create separate, independent microservices that consume your messages that can easily be scaled up/down. This can be done using Spring Cloud Stream only if that is preferred.
    The down side here is that you are obviously now running a separate app that consumes all the messages and republishes them which takes extra resources. Another down side might be that topic routing may not handle your filtering needs; topic routing will handle your example of filtering on names that start with a certain letter, but if you need to do math it won’t help you there.

  2. You use Spring Cloud Stream w/ the routing function as I recommended above.
    Upsides: You can use SPEL for filtering so it can handle more complexity than topic routing, you’re using Spring Cloud Stream for simpler development, the broker doesn’t have to execute selector processing.
    Downside: As far as I know you can’t scale the functions that the routing function calls individually so you’d have to scale the entire app up/down. This is the downside you referenced above as well…

  3. You don’t use Spring Cloud Stream, but instead if you still want to use Spring you could use our Spring Boot Java JCSMP or JMS Starters. These will allow you to use Selectors which allow you to do filtering as you wish.
    Upside: JCSMP/JMS allow you to define your selectors per microservice so you get your desired filtering and ability to scale your microservices up/down independently.
    Downsides: Broker has to process selectors which is not as performant as topic routing, but this may not matter depending on your use case. You’re not using Spring Cloud Stream so development may be a bit more complex.

Sorry it’s not an easy answer. There are quite a few variables here :wink: