問題タブ [eai]

システム A が新しい製品を作成し、私は NServiceBus を使用して新しい製品をシステム B に送信しています。システム A の既存の製品に更新がある場合は常に、システム B にもすぐに送信されます。

この新しいシナリオがあります。製品には、開始日と終了日によって決定される有効期間があります。新しい製品は、システム A で今日、「開始日」を指定して将来のある時点 (たとえば 5 日後) に作成することができます。システム B には、有効な製品のみが供給されることになっています。

したがって、製品が将来の開始日で作成される場合、システム A がメッセージを NServiceBus にプッシュするようにしますが、統合レイヤーがシステム B へのメッセージの発行を遅らせるようにします。

これは、NServiceBus を使用してどのように実現できますか。それとも、別の標準的なアプローチがありますか?

ありがとうございます。

市内各地に多くのショールームがある顧客に Java アプリケーションをインストールしており、セントラル オフィスと通信するための堅牢な方法を実装する必要があります。
アプリケーションがそれらを処理できるように、これらのショールームから製造部門に MySQL データベースに保存された販売注文を送信するという考え方です。問題は、インターネット接続が非常に不安定で、数日間アクセスできない場合があることです。どのショー ルームにもサーバーがなく (クライアント PC のみ)、セントラル オフィスにはパブリック IP がないため、販売注文を xml として添付した電子メールを送信することが解決策になると考えました。これは良い解決策ですか、それとも代わりに JMS を使用する必要がありますか? JAVA Mail と JMS 以外にこれを行う方法はありますか?

見込み客から、CICS ホストでホスト サービスを使用するための統合戦略の提案を求められています。

通常、この選択はお客様の CICS スペシャリストとの専用ミーティングに委譲するため、ここでは少しバランスが取れておらず、アドバイスが必要です。

経験則として、私は通常（CICSかどうかに関係なく）次のことをお勧めします。

• トランザクションが必要ない場合は WebServices を公開します
• トランザクションが必要な場合は MQ エンドポイントを公開します

ただし、議論するための特定のCICSの知識は実際にはありません。私は特に以下との共体験に興味があります:

• セットアップの複雑さ
• パフォーマンス
• MQ による分散トランザクション
• Dell Boomi の使用経験

CICS ホストに接続するための Boomi のベスト プラクティスへの提案やリンクはありますか?

私の他のオプションは次のとおりです。

• CICS Transaction Gateway を使用してネイティブ コネクタ プラグインを構築します。ただし、これにはかなりの労力と Boomi 側でのネイティブ Java 開発が必要であり、その利点についてはよくわかりません。さらに、これは Boomi=>CICS からの呼び出しには機能しますが、CICS=>Boomi 呼び出しをリッスンすることはできません。
• DB2 ストアード・プロシージャーを呼び出し、次に COBOL を呼び出します。これはすでに AS400 で行っており、オーバーヘッドとパフォーマンスの点で制限があることがわかっています。また、以下にリンクされている記事では、さらなる制限が提案されています。このソリューションにも、Boomi=>CICS は許可するが、CICS=>Boomi からの呼び出しは許可しないという制限があります。

ここで最も関連性の高い 2 つの質問は次のとおりです。

• メインフレームと Java を接続する実績のあるソリューションはどれですか? MQ シリーズ / IBM CICS Transaction Gateway で最も優れているのはどれですか?
• Windows デスクトップ アプリケーションからの CICS への接続

どちらも Dell Boomi へのリンクはありません

トピック交換でパブリッシュ/サブスクライブ メッセージング パターンを実装する RabbitMQ を使用して小さなクラスを作成しました。この pub/sub の上に、メソッドとプロパティがあります。

1. void Send(Message, Subject) - サブスクライバーが処理できるように、宛先トピックにメッセージをパブリッシュします。

2. MessageReceivedEvent - このメッセージング インスタンスでメッセージ受信イベントをサブスクライブします (メッセージング インスタンスは、作成時に目的のサブスクライブ トピックにバインドされます)。

3. SendWaitReply(Message, Subject) - メッセージを送信し、送信されたメッセージ ID (またはタイムアウト) と一致する相関 ID を持つ応答メッセージが受信されるまでブロックします。これは基本的に、pub/sub パターンに基づくリクエスト/リプライまたは RPC メカニズムです。

私が選択したメッセージング パターンは、システムの設計方法により、多少決まっています。SendWaitReply の潜在的な問題を軽減するために返信先キューを使用できることはわかっていますが、それはいくつかの要件を破っています。

現在、私の問題は次のとおりです。

• Listen イベントの場合、リスナーが単一のスレッドで実行されるため、メッセージはイベント サブスクライバーを介して同期的に処理されます。これにより、大量のメッセージを処理する際 (つまり、Web API からのイベントを消費するバックエンド プロセス内) に深刻なパフォーマンスの問題が発生します。イベントをサブスクライブしてから、タスクまたはスレッドプールを使用してコールバックのコレクションを並行してディスパッチするのではなく、コールバック関数を渡すことを検討しています。スレッドの安全性は明らかに呼び出し元の関心事です。これが正しいアプローチかどうかはわかりません。

• SendWaitReply イベントについては、メッセージ リスナー ループからすべての受信メッセージを取得し、空でない相関 GUID が含まれている場合はそれらを ConcurrentDictionary に配置するハック ソリューションと思われるものを作成しました。次に、SendWaitReply メソッドで、ConcurrentDictionary をポーリングして、送信されたメッセージの Id と一致するキーを含むメッセージを探します (または一定期間後にタイムアウトします)。これを行うためのより高速でより良い方法がある場合は、本当に調査したいと思います。おそらく、現在ブロックされているすべての SendWaitReply メソッドに、新しいメッセージが利用可能であり、継続的にポーリングする代わりにすべての Id をチェックする必要があることを通知する方法でしょうか?

  ---

2014 年 10 月 15 日更新

多くの徹底的な調査の結果、RabbitMQ または AMQP の範囲でSendWaitReplyについて上記で提示した特定のユースケースを直接処理するための「公式の」メカニズム/ヘルパー/ライブラリは存在しないという結論に達しました。当分の間、現在のソリューションに固執します (より堅牢な実装を調査します)。提供された RPC 機能を使用することを推奨する回答がありましたが、残念ながら、これはリクエストごとに排他的なコールバック キューを使用する場合にのみ機能します。これは、同じトピック交換ですべてのメッセージ (要求と応答) を表示するという私の主要な要件の 1 つを破っています。

さらに明確にするために、SendWaitReply要求の典型的なメッセージ ペアは次の形式です。

• Topic_Exchange.Service_A => some_command => Topic_Exchange.Service_B
• Topic_Exchange.Service_B => some_command_reply => Topic_Exchange.Service_A

これにより、 Topic_Exchange.#にリスナーを設定するだけで、さまざまなサービスを介して非常に深い「コール スタック」をトレースするためのすべてのシステム トラフィックを確認できる、強力なデバッグおよびロギング手法が得られます。

TL; DR - 以下の現在の問題

アーキテクチャ レベルからの後退 - メッセージ リスナ ループにまだ問題があります。EventingBasicConsumerを試しましたが、まだブロックが表示されます。私のクラスが機能する方法は、呼び出し元がクラスのインスタンスによって提供されるデリゲートにサブスクライブすることです。メッセージ ループがそのデリゲートでイベントを発生させ、それらのサブスクライバーがメッセージを処理します。メッセージイベントハンドラーをインスタンスに渡す別の方法が必要なようです。同期処理を強制する1つのデリゲートの背後にすべてが置かれるわけではありません。

JMS では、トピックは中心的な概念です。パブリッシュ/サブスクライブ パターンの表現です。

1. パブリッシャーは自分のメッセージをチャネルに公開します
2. サブスクライバーはそのチャネルにサブスクライブし、そのチャネルからメッセージを受信します
3. すべてのサブスクライバーがメッセージを受信すると、チャネルはメッセージを削除します

MSMQ/.NET に同様の機能はありますか?

注: パブリッシャーは、サブスクライバーの数またはサブスクライバーの数を気にする必要はありません。

RESTful エンドポイントからのメッセージを消費し、AMQP エンドポイントに送信するために、Apache Camel で メッセージ トランスレータ パターンを実装しています。

含まれているアプリケーションは Spring Boot に基づいているため、Camel の「spring-boot」コンポーネントを使用して 2 つのフレームワークを統合しています。この spring-boot リンクのドキュメントで示唆されているように、@Configuration拡張する注釈付きクラス内に Camel ルートを実装していRouteBuilderます。

私の質問は、実際の RESTful エンドポイントや構成済みの RabbitMQ ブローカーを必要とせずに、この翻訳の単体テストを行う方法に関するものですか? 多くのオンラインの例とCamel in Actionの本を読みました...そして、Camel ルートを単体テストするための典型的なアプローチは、ルートを単体テストにカットアンドペーストし、1 つまたはより多くのエンドポイント URL は " mock:whatever" で表されます。

たぶんうまくいくと思います...しかし、それは非常に脆弱であり、単体テストを更新せずに後で誰かが実際のコードを変更した場合、テストスイートは認識しません。

次のように、いくつかの Spring ベースの単体テストの例をモックに適応させようとしました。

私の希望は、Camel が単体テストからこれらのエンドポイント URL を取得し、それらをモックとして登録し、実際のコードがそれらの URL を使用しようとしたときに、実際のエンドポイントではなくモックを使用することでした。

ただし、これが可能かどうかはわかりません。単体テストで実際の URL を使用するとIllegalArgumentException、「実際の」エンドポイント URL をインスタンスに挿入できないようですMockEndpoint(" " で始まる URL のみmock:)。

mock:...単体テストで" " エンドポイント URL を使用しても、テスト対象のクラスの実際のエンドポイント URL に関連付けるものがないため、役に立ちません。そのため、実際のエンドポイント URL は決してオーバーライドされません。実際のコードが実行されると、通常どおり実際のエンドポイントが使用されます (目標は、RabbitMQ への外部依存なしでテストできるようにすることです)。

ここで本当に基本的なレベルで何かが欠けていますか? 単体テストがこのようなクラスに偽のルートを挿入する方法があるように思われるため、テスト中のコードは実際のエンドポイントからモックエンドポイントに気付かずに切り替えることができます. あるいは、コードをリファクタリングして、匿名Processorクラスをスタンドアロン クラスに昇格させることができると思います...そして、ルートとは別に、その翻訳ロジックを単体テストできます。しかし、それは不完全なテストのように思えます。