1

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.

amsmota
  • 171
  • 2
  • 11

2 Answers2

2

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.

Artem Bilan
  • 113,505
  • 11
  • 91
  • 118
  • Hi, thanks for your reply. I did know about connecting flows, including the disadvantages of doing it. I'm trying this way because this is a prototype to investigate SI and DSL in our use cases. Also (something I did not investigated yet) it looked to me a better approach to have the same infrastructure for the entire process (error handling and control bus). And finally because our use cases can be a little more complex than what I said. I do know a little about SI, I worked a lot with it in 2008 and 2009, but yes, maybe I should read more about the current implementation. Cheers. – amsmota Jun 01 '16 at 16:13
  • I'm not sure in your concern about `disadvantages`. You say: "read somewhere in the future by some specific state". So, what is the point to connect the `JdbcOutboundGateway`'s output with the `dbDataMessageSource()` by your wishes. The output of the first `.handle()` is an input of the next `.handle()`. Like it is with familiar ``. Since you would like to *poll* DB, there is no any inputs. That's why `MessageSource` is one of kind to start the flow, but not continue. For that purpose you should use the same `JdbcOutboundGateway`. Please, don't mix concerns. – Artem Bilan Jun 01 '16 at 16:19
  • Mix concerns? Well, the fact is JdbcOutboundGateway does exactly what I described, having a Pollable MessageSource (a JdbcPollingChannelAdapter) that can be used in the middle of the flow... Nevertheless, I'm doing some Proof Of Concepts, not production work, so now is the time to mix concerns. And I tend to follow Gerald M. Weinberg's principles, in this case "If you cannot think of three ways of abusing a tool, you do not understand how to use it." :) – amsmota Jun 02 '16 at 15:18
  • The Polling Source can't be in the middle of the flow, because flow is based on the input-output concepts from one endpoint to another. Since Polling Source doesn't have an `input` it can't be triggered by the output of the previous endpoint, therefore it can't be in the middle. Don't forget that `IntegrationFlow` inserts channels between endpoints. The Polling Source is one-way input components, so it can be only in the beginning of the flow. – Artem Bilan Jun 02 '16 at 15:25
0

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.

amsmota
  • 171
  • 2
  • 11