0

同様の、しかしより一般的な質問がここで尋ねられました: Camel プロセッサとサービス エンドポイントのビジネス ロジック

次に、次のフローを考えます (E1 と E2 はプロセッサを表し、キャメル フローのようにエンドポイントではありません)。パラメーター(p,q) でトリガーします。

Route: E1 -> E2

E1自体は、パラメーター(p,q)を使用して HTTP 要求を発行し、応答データd (sync) を受信して​​、これをE2に転送します。E2 は、 (p,q,d) に基づいて処理を続行します。したがって、基本的に追加データで入力を充実させます。

呼び出されるエンドポイントには、統合されるデータが含まれます。つまり、これは変更されず、将来的に構成可能にする必要はありません。

私は2つの解決策を試しましたが、どちらも私には間違っているようです:

  • エンドポイントを使用し、メッセージのヘッダー (または交換のプロパティ) に(p,q)http4:urlをピギーバックします。
  • http-request を明示的/プログラム的に発行し、応答を処理し、期待される(p​​,q,d)を転送するプロセッサを使用します。便宜上、camel-context 内producerTemplateに送信された状態でこれを行いました。http4:url

最初の問題は、多くのボイラープレート procducer などが追加され、実際のルートが非常にわかりにくくなることです。2 番目のアプローチでは、処理を新しいクラスにオフロードできますが (ルートに混合しないでください)、それでも camel-context が必要であり、これに依存します。

これに対する推奨事項は何ですか。「ビジネスロジックと配線を混ぜないでください」などのより抽象的なステートメントを除いて、周りには何も見つかりませんでした。

*実際のユースケースを追加*

E1 は 2 つの日付 (期間) と部門名を取得し、指定された期間に指定された部門にあったすべての名前を取得します。次に (上記ではこの詳細を無視しました)、名前が分割され、名前ごとに、指定された期間に保存されたすべてのデータが取得されます。この最後のステップでは、最初の入力からの日付が必要です (したがって、これらはルート全体に渡される必要があります)。

ありがとう、マルクス

4

1 に答える 1

0

クラウスに感謝:

好きなようにメッセージを充実させることができます。キャメルはあまり気にしません。プロセッサ/ pojo を使用する場合は、Java コードだけで、好きなことを行うことができます。エンリッチ / pollEnrich DSL を使用する場合、AggregationStrategy を使用してエンリッチメントを「マージ」します。

http4:url エンドポイントの結果によって、ルートの元の入力を充実させました。このようにして、データの「フェッチ」を実際のビジネスロジックから分離することができました。これは、残り(特にラクダ)から独立した Processor/AggregationStreategy Bean で発生するようになりました。

ありがとうマーカス

于 2013-10-04T08:10:07.183 に答える