問題タブ [saga]

ActiveMQ の MassTransit Saga 機能に代わるものはありますか? 学生時代に MassTransit を学びましたが、今は ActiveMQ を類推して学びたいと思っています。

私は ReBus で Sagas に取り組んでおり、NServiceBus での私の経験から、Saga の元の作成者に返信して、次のような更新を提供することができます。

ReBus でこれを行う同等の方法は見当たりません。これを行う方法はありますか? そうでない場合は、同じことを達成するために使用できる良いパターン (オリジネーターのポーリング以外) はありますか? 例として、顧客を作成しようとしていて、クライアントがアドレスを変更しようとする前にいつ作成されたかを知りたい場合があります。

以下は、私が簡単にまとめた顧客シナリオの簡単な例です。

Axon で開発しているプロジェクトがありますが、Saga が適切に実行されません。

My Saga には、次のような行が含まれています。

First イベントは開始サガをトリガーし、initialiseWorkflow タスクもトリガーします (追加のステップのセットを正しく作成します)。ただし、SecondEvent が到着すると (FirstEvent と同じ UUID associationProperty 値で)、サガはその秒を取得しません。イベント。

関連付けを強化するために次の行を具体的に含めようとしましたが、それも機能しませんでした。

皮肉なことに、正しく動作する axon テスト フレームワークを使用したテスト ケースがあります。これは次のようなものです。

この問題は、コマンドを CommandGateway に直接配置し、リポジトリで結果を直接確認しているエンド ツー エンド テストで発生します。

AnnotatedSagaManager が使用されていることを再確認しましたが、使用されています。

何が間違っているのか、またはSagasの仕組みを誤解している人はいますか?

編集：さらにいくつかの更新：

1) UUID を直接関連付けるときに toString() を使用する必要があることに気付いたので、値をイベントの文字列にしようとしましたが、進行しませんでした。

2) 関連付けられた値を出力してみましたが、直接の関連付け行が必要ないことがわかりました (uuid は、開始サガ プロセス中に関連付けられます)。

3) @StartSaga を secondEvent に配置しようとしましたが、これは "Processing SecondEvent ..." のコードに到達しましたが、新しいサガでした。

理解は深まりましたが、まだ解決策はありません。

this.MarkAsComplete();NServiceBus は、Saga 自体から呼び出されたときに、少なくとも RavenDB 永続ストア内の Saga データを削除します。

Saga が完了または終了したときに、Saga データをアーカイブする組み込みの方法はありますか? トレーサビリティの理由から、このような機能が必要です。

複数のメッセージ タイプを処理する 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 が処理されるまでキューに追加されます。