問題タブ [saga]

NEventStore: 5.1
簡単なセットアップ: WebApp (Asp.NET 4.5) == コマンド側

実際には処理されなかったコマンドから生成されたイベントを際限なく待つサガ/プロセスマネージャーに目を向けて、コマンドを失わないための「正しい」方法を探しています。

旧: ディスパッチャ

最初は同期コマンドを使用していましたが、 sagas /process-managersに注目して、最初にそれらを保存してから SyncDispatcher (または AsyncDispatcher) を介して取得する方が安全だと考えました。それ以外の場合、それが私の懸念です。サガがコマンドを送信しようとして、 app-crash/powerloss/...が原因でコマンドが終了しなかった場合、コマンドは失われ、誰も知りません。

そこで、コマンド ストリームを作成し、それに各コマンドを追加しました。そのIsDispatchedコマンドがすでに処理されているかどうかが示されました。
それはうまくいきました。

PollingClient と Command-Stream

ディスパッチャーが廃止されたので、に切り替えましたPollingClient。私が失ったのはDispatched情報です。

起動時の問題が発生しました:現在の最新のチェックポイントから
単純にポーリングを開始しましたが、アプリケーションを再起動すると、コマンドが保存されていてもクラッシュ前に実行されず、失われた可能性がありました (実際に発生しました)。

コマンドの基本的な結果を（ドメイン以外の）イベントとして別のストリームに保存するというアイデアに出くわしました。 このストリームにはとイベントが含まれます。 アプリケーションが起動するたびに、最新の command-id または command-checkpoint-number が抽出され、その直後のコマンドをロードするために使用されます...

CommandSucceededCommandFailed

質問

• 私の懸念は、sync コマンドの処理が saga で生成されたコマンドを失う危険性につながるということでしょうか? はいの場合、なぜですか?
• これは一般的に良い考えですか? 1 つの大きなコマンド ストリームですか?
• これは一般的に良い考えですか: 一般的なコマンド結果イベントをストリームに保存しますか?

DateTime プロパティをもう 1 つ追加して saga データ クラスを更新しましたが、すべてがうまくいきませんでした。スキーマは更新されず、各サガ メッセージで例外が発生し始めましたが、そこには重要なデータがなかったので、テーブルを削除しました。

それ以来、saga データ テーブルは次のように作成されています。

Saga データ クラスのフィールドはスキーマに存在しません。

ここに私のサガデータクラスがあります:

何が問題なのですか？サガ データ テーブルを削除する前は、まったく問題ありませんでした。

更新: データ クラスから 2 番目の DateTime フィールドを削除し、テーブルを再度削除すると、機能し始めました。これはなぜですか？

Unique 属性でマークされた 1 つのプロパティを持つ saga データ クラスがあります。ただし、これは、NServiceBus がこのフィールドに同一の値を持つ複数のサガを作成することを妨げませんでした。

ここに私のデータクラスがあります:

マッピングは次のとおりです。

データが値を取得する方法は次のとおりです。

そして、ここに、saga 永続化テーブル (Azure テーブル ストレージ) に表示されるものを示します。

このように機能すると思われますか、それとも何か不足している可能性がありますか?

特定の Database-Value が変更されるのを待つべき Saga があります。どうすればこれを達成できますか?

例：

そのOrderのbool「承認済み」がtrueの時にメールを送りたい。ただし、これには数時間または数日かかる場合があります。Saga に数時間後に再度確認するように指示するにはどうすればよいですか? 私は Sagas と NServiceBus を初めて使用するので、答えは簡単かもしれませんが、見つけられませんでした。

オブジェクトのリストを取得するハンドラーがあり、そのオブジェクトのリスト内の各アイテムに対して、イベントを発行します。以下のコードのようになります。

私の使用例は、message.List.Count が優れていることを期待しているため、foreach ループに時間がかかる可能性があることです。

したがって、100 個のエントリ オブジェクトのうち 50 個を処理したとします。Bus.Publish(entry) は何らかの理由で失敗します。ハンドラーは再試行ポリシーに従って再試行しますが、最初から 100 エントリすべての処理を開始します。

これは理想的ではないので、どこかで進行状況を維持したかったのです。MongoDB を永続レイヤーとして使用しているので、ハンドラーを Saga でラップできると考えました。Saga は、処理されたすべてのエントリを追跡します。ハンドラーが失敗した場合、再試行し、以前に達成した進捗状況に注意して Saga を取得することが期待されます。

ただし、簡単なテストを行った結果、ハンドラーの実行が完了するまで、Saga は (この場合は MongoDB に) コミットされないと想定するようになりました。したがって、私のユースケースでは、これは役に立ちません。

私の主な質問は、Handler が完了する前のある時点で Saga を DB にコミットできるかどうかです。これにより、すべてのエントリが発行のために送信された後に独自の永続性を記述する必要がなく、Saga のその他の利点がいくつか得られます。

私の2番目の質問は、これが実際に可能である場合、この特定の例でそれを行うべきですか? これは Saga の有効な使用法ですか、それとも別のアプローチが適切ですか?

これは私の初めての質問です。不明確または不完全な場合は申し訳ありませんが、さらに詳しい情報を提供する方法を教えてください。

CQRS + ES を使用してメール チケット システムを構築しようとしています。そのため、メールは会話に参加し (一種の Outlook 会話ですが、参加基準は異なります)、これらの会話には、人々がやり取りできるチケットが割り当てられます (タグ付け、ステータスの更新、メモの追加など)。

MailReceived現在、メールが受信されると、イベントを発生させる新しいメール集約が作成されます。
ProcessManagerルーター (または saga ルーター) は、条件に基づいて一致する「ConversationSaga」を見つけようとするか、新しいものを作成します。サガは、会話 ID をメール集約に割り当てるコマンドを送信します -->ConversationAssignedメールを生成します。

最後のイベント はConversationAssigned、チケットを生成するか、会話 ID に基づいて既存のチケットを更新する、チケット バウンド コンテキストによってインターセプトされます。チケットが作成/更新されると、イベントは ConversationSaga にルーティングされ、必要なコマンドが送信されます (ApplyTicketToMail --> MoveMailToFolder --> ...)

私の質問は次のとおりです
。1- 複数のメールをリンクする会話 ID として佐賀 ID を使用するのは異常ですか?
2-Conversation Aggregateルートを作成する可能性を確認していましたが、イベントソーシングにはまだ慣れておらず、AggregateRoots 内でイベントソースエンティティを処理する方法がわかりません (Mail をイベントソース集約にする必要があります)。

PS:私は C# を使用しており、MsSql DB と nhibernate を使用しており、メッセージングは​​ RabbitMq を使用しています。

CQRS とイベント ソーシング パターンを使用してシステムを作成しています (そう願っています)。ある読み取りモデルによって保存された統計データと、別の読み取りモデル (両方とも過去のイベントによって作成された) によって保存されたユーザー設定データに基づいて、ビジネス上の決定を下す必要があります。結果がそのデータに依存するビジネス ロジック ルールを配置するのに適した場所はどこですか?

• それはコマンドですか (コマンドで読み取りモデルに格納されたデータを取得できますか)?

• サガのような他の抽象化レイヤー？

現在、レガシー システムを nservicebus 5.0 に移行中です。ビジネス データを saga データに移行する一般的な最善の方法は何ですか? たとえば、2 日以内のキャンセルのみを許可する OrderCancellationPolicy サガがある場合、従来のシステムからの過去の注文によって、どのようにしてこれらの新しいサガが正しい状態で作成されるのでしょうか?

2 つの選択肢があります。1 つ目は、SQL スクリプトを記述して、saga 永続テーブルを事前設定することです (nhibernate 永続を使用しています)。もう 1 つは、MigrateOrderDataCmd など、従来の注文からのデータを含む特別なインポート メッセージを作成することです。インポート スクリプトは、サガが処理できるこれらのメッセージを送信し、サガ データをそのように設定できます。

この分野のガイダンスをいただければ幸いです。