Поделитесь опытом работы с распределёнкой

[nvyush]

получаем что нет разницы - то ли в базе свой агент, то ли код создания уведомления...

поэтому я вот и думаю - зачем усложнять в 2 разак особо не получая выигрыша?

Код создания уведомления — три строчки (условно) — добавить простенький служебный документ в служебную базу (типа как письмо в mail.box положить). Агент — довольно громоздкий код анализа списка адресатов на соответствие серверу и рассылки сообщений.

Всё-таки я склоняюсь к служебной базе уведомлений с проверкой репликации документов

 

[VladSh]

По ходу дела речь шла об агенте After documents are created or modified. Ситуация: уведомление среплицировалось, а документ — нет. Агент сработал на поступление уведомления, проверка показала отсутствие документа, сообщения не шлём. Затем документ среплицировался... Получается нужен второй агент по расписанию, который бы "подчищал" работу первого и посылал сообщения при обгоне документов уведомлениями.

Плюсы - "мгновенность", которая 100% не может быть мгновенной
Минусы - постоянно (для каждого документа!) дёргается AgentManager (а в реально работающей системе их могут работать сотни пользователей..), я считаю это далеко не хорошо. Лучше пожертвовать 2-3 минуты, зато отработать все запросы отправки в один приём.
И кому слать сообщения об обгоне? Зачем они?

Тут обсуждаются два варианта...

Я предложил третий, который работает уже почти 10 лет:
- отдельная служебная БД;
- порядок репликации, по большому счёту, не имеет значения, т.к. имеется проверка на "доступность документа";
- в этой БД генерить не уведомления, а запросы на действие "Отправка почты";
- агент находится в этой же служебной базе данных, который поднимая запросы отправляет почту, сам запрос остаётся как документ лога.

 

[nvyush]

...

Я предложил третий, который работает уже почти 10 лет:
- отдельная служебная БД;
- порядок репликации, по большому счёту, не имеет значения, т.к. имеется проверка на "доступность документа";
- в этой БД генерить не уведомления, а запросы на действие "Отправка почты";
- агент находится в этой же служебной базе данных, который поднимая запросы отправляет почту, сам запрос остаётся как документ лога.

КМК возникли непонятки из-за терминологии. Под "уведомлением" я понимал служебный документ, на основании которого генерируются сообщения пользователям, т.е. фактически "запросы на действие "Отправка почты""
Можно поподробнее про агента - тип, в двух словах что делает?

 

[VladSh]

nvy, в двух словах:

Обычный агент по расписанию:
- More than once a day: All day; запуск раз в 5 минут;
- Run on: Any Server;
- Target: None.

Вызывает одну функцию, куда передаётся String, являющийся сразу и именем вьюхи, в которой искать запросы, и именем искомой формы. Функция дёргает иерархию классов.

Базовый класс содержит базовый функционал, т.е. каркас кода для выполнения любых запросов (отправка почты - частный случай):
- проверки на локальную версию и транзитный сервер - выходим;
- получение документа-запроса, если агент вызван по noteid, иначе инициализация вьюхи и навигатора, обработка в цикле запросов;
- в цикле поиск базового дока и проверка на "доступность";
- метод для обработки запроса (переопределяется в наследуемых классах);
- пометка запроса как отработанного при успешной отправке;
- принтование инфы о том, сколько найдено запросов, сколько обработано и т.п....

Функционал отправки:
- определение и сравнение мэйл-сервера для каждой персоны;
- если что-то не так, то в зависимости от настроек отправки либо прерываем процесс (если необходимо обязательно отправить всем) либо при невозможности отправки исключаем этих персон из списка отправки (если достаточно отправить хотябы одному или для данного процесса возможно игнорировать отправку при ошибке);
- если ошибка, связанная с настройками, - генерю запись лога админу, если критическая - разрабу (но это уже общий механизм регистрации ошибок и логирования включается...).
Собственно и всё.

 

[nvyush]

- в цикле поиск базового дока и проверка на "доступность";

В общем случае документ уже может быть на сервере, но не быть доступным пользователю. Хотя в принципе в запрос можно сохранять временную метку-дату/время последнего обновления документа или номер редакции документа и проверять их совпадение.

- пометка запроса как отработанного при успешной отправке;

А если адресатов несколько и они на разных серверах? Пометка должна касаться только текущего сервера. Генерить документ-ответ с полем читателей только текущий сервер?

 

[VladSh]

В общем случае документ уже может быть на сервере, но не быть доступным пользователю. Хотя в принципе в запрос можно сохранять временную метку-дату/время последнего обновления документа или номер редакции документа и проверять их совпадение.

Проверка на "доступность" - это самый интересный момент. У меня сделано так, что проверять ничего не надо... но тут уже сикрет, сорри

А если адресатов несколько и они на разных серверах? Пометка должна касаться только текущего сервера. Генерить документ-ответ с полем читателей только текущий сервер?

При отправке есть список пользователей, из него определяем, что всего по этой отправке необходима доставка, допустим, на 3 сервера. Для каждого сервера создаём свой запрос на отправку письма, в котором находятся только те пользователи, у которых мыло лежит на этом сервере.

Таким образом сервер отрабатывает и изменяет (ставит пометку о факте отработки) только свой запрос. Закрывать их на ридерсы или нет - это дело вкуса.. я не любитель формул репликаций, но тут бы они подошли.

 

[nvyush]

Проверка на "доступность" - это самый интересный момент. У меня сделано так, что проверять ничего не надо... но тут уже сикрет, сорри :bequiet:

Уж не "заворачивается" ли сам документ в запрос? В принципе возможен и такой вариант — реплицируется только одна мегабаза с запросами, внутри которых упакованы документы. По прибытии на сервер назначения документ из запроса выкладывается в целевую базу и генерятся сообщения нужным пользователям. В таком варианте действительно не нужно никакой проверки доступности.

 

[VladSh]

Нет
Похоже сделано в БР, там есть БД "Транспорт", которая передаёт пакован доков в XML-виде, а на принимающей стороне агент "слушает" определённый порт... Т.е. там отказались от репликации. Для первой отправки доков это классно, а вот как потом их изменять, если работа с доком должна идти сразу на нескольких серверах... Может быть с помощью LWF, но как потом сливаются все изменения в один документ для меня осталось загадкой (функционал слияния, вроде, в закрытых lss'ках находится). IMHO: LWF - это гемор; тем более, что через 2 года истекает срок его официальной поддержки.