問題タブ [nservicebus-sagas]

タイトルは私が求めているものには適切ではないかもしれませんが、それを表現する良い方法が思いつきません.

基本的に、トランザクションがシステムに入力され、検証され、ビジネス ルールが適用され、トランザクションがデータベースに永続化されるシステムを設計しています。各トランザクションには定義済みのキーがあるため、コントローラー パターンを実装し、これらのステップを定義するサガを作成することを考えていました。

ただし、データの時限送信時に問題が発生します。指定されたカットオフ時間にさまざまなパートナーに送信する必要がある数千の異なるトランザクションがある可能性があります。指定されたパートナーのすべてのトランザクションがそのパートナーのファイルにある必要があります。私が見ていないのは、個々のサガを持つすべてのトランザクションを同時に起動して収集する方法です。

各トランザクションがカットオフ時間に起動するようにタイムアウトを実装することを考えていましたが、すべてのトランザクションをまとめるにはどうすればよいですか?

私が検討しているオプションの 1 つは、Quartz.Net を使用して各カットオフ タイムに実行する時間指定ジョブを設定し、そのジョブにメッセージをサガに発行させ、ConfigureHowToFindSaga 関数を使用してトランザクションのステータスを更新することです。これが最良の実装であるかどうかはわかりません。

スケジュールされたタスクを作成して開始しました

これで、サガの Handle() が MarkAsComplete() を実行する着信メッセージによって呼び出された場合、作成したスケジュールされたタスクはキャンセルされません。

タスクをキャンセルするにはどうすればよいですか?

NServiceBus で SAGA を作成しています。このサガは、変換して検証し、最後にインポートする必要がある文字列を処理しています。これら 3 つのアクションは別個のサービスです。NServiceBus の個別のハンドラーとしてアクションが必要です。NServiceBus でリクエスト/リプライ機能を使用しています。このような：

変換ハンドラは次のとおりです。

私の質問は次のとおりです。リクエストが transformHandler に送信されたとき。メッセージキューにメッセージが送信されます。次に、サーバーがクラッシュします。サーバーが再起動し、サーバーが TransformationRequest を取得し、機能しており、Saga に応答したいのですが、どうすればよいでしょうか? サガはもう生きておらず、.Register を処理できません。この問題を処理するにはどうすればよいですか?

ありがとうございました。

私はNHibernateでNServiceBusを使用しており、独自のプロセスでバスをホストしています。私が使用している構成は次のとおりです。

と：

この構成により、SQL Server データベースに、サガで指定したフィールドを使用してサガのテーブルが作成されます。これは素晴らしいことです。

しかし、Saga が実行されて完了すると、NServiceBus はレコードを saga テーブルに挿入していないように見えます。

テーブルはありますが、データはありません。

これは予想されるべきですか？サガが正常に完了した後、NServiceBus は永続的にサガ エントリを削除しますか?

最近、プロジェクトで Nservice バスの実装を開始しました。私たちは Saga Service を初めて使用し、以下のシナリオに直面しています。

サガに 4 つのステップがあり、メッセージ 1 によってサガが開始されるとします。

メッセージ 2 は、いくつかの外部サービスによってトリガーされます。長時間実行できる message1 の処理が完了した後にのみ、 message2 を処理する必要があります。

どうすればこれを達成できますか? メッセージ2ハンドルでThread.Sleepを使用するか、メッセージ1の完了を確認した後、メッセージ2の到着を確認した後、メッセージ2の到着を確認した後、メッセージ1の処理の最後に呼び出される共通のメソッドを持つようなものを使用する以外に。

Service Matrix は使用していません。

前もって感謝します。

複数のメッセージ タイプを処理する NServiceBus 実装があります。

MessageData は次のようなものです。

CreateMessage には、そのハンドラーで MessageParts に追加される MessagePart があります。ConfirmMessage は、特定の MessagePart のステータスを更新します。

これはシナリオです:

1) 最初の CreateMessage が受信されます。これにより、Raven に Saga が作成され、MessagePart (ステータス "1") が MessageParts に追加されます。

2) 最初の ConfirmMessage が受信されます。これにより、Saga に最初に追加された MessagePart の Status が「1 2」に更新されます。これは、RavenDB のドキュメントに移動すると、ブラウザーで表示されます。

3) 2 番目の CreateMessage が受信されます。これにより、2 つ目の MessagePart が MessageParts に追加されます。データを見ると、最初の MessagePart のステータスは「1 2」ではなく「1」のままであり、これにより同時実行例外がスローされます (ActualETag は ExpectedETag と等しくありません)。

サガデータはメッセージタイプごとにキャッシュされているようです。そうですか？解決策はありますか？

ノート：

複数の IAmStartedByMessages を使用していますが、ConfirmMessage が CreateMessage の前にある場合、このメッセージは CreateMessage が処理されるまでキューに追加されます。