amsmota
amsmota

Reputation: 171

MessageSource as a flow step

I'm writing a SI flow using the SI-DSL, so let me start by saying I don;t know if this question is related to the Si-DSL only or to both SI and SI-DSL.

My use case is like this
- getting messages from a Queue - saving the messages in a database table - retrieve those messages by selecting messages at some specific state at some point in the future - further processing the messages...

My problem is the 3rd step. It will be easy if the 3rd step was the 1st, because I could just use a JdbcPollingChannelAdapteras a MessageSource. However, I could not find a way of using one in the middle of the flow. So, in DSL terms, I can do (where dbDataMessageSource is a JdbcPollingChannelAdapter)

IntegrationFlows
    .from(dbDataMessageSource(), p -> p.poller(Pollers.fixedRate(24, TimeUnit.HOURS)))

But I cannot do

IntegrationFlows
            .from(Jms.messageDrivenChannelAdapter(...))
            .handle(new JdbcOutboundGateway(...)
            .handle(dbDataMessageSource(), p -> p.poller(Pollers.fixedRate(24, TimeUnit.HOURS)))

Instead of ".handle" I tried to use gateway, bridge, handleWithAdapter, but noting worked.

Any ideas?

Cheers.

Upvotes: 1

Views: 792

Answers (2)

amsmota
amsmota

Reputation: 171

Well, I found a way to do this the way I mentioned. I can rewrite the JdbcOutboundGateway, that includes both a JdbcMessageHandler and a JdbcPollingChannelAdapter, and make this last one configurable so I can set the polling time and the output channel the way I want it.

A little dodgy but it should work.

Cheers.

Upvotes: 0

Artem Bilan
Artem Bilan

Reputation: 121427

Not sure why everyone think that the flow must be declared only as a single IntegrationFlow object, but no one stops you to divide it to several of them and connect with the channel. One can finish with .channel("foo"), another can start with the IntegraitonFlows.from("foo"). Although that looks like you can omit that channel and connect both flow into one.

The IntegrationFlow just lets you to minimize the code count and really omit some boilerplate snippets. But if your logic requires channels, or has several phases, it is fine to divide and enjoy the results.

So, you logic is like:

  • read from the Queue and store in DB. It is one IntegrationFlow
  • poll the DB with dbDataMessageSource() and process. Another independent flow.

Please, read more about the Core Spring Integration. The Java DSL just tries to simplify the configuration, but it still follows with the same channel -> endpoint -> handler principles from the SI Core.

Upvotes: 2

Related Questions