問題タブ [enterprise-integration]

Camel 流暢なビルダーを使用して、一連の複雑なルートを設定しています。そこでは、RecipientList機能を使用した動的ルーティングを使用しています。

場合によっては、受信者リストに存在しないメッセージング エンドポイントが含まれるという問題が発生しました (たとえば、 のようなものseda:notThere)。

簡単な例は次のようなものです。

エクスチェンジがまだ存在しないエンドポイントにルーティングしようとした場合にエラーがスローされるように、ルートを構成するにはどうすればよいですか?

私は Camel 2.9.x を使用しており、デッド レター チャネルとさまざまなエラー ハンドラの実装を既に試しましたが、(一見) エラーや警告はログに記録されませんでした。

私が見る唯一のログは、Camelが存在しないエンドポイントに送信（しようとしている）していることを示しています：

前もって感謝します！

優先度の異なる JMS メッセージの処理の問題を解決しています。私は EIP 実装者として Apache Camel フレームワークを使用しています。消費する必要がある 2 つのキューがあります。最初のメッセージには優先度の高いメッセージが含まれ、2 つ目のメッセージには優先度の低いメッセージが含まれます。

ここで、次の手順を実行するループを含む特別なコンポーネント「ミキサー」を作成したいと思います。

1. プライオリティ キューを調べる
   • メッセージが含まれている場合は、それを出力キューに送信し、ループの先頭に移動します (メッセージが多数含まれている場合は、最初の 10 個のメッセージを処理してからステップ 2 に進みます)。
   • メッセージが含まれていない場合は、ステップ 2 に進みます。
2. 2番目のキューを見てください
   • メッセージが含まれている場合は、それを出力キューに送信し (ただしメッセージは 1 つだけ)、ループを繰り返します。
   • メッセージが含まれていない場合は、ループを繰り返します

ご覧のとおり、大量のメッセージがある場合は特別な比率を維持したいと思います (優先キューから 10 / 2 番目のキューから 1)。プライオリティ キューにメッセージがない場合は、2 番目のキューのメッセージをすぐに処理できます。複数の入力キューから消費する EIP Resequencer のようなものが欲しいです。

上記のコンポーネント「ミキサー」を持つ2つのキューから消費するラクダのルートを探しました。私はそのようなものが欲しいです:

しかし、私はそれを行う方法を見つけられませんでした。1 つのルートに入力できるのは 1 つだけです。より多くの入力がある場合、Camel はルートを内部的に複製し (2 つの独立したルートを持つことになります)、動作は次のようになります。

ここで説明されているように。そして、それは私が望んでいるものではありません:-(。私の問題を解決する方法について何かアイデアはありますか?事前に感謝します!

アプリケーションには次の Camel ルートがあります。

プロセッサがデータを検証し、メッセージを「importUri」に転送するとすぐに、「webServiceRoute」が応答ユーザーを返すようにします。しかし、現在、「importUri」交換が完了するまで、応答が呼び出し元に返されないようです。私の質問は、受信したリクエストを別のキューに非同期に転送する「正しい」方法は何ですか? 「importUri」交換からの応答はありません (つまり、InOnly である必要があります)。

ルート(Apache Camel の言い回し) についての私の理解では、ルートはあるエンドポイントから別のエンドポイントへのデータの流れを表し、途中でデータに対して EIP タイプの操作を実行するさまざまなプロセッサで停止します。

それがルートの正しい/公正な評価である場合、同じ内部に複数のルートが必要であると思わCamelContextれる問題をモデル化しています(私はSpringを使用しています):

1. ルート 1: Source-1 からデータを抽出して処理し、に変換してList<SomePOJO>から、アグリゲーターに送信します。
2. ルート 2: Source-2 からデータを抽出して処理し、さらに に変換してからList<SomePOJO>アグリゲーターに送信します。
3. ルート 3:ルート 1 とルート 2 の両方List<SomePOJO>からを受信するまで待機し、その後、集約リストの処理を続行するアグリゲーターが含まれています。

ここに問題があります:両方List<SomePOJO>の s が同時にアグリゲーターに到着する必要があります。または、アグリゲーター Bean は、2 つのリストを 1 つに集約して集約されたリストを送信する前に、両方のルートからデータを受信するまで待機List<SomePOJO>する必要があります国道3号線の残り。

これまでのところ、次の疑似コードがあります<camelContext>。

次にJavaで：

私の質問

1. 私の基本設定は正しいですか？つまり、direct:aggregatorエンドポイントを正しく使用して、のアグリゲーターroute-1との間route-2でデータを送受信していますか?route-3
2. アグリゲーターは期待どおりに機能しますか? Beanの実行には 5 秒しかかからないが、extractor1Beanの実行には 2 分かかるとします。t=5 で、アグリゲーターは からデータを受信し、終了するまで (2 分間) 待機を開始し、残りのデータを集約する必要があります。はい？route-1extractor2route-2extractor1extractor2

複数のルートに適用されるエラーハンドラーを定義しました。

SpecificProcessor クラスのいずれかで例外が発生すると、次のログが記録されます。

ここで、例外がルート 1 またはルート 2 で発生したかどうかを識別するのに役立つ何かを出力したいと思います。

どうすればそれを達成できますか？

.log(${routeId}) などを試しましたが、うまくいきません。

どうもありがとう！

私は現在、次のキャメルルートを持っています:

今のところ、意味のあるものを集約するつもりはありません ( completionSize=1)。本当にテストAggregationStrategyしているだけです。これが私の戦略です：

そしてまた私のpostProcessor豆：

このコードを実行すると、preProcessorBean が正しく実行されていることを示すログ メッセージが表示されます。また、メッセージを正しく「集約」し、最初のメッセージが到着MyAggregationStrategyした後にそれを渡すこともわかります（これも. ただし、次の出力が に表示されます。postProcessorcompletionSize=1postProcessor

なぜpayloadNULLになるのか誰にもわかりますか？内部で初期化されているはずではありませんMyAggregationStrategyか?!? もっと多くのコードを投稿できてうれしいですが、AggregationStrategyAPI の使い方が間違っていることが原因だと思います。

私のアプリケーションは、さまざまな顧客から (XML の形式で) 注文を受けたミドルウェア (MW) として機能する必要があります。 XML をこれらのコンポーネントの 1 つに

この MW は、最初に着信要求を検証し、優先チャネルを介して注文を要求した顧客に確認を送信します。チャネルと顧客のエンドポイント情報は、受信 XML に存在します。

注文を受け取ったら、優先チャネルを介してさまざまなサプライヤーに注文要求を xml 形式で送信する必要があります。データベースにサプライヤーとその優先チャネル情報があります。

つまり、エンタープライズ統合のユースケースです。

コア Java テクノロジを使用してそれを行うことを計画していました。これが私が計画していたアプローチです。

着信要求のタイプ (JMS キュー、ファイル システム、HTTP、Web サービス要求 (rest/soap)) ごとに 4 つのリスナー/エントリ エンドポイントがあります。これらのリスナーは、xml 文字列を jms キューに配置します。これは受付係として機能し、プロセスを非同期にします。

これで、キューでリッスンする jms コンシューマーができます。このコンシューマは、xml 文字列を解析して Java オブジェクトに変換します。検証を実行します。確認を顧客に送信します (確認は、顧客の好みに基づいて送信する必要があります。好みに基づいて確認を送信する確認プロセッサ ファクトリを使用します)。検証が完了したら、この pojo を別の pojo 形式に変換して、xstream/jaxb がさらにそれを xml 形式にマーシャリングし、soap、jms、ファイル要求などを通じて、優先チャネル (サプライヤー設定は db に保存されます) でサプライヤーに送信します。

このCAMELリンクhttp://java.dzone.com/articles/open-source-integration-apacheに出くわした人もいれば、完璧なソリューションを提供しているように見え、これがエンタープライズ統合のユースケースであることがわかりました。

専門家は、キャメルがこれに適したソリューションであるとアドバイスしてください。または、Spring 統合のような他のエンタープライズ統合フレームワーク、ESB はこの場合により有益です。誰かが ESB がこの種のユースケースを解決するリソースを教えてくれれば。それは本当に役に立ちます。

時間の制約があるため、すべてのソリューションを検討することはできませんでした。専門家の提案を探して、1 つに集中できるようにします。