кумулятивный шаблон обмена сообщениями

Question

Я ищу руководство по дизайну здесь больше, чем актуальные решения, но приветствую обоих.

Сценарий заключается в том, что у меня есть издатель, ответственный за публикацию пользовательских обновлений, выполненных в системе. Мои нисходящие системы являются подписчиками на эти обновления.

Задача, которую я испытываю, заключается в том, что пользователи восходящей системы регулярно сохраняют свою работу. Причина, по которой они делают это, состоит в том, что одно «логическое» обновление на самом деле включает в себя переход на многие экраны, а также естественным для них многозадачность на другие вещи, и как таковые они сильно ударяют «сэкономить». Каждый раз, когда они нажимают «Сохранить», мы получаем сообщение.

Итак, для каждого «логического» обновления у нас может быть 5-10 отдельных сообщений об обновлении, некоторые из которых могут быть дублированы.

Это вызывает накладные расходы для пользователей моих нисходящих систем, которые перегружены объемом обновлений. Для каждого обновления им нужно сначала проверить, является ли это «действительной» частью работы, и отбросить его, если это только результат сохранения вверх.

Я знаю, что лучшим решением было бы изменить восходящую систему, чтобы пакетные файлы сохранялись вместе в одно обновление, но это было бы слишком дорогостоящим, поскольку это должно было бы включать поставщика.

Редактировать: В сообщениях нет данных последовательности. Поэтому, когда мы получаем обновление, нет способа рассказать, как «далеко» через процесс пользователь. Они могли закончить все за один раз, или они могут быть только на 10%, и мы получим еще 10 обновлений, прежде чем они закончатся.

Редактировать: Я использую BizTalk как платформу обмена сообщениями.

Редактировать: Образец, который я хочу реализовать, это агрегатор - http://eaipatterns.com/Aggregator.html. Проблема в том, что я не знаю, когда завершена серия сообщений, содержащих входные данные.

Answer 1

Я решил реализовать вариант шаблона агрегатора, посредством которого сообщение по умолчанию (последнее) выбирается из коллективного обмена.

Однако для «триггера» (набора условий, указывающих, что агрегация завершена), вместо того, чтобы полагаться на завершение серии, у меня будет окно обслуживания, установленное в определенное время каждый день.

Надеюсь, это поможет другим.