Работайте напрямую в той БД, где создаёте документ (+)

Замечание к документу "Ну дело в том что я так понимаю мне нужно всего лишь среплецировать один документ" >>>

Тема: Работайте напрямую в той БД, где создаёте документ (+)

Создан:	Ivan Tsibanenko 06/20/2006 05:17 PM
Модифицирован:	Ivan Tsibanenko 06/20/2006 05:28 PM

Папка:
06. Разработка Notes-приложений

Тип сообщения:
Мне лень заполнять это поле

Сообщение:
Если действительно нужна гарантированная срочность, лучше использовать работу с БД напрямую. Если безопасность или структура сети запрещает прямое подключение к центральному серверу - используйте passthru подключение.
При использовании почты (mail in) или репликации, может возникнуть ситуация, когда пользователь считает, что документ уже отправлен, а исполнитель документ не получил (например, "упал" канал или админы пошалили, в итоге почта и репликация не ходит, но никто этого не замечает, так как таймаут на почту установлен 24 часа по умолчанию). Это будет "дырой" по срочности... если не настроите мониторинг серверов, каналов и т.п., но это уже чуть другая тема.

Другой вопрос, что когда канал поднимется, документик всё равно дойдёт до получателя, и это есть плюс, потому что пока канал восстановили, пользователь-то мог уже домой свалить...

Метод CopyToDatabase - суть то же самое, что прямой доступ к центральной БД, так что проще и приятнее будет, например, по кнопке в "локальной" региональной/филиальной БД создавать документ в БД на сервере-получателе.

===========================================================

В одном приложении я использовал метод NotesAgent.RunOnServer в качестве proxy для данных.
1. Пользователь, по окончании редактирования, создавал документ-запрос в специальной БД и в этой же БД запускал агента RunOnServer(NoteID).
2. Агент запускался на сервере, подбирал документ-запрос, после чего в настройках маршрутизации определял, на какой сервер его передавать.
3. На сервере-получателе запроса он точно так же создавал документ-запрос в реплике той же специальной БД и запускал на том сервере точно такой же агент методом RunOnServer.
4. Пункты 2 и 3 исполняются до достижения сервера, который должен обработать данный запрос.
5. Агент, обработавший запрос, сохраняет данные в тот же документ, в котором этот запрос получил.
6. Все предыдущие запущенные агенты получают обрабтно управление (а они сидели, ждали, пока ответит "крайний" сервер) и переносят ответ из документа, который они сами создали, в документ, который они получили в качестве параметра при запуске.
7. Крайним в получении ответа оказывается пользователь.

При этом:
1. Возвращается как ответ, так и ошибка, полученная на любом из этапов.
Например, если упал канал, пользователь получает сообщение об ошибке. И это, в случае срочности, есть достоинство!
2. БД на всех серверах - одна и та же (реплика). Сама она реплицировалась периодически, и все созданные на разных серверах запросы собирались в одну кучку, поэтому в итоге получался лог обработки запросов.
3. На достаточно узком канале (160kbit/s) между 2-мя серверами запрос в 5kb размером занимал менее секунды
(пользователь -> сервер1 -> сервер2[обработка] -> сервер1 -> пользователь)
4. Приложение не использовалось интенсивно, возможны подводные камни!!!