メインのオーケストレーションが一連のメッセージの処理を担当している状況があります。これらのメッセージは一連の顧客に属し、オーケストレーションは受信したメッセージを読み取り、新しい顧客 ID が見つかるたびに、特定の顧客のメッセージの処理を担当する新しいオーケストレーションを起動します。受信したメッセージの順序を保持する必要があるため、新しく作成されたオーケストレーションはメッセージを処理し、メインのオーケストレーションからの追加メッセージを待機する必要があります。
これに取り組むためにさまざまな方法を試みましたが、うまく実装できませんでした。これをどのように行うことができるかについて、ご意見をお聞きしたいと思います。
ありがとう。
サブオーケストレーションを開始するためにマスターオーケストレーションは必要ないと思います。コンボイパターンを実装するマスターオーケストレーションについて話しているのではないと思います。それで、もしそうなら、私ができることは次のとおりです。
ここに、シングルトン オーケストレーションを実装する方法の簡単な例があります。この例は、一度しか存在しないオーケストレーションをセットアップする方法を示しています。そこに送られるすべてのメッセージは、受信順に並べられ、一度に 1 つずつ処理されます。あなたの例は、これを顧客 ID で実行したいという点で異なります。これは非常に簡単です。受信メッセージで顧客 ID をプロモートし、それを相関タイプに追加します。これで、オーケストレーションのインスタンスは顧客ごとに 1 つだけになります。
シングルトンの問題はこれです。ある時点でそれらを殺さなければなりません。だから、あなたはそれらを終わらせる必要があります。特定の顧客への最後のメッセージが、属性などを通じて死ぬ時が来たことをオーケストレーションに知らせる方法がある場合、これを行うことができます。これが不可能な場合は、タイマーを設定する必要があります。x 秒以内にメッセージが受信されない場合は、orch を終了します。これはすべて簡単に行うことができますが、ゾンビを導入することができます. ゾンビは、そのオーケストレーションがシャットダウンされているときに、その顧客への別のメッセージが届いたときに発生します。これは通常、待機時間を微調整することで解決できます。とにかく、時折ゾンビを引き起こします。
フィールドからのメモ。私たちはこれを行ってきましたが、これは実際には優れた長期的な解決策ではありません. 顧客情報の更新を受け取っていたため、注文処理を確実にする必要がありました。私たちはこのシングルトン アプローチを行いましたが、ゾンビの問題と例外の問題から問題がありました。シングルトン オーケストレーションが例外をスローすると、その顧客に対する今後のすべてのメッセージの処理がブロックされます。そのため、考えられるすべての例外を処理します。本当の解決策は、遠端のシステムに更新メッセージのタイム スタンプをチェックさせ、最後の更新よりも古いメッセージを破棄させることでした。私たちはこの方法で行きたかったのですが、受信システムはこの余分な作業をしたくありませんでした。
あなたが望むのは、ネストされたコンボイのセットのようです。それを機能させることは可能かもしれませんが、それは... まあ、痛いです. 特に、私の最初の心配はメンテナンスです。プロセスへの変更は首の骨の痛みであり、さらに悪いことに、展開は本当に、本当にひどいものです。
個人的には、これを実装し、可能であればコンボイを回避する別の方法を見つけようとしますが、それはあなたの特定のシナリオに大きく依存します.
差し支えなければ、いくつか質問します。
注文の要件は何ですか? たとえば、単一の受信バッチまたは複数のバッチにまたがって、顧客ごとに注文された処理のみが必要ですか? 後者の場合、マスター オーケストレーションを使用せずに、顧客ごとに 1 つのコンボイ インスタンスを強制するだけで済みますか? まだ素晴らしいとは言えませんが、物事を大幅に簡素化する可能性があります。
注文に関する失敗の要件は何ですか? 処理を完全に停止する必要がありますか? メッセージを保存して続行しますか? 再試行はどうですか？
注文はメッセージの到着時間のみに基づいていますか? 到着時間だけに頼るのではなく、内部で強制的に注文するために使用できるメッセージはありますか?
個々のメッセージの処理は何をしますか? 特定のメッセージが処理されるときに特定の前提条件が確実に満たされるようにするための順序付け要件です (たとえば、メッセージは、子の前に親を処理する必要があるツリー構造を表します)。