累積メッセージングパターン

Question

私は実際のソリューションよりもここでデザインガイダンスを探していますが、両方を歓迎します。

私は、システムで実行されたユーザーの更新を発行する発行者がいます。私の下流のシステムは、これらの更新プログラムの購読者です。

私が抱いている課題は、上流システムのユーザーが定期的に作業を保存していることです。彼らがこれをやっている理由は、1つの "論理的な"アップデートが実際に多くの画面を遷移させることに加え、他のものに対してマルチタスキングを起こすことも当然であり、彼らがセーブするたびに、私たちはメッセージを受け取ります。

だから、それぞれの "論理的な"アップデートに対して、おそらく5-10個の個別のアップデートメッセージがありますが、そのうちのいくつかは複製できます。

これは、更新量が圧倒されているダウンストリームシステムのユーザーにオーバーヘッドを引き起こします。それぞれの更新に対して、最初にこれが "実行可能な"作品を表すかどうかを確認し、これが上流保存の結果のみである場合は破棄しなければなりません。

アップストリームシステムを一括して1つのアップデートに変更するのが最善の解決策だとわかっていますが、これはベンダーが関与しなければならないのでコストがかかるでしょう。

編集：メッセージにシーケンスデータがありません。だから私たちがアップデートを受け取ったとき、それはユーザーがどのようにプロセスを「遠く」行っているかを示す方法がありません。彼らは一度にすべてを完了することができたか、または方法の10％に過ぎない可能性があり、完了する前に10個の更新が追加されます。

編集：具体的には、メッセージングプラットフォームとしてBizTalkを使用しています。

編集：実装したいパターンはアグリゲータ - http://eaipatterns.com/Aggregator.htmlです。問題は、入力を構成する一連のメッセージがいつ完了するかを知る方法がないことです。

Answer 1

私は集約パターンの変種を実装することにしました。これによって、デフォルトのメッセージ（最新のもの）が集合的インターチェンジから選択されます。

しかし、「トリガ」（集約が完了したことを示す一連の条件）では、シリーズの完成に頼るのではなく、毎日特定の時間にサービスウィンドウを設定します。

他人に役立つことを願っています。