В этом материале подробная инструкция по настройке обмена РИБ для 1С:Предприятие 8 и проблемы, с которыми столкнулся автор.
1. Создание узлов
Создаем новые узлы (главный и подчиненный): в пользовательском режиме "Операции / Планы обмена/Полный"
Выберем план обмена "Полный"
Создаем две записи:
- первую запись назовем "ЦБ" (главный узел), код укажем "ЦБ",
- вторую запись назовем "Подчиненный узел", код укажем "ПУ".
Значек с зеленным кружком - "ЦБ" (главный узел)
Для подчиненного узла нажимаем на иконку "Создать начальный образ". (Потребуется монопольный доступ)
Создать начальный образ
Далее в открывшемся окне заполняем параметры новой базы. По окончании нажимаем кнопку "Готово"
Создание начального образа ИБ
Начнется создание начального образа подчиненного узла распределенной информационной базы, по окончании появится сообщение "Создание начального образа успешно завершено". Жмем кнопку "ОК".
Добавляем базу подчиненного узла в список баз, запускаем ее.
В этой подчиненной базе открываем полный план обмена - значок "ЦБ красный, это значит, что этот узел является главным для информационно базы, в которой мы находимся.
2. Настройка префиксов
Для каждой базы, в настройках параметров учета (в УПП "Сервис / Параметры учета") на закладке "Обмен данными", устанавливаем префиксы. Это делается для того чтобы не возникало конфликтов в номерах и кодах документов и справочников, созданных в двух базах.
Для автообмена, устанавливаем галочку "Использовать механизм автоматического обмена..."
Закладка "Обмен данными"
3. Добавляем настройку обмена данными между узлами
Открываем: "Сервис \Распределенная информационная база (РИБ)\Настроить узлы РИБ"
Нажимаем "Добавить", откроется окно "Настройка обмена данными"
Настройка обмена данными
Нажимаем на значок "Выполнить обмен по текущей настройке"
Выполнить обмен по текущей настройке
Теперь о "подводных камнях"
1. Обмен данными может выполняться в автоматическом режиме и может быть инициализирован в следующих случаях:
* При запуске программы. Обмен будет выполняться при запуске программы,
* При завершении работы с программой. Обмен будет выполняться перед завершением пользователем работы с программой,
* При появлении каталога. Обмен будет выполнен только в том случае, если каталог указанный пользователем был невиден, а в настоящий момент стал виден. Настройка может быть использована для выполнения автоматического обмена при подключении к локальной сети или flash карты. Программа периодически будет проверять видимость указанного в настройках каталога и отмечать его текущее состояние,
* При появлении файла. Рекомендуется использовать данные режим, когда нужно выполнить обмен, если появляется входящий файл обмена данными. В этом случае, достаточно указать полный путь к входящему файлу обмена данными. Программа периодически анализирует наличие файла, и как только он появится, будет выполнен обмен, а после обмена этот файл будет принудительно УДАЛЕН (это делается для того, что бы процедура обмена не выполнялась постоянно),
* Периодический обмен данными. Обмен будет выполняться согласно настройкам периодического обмена данными. Если информационная база работает в файл-серверном режиме, то периодический обмен выполняется только у пользователя, который указан в параметрах учетной политики как "Пользователь для регламентных заданий в файловом режиме". В Клиент-серверном варианте обмен выполняется на сервере 1C:Предприятия.
У меня Клиент-серверный вариант - для работы регламентного автообмена пришлось перегружать сервер
2. Кодировка Windows.
Обмен прерывался ошибкой - так как не происходит сжатие файла. Это из-за ошибки кириллицы в командной строке при сжатии.
Лечится исправлением кодировок в реестре.
Например, для Windows Server 2008 -
Код
REGEDIT4
"1250"="c_1251.nls"
"1251"="c_1251.nls"
"1252"="c_1251.nls"
"1253"="c_1251.nls"
"1254"="c_1251.nls"
"1255"="c_1251.nls"
3. Создавая копию базы (например, для доработки) в клиент-серверном варианте, НЕОБХОДИМО, чтобы РЕГЛАМЕНТНЫЕ ЗАДАНИЯ КОПИИ базы были ВЫКЛЮЧЕНЫ. Блокировка регламентных заданий для копии ВКЛ
Если их не заблокировать, то копия будет делать обмены по тому же расписанию, что и основная база. Значит, часть сообщений в удаленные узлы будет формироваться из рабочей базы, а часть из копии, что приведет рассинхронизации конфигураций.
Это моя первая в жизни статья, конструктивная критика приветствуется.
Целевая аудитория - те, кто первый раз сталкивается с РБД.
Задачи РБД
Первое с чего необходимо начать - это ответить на вопрос «Зачем нам нужна РБД?». Вариантов ответов много, в частности:
- У нас есть филиалы, работающие в несвязных БД. Теперь мы хотим, чтобы информация между ними синхронизировалась;
- У нас есть филиалы, однако нагрузка на базу слишком велика (имеются ввиду блокировкитранзакций, не объем БД) и онлайн актуальность (не путать с актуальностью в несколько минут, онлайн - это когда после выполнения каждой транзакции данные передаются во второй узел) данных для филиалов не требуется;
- У нас есть филиалы, в которых происходит только ввод данных (например, розничные магазины), поэтому можно существенно снизить нагрузку на центральную БД;
- Из соображений безопасности мы хотим, чтобы в филиалах даже теоретически(с админ. паролем) не было доступа к важным данным, например балансу предприятия.
В одном случае для меня были актуальны вопросы 2 и 4, в другом 2 и 3. Первый пункт слишком обширный и в рамках тематики данной статьи рассматриваться не будет.
Также лучше сразу рассмотреть проблематику транспорта файлов обмена, потому что в некоторых случаях она может наложить существенные ограничения на реализацию обмена данных. Сначала необходимо определить в каких филиалах точно появятся узлы РБД (обычно это региональные филиалы). Далее рассматриваем, где ещё мы хотим установить узлы РБД, и нужна ли в них онлайн актуальность. Например, для розничных магазинов далеко не всегда есть возможность установки даже модема, а установка беспроводной связи будет слишком дорогая. Здесь необходимо принять решение - возможно, данный магазин может работать в оффлайне и периодически обмениваться с центром (раз в день/раз в неделю) с помощью физического носителя, например флешки.
В некоторых случаях обмен посредствам физического носителя невозможен, например это очень удаленный филиал, где есть существенные проблемы с наладкой высокоскоростной связи. Здесь стоит примерно подсчитать объем информации при обмене. Часто при актуальности раз в час либо несколько раз в день достаточно 32к модема. Однако стоить помнить, что вместе с обновлениями данных придется иногда присылать обновления самой конфигурации или внешних файлов (печатный формы, фотографии товаров), поэтому периодически будет возникать ситуация, когда файл обмена существенно увеличиться из-за таких обновлений.
Топология
Итого мы получили следующие вопросы, на которые необходимо ответить:
- В каких подразделениях мы гарантированно будем устанавливать узлы РБД и есть ли там возможность установить высокоскоростной канал;
- В каких подразделениях установка узла РБД не требуется;
- Какие подразделения могут работать с актуальностью в несколько часов;
- Какие подразделения могут работать в оффлайн режиме (обмен данными меньше 3-4х раз в день).
Ответив на эти вопросы, мы получаем приблизительную схему нашей РБД. Для крупных компаний обычно получается нечто следующее:
Рис 1. Типовая схема РБД крупной компании
Если с узлами «Филиал» все относительно ясно - это крупные центры, требующие автоматизации, то под узлами «Магазин» подразумевается узел с серьезной нагрузкой на БД при вводе данных, который для снижения нагрузки следует отделить. Например, магазин с 50-тью кассами и ежедневным товарооборотом больше 10000 единиц.
- Магазины - ввод данных о собственном товарообороте и движении денежных средств. Аналитика поверхностная, только по своему магазину.
- Филиалы - ввод данных неавтоматизированных точек, бухгалтерия, зарплата и кадры, производство и т.п. Аналитика в рамках собственного филиала.
- Центр - ввод данных неавтоматизированных филиалов. Аналитика предприятия в целом.
Важно понимать в каких целях будет использоваться БД в каждом узле. От целей выстраиваются задачи, необходимые к реализации, например:
- Филиалы видят историю взаиморасчетов с контрагентами друг друга;
- Магазины видят остатки товаров во всем (либо части) предприятия;
- Аналитика доходов/расходов, выполнения бюджета и т.п.видны только в рамках иерархии собственного подразделения;
- Бухгалтерия, зарплата и кадры видны только в рамках иерархии собственного подразделения;
- Номенклатура, все её свойства и характеристики видны во всех узлах РБД;
- Относительно иерархии подразделений все данные попадают вверх, но фильтруются вниз;
- В центр попадает абсолютно вся информация о компании.
Ставя перед собой подобные вопросы можно ответить на самый сложный вопрос - какая информация, где и как должна курсировать между узлами РБД? Почему самый сложный? Зная, какие наборы данных курсируют между узлами, можно однозначно понять, как «нарезать» текущую БД, чтобы данные оставались логически целостными. Например, нельзя данные об остатках товаров отрывать от данных о текущих резервах.
Теперь, в зависимости от потоков информации, перерисуем схему РБД:
Что мы видим на рисунке 2? Согласно иерархии подразделений компании выстроилась топология потока информации между узлами БД. Также добавился узел «Центр 2», почему? При реализации топологии «Звезда» нагрузка на центр всегда выше, чем нагрузка на периферийные узлы, при этом часто нагрузка, генерируемая самим узлом, и так высока. Примеры использования узлов «Центр 1» и «Центр 2»:
- «Центр 1» служит только для консолидации данных остальных узлов РБД. Доступ к нему имеет только администратор. «Центр 2» служит для работы головного офиса;
- «Центр 1» служит для работы головного офиса. Однако тяжелые аналитические, тестовые, создающие огромную нагрузку на БД, операции выполняются в узле «Центр 2»; например восстановление последовательности, перепроведение закрытых периодов, формирование сводных отчетов по всему предприятию за длительный промежуток времени, формирование аналитики, приводящей к изменению данных;
- «Центр 1» служит для работы головного офиса. «Центр 2» является резервным, на случай непредвиденных ситуаций для быстрого восстановления всей РБД.
Реализация обмена
Существуют 2 варианта работы РБД:
- Автоматический - происходит без участия пользователя. Контроль за внештатными ситуациями,возложен либо на администратора БД, либо на продвинутого пользователя;
- Ручной - обмен происходит только по желанию пользователя.
По своему опыту приводил все реализации всегда к автоматическому варианту. Если были проблемы с транспортом файлов обмена (наличие сети в узле не постоянно), то максимум, что позволял пользователю - это нажать кнопку «Произвести обмен сейчас». Ситуации, когда помимо обновления данных идет обновление конфигурации желательно приводить тоже к полностью автоматическим (например, используя стороннее ПО).
Формирование пакетов обновлений
Так как есть однозначное решение о том, на какие узлы РБД возложены какие функции, то можно сформировать только тот пакет данных, который нужен этому узлу. С одной стороны, необходимо указать какие типы объектов будут синхронизироваться между узлами. Например, регистры бухгалтерии для узла «Магазин 1» не должны вообще синхронизироваться, т.к. данные вводятся только на уровне узла филиала. С другой стороны те типы данных, которые подлежат обмену необходимо фильтровать с привязкой к подразделению. Например, данные о поступлении денег узла «Магазин 1 филиала 2» могут находиться только в узлах «Филиал 2», «Центр 1» и «Центр 2».
Однако есть и обратная проблема, если слишком сильно фильтровать данные обмена, то пакет данных потеряет логическую целостность. Например, остатки товаров учитываются в разрезе складов, а резервы учитываются в разрезе фирмы в целом, тогда если фильтровать остатки товаров по складам и не фильтровать резервы, то данные будут некорректными.
Также следует решить, на каком этапе своей жизни объект подлежит обмену. Например, обмену подлежат только проведенные расходные накладные, но никак не просто сохраненные. Либо Расходные накладные магазинов никогда не выгружаются из узла «Центр», даже после их корректировки, однако нужно учитывать обратный эффект - данные могут быть рассинхронизированы, либо какие-то изменения могут быть затерты.
Важно понимать - при обмене между узлами, какой-то из них является приоритетным. Рассмотрим ситуацию:
- В узле «Магазин 1» создали документ;
- При обмене он попал в узел «Филиал 1»;
- Документ корректируется одновременно в обоих узлах.
Какой из документов будет считаться истинным? В 1С 8.х при использовании механизма «Планы обмена» по умолчанию приоритетным является главный узел, т.е. в данном случае изменения, сделанные в узле «Магазин 1» будут утеряны и заменены на данные из узла «Филиал 1».
Есть другая, более сложная ситуация, когда корректируют одновременно два связных объекта. Например, расходная накладная и ПКО по ней корректируются в разных узлах, здесь существует вероятность потери целостности, если изменят цены, сумму оплаты, контрагентов и тп.
Также немаловажно контролировать удаление объектов, иначе это может привести к тому, что, например, расходной накладной уже существовать не будет, а движения по бухгалтерскому учету останутся.
Механизмы обмена в 1С 8.х
Существуют два подхода для реализации:
- Механизм «Планы обмена»;
- Собственная реализация регистрации объектов.
Рассмотрим оба варианта.
Механизм планов обмена позволяет, без какой либо настройки, за несколько минут, создать РБД с полным обменом данными. Если установить флаг «Распределенная информационная база», то при создании пакета обновления будут выгружены и обновления конфигурации. Всего за несколько минут можно настроить и правила разрешения/запрета обмена различными типами данных, открыв состав плана обмена. Если установить флаг «Авторегистрация» в положение «Запретить», то данный тип объекта, без дополнительных усилий, никогда обмениваться не будет.
Зачем нужна регистрация, почему не выгружать все и сразу? В любом случае файл, содержащий только изменения состояния БД, будет меньше полного снимка самой БД. Поэтому вариант полной выгрузки рассматриваться не будет.
Как настроить фильтрацию данных по принадлежности к подразделению? Здесь уже придётся программировать. В моей реализации на запись любого объекта была установлена подписка на событие «При записи», где, посредством свойства «ОбменДанными.Получатели», можно установить список получателей данного объекта. Т.е. при выгрузке стандартными средствами для узла, которого нету в списке, объект выгружен не будет. Есть и другое решение - выбирать выгружать ли объект можно непосредственно при выгрузке объекта, в процедурах «ПриОтправкеДанныхПодчиненному» и «ПриОтправкеДанныхГлавному» модуля плана обмена.
Оба варианта имеют право на существование. Однако в качестве лучшего варианта выбрал первый, потому что вычисление признака выгружаемости происходит сразу же при записи объекта, что увеличивает длительность записи объекта на 3-5% (можно оптимизировать, в некоторых случаях можно досвести до 0.01%) т.е. в среднем 0.1-0.3 секунды, а в случае расчета выгружаемости объекта непосредственно при отправке данных, которая и так создает существенную нагрузку на БД, это время будет составлять до нескольких минут.
Для полного понимания работы механизма «Планы обмена» рекомендую прочитать главу 15 книги «Профессиональная разработка в система 1С:Предприятие 8», Габец А.П., Гончаров Д.И.
Любая собственная реализация, на мой взгляд, либо повторит механизм «Планы обмена», либо будет выгружать объект сразу при изменении, либо будет выгружать больше, чем механизм «Планы обмена» (например, выгрузить все изменения за сегодняшний день). Данный вопрос не рассматриваю за неимением опыта реализации.
Транспорт
Задача транспортировки файлов от главного к подчиненному узлу сводиться к максимальной отказоустойчивости. Не редко файлы шифруются либо передаются по защищенному каналу. Для передачи файлов желательно использовать несколько различных служб, либо подготовить несколько различных вариантов подключения. Например, основной способ передачи - это используя FTP -сервер, подключенный через VPN -туннель; резервный - это e -mail сервер с TLS -подключением. Зачем нужен резервный канал с другой службой? Как показывает практика, использовать 2 различных FTP сервера менее надежно, чем FTP сервер и E -Mail .
Рекомендую службу создания пакета обновления отделять от службы транспорта, это повысит отказоустойчивость всего комплекса обмена данными. В случае, если служба, занимающаяся транспортом файлов, не отработает, то служба создания пакетов обновлений продолжит нормально работать и при некоторых условиях будет перезапускать службу транспорта и наоборот.
Моя реализация РБД
Реализация полностью автономна, поэтому как подзадача выступала максимальная отказоустойчивость. Отсюда получилось 2 службы - служба транспорта обновлений и служба импорта/экспорта данных. Обе службы работают независимо друг от друга.
После каждого успешного цикла импорта-экспорта данных сохранялось время последнего обмена с этим узлом. Если обмена не происходило очень долго, то транспортная служба начинала выгружать файлы во все, доступные ей, каналы связи из расчета на то, что второй узел все-таки получит обновления и выгрузит свои файлы. В случае исключительных ситуаций система сама отправляет сообщение администратору с подробным описание ошибки.
Для сокращения объема траффика xml -файлы упаковывались в zip -архивы. Система поддерживает два вида транспорта - FTP и E -mail .
В качестве настроек для фильтра данных существуют две таблицы. В одной (табличная часть планов обмена) хранятся условия по общим реквизитам (для каждого объекта система пытается найти этот реквизит), в другой настройки под конкретный объект метаданных. При записи любого объекта сначала происходит поиск условий по общим реквизитам (например, Подразделение), после чего система пытается определить, есть ли персональное правило на этот тип объекта по всем его реквизитам. Не рекомендую фильтровать списки - велика возможность ошибиться, например, из табличной части расходной накладной исчезнут несколько строк, а остатки при этом будут двигаться все и наоборот.
Важно понимать, под каким системным пользователем будут работать службы, т.к. может не хватить прав на создание файлов даже во временной папке 1С. Для отладки крайне рекомендую писать каждую, успешно выполненную, операцию в журнал регистраций, либо в txt -файл. В 1С 8.1 выполнение серверного кода отладить нельзя.
Для удобства отладки и настройки своей реализации прикладываю обработку "Регистрация изменений", описание которой находится в самой обработке.
Общая схема работы комплекса обмена данными указана на рис 3.
Фильтрация данных происходит в подписке на событие «ПередЗаписью» каждого объекта. Не стоит забывать, что при создании начального образа узла данные тоже необходимо отфильтровать. Процедура создания начального образа довольно длительна, поэтому рекомендую оптимизировать по максимуму её код (например, кэшировать настройки фильтрации).
Послесловие
Главная задача - это ответить на список вопросов:
- Зачем нам нужна РБД?
- Чем не устраивает работа через RDP- клиент?
- Где и почему мы хотим установить узлы РБД?
- Как будет происходить транспорт обновлений?
- Какой уровень отказоустойчивости будет реализован?
Обработка "РегистрацияИзменений"
Обработка позволяет принудительно регистрировать изменения в объектах. Есть несколько вариантов регистрации изменений:
- Если установлена галочка на каком-либо метаданном и НЕ выбран ни единый объект и НЕ установлен флаг "Выгружать по всем значениям", то РЕГИСТРИРУЕТСЯ ТОЛЬКО ВЫБРАННАЯ ТАБЛИЦА;
- Если установлен флаг "Выгружать по всем значениям", то выбранные метаданные будут выгружен по всем объектам в цикле;
- Если переключатель установлен в режим "Выгружать только выбранные объекты", то буду выгружены исключительно выбранные объекты (например: установка флага на метаданном без выбора объектов равносильна включенному флагу "Выгружать по всем значениям" и переключателю в позиции "Выгружать только выбранные объекты";
- Если переключатель установлен в режим "Выгружать выбранные и непосредственно связанные объекты" то буду выгружены выбранные объекты и те объекты, существование которых зависит от существования выбранного объекта(например: у справочников - подчиненные справочники);
- Если переключатель установлен в режим "Выгружать по всем ссылкам", то буду выгружены ВСЕ объекты в которых присутствует ссылка на выбранный объект.
Из дополнительного функционала доступно:
- Перерегистрация зарегистрированных объектов, часто требуется для отладки;
- Удаление зарегистрированных, часто требуется для отладки;
- Печать изменений - печать полного перечня объектов, которые помечены как измененные;
- Печать дерева конфигурации - только для удобства просмотра всей конфигурации.
Технология распределенных информационных баз (РИБ) позволяет создать территориально распределенную систему на базе конфигураций 1С Предприятие. Это позволяет иметь общее информационное пространство даже с теми подразделениями, которые не имеют надежного канала связи, сочетая высокую автономность узлов с возможностью оперативного обмена информацией. В наших статьях мы рассмотрим особенности и практическую реализацию этого механизма на платформе 8.2
Прежде всего зададимся вопросом: почему именно автообмен? Современные технологии, в сочетании с недорогим и быстрым интернетом, позволяют организовать удаленную работу без каких либо затруднений. Выбор способов как никогда широк: RDP, тонкий и веб-клиенты, объединение сетей при помощи VPN - есть над чем задуматься. Однако все эти способы имеют один существенный недостаток - сильная зависимость от качества канала связи.
Даже при идеальной работе местного провайдера гарантировать 100% доступность канала связи невозможно. Проблемы у магистрального провайдера, отсутствие электроснабжения, физическое повреждение линии связи и многие другие факторы делают эту задачу неразрешимой. В тоже время недоступность информационной базы на удаленном складе или в розничном магазине приводит к вполне ощутимым убыткам. Ну и наконец не будем забывать, что есть места (например промзоны на окраине городов) в которые подвести качественный канал связи дорого и/или проблематично.
Механизм РИБ позволяет избавиться от указанных недостатков, каждое подразделение имеет собственный экземпляр информационной базы с которой можно работать автономно даже при полном отсутствии связи с внешним миром. А небольшой объем передаваемой информации позволяет использовать для обмена любой канал связи, в том числе мобильный интернет.
РИБ на платформе 8.2 не является чем-то принципиально новым, представляя собой дальнейшее развитие УРИБ платформы 7.7, только теперь эта технология стала доступней и проще. В отличии от компоненты УРИБ, которую нужно было приобретать отдельно, РИБ является неотъемлемой частью многих типовых конфигураций и работает полностью в пользовательском режиме, позволяя обойтись без Конфигуратора даже на этапе настройки.
На этом месте пора бы было перейти к практической части, но придется сделать еще одно отступление. Дело в том, что переход на платформу 8.2, который вроде бы уже произошел, по факту привел к появлению двух типов конфигураций: на основе управляемого приложения, "родные" для платформы 8.2, и адаптированные с 8.1, продолжая использовать устаревшие технологии и механизмы. Так как существенная часть конфигураций (Бухгалтерия предприятия, Зарплата и управление персоналом) являются адаптированными или переходными, то сбрасывать их со счетов нельзя, поэтому первая часть нашей статьи будет посвящена этим конфигурациям (по сути платформе 8.1), в то время как во второй мы разберем настройку автообмена для конфигураций на основе управляемого приложения (платформе 8.2).
Рассмотрим практическую задачу: настроить автообмен через FTP для конфигурации Бухгалтерия предприятия 2.0. Несмотря на то, что РИБ позволяет производить обмен с использованием электронной почты или общих файловых ресурсов, мы рекомендуем использовать именно FTP, как наиболее простой и надежный способ связи. Как настроить собственный FTP-сервер вы можете прочитать в , либо можно использовать FTP сервис любого хостинг провайдера.
В первую очередь нам нужно настроить узлы обмена. Для этого запустим конфигурацию с правами администратора и выберем Операции - Планы обмена.
В появившемся списке выберем Полный план или По организации , если в одной базе ведется учет по нескольким фирмам и обмен нужно производить только для одной из них. В открывшемся окне уже существует один узел - центральный, нам нужно его отредактировать, указав код и название.
После чего создадим еще один узел для филиала, заполнив его аналогичным образом (для добавления нажмите зеленый кружок с плюсом). Следующим шагом будет создание начального образа для данного узла, который представляет собой готовую информационную базу в файловом режиме. Для этого кликните правой кнопкой мыши на нужном узле и в выпадающем списке выберите Создать начальный образ .
Теперь перейдем Сервис - Распределенная информационная база (РИБ) - Настроить узлы РИБ .
В открывшемся окне нажмите кнопку Добавить и настройте новый обмен, указав удаленный узел, тип обмена (через FTP) и параметры подключения к серверу.
Закладка Автоматический обмен позволяет настроить расписание обменов, обмен по событиям (начало и завершение работы и т.п.), данные настройки производятся для пользователя от чьего имени будет выполняться обмен, поэтому убедитесь в наличии у него прав для обмена данными.
Не забудьте указать префикс узла для нумерации документов (иначе вы получите разные документы с одинаковыми номерами) в Сервис - Настройки программы, здесь же можно настроить и некоторые другие параметры обмена. На этой же закладке следует выбрать пользователя для выполнения заданий обмена, если вы этого не сделаете расписание работать не будет. Помните, что обмен будет производиться только в том случае, если данный пользователь выполнил вход в программу.
На этом настройка центрального узла закончена, теперь нужно произвести аналогичные настройки для периферийного узла, подключив начальный образ как существующую ИБ. После чего можно приступать к обмену данными. Для контроля следует воспользоваться Монитором обмена данными , он позволяет не только контролировать успешность прохождения выгрузки/загрузки, но и показывает возникшие коллизии или отложенные движения (если пользователю производившему обмен не хватает прав для совершения каких либо действий в базе). Наличие данного инструмента позволяет быстро и эффективно решать различного рода проблемы, возникающие при автообмене.
На этом настройку обмена можно считать законченной и приступать к работе в распределенном режиме. Отдельно стоит остановиться на обновлении или внесении изменений в конфигурацию. Эти действия доступны только на центральном узле, все внесенные изменения будут автоматически распространены на периферийные узлы при следующем обмене. Для автоматического внесения изменений требуется чтобы периферийная база находилась в монопольном режиме, в противном случае нужно будет запустить Конфигуратор и выполнить Обновление конфигурации базы данных вручную.
РИБ - распределенная информационная база, представляющая из себя древовидную конструкцию, ветвями которой являются отдельные развернутые базы 1С Предприятия. Эти базы называют узлами распределенной информационной базы (далее просто узлы). Между этими узлами образован обмен информацией для синхронизации всех узлов (конфигураций и баз).
Основной механизма является механизм обменов с некоторыми отличительными и универсальными возможностями. Основным отличием можно выделить то, что механизм обмена РИБ является более специализированным и узким, тогда как универсальные обмены дают пользователю более обширный круг возможностей.
Базовые принципы работы РИБ
Изменять структуру конфигурации возможно только в главном корневом узле распределенной информационной базы. Далее эти изменение иерархически распространяются к подчиненным узлам. Таким образом это обеспечивает единое пространство структуры конфигурации во всех узлах РИБ.
Данные же могут быть изменены в любом из узлов, которые в свою очередь распространяются по всем остальным узлам. Причем эти данные не обязательно должны быть переданы остальным участникам системы и их полная идентичность может не поддерживаться. Состав данных, которые учавствуют в обмене с другими участниками РИБ, разработчик может настроить по своему желанию. Причем настройки могут производится не только на урочне метаданных конфигурации, но и на уровне отдельных элементов, на которые можно наложить специальные отборы.
Как уже было сказано выше, механизм РИБ достигается за счет использования планов обмена. но чтобы тот или иной план мог использоваться в этой иерархической структуре, у него должно быть активировано свойство "Распределенная информационная база".
Все данные в РИБ передаеются посредством сообщений. Содержимое этих сообщений четко регламентировано и не может быть произвольным, как в универсальном механизме обменов. Данные помещаются в сообщение используя принцип XML сериализации. Кроме этих изменений данных, в сообщение также помещается информация о изменении конфигурации, а также некоторое количество служебной информации. Изменения регистрируются от помещаются в сообщение обмена полностью автоматически. Ни пользователь, ни разработчик на это повлиять не могут.
Прием и формирование сообщений обмена в РИБ устанавливаются одной командой
Планыобмена. ЗаписатьИзменения(ЗаписьСообщения, 0 )
Содержимое читается посредством команды
Вывод
Можно смело говорить, что механизм РИБ в основном состоит из механизма универсального обмена с некоторыми отличительными особенностями, которые присутствуют только в структуре РИБ.
Ключевые слова: распределенная, УРБД, XML, регистрация, узел, узла, авторегистрация, начальный, образ, POP3, SMTP, ПочтовоеСообщение, периферийная, центральная, репликация, обмен
Дисклеймер и условия использования
Все случайно упомянутые в статье торговые марки принадлежат своим владельцам.Статья опубликована под лицензией Creative Commons Attribution-Share Alike 3.0 Unported License.
http://creativecommons.org/licenses/by-sa/3.0/
Сразу замечу, что все нижеследующее относится к релизу платформы 8.0.7.36 и выше.
Шаг 1. Создание плана обмена
Создаем в конфигурации план обмена. Называем его, например "РаспределеннаяБаза". Обязательно в
свойствах плана обмена ставим флажок "Распределенная информационная база".
На закладке "Прочее" по кнопке "Состав" определяем, какие объекты будут включаться в обмен. По
умолчанию можно включить все объекты ("Действия"-"Включить все"). Важным моментом является параметр
"Авторегистрация". В общем случае ее нужно разрешить для всех объектов.
Замечание: при добавлении новых объектов в конфигурацию, они не включаются в план обмена. Т.е. после
добавления объекта его необходимо добавить в состав плана обмена.
Если Вы хотите, чтобы некоторые объекты не участвовали в обмене, просто исключаете их из состава
плана обмена. Но тогда контроль ссылочной целостности остается целиком на вашей совести. Если, к
примеру, некий документ не включен в план обмена, а регистр, по которому он делает движения включен,
то в базе-приемнике вполне реально получить движения по регистру без документа-регистратора, что
согласитесь, не есть хорошо.
В принципе, этих действий достаточно, чтобы РБД заработала в "ручном" режиме. Для этого запускаем
Предприятие, открываем наш план обмена через меню "Операции". В плане обмена всегда присутствует
предопределенный узел "с точкой". Это описание текущего узла. Его нужно открыть и заполнить. В нашем
случае будут доступны поля "Код" и "Наименование". Присвоим нашему узлу код "AA" и назовем
"Центральная". Добавим в план обмена один узел. Присвоим ему код "ВВ" и назовем "Периферийная".
Теперь мы можем создать образ периферийной базы. Делается это нажатием кнопки "Создать начальный
образ". В списке узлов должна быть выбрана периферийная база. Образ базы создается в виде готовой ИБ
в каталоге или на сервере 1С:Предприятия. (в отличие от 7.7, где образ ИБ создавался как файл
выгрузки). Далее созданную базу можно перенести в нужное место, просто скопировав файлик 1CV8.1CD
(для файлового варианта), либо через Конфигуратор через выгрузку-загрузку данных.
Если Вы откроете план обмена в периферийной ИБ, то Вы увидите, что узлом "с точкой", т.е. текущим
узлом стал узел "Периферийная", а иконка у узла "Центральная" стала красного цвета, т.е. узел
"Центральная" является главным узлом по отношению к текущему.
Обмен в "ручном" режиме можно производить при помощи кнопок "Записать изменения" и "Прочитать
изменения". В первом случае будет предложено выбрать файл, куда изменения будут записаны, во втором
- файл, откуда изменения будут считаны. Обмен ведется в формате xml. Изменения записываются для
выбранного узла.
Шаг 2. Выгрузка изменений в XML-файл и отправка по электронной почте
Итак мы создали план обмена, создали периферийную ИБ и даже научились переносить данные между
базами. Теперь наша задача научить базы обмениваться по электронной почте.
Добавляем в план обмена два реквизита: ЭлектронныйАдрес типа "строка" и "ВыполнятьОбмен" типа
"булево". В реквизите ЭлектронныйАдрес будем хранить email узла, т.е. тот адрес, на который будем
посылать сообщения обмена. Реквизит ВыполнятьОбмен нужен, чтобы быстро отключить автоматическую
посылку-отправку сообщений.
Процедуру для работы с электронной почтой сделаем универсальной, т.е. сделаем возможным
использование как MAPI (отправка-получение через почтового клиента, например, MS Outlook), так и
прямое обращение к SMTP/POP3 серверам.
Добавим в конфигурацию несколько констант:
где-нибудь в общей форме обеспечиваем редактирование значений этих констант.
Добавим общий модуль, назовем его "рбРаспределеннаяБаза". В нем пишем:
Процедура рбОтправитьСообщенияОбмена() Экспорт ИспользоватьSMTP = Константы.ИспользоватьОбменПоSMTP.Получить(); //Сначала создаем объект Почта, который в зависимости от настроек будет типа ИнтернетПочта, //если используется прямое обращение к серверам, либо Почта если используется MAPI. Если ИспользоватьSMTP Тогда //Для объекта типа ИнтернетПочта создаем и заполняем почтовый профиль. ПочтовыйПрофиль = Новый ИнтернетПочтовыйПрофиль; ПочтовыйПрофиль.АдресСервераSMTP = Константы.АдресСервераSMTPОбмена.Получить(); ПочтовыйПрофиль.ПортSMTP = Константы.ПортСервераSMTPОбмена.Получить(); ПочтовыйПрофиль.ПользовательSMTP = Константы.ПользовательСервераSMTPОбмена.Получить(); ПочтовыйПрофиль.ПарольSMTP = Константы.ПарольПользователяSMTPОбмена.Получить(); ПочтовыйПрофиль.ВремяОжидания = Константы.ВремяОжиданияСервера.Получить(); Почта = Новый ИнтернетПочта(); Попытка Почта.Подключиться(ПочтовыйПрофиль); Исключение Сообщить("ОБМЕН: Ошибка при подключении к почтовому профилю! Обмен не выполнен! " + ОписаниеОшибки(), СтатусСообщения.ОченьВажное); Возврат; КонецПопытки; Иначе Почта = Новый Почта(); Попытка Почта.Подключиться(); Исключение Сообщить("" + ОписаниеОшибки(), СтатусСообщения.ОченьВажное); Возврат; КонецПопытки; КонецЕсли; //Далее выбираем все узлы из плана обмена, за исключением текущего, //у которых установлен реквизит ВыполнятьОбмен. ВыборкаУзлов = ПланыОбмена.РаспределеннаяБаза.Выбрать(); Пока ВыборкаУзлов.Следующий() Цикл Если Не ВыборкаУзлов.ВыполнятьОбмен Тогда Продолжить; КонецЕсли; Если ВыборкаУзлов.Ссылка = ПланыОбмена.РаспределеннаяБаза.ЭтотУзел() Тогда Продолжить; КонецЕсли; ЭлектронныйАдрес = СокрЛП(ВыборкаУзлов.ЭлектронныйАдрес); Если ЭлектронныйАдрес = "" Тогда Продолжить; КонецЕсли; //С помощью объектов ЗаписьXML и ЗаписьСообщения выполняем запись изменений //для выбранного узла в xml-файл. Узел = ВыборкаУзлов.Ссылка; ЗаписьXML = Новый ЗаписьXML(); ИмяФайлаСообщения = КаталогВременныхФайлов() + "Message_ " + СокрЛП(ПланыОбмена.РаспределеннаяБаза.ЭтотУзел().Код) + "_ " + СокрЛП(Узел.Код) + ".xml "; ЗаписьXML.ОткрытьФайл(ИмяФайлаСообщения); ЗаписьСообщения = ПланыОбмена.СоздатьЗаписьСообщения(); ЗаписьСообщения.НачатьЗапись(ЗаписьXML,Узел); ПланыОбмена.ЗаписатьИзменения(ЗаписьСообщения); ЗаписьСообщения.ЗакончитьЗапись(); ЗаписьXML.Закрыть(); //Затем создаем новое письмо, прикрепляем к нему полученный xml-файл и //отправляем по адресу, указанному в реквизите ЭлектронныйАдрес узла. Файл = Новый Файл(ИмяФайлаСообщения); ТемаСообщения = "1С:Обмен " + СокрЛП(ПланыОбмена.РаспределеннаяБаза.ЭтотУзел().Код) + "_ " + СокрЛП(Узел.Код); Если ИспользоватьSMTP Тогда ПочтовоеСообщение = Новый ИнтернетПочтовоеСообщение; ПочтовоеСообщение.Тема = ТемаСообщения; ПочтовоеСообщение.Вложения.Добавить(ИмяФайлаСообщения, Файл.Имя); ПочтовоеСообщение.Получатели.Добавить(ЭлектронныйАдрес); Почта.Послать(ПочтовоеСообщение); Иначе ПочтовоеСообщение = Новый ПочтовоеСообщение; ПочтовоеСообщение.Тема = ТемаСообщения; ПочтовоеСообщение.Вложения.Добавить(ИмяФайлаСообщения); ПочтовоеСообщение.Получатели.Добавить(ЭлектронныйАдрес); Почта.Послать(ПочтовоеСообщение, Ложь); КонецЕсли; Если Константы.ВыводитьСообщенияОбмена.Получить() Тогда Сообщить("ОБМЕН: Сообщение обмена для узла " + Узел.Наименование + " отправлено! ", СтатусСообщения.Информация); КонецЕсли; УдалитьФайлы(ИмяФайлаСообщения); КонецЦикла; Почта.Отключиться(); КонецПроцедуры
Рекомендую в интерфейс добавить дополнительную панель, на одну из кнопок которой повесить вызов этой
процедуры. Теперь осталось запустить Предприятие, настроить электронный адрес периферийной ИБ,
поставить галку "Выполнять обмен", нажать на кнопку процедуры на панели и бежать получать почту для
указанного эл. адреса. Должно придти письмо с темой "1С:Обмен AA_BB" и вложенным файлом
"Message_AA_BB.xml".
Итак, половина дела сделана: мы научили "восьмерку" отправлять сообщения обмена РБД по электронной
почте.
Шаг 3. Получение обновлений по электронной почте и запись их в ИБ
Теперь займемся обратной процедурой: получение обновлений по электронной почте и запись их в ИБ.
В параметры сеанса добавим параметр "ИдетОбменРаспределеннойБазы" типа Булево. Ниже я объясню его
назначение.
Добавим в общий модуль рбРаспределеннаяБаза такую процедуру:
Процедура рбПолучитьСообщенияОбмена() Экспорт ИспользоватьSMTP = Константы.ИспользоватьОбменПоSMTP.Получить(); //так же, как в процедуре рбОтправитьСообщенияОбмена(), сначала создаем объект Почта Если ИспользоватьSMTP Тогда ПочтовыйПрофиль = Новый ИнтернетПочтовыйПрофиль; ПочтовыйПрофиль.АдресСервераPOP3 = Константы.АдресСервераPOP3Обмена.Получить(); ПочтовыйПрофиль.ПортPOP3 = Константы.ПортСервераPOP3Обмена.Получить(); ПочтовыйПрофиль.Пользователь = Константы.ПользовательСервераPOP3Обмена.Получить(); ПочтовыйПрофиль.Пароль = Константы.ПарольПользователяPOP3Обмена.Получить(); ПочтовыйПрофиль.ВремяОжидания = Константы.ВремяОжиданияСервера.Получить(); Почта = Новый ИнтернетПочта(); Попытка Почта.Подключиться(ПочтовыйПрофиль); Исключение Сообщить("ОБМЕН: Ошибка при подключении к почтовому профилю! |Обмен не выполнен! ", СтатусСообщения.ОченьВажное); Возврат; КонецПопытки; Иначе Почта = Новый Почта(); Попытка Почта.Подключиться(); Исключение Сообщить("ОБМЕН: Ошибка при подключении к почтовому профилю пользователя! |Обмен не выполнен! ", СтатусСообщения.ОченьВажное); Возврат; КонецПопытки; КонецЕсли; МассивСообщений = Новый Массив; Если ИспользоватьSMTP Тогда ВсеСообщения = Почта.Выбрать(Ложь); Иначе ВсеСообщения = Почта.Выбрать(Ложь, Ложь); КонецЕсли; //Отбираем среди всех писем те, которые имеют тему "1С:Обмен". //Маленькое, но важное замечание: //считаем, что все полученные письма с темой "1С:Обмен" предназначены //именно для текущего узла, //т.е. что у разных узлов в плане обмена РАЗНЫЕ электронные адреса. Для Каждого Сообщение Из ВсеСообщения Цикл Если Лев(Сообщение.Тема, 8 ) <> "1С:Обмен " Тогда Продолжить; КонецЕсли; Попытка МассивСообщений.Добавить(Сообщение); //Вложение письма сохраняем на диске. //Аккуратную проверку вложения оставим пока "за кадром." Вложение = Сообщение.Вложения; ИмяФайлаСообщения = КаталогВременныхФайлов() + Вложение.Name; ДанныеОбмена = Вложение.Данные; ДанныеОбмена.Записать(ИмяФайлаСообщения); //С помощью объектов ЧтениеXML и ЧтениеСообщения читаем данные //обновления из сохраненного файла. Перед записью обновлений в ИБ //устанавливаем параметр сеанса ИдетОбменРаспределеннойБазы в Истина. //Затем читаем изменения в ИБ: ПланыОбмена.ПрочитатьИзменения(ЧтениеСообщения). //Попутно сохраняем сообщения в массиве, чтобы потом их все сразу удалить. ЧтениеXML = Новый ЧтениеXML(); ЧтениеXML.ОткрытьФайл(ИмяФайлаСообщения); ЧтениеСообщения = ПланыОбмена.СоздатьЧтениеСообщения(); ЧтениеСообщения.НачатьЧтение(ЧтениеXML); ПараметрыСеанса.ИдетОбменРаспределеннойБазы = Истина; ПланыОбмена.ПрочитатьИзменения(ЧтениеСообщения); ЧтениеСообщения.ЗакончитьЧтение(); ЧтениеXML.Закрыть(); Если Константы.ВыводитьСообщенияОбмена.Получить() Тогда Сообщить("ОБМЕН: Данные обмена приняты ",СтатусСообщения.Информация); КонецЕсли; Исключение Сообщить("ОБМЕН: Ошибка при получении данных обмена: " + ОписаниеОшибки(), СтатусСообщения.ОченьВажное); КонецПопытки; //После того, как чтение данных обмена закончено, возвращаем //параметру сеанса ИдетОбменРаспределеннойБазы значение Ложь. ПараметрыСеанса.ИдетОбменРаспределеннойБазы = Ложь; Попытка УдалитьФайлы(ИмяФайлаСообщения); Исключение //если не получилось, ну и ладно КонецПопытки; КонецЦикла; Если ИспользоватьSMTP Тогда Почта.УдалитьСообщения(МассивСообщений); КонецЕсли; Почта.Отключиться(); КонецПроцедуры
Теперь про то, для чего нужен параметр сеанса ИдетОбменРаспределеннойБазы.
Дело в том, что при чтении данных методом ПланыОбмена.ПрочитатьИзменения() происходит вызов
процедур-обработчиков события ПередЗаписью() изменяемых/добавляемых объектов. И если при записи
какого-либо объекта в процедуре обработчике параметр Отказ будет установлен в значение Истина, то
при выполнении ПланыОбмена.ПрочитатьИзменения() возникнет исключение, и, соответственно, обмен
выполнен не будет. Значение параметра сеанса ИдетОбменРаспределеннойБазы может быть
проанализированно в процедурах-обработчиках, дабы избежать подобной ситуации.
С выходом редакции 12 (хотя я могу ошибаться в версиях), актуальность этого метода несколько
устарелаА, поскольку у объектов появилось свойство ПараметрыОбмена
, у которого, в свою
. Это свойство принимает значение Истина, когда идет
сохранение данных через план обмена.
Теперь в интерфейсе на нашей панели добавляем еще одну кнопку, на которую вешаем вызов этой
процедуры. Запускаем Предприятие и наслаждаемся.
Почти все сделано, осталась малость: заставить наши процедуры выполняться в автоматическом режиме.
Шаг 4. Настройка автоматического обмена
Итак, мы почти вплотную приблизились к цели нашего повествования. Остался всего один шаг: запустить
выполнение процедур обмена в автоматическом режиме. Приступим.
Добавим константу ИнтервалАвтообменаРаспределеннойБазы типа Число(5,0).
В настройки пользователя добавим параметр ВыполнятьОбменРаспределенныхБаз. Для конфигурации
"Управление торговлей" это делается так:
* В план видов характеристик "НастройкиПользователей" добавим предопределенную
характеристику ВыполнятьОбменРаспределенныхБаз типа Булево.
* В форме элемента справочника "Пользователи" настраиваем изменение этого параметра (как это
сделать можно посмотреть в модуле формы, по аналогии с остальными параметрами).
В модуль рбРаспределеннаяБаза добавляем процедуру:
Процедура рбВыполнитьОбмен(прПользователь) Экспорт Если нпПолучитьЗначениеПоУмолчанию(прПользователь, "") Тогда рбПолучитьСообщенияОбмена(); рбОтправитьСообщенияОбмена(); КонецЕсли; КонецПроцедуры
в модуль приложения:
Процедура ПроверитьПодключениеАвтообмена() Экспорт Если нпПолучитьЗначениеПоУмолчанию(глТекущийПользователь, "ВыполнятьОбменРаспределенныхБаз ") И Константы.ИнтервалАвтообменаРаспределеннойБазы.Получить() > 0 Тогда ПодключитьОбработчикОжидания("ВыполнитьАвтообмен ", Константы.ИнтервалАвтообменаРаспределеннойБазы.Получить()); Иначе ОтключитьОбработчикОжидания("ВыполнитьАвтообмен "); КонецЕсли; КонецПроцедуры Процедура ВыполнитьАвтообмен() Экспорт рбВыполнитьОбмен(глТекущийПользователь); ОтключитьОбработчикОжидания("ВыполнитьАвтообмен "); Если нпПолучитьЗначениеПоУмолчанию(глТекущийПользователь, "ВыполнятьОбменРаспределенныхБаз ") И Константы.ИнтервалАвтообменаРаспределеннойБазы.Получить() > 0 Тогда ПодключитьОбработчикОжидания("ВыполнитьАвтообмен ", Константы.ИнтервалАвтообменаРаспределеннойБазы.Получить()); КонецЕсли; КонецПроцедуры Процедура ОтключитьАвтообмен() Экспорт ОтключитьОбработчикОжидания("ВыполнитьАвтообмен "); КонецПроцедуры
в процедуру ПриНачалеРаботыСистемы() модуля приложения добавим такие строки:
(после подключения торгового оборудования)
...
ПараметрыСеанса.ИдетОбменРаспределеннойБазы = Ложь;
ПроверитьПодключениеАвтообмена();
Добавим на нашу панель еще пару кнопок для управления процессом: на одну вешаем процедуру
ПроверитьПодключениеАвтообмена(), на другую - ОтключитьАвтообмен()
Запускаем предприятие, настраиваем свойства пользователя и интервал автообмена и все!
Теперь при заходе в базу под этим-самым-настроенным пользователем будет запускаться обработчик
ожидания ВыполнитьАвтообмен(). Естественно, в периферийной базе тоже нужно настроить пользователя
для обмена.
Еще одно маленькое, но важное замечание:
Во всей, созданной нами прелести, присутствует одна неприятность: изменение конфигурации. При
получении периферийной базой сообщения, в котором будут содержаться изменения конфигурации, оно
будет принято, но возникнет исключительная ситуация. При этом измененная конфигурация будет
загружена. Для обновления конфигурации БД необходимо выгнать всех пользователей, зайти в
конфигуратор и выполнить обновление конфигурации БД (перед этим неплохо сделать выгрузку данных). К
сожалению, это неизбежное зло. Можно немного облегчить себе жизнь, написав коротенький bat-файл
примерно такого содержания:
1cv8.exe CONFIG /F<путь к ИБ> /N<Пользователь> /P<Пароль> /UpdateIBCfg
И еще одно замечание:
К сожалению, xml-файлы не отличаются компактностью, но, к счастью, прекрасно сжимаются. Можно в
процедуры отправки и получения сообщений добавить упаковку-распаковку файлов. COLOR="#666666">Делать это можно либо внешним архиватором, либо используя ВК, например Wheel.AddIn
(http://1c.proclub.ru/modules/mydownloads/personal.php?cid=81&lid=2714) .
С выходом 10 (кажется) редакции, предыдущее предложение несколько устарело, поскольку в платформу
были встроенны средства сжатия файлов по алгоритму ZIP. Т.е. теперь есть возможность сжимать файлы
без использования ВК.
