私は実際のソリューションよりもここでデザインガイダンスを探していますが、両方を歓迎します。累積メッセージングパターン
私は、システムで実行されたユーザーの更新を発行する発行者がいます。私の下流のシステムは、これらの更新プログラムの購読者です。
私が抱いている課題は、上流システムのユーザーが定期的に作業を保存していることです。彼らがこれをやっている理由は、1つの "論理的な"アップデートが実際に多くの画面を遷移させることに加え、他のものに対してマルチタスキングを起こすことも当然であり、彼らがセーブするたびに、私たちはメッセージを受け取ります。
だから、それぞれの "論理的な"アップデートに対して、おそらく5-10個の個別のアップデートメッセージがありますが、そのうちのいくつかは複製できます。
これは、更新量が圧倒されているダウンストリームシステムのユーザーにオーバーヘッドを引き起こします。それぞれの更新に対して、最初にこれが "実行可能な"作品を表すかどうかを確認し、これが上流保存の結果のみである場合は破棄しなければなりません。
アップストリームシステムを一括して1つのアップデートに変更するのが最善の解決策だとわかっていますが、これはベンダーが関与しなければならないのでコストがかかるでしょう。
編集:メッセージにシーケンスデータがありません。だから私たちがアップデートを受け取ったとき、それはユーザーがどのようにプロセスを「遠く」行っているかを示す方法がありません。彼らは一度にすべてを完了することができたか、または方法の10%に過ぎない可能性があり、完了する前に10個の更新が追加されます。
編集:具体的には、メッセージングプラットフォームとしてBizTalkを使用しています。
編集:実装したいパターンはアグリゲータ - http://eaipatterns.com/Aggregator.htmlです。問題は、入力を構成する一連のメッセージがいつ完了するかを知る方法がないことです。
申し訳ありません質問の主な点を得ることができません – sll
私は他の人がこの問題に近づく方法についての提案を探しています。私はコヒーレントな方法でメッセージをバッチアップすることで、下流のシステムへのメッセージングの量を減らす必要があります –
おそらくあなたは[Message Sequence](http://eaipatterns.com/MessageSequence.html)パターンを探していますか?したがって、ユーザは 'SequenceNumber == SequenceSize'でアップデートを受け取った時にアップデートを処理することができます – sll