Azure で実行されているバスにコマンドを発行する必要があるイベントを消費する、MSMQ から実行されている既存のサービスバスがあります。
Azure を外部に公開し、内部メッセージ用に msmq を保持しています。
これを達成するために送信専用バスのインスタンスを新たに作成しようとしましたが、運が悪かったので、いくつかのポインター/コード サンプルをいただければ幸いです。
この質問に対する答えが見つかりませんでした。現時点での回避策は、トランスポート プロトコルとして Azure を実行する nservicebus をホストする Web API をセットアップすることです。したがって、MSMQ コンシューマーが API を呼び出し、その API がコマンドを Azure バスに送信します。理想的ではありません...まったく、それが私が思いついたものです。
少し異なるが、ゲートウェイ構成に関する関連する質問を作成しました: Nservicebus msmq to azure queue using gateway
Yves Goeleven がここにまとめた例があります。
すべてのコメントをこの回答に集約し、さらに追加しました。
NServiceBusゲートウェイを使用してサイト間通信を行ってみてください。
ゲートウェイは、複数のサイト間のブリッジです。各サイトは独自のキューイング テクノロジーを選択できます。共通にする必要があるのは、シリアライザーだけです。(ただし、これはバグとして記録されています)。
記事で現在サポートされているチャネル タイプは http/https のみであるが、Azure/Amazon SQS などのクラウド サイトが将来的に計画されていると記載されている場合、それはブリッジング テクノロジのみを指しています。Azure (または Amazon SQS) ゲートウェイ チャネルがあれば、中間の HTTP(S) ステップは必要ありません。
現在の例:
a) サイト A の MSMQ Q => HTTPS チャネル => サイト B の Azure Q
b) サイト A の MSMQ Q => HTTPS チャネル => サイト B の SQL Q
今後の例:
a) サイト A の MSMQ Q => サイト B の Azure Q でもある Azure チャネル
b) サイト A の MSMQ Q => Azure チャネル => サイト B の SQL Q
チャネルは、ゲートウェイで使用されるトランスポート プロトコルを参照します。エンドポイントで使用されるキューイング テクノロジーは関係ありません。