3

これは多くの人にとって非常に明白なことですが、私のクライアントは、私があまり便利ではないパターンを使用しています。

たとえば、顧客が nservicebus を介してサード パーティ システムに送信される預金または引き出しを送信する場合です。サードパーティのシステムがそのトランザクションを処理する必要がありますが、トランザクションが完了するまでに数日、場合によっては数週間かかる場合があります。

今日の解決策は、トランザクションを第三者システムに渡すためのメッセージを最初に送信する saga を作成することです。完了したら、サガの次のステップは、完了の更新を確認することです。トランザクションが完了していない場合は、'待機のように' requesttimeout が送信されます。タイムアウトに達すると、同じチェックがもう一度実行され、新しい requesttimeout が送信されます...など。これは永遠のループでした。他に行うことは、ServiceInsight を同じ SagaTimeout で何度も完全に満たすことです。

私は一眼レフを調べてきましたが、手短に出てくるようです。すべてのメッセージではなく、特定のメッセージに対してのみ多くの再試行が必要です。

さらに、サードパーティのシステムはトランザクションが完了したというイベントを送信できないため、完了の更新をポーリングする必要があります。

もう1つ、より良い解決策は、トランザクションのステータスを保存し、トランザクションをサードパーティに送信して、この特定の物語を終わらせることです. 次に、時間間隔を使用して完了の更新をチェックするサガを作成します。

このように sagatimeouts を使用するのは一般的なパターンですか? そして、サガ/ハンドラーが完了の更新のみをチェックすることはより良い解決策ですか?

4

2 に答える 2

3

私が知る限り、あなたは本来あるべき方法でそれを行っています。もちろん、タイムアウトを処理するために別のサガを開始することもできますが、それを行う正当な理由はありません。

トランザクション/プロセスがサード パーティのシステムでいつ終了するかわからないため、エンド ユーザーにとって時間にあまり敏感ではないため、頻繁にタイムアウトを要求する必要はありません。サガ データのタイムアウト数をカウントし、次のタイムアウトまでの期間を長くして、タイムアウト数を最小限に抑えることもできます。また、サガが実行されている時間を確認し、サードパーティのシステムがトランザクションを完了するのに「時間がかかりすぎる」場合は、誰か (あなたまたは顧客など) に警告することもできます。これは、NSB サガが真価を発揮するところです。これらの状況を非常に柔軟に処理できます。

また、断続的なエラーが発生したときにハンドラーを再試行することのみを目的としており、この種の目的で SLR を使用しないでください。

于 2015-11-04T08:56:43.513 に答える