問題タブ [saga]

NServiceBus を使用して、外部サービスに顧客情報を要求し、タイムアウトを発生させるサガを作成しました。タイムアウトの期限が切れた後、そのサガは外部サービスに応答があるかどうかを確認します。それに応じて、対応する顧客のデータがあり、その対応する顧客がシステムに存在するかどうかを確認する必要がある状況があります (存在しない場合は作成する必要があります)。その後、それを参照する追加の監査エンティティを作成する必要があります。顧客 (それらを作成するために必要な情報がすべて揃っている場合)。

特定の顧客が存在するかどうかを確認する方法と、顧客を作成する方法がない場合はどうすればよいのだろうか。

これまでのところ、いくつかのアイデアがあります。

• メッセージ ハンドラー内から WCF サービスを呼び出す (チェック、作成)

• NSB 経由で Customer 境界コンテキストにメッセージを送信し、ID を含む応答を待ちます。

NServiceBusをエンタープライズサービスバスとして使用しています。開発中のソリューションには、すべてのクライアントアプリケーションから最大10,000件のメッセージを受信するオーケストレーションサービスがあります。アーキテクチャのパフォーマンスを改善し、その結果、提供されるソリューションを強化したいと思います。

Saga Dataクラスを使用していて、すべてのワーカースレッド間でアクセスを共有したい（これまでは1つのスレッドに設定しましたが、少なくとも10に設定したい）。複数のスレッドがアクセスしようとするとどうなりますか。同じ佐賀のスタンス？NSBはすでにそのような同時実行機能を提供していますか？自分で実装する必要がありますか？後者の場合、何かヒントはありますか？

前もって感謝します

製品カタログの公開プロセスを担当するサガ サービス ProcessCatalog があります。

クライアント アプリケーションは、PublishCatalog メッセージを送信します。各メッセージには、catalogid と項目リストが含まれています。

SagaId としてカタログ ID を選択しました。

ProcessCatalog サービスは、適切な順序で他のビジネス サービスを配置する長期実行ビジネス プロセスです。

公開プロセスを推進するために、ProcessCatalog は現在のカタログ アイテムの構成を念頭に置いておく必要があります。

同じユーザーが最初に UI ボタン​​を押して PublishCatalog(catalogId=1, Itemlist={A,B,C} ) を送信し、次にカタログの構成 (itemList ={A,D,E}) を変更するとどうなりますか? UI ボタン​​をもう一度クリックして、同じ CatalogId の別の PublishCatalog を送信しますか?

ProcessCatalog エンドポイントが 1 つのワーカースレッドで構成されている場合、すべて正常に動作します (私は思います)。しかし、workthread が 1 よりも大きく、2 つのメッセージが同時に処理される場合はどうなるでしょうか。2 番目のスレッドが 1 番目のスレッドの前に実行を完了するとどうなりますか?

これがビジネス設計上のバグなのか、それとも通常の技術的な問題なのかを尋ねます。

nservicebus を使用したワークフロー プロセスの実装中に問題に直面しています。バージョン2.0.1329.2を使用しており、実装しようとしているワークフローは非常に単純です。

計算する必要がある記事のリストがあります。ワークフローは、公開された最初のリストから始まります。その後、ユーザーは元のリストからいくつかの記事を追加または削除して他の公開を行うことができます。すべてのリストにはコード識別子があります。

リストのコードで識別されるオーケストレーション サービスを使用して実装しました。佐賀データには、リストが作成された記事のすべての参照もあります。

問題は、ユーザーが同じリストの別の公開中に記事のリストを公開すると、プロセス状態のロックがなく、このように同時実行制御はありませんが、後で終了するハンドラーには独自のデータが保持されます。

例えば：

1. 追加する 10 個の記事を含むリストが時間 [t] に到着し、オーケストレーション サービスがデータベースから saga データをロードし、時間 [t + 5] に変更して保存します。
2. 追加する項目が 1 つあるリストが時刻 [t+1] に到着すると、オーケストレーション サービスはデータベースから saga データをロードし、時刻 [t+4] に変更して保存します。

時間[t + 6]に6つの追加要素が必要ですが、5つの追加要素しか得られません..

動作は次のようにすべきだと思います: 同じリストに関連する場合、2 番目のメッセージは、最初のメッセージが終了するまでプロセス状態がロックされていることを検出する必要があります。

このため、ワークフロー プロセスの実装をサポートするようにオーケストレーション サービスが適切に作成されていないかどうか疑問に思っていますが、ワーカー スレッドの数を 1 つだけに設定すると、並列効率が失われます。

Ravenを使用してサガを永続化しています。実装したいのですがIFindSagas、2つのプロパティに基づいてサガを見つける必要があるため、機能しません。このインターフェースでは、単一のプロパティで単一のサガを検索することしかできません。SiteIdEmailAddressConfigureMappingISagaPersister

私はこのようなサガファインダーを実装しました

したがって、基本的には、との連結であるMySagaDatacalledにプロパティを追加しました。これで調べられます。これはハックのように感じます。sagaパーシスターを使用して、複数のプロパティでsagaを取得したり、1つのプロパティに基づいてsagaのリストを取得したりして、他のプロパティでフィルタリングしたりする方法はありますか？SagaLookupSiteIdEmailAddress

私は、多くの場合、正常に機能する大量輸送の物語を実装しました。ただし、メッセージがエラー キューに移動したり、消えたように見える場合があります。私はRabbitMQを使用しています。

知りたいこと: 1. メッセージがエラー キューに送られる理由/例外メッセージを取得するにはどうすればよいですか? (注: 私のハンドラー ロジックは try-catch ブロック内にあるため、これらのエラーはハンドラー ロジックが呼び出される前でも発生しているようです) 2. 失われたメッセージの原因は何ですか?

前もって感謝します。

NServiceBus Saga\Handler 内から Wcf サービスを正しく呼び出すのを手伝ってくれる人はいますか?

現在、ハンドラー内から同期呼び出しを行っています。

ただし、IIRC は少し前に NServiceBus のドキュメント ページで Saga の使用を推奨していましたが、それ以上の詳細は提供していませんでした。

私の理解では、Saga は、Wcf 呼び出しが処理されている間は永続化され、その後、応答を受信するために再開できるため、優先されます。(他の唯一の考えは、一般的にハンドラーよりも長く実行されるため、佐賀が好まれるということです)。

私が助けを必要としているのは、Wcf サービスからの応答で Saga インスタンスを再開する最も適切な方法です。

ありがとうマーク

私はサガを理解しようとしていますが、その間、私はサガについて特定の考え方を持っていますが、私がその考えを正しく理解したかどうかはわかりません。したがって、私は詳しく説明して、それが正しいか間違っているかを他の人に教えてもらいたいと思います。

私の理解では、sagasは、実行時間の長いプロセスをモデル化する方法の問題に対する解決策です。長期実行とは、複数のコマンド、複数のイベント、場合によっては複数の集計を含むことを意味します。プロセスは、それらの間の依存関係を回避するために、参加しているアグリゲートの1つの内部でモデル化されていません。

基本的に、サガは、内部および外部のコマンド/イベントに反応するコマンド/イベントハンドラーにすぎません。独自のロジックは含まれていません。これは単なる（有限）ステートマシンであるため、イベントXが発生したときに、コマンドYを送信するなどのタスクを提供します。

Sagasは、アグリゲートと同様にイベントストアに永続化され、特定のアグリゲートインスタンスに関連付けられるため、この特定のアグリゲート（またはアグリゲートのセット）が使用されると再ロードされます。

これは正しいですか？

長時間実行されるビジネス プロセスがあります (数分ではなく数週間)。プロセスの開始は、ユーザーのアクションによってトリガーされます。私が抱えている問題は、サガの次のステップが2つの場所のいずれかから来るということです.トリガーする必要があります。

サガは、このビジネス プロセスで使用する正しいメカニズムですか? もしそうなら、これはどのように達成されますか？サガがこのタスクに適していない場合、単純にデータベースに対して毎晩バッチ ジョブを実行するよりも優れたメカニズムはありますか? 毎晩バッチ ジョブを実行することに対する私の嫌悪感は、単純に、この物語の次のポイントを照会するためにヒットしなければならないデータベース テーブルのサイズです。