1

私は SI-DSL を使用して SI フローを書いているので、この質問が Si-DSL のみに関連するのか、SI と SI-DSL の両方に関連するのかはわかりません。

私のユースケースは次のようなものです
-キューからメッセージを取得する-メッセージをデータベーステーブルに保存する-将来のある時点で特定の状態でメッセージを選択してそれらのメッセージを取得する-メッセージをさらに処理する...

私の問題は3番目のステップです。JdbcPollingChannelAdapter を MessageSource として使用できるので、3 番目のステップが 1 番目であれば簡単です。しかし、流れの途中で使い道が思い浮かびませんでした。したがって、DSL 用語で、私はできる (ここで dbDataMessageSource は JdbcPollingChannelAdapter である)

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

しかし、私はできません

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

「.handle」の代わりに、gateway、bridge、handleWithAdapter を使用しようとしましたが、うまくいきませんでした。

何か案は？

乾杯。

4

2 に答える 2

2

フローを単一のオブジェクトとしてのみ宣言する必要があると誰もが考える理由はわかりませんが、フローIntegrationFlowをいくつかのオブジェクトに分割してチャネルに接続することを誰も止めません。で終わる.channel("foo")ものもあれば、で始まるものもありIntegraitonFlows.from("foo")ます。そのチャネルを省略して、両方の流れを 1 つに接続できるように見えますが。

を使用すると、コード数を最小限に抑え、いくつかのIntegrationFlowボイラープレート スニペットを実際に省略できます。ただし、ロジックにチャネルが必要な場合、または複数のフェーズがある場合は、分割して結果を楽しむことができます。

したがって、ロジックは次のようになります。

  • キューから読み取り、DB に格納します。一つですIntegrationFlow
  • DB をポーリングしdbDataMessageSource()て処理します。別の独立した流れ。

Core Spring Integration の詳細をお読みください。Java DSL は構成を単純化しようとしているだけですが、それでもchannel -> endpoint -> handlerSI コアと同じ原則に従います。

于 2016-06-01T15:38:54.693 に答える
0

さて、私は私が言及した方法でこれを行う方法を見つけました。JdbcMessageHandler と JdbcPollingChannelAdapter の両方を含む JdbcOutboundGateway を書き直し、最後の 1 つを構成可能にして、ポーリング時間と出力チャネルを希望どおりに設定できるようにします。

少し危険ですが、うまくいくはずです。

乾杯。

于 2016-06-01T16:23:43.737 に答える