Офисные технологии Lotus Notes  Что такое Notes Что такое NotesЧто такое Notes  Lotus Notes как совокупность восьми ключевых технологий Lotus Notes. Уведомление о приходе новой почты

По умолчанию, Domino реплицирует все базы данных, которые имеют одинаковые ID реплик. Для реплик только определенных баз данных, редактируйте поле File/Directories to Replicate в документе подключения. В это поле, введите имена баз данных или имена каталогов, которые Вы хотите реплицировать. Отделите их друг от друга, точкой с запятой.

Чтобы определить выбранную базу данных для репликации, введите ее имя файла, включая.NSF расширение. Если база данных находится в подкаталоге, включите путь относительно каталога данных Notes - например, EAST\SALES.NSF.

Чтобы определить все файлы расположенные в каталоге, введите EAST\. Вы не можете использовать для этой цели звездочку (*).

Репликации баз данных согласно их приоритетов.

Менеджеры Базы данных назначают приоритет репликаций базам данных так, чтобы Domino администраторы могли наметить репликации для баз данных, основанных на приоритете. Например, Вы можете наметить первоочередной приоритет для баз данных, которые являются критическими для делового процесса - например, Domino Directory реплицируется часто. Вы можете наметить так же низкоприоритетные базы данных.

Установки репликаций с использованием приоритета, редактируются в поле Replicate databases of документа подключения. Установка по умолчанию Low & Medium & High priority.

Если двум репликам назначены, различные приоритеты, Domino используют приоритет, назначенный для реплик на сервере, который является инициатором репликации.

Ограничение времени репликаций.

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

Чтобы ограничивать время реплик, Вы вводите значение в поле Replication Time Limit из документа подключения.

Предостережение : Если Вы определяете очень маленькое время, базы данных не смогут реплицироваться полностью. Файл LOG.NSF делает запись, указывающую, что произошло завершение связи, но репликация не была успешна. История репликации не обновляется.

Чтобы ограничивать репликации по времени для всего сервера, редактируйте NOTES.INI файл, чтобы включить переменную ReplicationTimeLimit.

Использование нескольких репликаторов одновременно

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

Когда Вы используете несколько репликаций, каждый репликатор обращается только с одной сессией репликаций. Например, если на сервере Hub-E/East/Acme намечена репликация с сервером HR-E/East/Acme и с Hub-W/West/Acme одновременно, один репликатор обрабатывает репликацию Hub-E/East/Acme и HR-E/East/Acme, другой репликатор обрабатывает реплику между Hub-E/East/Acme и Hub-W/West/Acme.

Несколько репликаторов обращаются с несколькими репликами, между одним сервером источником и несколькими серверами назначения одновременно.

Пример. Если База данных 1 и База данных 2 на Hub-E/East/Acme нуждаются в репликации с Hub-W/West/Acme, то только один репликатор общается с каждой сессией репликации, по очереди.

Исследуйте документы подключений, которые намечают Ваши репликации на каждом сервере. Регулируя графики реплик и запуская несколько репликаторов, Вы можете сокращать время полного цикла репликаций. С этим сокращением циклов, Вы можете наметить одни или более дополнительный циклов в день, что означает уменьшение интервалов времени для обновления данных баз данных, более быстрый цикл репликаций. После того, как Вы запускаете несколько репликаторов, Вы можете использовать команду - Tell, чтобы остановить все репликаторы; однако, Вы не можете использовать команду - Tell, чтобы остановить определенный репликатор.

Если Вы не используете несколько репликаторов, не намечайте реплики с сервера с использованием различных портов в одно и тоже время.

Пример. Если Вы используете один репликатор, не намечайте реплику с Hub-E/East/Acme на Hr-E/East/Acme по COM1, на тоже самое время, что и с Hub-E/East/Acme, на Hub-W/west/Acme по COM2 одновременно.

Разрешение использования нескольких репликаторов.

Отклонение запросов на репликации с сервера.

Чтобы оградить сервер от принятия просьб о репликациях, редактируйте NOTES.INI файл, чтобы включить переменную ServerNoReplRequests. Если эта установка установлена в 1, сервер отказывается от всех запросов на репликацию.

Вы можете использовать эту особенность, чтобы уменьшить рабочую нагрузку репликаций на выбранном сервере.

Запрещение репликаций.

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

Чтобы запретить репликации, отредактируйте документ подключения в Domino Directory. В секции Replication, запретите использование репликации, установите значение поля Replication в Tasks – Disabled.

Форсирование намеченных репликаций.

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

Имеются много ситуаций, когда принудительные репликации необходимы. Например, Вы можете захотеть модернизировать базу данных немедленно, без того, чтобы ожидать намеченной репликации, или Вы могли бы реплицировать данные с различных серверов, потому что обычно эти сервера недоступны.

Когда Вы вынуждаете немедленную репликацию Сервер - Сервер, Вы можете вести репликацию в одном или в обоих направлениях.

Команды для репликатора:

Replica - Реплицируются изменения в базах данных в обоих направлениях. Domino сначала забирает изменения, потом выталкивает измененные документы.

Pull - Реплицируются изменения в базах данных в одном направлении, где сервер только забирает изменения с другого сервера

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

Джозеф Андерсон и Пит Бэркхардт
Опубликовано 25.04.2007

Гибкость и свобода, которую даёт репликация, является непревзойдённым преимуществом IBM Lotus Notes. Многие организации решили использовать эту мощную функцию в полном масштабе, и их пользователи работают с локальными репликами своих баз данных Notes, в том числе и с почтовыми базами данных. Преимущества и недостатки использования локальных реплик почтовых баз данных подробно обсуждаются в статье developerWorks Lotus, " ."

Кроме моментов, рассматриваемых в этой статье, в Lotus Notes/Domino добавлены функции, которые могут сделать реализацию локальных почтовых реплик ещё более соблазнительным. В статье обсуждаются эти дополнительные улучшения и даются рекомендации по настройке локальных почтовых реплик. Прежде чем объяснять модель локальных реплик и излагать технические подробности по организации среды в пределах вашей инфраструктуры, давайте посмотрим на пример применимости данной модели.

Пример реализации локальных почтовых реплик

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

Компания XYZ со временем развернула почтовые серверы Lotus Domino для каждого нового местоположения, так как это было заложено в стандартную конфигурацию и поскольку у большинства узлов с менее чем 25 пользователями имелся канал связи с невысокой пропускной способностью. Большая часть почтовой коммуникации внутри компании происходит между этими узлами, а требования для пользователей электронной почты, находящихся в одном и том же офисе минимальны. Со временем количество почтовых серверов Lotus Domino вне центрального узла выросло до 37, а обслуживали они приблизительно 1400 пользователей, в то время как в главном офисе имелось два объединённых в кластер почтовых сервера Lotus Domino при 2900 пользователях. Финансовый отдел компании поставил и рассмотрел вопрос о количестве серверов и лицензий, необходимых для функционирования среды обмена электронными сообщениями. Чтобы уменьшить количество требуемых серверов и лицензий, и при это сохранить высокий уровень отказоустойчивости и балансировки нагрузки, отдел информационных технологий решил переместить часть пользователей в центральный офис и внедрить локальные почтовые реплики.

Группа IT оценила применяющиеся на данных момент модели использования подобного оборудования в компании, определив размещение серверов, количество пользователей и имеющуюся в наличие пропускную способность. В таблице 1 определены следующие категории.

Таблица 1. Оценка текущих моделей использования

Количество узлов в окружении	Количество пользователей	Доступная пропускная способность	Рекомендуемые мероприятия
11	Менее 25	Перевести в центральный офис
1	25 – 50 пользователей	Менее 256 KB	Перевести в центральный офис (отслеживать)
7	25 – 50 пользователей	Более 256 KB	Перевести в центральный офис
2	50 – 150 пользователей	Менее 1 MB	Развернуть серверный кластер
13	50 – 150 пользователей	Более 1 MB	Перевести в центральный офис
3	Более 150 пользователей	Развернуть серверный кластер

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

Высшее руководство IT-отдела затребовало, чтобы все пользователи в окружении использовали один и тот же метод доступа. Для выполнения этой задачи, группа IT разработала и настроила политики Setup и Desktop для автоматизации процесса развёртывания. До принятия решения о переходе на локальные почтовые реплики в окружении существовала одна политика Desktop и одна Setup. Чтобы гарантировать, что среда не будет перегружена запросами на репликацию данных конечным пользователям, группа IT разработала политики Setup и Desktop для каждого места, таким образом специалисты могли контролировать процесс репликации. После перехода на локальные почтовые реплики, группа IT снова вернулась к меньшему числу политик Setup и Desktop, реализовав один набор политик для каждого сервера.

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

Объяснение механизма репликации локальной почтовой базы данных

Довольно часто мы слышим, как люди говорят о локальной почте, сравнивая её с серверной. Что же это означает на самом деле? Репликация локальной почтовой базы данных предполагает, что копия, или реплика почтового файла пользователя находится на его рабочей станции, что позволяет пользователю работать с почтой без подключения к серверу. Периодически отправляется исходящая почта, а почтовый файл реплицируется с его версией на сервере, при этом происходит обмен изменениями между двумя базами данных. Изображение конфигурации окружения приводится на Рисунке 1.

Рисунок 1. Конфигурация окружения локальных почтовых реплик

Чтобы создать подобное окружение, вам выполнить некоторые настройки в клиенте Lotus Notes пользователя.

На рабочей станции пользователя необходимо создать реплику почтовой база данных пользователя. Строго рекомендуется использовать каталог директорий, чтобы позволить пользователям искать имена при адресации почтовых сообщений во время локальной работы. И вы, администратор, и пользователь можете создавать локальные реплики вручную с рабочей станции пользователя, либо при помощи политик Lotus Notes/Domino. После создания локальной реплики и каталога директорий, их необходимо настроить на синхронизацию с серверными репликами базы данных. Мы рекомендуем проводит репликацию базы данных каждые 30 минут. Настроив репликацию на 30 минут, вы гарантируете, что клиент не уменьшит производительность сервера и свою собственную слишком частой репликацией.

Lotus Notes на рабочей станции необходимо настроить так, чтобы происходила проверка новой почты на сервере. Параметр проверки новой почты нужно установить на каждые пять минут, что позволяет пользователю получать почту через гораздо более короткие промежутки, чем 30-минутный интервал между репликациями. Это гарантирует, что клиент поддерживает открытую сессию связи с сервером Domino и регулярно получает уведомления о получении новой почты.

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

Может показаться, что вам или пользователю придётся выполнять довольно значительный объём изменений с рабочей станции пользователя. Хотя ручная конфигурация и возможна, вы также можете создать в окружении Lotus Notes/Domino политики, которые выполняют эти изменения без необходимости посещать отдельную рабочую станцию. Поскольку политики позволяют вам переконфигурировать большое число рабочих станций одновременно, нужно непременно позаботиться о том, чтобы эти изменения развёртывались гранулировано, чтобы не заполонить сеть одновременными запросами на создание реплик или почтовых файлов и каталогов директорий.

Улучшения в работе с локальными почтовыми репликами

Многие организации предпочитают, чтобы их пользователи работали с локальными почтовыми репликами по многим причинам. Однако традиционно имеется несколько недостатков данной конфигурации с точки зрения администрирования. Эти недостатки связаны конфигурированием рабочей станции, обучением пользователей и обеспечения пользователей службами каталогов. Благодаря усовершенствованиям репликации, политик и каталогов директорий в последних версиях Lotus Notes (V6.0 и более поздних), локальными почтовыми репликами даже стало легче управлять.

Сетевая компрессия

Начиная с Lotus Notes 6.x, в репликацию было внесено множество изменений, что значительно увеличило эффективность как с точки зрения быстродействия, так и использования сети. Введение компрессии при репликации уменьшает объём данных, передаваемых между клиентом и сервером до 30-40%, если сетевой траффик уже не сжимается роутерами или ПО для VPN. Вы можете прочитать более подробно о сетевой компрессии в статье developerWorks Lotus, " ."

Потоковая репликация

Кроме того, в Lotus Notes V6.0 появилась потоковая репликация. Эта функция повышает удобство пользователя при работе с локальной почтовой репликой. Во время репликации новые документы реплицируются в локальную почтовую реплику в порядке от самого маленького до самого большого по размеру. Это устраняет задержки, возникающие, когда одно сообщение с большим вложением, реплицирующееся первым, блокирует множество других сообщением. Кроме того, потоковая репликация позволяет пользователям просматривать документы и работать с ними, пока они реплицируются в локальную почтовую базу данных, так что больше не нужно ждать завершения репликации всех изменений, чтобы можно было начать работать с новыми сообщениями.

Асинхронное уведомление

Начиная с Lotus Notes V6.5.x, появилась асинхронное уведомление. Если клиент Notes работает с локальной почтовой репликой и имеет открытое подключение к серверу Domino, последний отправляет уведомление о новых сообщениях клиенту. Это уведомление, отправленное сервером Domino запускает на клиенте Notes репликацию почтового файла, доставляя новое сообщение в локальную почтовую реплику. Такая репликация происходит без вмешательства пользователя и не зависит от графика репликации, установленном в клиенте Lotus Notes. Данная функция позволяет пользователям получать входящее почтовое сообщение немедленно при работе с локальными репликами.

Политики

Политики появились, чтобы помочь в конфигурировании и управлении настройками на рабочей станции пользователя. Эта мощная функция даёт вам значительную гибкость при конфигурировании рабочих станций для пользователя. При помощи политик, вы можете выполнить все настройки, необходимые для обеспечения работы пользователя с локальной почтовой репликой, не посещая рабочую станцию пользователя. Ниже мы покажем вам, как настраивать политики для выполнения этого сценария. Для получения более подробной и общей информации по политикам см. следующие статьи developerWorks Lotus, " " и " ."

Каталоги директорий

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

Сжатый или мобильный каталог директорий
Мобильный каталог директорий содержит пользовательские и групповые записи из вашей Domino Directory и других директорий, которые вы можете выбирать. Мобильный каталог директорий сжимает записи из директорий, которые вы выбираете, в базу данных каталога директорий. Пропорция по умолчанию, используемая для сжимания записей, - приблизительно 255 записей (одна запись равняется одной пользовательской или групповой записи) в Domino Directory сжимаются в одну запись в мобильном каталоге директорий. В результате размер каталога директорий очень мал, однако сортировку можно осуществлять лишь по имени или фамилии, что должно быть указано при создании каталога директорий.
Расширенный каталог директорий
Расширенный каталог директорий базируется на пользовательских, групповых и серверных записях в вашей Domino Directory и других директориях по вашему выбору. Расширенный каталог директорий не предлагает сжатия записей, в результате чего расширенный каталог директорий гораздо больше по размеру, чем мобильный каталог директорий. Тем не менее, расширенный каталог директорий меньше чем Domino Directory, так как в нём не содержатся документы Connection, программные документы, и т. п. Он также очень гибок в плане удобства поисковых пользовательских функций, поскольку работает точно так же, как при выполнении поиска в обычной Domino Directory (то есть поиск по имени, фамилии, прозвищу, и т. д.)

Ключевым фактором удовлетворённости пользователей при работе с локальными почтовыми репликами является обеспечение возможности пользователей выполнять поиск имён в директории при работе в режиме offline. Как у мобильного, так и у расширенного каталога директорий есть свои преимущества и недостатки. Хотя мобильный каталог директорий меньше по размеру, расширенный каталог директорий обеспечивает более гибкие поисковые возможности. Эмпирическое правило выбора подходящего для вашего окружения каталога директорий должно основываться на размере каталога директорий. Если размер созданного расширенного каталога директорий превышает 50 MB, используйте вместо него мобильный каталог директорий. При использовании размера в качестве принципа выбора между двумя типами каталогов директорий принимается в расчёт время, которое пользователь будет тратить на репликацию каталога директорий и учитывается рост директории в будущем.

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

Настройка окружения

Необходимо выполнить множество настроек и конфигураций на пользовательской рабочей станции, чтобы у пользователей появилась возможность успешно и комфортно работать с локальными почтовыми репликами при пользовании электронной почтой. Эти настройки находятся в пользовательских установках (User Preferences) и документе Location на рабочей станции пользователя и приведены в Таблице 2.

Таблица 2. Обзор настраиваемых полей

Настройка на рабочей станции	Значение
Создание локальных реплик	Почтовый файл, каталог директорий
Пользовательские установки
Последовательный каталог директорий (вкладка Mail\General)	Имя базы данных каталога директорий
Проверка новой почты каждые (вкладка Mail\General)	5 минут
Автоматическое обновление Inbox (вкладка Mail\General)	Включено
Создание полнотекстового индекса для поиска (вкладка Replication)	Включено
Следует ли Notes шифровать новые реплики? (вкладка Replication)	Локальное шифрование со Средним (Medium) уровнем
Документ Location (вкладка Mail)
Размещение почтового файла	Локально
Опережающий ввод имени получателя	Только локально
Адресация почты	Локально и на сервере
Передача исходящей почты если	1
Документ Location (вкладка Replication)
Разрешение репликации	Включено
Создание новых реплик	Немедленно
Репликация при запуске Notes	Включено, Подсказка перед репликацией
График	Включено
Репликация ежедневно между	7:00 AM – 7:00 PM
Повтор каждые	30 минут
Дни недели	ПН, ВТ, СР, ЧТ, ПТ
Репликации при завершении Notes	Подсказка о репликации при выключении Notes, если что-либо ждёт отправки.

Существует два способа выполнения данных настроек на рабочей станции пользователя: вручную или при помощи политик. В данном разделе статьи рассматривается процесс ручного конфигурирования клиента. В следующем разделе обсуждается настройка этих параметров с помощью политик Lotus Domino.

Создание локальных реплик

По умолчанию, при настройке окружения Lotus Notes не создаётся локальной реплики почтовой базы данных или каталога директорий, что необходимо для наилучшего использования модели локальной репликации. Следующие задачи касаются почтовой базы данных, однако важно выполнить эти же шаги и для каталога директорий.

ПРИМЕЧАНИЕ: Перед созданием локальной реплики каталога директорий, создайте сначала каталог директорий на сервере Domino. Более подробную информацию по созданию каталога директорий см. в .

Создайте новую реплику почтовой базы данных, выбрав почтовую базу данных на вашей рабочей станции, и выбрав File – Replication – New Replica. Примите для новой реплики все значения по умолчанию и нажмите OK, чтобы подтвердить создание новой реплики на локальной рабочей станции (см. Рисунок 2).

Рисунок 2. Диалоговое окно Create Replica

Настройка шифрования для локальной почтовой реплики

Для сохранности данных убедитесь, что почтовая база данных локально шифруется. Откройте окно Database Properties и нажмите на кнопку Encryption Settings. В диалоговом окне Encryption выберите опцию "Locally encrypt this database using", а затем выберите соответствующий уровень шифрования из выпадающего списка. По умолчанию используется Medium Encryption.

ПРИМЕЧАНИЕ: В зависимости от требований безопасности окружения, могут потребоваться различные уровни шифрования. Окружение Domino предусматривает три различных уровня шифрования. Более подробная информация по уровням шифрования содержится в Lotus Domino Administrator Help .

Пользовательские настройки

Диалоговое окно User Preferences содержит параметры конфигурации клиента. Для открытия диалогового окна выберите File – Preferences – User Preferences. Чтобы обеспечить своевременное появление новой почты в локальной реплике почтового файла, выберите вкладку Mail - General и выполните следующие настройки (см. Рисунок 3):

В разделе Configuration введите или перейдите к имени файла локального каталога директорий в поле Local address books.
В разделе Receiving выберите опцию "Check for new mail every", а затем установите интервал пять минут.
В разделе "When New Mail Arrives" выберите опцию Automatically refresh Inbox.

Рисунок 3. Настройки почты в диалоговом окне User Preferences

Выберите вкладку Replication и сконфигурируйте настройки по умолчанию, применяемые при создании новых реплик (см. Рисунок 4).

Выберите опцию "Create full text index for searching", чтобы гарантировать, что все новые реплики готовы для поиска.
Выберите опцию Locally encrypt using, а затем определите соответствующий уровень шифрования. Это гарантирует, что все базы данных, реплицируемые локально, по умолчанию шифруются, что обеспечивает защиту данных.

Рисунок 4. Настройки репликации в диалоговом окне User Preferences

Настройка документа Location

При обычном процессе установки клиента, клиент Notes настроен на использование почтовой базы данных и информации о директориях на сервере. Чтобы пользователь мог работать с локальной почтовой репликой, измените документ Location в Personal Address Book так, чтобы использовались локальные ресурсы рабочей станции, а не ресурсы сервера.

Откройте документ Location, выберите вкладку Mail и установите следующие значения (см. Рисунок 5):

Mail file location (Расположение почтового файла): Local (Локально)
Transfer outgoing mail messages if (Отправить исходящую почту если): 1 (messages pending) (сообщение отложено)

Рисунок 5. Настройка опций почты в документе Location

Следующий шаг - включить репликацию баз данных с сервера. На вкладке Replication документа Location установите следующие значения:

Рисунок 6. Настройка опций репликации в документе Location

Настройка серверных политик

В предыдущем разделе статьи вы рассмотрели, как вручную настраивать локальные почтовые реплики для пользователей в вашем окружении. Эти действия можно автоматизировать, реализовав политики Lotus Notes/Domino. В следующих разделах проводится обзор реализации политик, необходимых для подготовки окружения для локальных почтовых реплик. Более подробный обзор политик Lotus Domino содержится в Lotus Domino Administrator Help .

Существует два типа политик, используемых для инициализации и поддерживания настроек, связанных с локальными почтовыми репликами. Политики Setup применяются к новым клиентам в ходе их настройки и ввода в окружение. Важно иметь в виду, что политики Setup применяются только тогда, когда клиент Notes настраивается в первый раз. Политики Desktop применяются к клиенту Notes каждый раз, когда клиент запускается и открывает сеанс связи с сервером Lotus Domino. Политика Desktop очень полезна для задействования параметров конфигурации для пользователей, у которых уже есть клиент client.

Создание политики Setup

Следующие шаги проведут вас через создание политики Setup, с упором на элементы, специфичные для локальных почтовых реплик. Если у вас уже имеется настроенная политика Setup, вы можете её модифицировать, чтобы внести указанные здесь изменения с целью задействовать локальные почтовые реплики. Как было указано ранее, политика Setup применяется только к новым конфигурациям. Вы должны внести эти настройки в политику Desktop, чтобы убедиться, что они применяются на постоянной основе.

Откройте Domino Directory и перейдите в представление Policies\Settings. Нажмите на кнопку Add Settings и выберите Setup для создания политики Setup. На вкладке Basics документа Setup Settings выберите опцию "Create local mail file replica" (см. Рисунок 7).

Рисунок 7. Настройка основных опций в политике Setup Settings

На вкладке Databases документа добавьте ссылку на базу данных для каталога директорий в поле Mobile Directory Catalog. Затем выберите вкладку Preferences, а на подвкладках Mail и News установите интервал проверки новой почты на пять минут и выберите опцию Automatically Refresh Inbox.

На подвкладке Preferences - Replication включите "Create replicas ready for searching," в поле Encrypt replicas установите значение Locally encrypt, а также для поля Encrypt установите желаемый уровень шифрования (High, Medium, Low). См. Рисунок 8.

Рисунок 8. Настройка опций репликации в политике Setup

Создание и расширение политики Desktop

При помощи лишь базовой функциональности, поставляемой с политиками Setup и Desktop, вы не можете произвести полную настройку документа Location. Изменение настроек типа почты, включение репликации и управление графиком репликации не является частью опций по умолчанию документа политики Desktop. Тем не менее, вы можете настраивать документ политики Desktop в Domino Directory для получения контроля над всеми настройками в документе Location пользователя. В данном разделе содержится информация по настройке документа политики Desktop и конфигурированию и управлению этими настройками.

Способность настраивать формы политики Desktop для управления параметрами Notes.ini и настройками документа Location описывается в технической заметке Lotus Support, " ." Мы рекомендуем уменьшить влияние настройки директории при помощи создания отдельной подформы, которую вы можете вставить в форму политики Desktop.

Прежде всего, откройте Domino Directory в IBM Lotus Domino Designer. Перейдите в раздел Shared Code\Subforms базы данных и создайте новую подформу с именем $ClientLocationDoc.

В этой подформе создайте таблицу с двумя вкладками: Mail и Replication. На вкладке Mail воссоздайте конфигурацию вкладки Mail документа Location в Personal Address Book. Тем не менее убедитесь, что вы добавляете LocAll в начало имени в каждом поле, как показано на Рисунке 9.

ПРИМЕЧАНИЕ: Если вы копируете таблицу из документа Location в Personal Address Book, непременно измените имена полей во всех hide-when- и field-формулах (по умолчанию входная трансляция, входная валидация и т. д.) для принятия LocAll, добавленного в именам полей. Кроме того, убедитесь, что вы удалили поля MailFile и MailFormat из скопированной таблицы. Эти поля либо уже находятся где-то в документе Policy, либо относятся к конкретному пользователю и не должны управляться политиками.

После заполнения вкладки Mail подформы, перейдите к вкладке Replication для воссоздания конфигурации вкладки Replication документа Location в Personal Address Book. Опять же, убедитесь, что вы добавили LocAll в начало имени каждого поля, как показано на Рисунке 10.

Рисунок 10. Создание новой подформы Replication в Domino Directory

ПРИМЕЧАНИЕ: Воссоздайте таблицу из документа Location в Personal Address Book, однако не выполняйте копирование и вставку таблицы, поскольку большинство полей документа Location являются полями общего пользования. Создав эти поля в вашей подформе как индивидуальные, вы можете поддерживать независимость подформы в будущем и принимать ваши изменения всех hide-when- и field-формул (по умолчанию входная трансляция, входная валидация и т. д.), а также добавлять LocAll ко всем именам полей без влияния на другие общие поля в Domino Directory.

После заполнения подформы $ClientLocationDoc сохраните и закройте её. Затем откройте форму "Policy Settings\Desktop Settings". В этой форме вставьте ещё одну вкладку в главную таблицу между вкладками Databases и Dial-up Connections. Назовите эту новую вкладку Location Document и вставьте вашу новую подформу в эту вкладку (см. Рисунок 11).

Рисунок 11. Добавление новых подформ к форме Desktop Settings Policy

ПРИМЕЧАНИЕ: Создайте копию формы "Policy Settings\Desktop Settings" перед её изменением. Кроме того отключите возможность обновления из шаблона оформления Domino Directory, чтобы ваши изменения не перезаписывались при замене или обновлении шаблона во время регулярного обслуживания директории.

После вставки новой подформы в новую вкладку сохраните и закройте форму "Policy Settings\Desktop Settings". Проверьте форму, чтобы убедиться, что ваши изменения отображаются в директории и их можно настраивать при помощи значений.

После завершения настройки откройте Domino Directory с помощью клиента Lotus Notes и перейдите в представление Policies\Settings. Нажмите кнопку Add Settings и выберите Desktop для создания политики Desktop.

На вкладке Basics документа, в разделе Server Options, выберите опцию "Create local mail file replica". На вкладке Databases документа добавьте ссылку на базу данных для каталога директорий на поле мобильного каталога директорий.

На новой вкладке Location Document, добавленной вами, выберите вкладку Mail (см. Рисунок 12). Установите следующие параметры:

Mail file location (Размещение почтового файла): Local (Локально)
Domino mail domain: Имя вашего почтового домена Domino
Recipient name type-ahead (Опережающий ввод имени получателя): Local Only (Только локально)
Mail addressing (Адресация почты): Local then Server (Локально, а затем на сервере)
Transfer outgoing mail if (Отправить исходящую почту если): 1 messages pending (сообщение отложено)

Рисунок 12. Настройка Location Document – Mail settings в документе Desktop Settings

На новой вкладке Location Document выберите вкладку Replication (см. Рисунок 13). Установите следующие параметры:

Enable replication (Включить репликацию): "Replication is enabled for this location (Репликация включена для данного узла)"
Create new replicas (Создание новых реплик): Immediately (Немедленно)
Replicate when Notes starts (Репликация при запуске Notes): "Replicate when Notes starts" и Prompt before replicating (Подсказка перед репликацией)
Schedule (График): Replication Interval (Интервал репликации)
Replicate daily between (Репликация ежедневно): 7:00 AM – 7:00 PM
Repeat every (Повторять каждые): 30 minutes
Days of week (Дни недели): ПН, ВТ, СР, ЧТ, ПТ
Replicate when Notes ends (Репликация при завершении Notes): "Prompt to replicate when Notes shuts down (Подсказка при выходе из Notes)" и "If outbox is not empty (Если папка Исходящие не пуста)"

Рисунок 13. Настройка Location Document – Replication в документе Desktop Settings Policy

На подвкладке Preferences - Mail and News документа Policy установите интервал проверки новой почты в пять минут и включите опцию Automatically Refresh Inbox. На подвкладке Preferences - Replication включите "Create replicas ready for searching,", в поле Encrypt replicas установите Locally encrypt, а в поле Encrypt using - желаемый уровень шифрования (High, Medium, Low). Сохраните и закройте документ политики Desktop.

Вопросы обучения конечных пользователей и сотрудников технического сопровождения

Модель локальной репликации не требует специального обучения пользователей при правильной настройке. Цель при реализации - по возможности максимально автоматизировать весь процесс при помощи политик. Тем не менее есть несколько моментов, которые могут потребовать некоторого обучения, чтобы убедиться, что пользователи понимают проблемы, которые могут возникнуть.

Уведомление о приходе новой почты

Клиент Lotus Notes регулярно проверяет новую почту на сервере Domino. Если на сервере есть новые сообщения, которые ещё не были реплицированы на клиент, пользователь получает уведомление о приходе новой почты, однако он не в состоянии найти новую почту в локальной папке Inbox. Задержка в доставке сообщений зависит от размера почтового сообщения и загруженности сервера. Когда пользователь использует серверную копию почтовой базы данных, сообщение появляется в Inbox до уведомления.

Задержка при отправке сообщений на сервер перед выключением

Если сообщение отправляется до закрытия клиента Notes, может не хватить времени на отправку сообщения на сервер. В конфигурации указано отправлять сообщения немедленно, но в зависимости от размера сообщения или типа соединения с сервером, сообщение может быть в процессе отправки. Вы увидите следующее сообщение (см. Рисунок 14), если сообщение не было отправлено полностью.

Рисунок 14. Предупреждение о наличии исходящего сообщения, ожидающего отправки, перед закрытием клиента

Репликация только почты для уменьшения нагрузки на сервер

Одна из проблем с пользователями, использующими локальные почтовые реплики, это то, что они склонны реплицировать все базы данных на вкладке Replication вместо использования опции "Replicate Mail Only". На вкладке Replication нажмите кнопку Start Now и выберите одно из нижеуказанного:

Start Now. Запускает репликацию всех баз данных с вкладки Replication.
Start Mail Only Now. Запускает репликацию почтовой базы данных.
Start High Priority Databases Now. Запускает репликацию всех баз данных, отмеченных как имеющих высокий приоритет.

Обратите на Notice галочку слева от почтовой базы данных на вкладке Replication. Она включает/выключает репликацию базы данных; пользователи могут выключить эту опцию. Политики не включают эту опцию принудительно. Следовательно, если пользователь отключает репликацию почтового файла, она не будет происходить, пока пользователь снова не отметит базу данных.

Опции настройки вкладки Replication

Вы можете модифицировать вкладку Replication под нужды пользователей. Ниже даётся набор инструкций по указанию пользователям опций конфигурации вкладки Replication.

Пользователи могут нажать на направленную вниз стрелку на кнопке Replication (см. Рисунок 15). Они могут менять размеры иконок, изменять режим отображения вкладки, отображать все базы данных или только отмеченные для репликации или создавать папки для организации баз данных.

Рисунок 15. Изменение внешнего вида и функциональности вкладки Replication

Заключение

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

Система управления документооборотом Lotus Notes

Характеристика

LotusNotes– ориентированная на БД собственного формата система клиент-серверной архитектуры, разработанная корпорациейLotusDevelopment, разработкой и продажами которой в настоящее время занимаетсяIBM. Система работает под управлением различных платформ семействWindowsиUNIX.

Назначение

LotusNotesизначально разрабатывалась для работы в локальных сетях, но сейчас может работать и в глобальных, например, в Интернете .

Основные компоненты:

ПО промежуточного уровня (Middleware).

Краткое описание функционирования

Каждый клиент или сервер может иметь несколько локальных БД. Каждая БД представляет собой коллекцию заметок (notes). Клиент представляет собой совокупность запускающей подсистемы и модулей просмотра, сопоставимых по функциональности сWeb-браузерами. В отличие от браузеров, они предоставляют возможности не только чтения, но и редактирования информации.

Основная функция сервера Lotus(LotusDomino) – управлять коллекцией БД и предоставлять к ним доступ клиентам и другим серверам.

Репликация

Репликация основывается на связующих документах (connection documents) – особых заметках, содержащихся в каталоге Domino и описывающих время, способ (схему репликации – см. табл. 5) и объект репликации .

Таблица 4 Разновидности идентификаторов Notes
Идентификатор	видимости	Описание
Универсальный идентификатор (Universal ID, UNID)	Глобальная	Глобально уникальный идентификатор, присваиваемый каждой заметке
Идентификатор инициатора (Originator ID, OID)	Глобальная	Идентификатор заметки, включающий информацию об истории
Идентификатор БД (Database ID)	В пределах сервера	Отметка времени создания БД или восстановления БД после сбоя сервера
Идентификатор заметки (Note ID)	В пределах БД	Идентификатор заметки, зависящий от экземпляра БД
Идентификатор реплики (Replica ID)	Глобальная	Отметка времени, используемая для идентификации копий одной БД

Операции изменения:

модификация документа;

добавление документа;

удаление документа.

Модифицированный документ должен быть разослан на все реплики. Изменения заметки заканчиваются изменением ее OID, предыдущее значение которого копируется в журнал истории документа. При добавлении документа для него создаются новые UNID и OID. При удалении документа на его место в БД помещается заглушка удаления (deletion stub). Заглушка удаления не уничтожается до тех пор, пока не уничтожены все копии удаленного документа .

Таблица 5 Схемы репликации
	Описание
Извлечение-продвижение	Задание на репликацию считывает изменения с целевого сервера и передает на него собственные изменения
извлечение	Задание на репликацию считывает изменения с целевого сервера и передает на него собственные изменения по его запросам
Продвижение	Задание на репликацию передает собственные изменения на целевой сервер, никак не реагируя на имеющиеся на нем изменения
Извлечение	Задание на репликацию считывает изменения с целевого сервера, не пытаясь передать ему собственные изменения

Разрешение конфликтов репликации

В процессе репликации по схеме извлечение-продвижение для каждой реплики создается список OID. Затем сравниваются списки с двух серверов. Заметки с UNID, отсутствующими на другом сервере, (т. е. добавленные) должны быть переданы на него.

Для заметок, имеющих в списках серверов A и B одинаковые UNID, но разные OID, выполняются следующие действия. Задание на репликацию просматривает истории обеих заметок. Если одна из историй является частью другой, то конфликт отсутствует: более новая заметка замещает более старую. Если изменения относятся к различным элементам заметки, то конфликтующие модификации также отсутствуют: в объединенную заметку передаются наиболее новые элементы. Во всех остальных случаях конфликт неразрешим. При этом Notes выбирает один из документов победителем. Им становится копия с большим последовательным номером в OID или (в случае равенства последовательных номеров) с большей отметкой времени .

Репликация в кластере

В кластере вместо явного планирования репликации при помощи связующих документов изменения просто немедленно передаются на все реплики кластера.

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

4. Lotus Domino и Notes как совокупность восьми ключевых технологий

Что же такое «интегрированные системы для совместной работы» вообще и что составляет суть Domino и Notes, в частности с технологической точки зрения? В упомянутом ранее отчете IDC содержатся интересные результаты опроса европейских пользователей систем для совместной и коллективной работы. По результатам этого опроса были указаны в порядке убывания интенсивности использования следующие технологии, которые и составляют суть «ПО для совместной работы»:

Электронная почта.
Средства распространения и совместного использования информации.
Управление документами.
Возможности выполнения специализированных приложений.
Средства управления корпоративными знаниями.
Управление потоками работ (workflow).
Средства поддержки приложений «дискуссионного» типа.
Мгновенная пересылка сообщений (chat).
Конференции в реальном времени.

Lotus Domino и Notes сами по себе, а также в сочетании с другими продуктами семейства Domino включают все перечисленные выше технологии. И все же если говорить о ключевых технологиях, важных с точки зрения понимания архитектуры продукта и возможностей его применения, то можно выделить следующие:

Документоориентированная база данных.
Средства разработки приложений.
Система электронной почты.
Система реплицирования (тиражирования) документов, информации и приложений.
Средства защиты информации и разграничения доступа.
Средства календарного планирования и составления расписаний.
Web-технологии и технологии Internet/Intranet.
Средства интеграции с реляционными базами данных, системами управления ресурсами предприятий (ERP) и транзакционными системами.

Многие из этих технологий, взятые в отдельности, были достаточно хорошо известны и до появления Notes. Но, объединенные вместе в рамках единой системы, они дали совершенно новое качество, которое позволяет утверждать: в настоящее время на рынке нет аналога данному программному продукту.

Прежде чем мы кратко остановимся на каждой из этих восьми технологий, сделаем следующее замечание. Во всей статье мы упоминаем в основном два программных продукта: Lotus Domino и Lotus Notes. Это связано с тем, что Domino/Notes - это клиент-серверная технология, где в качестве сервера выступает Lotus Domino, а в качестве клиентской части - Lotus Notes. Однако сразу же следует отметить уникальность сервера Domino, которая состоит в том, что это еще и Web-сервер и почтовый сервер, поддерживающий стандарты Internet, поэтому в качестве клиентской части для работы с приложениями Domino и электронной почтой могут использоваться Web-браузеры и другие почтовые клиенты Internet. За счет поддержки промышленных стандартов, таких, в частности, как ODMA, ActiveX, OLE и ряда других, для доступа и сохранения данных на сервере Domino с той или иной степенью полноты в качестве клиентов могут использоваться популярные офисные пакеты, мобильные телефоны, персональные цифровые помощники типа PalmPilot, пейджеры и т.д.

4.1. Документоориентированная база данных Domino/Notes

Сердцем Domino и Notes является хранилище объектов, известное как NSF (Notes Storage File), в котором и хранятся данные.

Базы данных Domino и Notes отличаются от реляционных СУБД, с которыми многие привыкли работать. В реляционных СУБД данные описываются с помощью таблиц, жестко задающих формат данных.

Основой единицей хранения информации в базе данных Lotus Domino/Notes является отдельный документ . Структура документа Notes определяется формой , содержащей в себе набор полей различных типов. Например, документ, относящийся к обслуживанию клиентов, может содержать в себе дату, имя клиента, идентификационный номер клиента, имя оператора, текстовое поле для описания запроса клиента, а также поле статуса запроса. Notes использует индексированные представления для отображения списков документов, навигаторы и полнотекстовые индексы для поиска документов, а также агенты для автоматизации определенных процессов в базе.

Реляционная база данных, как правило, жестко структурирована, и каждая запись в таблице имеет один и тот же набор полей, пространство под который определено и выделено заранее. Люди в 90% случаев имеют дело с документами, которые являются слабо структурированными объектами, и Notes изначально проектировался для работы с такой информацией. Это и предопределило структуру базы данных Notes. Отдельный документ не обязательно имеет такие же поля, что и остальные документы; под поле выделяется столько памяти, сколько это необходимо для хранения конкретных данных; поля в документы могут добавляться динамически, по мере возникновения необходимости в них или при изменениях представлений разработчиков и пользователей.

База данных Notes может хранить любые типы данных - от простого текста, чисел, времени и даты до форматированного текста, графических образов, звука, видео и произвольных данных, которые могут храниться в виде присоединенных объектов в своем родном формате. Например, это может быть присоединенный файл формата MS Word или электронной таблицы Lotus 1-2-3.

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

Хранение форматированного текста, присоединенных и внедренных объектов. Хранилище объектов Notes оптимально подходит для эффективного управления и распределения деловой информации. Эта информация обычно состоит из различных типов данных, таких как таблицы (возможно, полученные из реляционной базы данных или электронной таблицы), отформатированный текст, Web-страницы, графика, присоединенные или внедренные объекты, объекты мультимедиа: сканированные изображения и факсы, звуковые фрагменты и видеофрагменты. Таким образом, Notes может выступать в качестве универсального хранилища объектов и центральной точки доступа к любой корпоративной информации.
Документы могут относиться друг к другу как «родительский» и «дочерний» документы. Например, если вы создали приложение для отслеживания внешних контактов, то «родительским» документом может быть описание организации, «дочерними» на первом уровне - карточки сотрудников, а на следующем - отчеты о встречах с сотрудниками или письма и т.д.
Полнотекстовый поиск. Lotus Notes поддерживает функцию полнотекстового поиска, которая позволяет пользователям индексировать документы Notes и вести их поиск по запросам. Notes показывает документы, удовлетворяющие критериям поиска, либо в порядке степени их соответствия критерию, либо в заданном пользователем порядке.
Управление версиями. Lotus Notes содержит функцию управления версиями документа, которая отслеживает многочисленные изменения, вносимые в документ различными пользователями. Автоматическое управление версиями реализовано таким образом, что при каждом сеансе редактирования документ помечается либо как основной, либо как производный от оригинала. При этом изменения, внесенные в документ Notes одним пользователем, не стираются, когда другой пользователь сохраняет свои изменения в документе. Функция управления версиями Notes является достаточно гибкой, ее можно модифицировать в соответствии с потребностями любой рабочей группы. Кроме того, пользователи имеют возможность добавлять дополнительные комментарии к оригиналу документа, работая с ним как с производным, то есть не сохраняя оригинал повторно.
Ссылки на документы. Notes имеет средства поддержки гипертекста, то есть каждый документ может содержать «ссылки» на другие документы в любой базе данных Notes или на Web-документы. Пользователи имеют возможность легко создавать ссылки с одной страницы на другую с помощью одного щелчка мыши.

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

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

Базы данных Domino/Notes поддерживаются целым набором сервисов , которые берут на себя выполнение большого количества операций нижнего уровня. Например, отдельный сервис отвечает за создание и обновление индексов , сервис репликации отвечает за поддержание копий баз данных на разных серверах и клиентских машинах в синхронном по отношению друг к другу состоянии, сервис маршрутизации отвечает за доставку почтовых сообщений и т.д. Эти сервисы выполняются на сервере Domino, некоторые из них - также на клиенте Notes. Разработчики приложений для Domino не должны думать об этих задачах нижнего уровня, а могут полагаться на сервисы Domino, которые выполнят эту трудоемкую, полную мелких деталей, черновую работу.

Базы данных Notes, как правило, располагаются на серверах Domino, однако могут находиться и на клиентских машинах с Notes, что является очень важным с точки зрения поддержки работы пользователей в режиме off-line и мобильных пользователей. Пользователи получают доступ к данным на сервере через сеть, либо через модем, либо работая с данными локально с помощью клиента Notes. Однако, как уже отмечалось, в качестве клиента для работы с данными и приложениями на сервере Domino могут использоваться Web-браузеры, почтовые клиенты Internet и т.д.

Пользователи имеют возможность просмотра списков документов, хранящихся в базе данных Domino/Notes, которые также называются представлениями, видами или взглядами (view). Когда пользователь Notes открывает вид, то названия полей выводятся как заголовки столбцов данных. Если, например, пользователь желает просмотреть документы по дате, то Notes, отсортировав их по значениям в этом поле, открывает вид, самый левый столбец которого содержит дату, а прочая информация из полей (номер клиента, название политики и т.п.) выводится в столбцах справа от основного. Виды в Notes отличаются гибкостью и используют схематичную метафору, основанную на «раскрытии и скрытии». Например, если основной документ имеет множество дочерних документов, то пользователь может по своему выбору просмотреть либо основной документ, либо основной документ и все документы следующего уровня, либо все уровни документов, относящихся к первому основному документу.

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

Таким образом, чтобы создать работоспособную базу данных в Domino/Notes, достаточно выполнить следующие действия:

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

Для решения этих задач имеются соответствующие графические средства разработки, о чем речь пойдет ниже. Создав данные элементы, можно начинать вводить документы и работать с базой данных. При этом следует отметить, что в Notes понятия «база данных» и «приложение» являются, по сути дела, синонимами. Хотя в более сложных случаях Domino-приложение может состоять из нескольких связанных между собой баз данных либо интегрировать в себе данные из других источников, таких как реляционные СУБД. Конечно, для создания более сложных приложений потребуются также другие средства разработки, поставляемые вместе с Domino и Notes, о чем мы расскажем далее.

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

4.2. Репликация

Многие заказчики, уже давно и активно использующие Domino и Notes, на вопрос о том, какая из всех технологий этих продуктов им больше всего нравится, называют репликацию. По сути, системой репликации решаются две основные задачи:

Поддержка территориально-распределенной работы (синхронизация данных и приложений).
Поддержка работы мобильных пользователей.

Domino и Notes обеспечивают коллективное использование информации в любое время и независимо от места расположения пользователя. Пользователями баз данных и приложений Notes могут быть сотрудники из различных подразделений организации в регионе, в стране или во всем мире. Каждое из этих подразделений может иметь свой сервер, подключение к которому персонала производится достаточно просто и без больших затрат. В результате пользователь будет иметь доступ к данным и приложениям на своем локальном сервере, вместо того чтобы работать с удаленным сервером по медленным каналам связи.

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

Следует отметить «всеядность» Domino и Notes в плане использования каналов связи: это могут быть сети TCP/IP, X.25, ISDN, коммутируемые телефонные каналы и т.д. Одна из самых тонких и великолепно проработанных разработчиками Lotus технологий - эффективное использование произвольных каналов связи.

Domino позволяет также создавать и централизованную архитектуру, если коммуникации, доступные конкретной организации, это позволяют.

Репликация в Notes непревзойденна по своей функциональности и степени гранулированности: она выполняется на уровне отдельных полей и идеально настраиваема . Репликация характеризуется следующими свойствами:

Двунаправленность. Пользователи во всех подразделениях организации, в которых имеется полученная с помощью репликации копия базы данных, могут добавлять, модифицировать и удалять документы. Двунаправленная репликация в Notes синхронизирует все изменения, произведенные во всех представительствах, а не только распространяет по удаленным серверам изменения, внесенные в центральной точке.
Эффективность . При синхронизации баз данных репликация необходима только для новых полей документов или для полей документов, в которые были внесены изменения на любом из экземпляров базы данных, участвующих в процессе репликации. Такая репликация на уровне поля обеспечивает оптимальное использование ресурсов и самую короткую продолжительность цикла синхронизации.
Репликация для клиента Notes. Пользователям, подключающимся к серверу от случая к случаю (например, мобильные пользователи, работающие в удаленной точке, находящиеся в командировках или дома), необходим такой же уровень доступа к информации, как и подключенным пользователям. Notes не ограничивается организацией взаимодействия между серверами, он также поддерживает репликацию между клиентом и сервером. За счет этого обеспечивается великолепная поддержка работы мобильных пользователей , работающих с данными и приложениями Notes в режиме off-line точно так же, как если бы они находились в офисе и были подключены к серверу. Пользователь легко может унести с собой актуальные копии баз данных Notes, работать с ними локально, а затем синхронизировать их, как только представится такая возможность.
Выборочная репликация. С помощью всего лишь нескольких щелчков мыши пользователь Notes может скопировать к себе только определенное подмножество информации из базы данных Notes. Notes позволяет пользователям определять тип документов, с которыми они хотят работать на своих клиентских рабочих станциях. При помощи выборочной репликации пользователи могут копировать только те документы, которые подверглись изменениям, например, за последние 30 дней или были только составлены каким-либо конкретным членом рабочей группы.
Фоновая репликация. Проведение процесса репликации для мобильного пользователя не должно вызывать прекращения всей остальной работы на портативном или домашнем компьютере. Репликация в Notes может выполняться в фоновом режиме, что позволяет пользователю продолжать работу над другими задачами.
Синхронизация дизайна и логики приложений. Этот аспект часто остается незамеченным при поверхностном знакомстве с продуктом, хотя именно данная технология позволяет легко распространять приложения по всей организации и за ее пределами и вносить в них нужные изменения по мере необходимости. Во время сеансов связи между серверами Domino пересылаются не только данные как таковые, но и все изменения в дизайне и логике приложения. Domino хранит данные и дизайн отдельного приложения в едином файле NSF. Представьте, например, приложение Notes для сбора отчетности из регионов. Если, скажем, разработчики в Москве внесут изменения в форму ежедневной отчетности, то в процессе очередного сеанса репликации все эти изменения будут переданы в удаленные подразделения. На следующее утро пользователь во Владивостоке увидит, что дизайн приложения изменился, и начнет работать с новой, по сути, версией приложения.

4.3. Система электронной почты и передачи сообщений

На самом деле, если бы из перечисленных выше восьми ключевых технологий было бы разрешено воспользоваться только одной - самой важной, эффектной, надежной и т.д., то, по всей видимости, многие пользователи остановили бы свой выбор на системе электронной почты Domino/Notes. Внедрение продукта уже оправдывает себя только при использовании его в качестве корпоративной системы электронной почты.

Эта система может быть охарактеризована словами: надежная, масштабируемая, защищенная и управляемая . В мире есть организации, в которых более 100 и даже 200 тысяч сотрудников объединены системой передачи сообщений Domino и Notes. Это означает, что, выбрав эту технологию, вы не натолкнетесь на такие технологические ограничения, когда все работает хорошо при десятках или нескольких сотнях пользователей, но при дальнейшем расширении инфраструктуры начинаются непреодолимые проблемы. Что касается защищенности, то Domino предлагает самую мощную из возможных систему защиты для почты в Internet, применяемую для подписываемых и шифруемых сообщений, за счет бесшовной интеграции инфраструктуры публичных ключей (Public Key Infrastructure, PKI) и сертификатов X.509 V3.

Важно то, что Lotus Development является единственным поставщиком, предлагающим полную интегрированную коммуникационную платформу для организаций, стремящихся перейти от обычной электронной почты к усовершенствованным возможностям передачи сообщений и Web-приложениям для совместной работы. Сервер Domino обеспечивает встроенную поддержку любых клиентов передачи сообщений, которыми может воспользоваться заказчик: Web-браузеров, Microsoft Outlook, Eudora и других почтовых клиентов POP3 и IMAP4. Кроме того, Domino является превосходным дополнением к лучшему в мире клиенту для совместной работы и электронной почты - Lotus Notes.

Система передачи сообщений Notes используется как по своему основному назначению - для связи между людьми, так и в качестве важного компонента приложений автоматизации рабочих потоков (workflow), а также в качестве платформы для группового ведения календаря и планирования.

Система передачи сообщений Notes предоставляет в ваше распоряжение простой в использовании ящик электронной почты. Более опытные пользователи для обработки и организации больших объемов почты могут использовать средства управления сообщениями. Пользовательский интерфейс Notes построен на базе завоевавшего множество наград интерфейса Lotus cc:Mail, который, по сути, стал стандартом интерфейса электронной почты для всех производителей. Notes включает в себя мощный редактор для форматирования текста почтового сообщения. Имеется возможность использования агентов для выполнения различных задач - таких, например, как просмотр присоединенных к поступающим сообщениям файлов на наличие ключевых слов и сохранение их в соответствующей папке. Агенты могут автоматизировать выполняемые на сервере задачи, давая вашему Web-узлу возможности по автоматической генерации почтовых сообщений определенного содержания при наступлении определенных условий и событий.

Следует особо отметить, что электронная почта является неотъемлемой, фундаментальной частью систем автоматизации потоков работ и документооборота (workflow). Интегрированная в Domino/Notes система передачи сообщений и базы данных документов объединяют в себе оба метода коллективного использования информации - «принудительное проталкивание» и «добровольное извлечение», а также предоставляет пользователям интуитивно понятные и эффективные средства для совместной работы. Например, при создании исходного варианта документа, который должны просмотреть несколько сотрудников, пользователь может послать им сообщение по электронной почте, которое включает в себя только ссылку на этот документ. Каждый из получивших сообщение может одним щелчком мыши открыть документ, что обеспечивает работу всех сотрудников с одним и тем же, самым последним, вариантом документа. Почтовые сообщения могут содержать ссылки на любые документы в базе данных Notes, включая дискуссии, профили заказчиков и документацию (такие, например, как описания правил и процедур, руководства по поиску неисправностей и т.д.), страницы Web и службы новостей.

В большинстве бизнес- и workflow-приложений требуется поставить в известность конкретного человека или обновить документ на основе значения определенного поля или состояния процесса. Рассмотрим приложение по обслуживанию заказчиков. Запрос заказчика поступает в виде формы, заполненной им на Web-странице. Запрос вводится в базу данных Domino по обслуживанию заказчиков. После ее сохранения сервер Domino автоматически посылает сообщение по электронной почте соответствующему представителю по обслуживанию. Представитель открывает сообщение и щелчком мыши на содержащейся в нем ссылке открывает запрос из коллективно используемой базы данных, в которой можно сохранять свои замечания и комментарии. Кроме того, Domino-приложение контролирует этот процесс, так что если он по какой-то причине останавливается (например, если представитель не предпринимает никаких действий по этому запросу в течение 12 часов), то Domino рассылает дополнительные сообщения по электронной почте, на этот раз не только представителю по обслуживанию, но и его менеджеру и начальнику отдела обслуживания заказчиков, предупреждая их о потенциальной проблеме, перед тем как она действительно приобретет остроту.

Вследствие упомянутых выше возможностей, функций электронной почты, инициированных по умолчанию, а также того, что вместе с Domino поставляются шаблоны баз данных типа «Библиотека документов», «Дискуссионная база данных», «Согласование документов» и ряд других, Domino и Notes являются, по сути, готовым решением в области совместной работы людей, которое можно сразу же начать использовать. Обеспечение доступности этих возможностей пользователям Internet (не имеющим клиента Notes), выполняется просто за счет выбора шаблона, поддерживающего работу через Web.

Естественно, функционирование системы электронной почты невозможно без ряда сервисов и служб, на которых основана среда передачи сообщений и которые поддерживают сервер Domino:

Надежное, гибкое и масштабируемое хранилище сообщений Domino , основанное на рассмотренной выше технологии баз данных.
Сервис каталога масштаба предприятия (Domino Directory). Каталог Domino Directory - это масштабируемый и защищенный компонент архитектуры с полной поддержкой протокола службы каталогов LDAP V3, который может легко справляться с требованиями к службе каталогов даже очень крупных предприятий, обеспечивая гарантированную поддержку миллионов записей. Изменения, сделанные в одном экземпляре этого каталога, могут распространяться по организации с помощью эффективного и защищенного сервиса репликаций Domino, с гарантией синхронизации всех копий Domino Directory. В отличие от некоторых своих конкурентов, Domino не требует от административного персонала постоянно обновлять все копии каталога для обеспечения изменений. Возможности Domino и Notes по реплицированию только измененных частей записей каталога (вплоть до уровня поля) еще более уменьшают время репликации и сетевой трафик, связанный с синхронизацией каталогов по сети. Domino Directory является краеугольным камнем модели безопасности Domino и Notes. Он содержит сертификаты, используемые для аутентификации всех пользователей при их входе в систему, сертификаты, в свою очередь, содержат публичные ключи, используемые для подписей и шифрования. Этот каталог также играет роль центра управления и конфигурирования сети. Он обслуживает пользователей, группы пользователей, записи о соединениях, роли и другую информацию по контролю доступа, что позволяет осуществлять централизованное управление (даже в режиме off-line) всей сетевой инфраструктуры.
Сервис маршрутизации сообщений. Маршрутизатор Domino обеспечивает высокопроизводительную и высокоточную передачу сообщений - как для почты, так и для приложений поверх широкого диапазона протоколов. Например, пользователи Domino могут работать с множеством протоколов, используя и SMTP и родной для Notes протокол - Notes Remote Procedure Calls (NRPCs). Для совместимости с существующими системами NRPCs способен работать с широким диапазоном сетевых протоколов. Кроме того, маршрутизатор Domino дает администраторам новые способы уменьшения издержек и улучшает эффективность использования сети за счет многорежимной маршрутизации, широких возможностей по подавлению спама, поддержки системы адресов Internet, исчерпывающей поддержки расширенной спецификации E/SMTP, встроенного MIME-кодирования данных и файловых объектов без дополнительных преобразований.
Сервис безопасности (более подробно будет рассмотрен позже).

Сервер Domino поддерживает также режим хранения «одной копии объекта», что позволяет экономить дисковое пространство и уменьшать трафик при рассылке одних и тех же сообщений большому количеству пользователей.

Таким образом, передача сообщений в Domino - это передача сообщений в соответствии со стандартами Internet, для которых Domino предлагает всеобъемлющую поддержку.

Алгоритм репликации
Рассмотрим пошагово, что происходит в сеансе репликации

Шаг 1

данному серверу

Шаг 2

кэш идентификаторов реплик

Шаг 3

Определяется, не запрещены ли репликации базы. Если в установках одной из реплик выбрана опция, запрещающая репликацию (Temporarily disable replication for this replica в настройках репликации), репликации базы не происходит, о чем уведомляет строка на консоли сервера Replication is disabled for <сервер> <база>
Может ли каждый из серверов открыть реплику на другом сервере. Если один из серверов не имеет доступ (уровень доступа No Access) к одной из реплик, либо не имеет доступа к подключенному (связаному) каталогу, внутри которого находится реплика, репликация базы заканчивается выдачей сообщения Access control is set in <сервер> <база> to not allow replication from <сервер> <база> . Если оба сервера имеют доступ к обеим репликам, репликатор открывает реплику на вызванном сервере.
Репликация ACL. Для репликации ACL необходимо, чтобы у вызванного сервера был доступ Управляющего (Manager) в ACL вызвавшего сервера и в настройках репликации на вызвавшем сервере была выбрана опция Receive these elements from other replicas: Access Control List . Репликатор сравнивает даты изменения ACL в обеих репликах. Если ACL "чужой" реплики изменился позднее, чем ACL "своей", репликатор получает ACL с вызванного сервера и заменяет им свой ACL, после чего снова проверяет, может ли каждый из серверов открыть реплику другого. При схеме Pull-Push зеркально-аналогичные действия выполняются репликатором по отношению к ACL на вызванном сервере. При схеме репликации Pull-Pull обновление (если необходимо) произведет репликатор вызванного сервера после передачи ему управления во второй фазе репликационной сессии
Репликация элементов дизайна. Для успеха этой части репликации базы необходимо, чтобы уровень доступа вызванного сервера в ACL реплики базы на сервере-инициаторе был не ниже уровня Разработчика (Designer). Сервер выискивает и принимает на свою сторону элементы дизайна, изменённые на вызванном сервере позднее, чем изменились эти элементы на его стороне, заменяя последние. Но только если это разрешают делать опции, прописанные в параметрах репликации базы в полях Receive these elements from other replicas: Design elements, Agents, Replication formulas . Удаление элементов дизайна происходит подобно удалению документов путем передачи информации об удалении (stubs ). После приёма изменений сервер производит выталкивание изменений, произошедших на своей стороне (схема Pull-Push ) после зеркально-аналогичных проверок, либо переходит к следующей стадии приема, оставив передачу изменений до второй фазы сессии (схема Pull-Pull )
Репликация документов. Прием изменений документов на сервер-инициатор происходит, если вызванный сервер имеет доступ к базе (ACL) и документам (поля доступа к документам типа Readers и Authors), позволяющий создавать, изменять или удалять документы. Среди документов вызываемого сервера строится специальное представление, содержащее документы согласно формуле репликации. Затем репликатор создает список идентификаторов документов, которые были изменены со времени последней репликации. Если в настройках репликации включен параметр Receive documents from server - Smallest first , полученный список сортируется по размеру документа, в противном случае - по дате модификации. Далее для каждого документа по идентификатору ищется его собрат в своей реплике. Если этого не удалось, новый документ добавляется в реплику. Если документ не новый - сравниваются время последней модификации и последовательные номера этих документов. Если документ оказался измененным с момента последней репликации на обоих серверах - возникает репликационный конфликт (этот случай рассматривается ниже). В противном случае изменения передаются на сервер-инициатор репликации, модифицируя документ на его стороне. Причем, начиная с версии 4.x происходит не полное копирование всех полей, копируются только поля, имеющие неодинаковые флаги Seq Num . Это существенным образом сокращает объём передаваемой информации. Именно это и называют репликацией на уровне полей (пунктов, items). Далее, в зависимости от схемы репликации, либо репликатор сервера повторяет описанные в этом пункте действия в зеркальном направлении, выталкивая новые и модифицированные документы (схема Pull-Push ), либо сразу переходит к следующему пункту, оставляя эту работу для чужого репликатора (Pull-Pull )
Обновление записи в истории репликаций. При успешном завершении предыдущих стадий репликации репликатор делает запись в истории репликаций своей реплики. Если репликация происходит по схеме Pull-Push , то подобную запись репликатор вносит и в историю репликации чужой реплики

Шаг 4

Pull-Push

обратной стороне

Устранение конфликтов репликаций
Когда репликатор обнаруживает, что с момента последней репликации оказались изменёнными версии документа в обеих репликах базы, он вынужден обрабатывать ситуацию репликационного конфликта. Выбирается версия документа, имеющая более позднее время модификации и используется в качестве основного документа. Вторая версия документа сохраняется в виде ответного документа (response) к основному (наличие поля $Ref с ссылкой на основной документ). Кроме того, в ответный документ добавляется поле с именем $Conflict и пустым значением. В представлениях, поддерживающих иерархическую организацию документов, такие документы отображаются в виде ответного документа, отмеченного ромбиком в колонке выделения документов, и строкой .
Собственно, на разрешение конфликтов, начиная с пятой версии Notes, влияет значение поля $ConflictAction , значение которого в интерфейсе клиента Domino Designer может быть задано через свойство формы Conflict Handling , по которой создаются документы

Значение этого свойства Create Conflicts (отсутствие поля $ConflictAction или значение поля, установленное в значение "1" , в документе) задаёт описанное выше разрешение конфликтной ситуации - создание репликационного конфликта
Значение свойства Merge Conflicts (значение поля $ConflictAction , равное "2" ) - объединение конфликтов, произошедших при редактировании различных полей в различных репликах базы данных

Организационно для разрешения возникших конфликтов необходимо собрать авторов изменений "за круглым столом" для осмысления внесенных изменений и выработки согласованного варианта.
Технически этот вопрос разрешается так. Если решено оставить версию документа, принятую за основную, конфликтный документ просто удаляют. Если нужно оставить версию конфликтного документа, то его открывают в режиме редактирования, сохраняют (при этом исчезают поля $Conflict и $Ref , и документ становится главным), а затем удаляется другая версия документа. [Но в этом случае, если конфликт произошел с ответным (response) документом, вместе с полем $Ref теряется и его привязка к главному документу. Необходимо восстановить утерянную связь]. Наконец, если должны остаться обе версии, достаточно пересохранить конфликтный документ.
Если в процессе эксплуатации базы наблюдается усиленная тенденция к образованию конфликтов, скорее всего, необходимо изменять или дизайн базы, или технологию работы с ней. Одним из наиболее эффективных приемов изменения дизайна - разбиение большого документа на несколько мелких, где изменения вносятся не в один документ, а на основе создания новых, более мелких документов. Кроме этого, в окне свойств формы предусмотрены опции Versioning (Поддержка версий) - управление версиями документа и Conflict Handling (Обработка конфликтов) - с параметром автоматического слияния (Merge conflicts ) конфликтных документов, если разные пользователи изменяли в них разные поля.
К организационным моментам относится, в первую очередь, технологическое ограничение возможности редактирования документа как можно меньшим количеством пользователей (в идеале - автор документа плюс, для страховки, управляющий базы). Остальные пользователи вносят изменения в документ путем создания ответных к нему документов в форме замечаний.