問題タブ [rebus]

Rebus がこのシナリオで機能することを実証するために、POC を作成する必要があります -

イベントをリッスンし、それに応じて処理する複数のサブスクライバー。BuiltInContainer と構成を使用してこれを構成するにはどうすればよいですか? 複数のキューと複数のエンドポイントを構成する必要がありますか? また、コンテナーの単一のインスタンスまたは複数のインスタンスを構成する必要がありますか?

MSMQ 経由で Rebus へのメッセージ送信をトリガーするボタンを含むビューを提供する ASP.NET Web プロジェクトを使用しています。メッセージ ハンドラーは長時間実行される操作 (15 ～ 30 分) であり、メッセージの処理中に rebus コマンド ハンドラーが Web に更新を送信するようにしたいと考えています。

私の Web アプリケーションには、SignalR を介してクライアントにステータス メッセージをプッシュする CommandStatusReply のハンドラーがあります。ImportProducts メッセージが処理されたときに、すべての CommandStatusReply メッセージが「バッチで」送信されることを除いて、すべてが機能します。代わりにすぐに送ってほしいです。これは可能ですか？その場合、何が欠けていますか？

Bus.Send()、Bus.Reply()、および Bus.Publish() を試しましたが、Bus.Reply/Send を TransactionScope(TransactionScopeOptions.Suppress) でラップしようとしても無駄でした。

パブリッシュする予定のメッセージを延期したいのですが、Rebus はメッセージを送信キューに返します。実際の受信者にそれらを送信することを期待していました。

私はここで何か間違ったことをしていますか、それとも遅延関数を間違って理解しましたか?

共有Domain.Messagesアセンブリにメッセージ タイプがあり、ファイル内の RebusConfigurationSection を使用して、そのアセンブリから別のエンドポイントにメッセージをマップする必要があり.configます。

そのようです：

それはうまくいきませんが、どういうわけかそれは可能ですか、それとも実装を使用してIDetermineMessageOwnershipそこでルーティングを処理する必要がありますか?

テスト環境で Rebus Servicebus コンソール アプリケーションを Windows サービスとして実行しています。サービスバスは次のように作成されます。

アプリ設定は次のようになります。

ご覧のとおり、RabbitMQ @localhost と通信しています。

これまでのところ、これは魅力のように機能します。

ただし、同じサーバー上に Servicebus の別のインスタンスをセットアップする必要があり (これはテストサーバーであり、複数のブランチがあります)、いくつかの問題に遭遇しました。

2 番目のインスタンスの appsettings は次のようになります。

最初のサービスへのメッセージの送信を開始すると、2 番目のサービスによってもメッセージが受信されていることがわかります。これは、同じ RabbitMQ インスタンス @localhost を使用しているためだと思います。

私はサービスバスの専門家ではありませんが、別のキューを使用するだけでこの問題を解決できると思っていましたが、そうではありませんでした。

仮想ホストについて読んだことがありますが、それでよろしいですか?

私がしたいこと：

メッセージを service1 に送信 -> 特定のデータベースに保存

メッセージを service2 に送信 -> 別のデータベースに保存

実際に何が起こるか:

メッセージを service1 に送信 -> service1 AND service2 がメッセージを取得し、両方のデータベースに保存します。

誰かが私を正しい方向に向けてもらえますか? :)

メッセージを rebus にパブリッシュするときに、現在のユーザーに関する情報を取得して、ハンドラーとサガがアプリケーション ユーザー情報に透過的かつ正確にアクセスできるようにしたいと考えています。ソースコードで少し迷っていますが、基本的にはいくつかのことを設定しようとしています:

1. メッセージが発行されたときに実行され、現在のユーザー情報をヘッダーに入れるフック

2. メッセージの受信時にワーカーで実行され、ClaimsPrincipal.Current を書き換えるフック。

3. 処理が完了したときにワーカーで実行され、ClaimsPrincipal.Current をリセットするフック。

任意の提案をいただければ幸いです。

最初のメッセージでサガが MarkAsComplete を呼び出したときに IStoreSagaData.Delete が呼び出されていないことがわかりました。これは設計によるものですか？これにより、完了したサガのアーカイブを保持することができなくなります。