Быстрое создание узла риб 1с. Распределенная информационная база: Основы. Настройки обменов распределенной информационной базы

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

Осуществим эту задачу через настройку Распределенной информационной базы. Конфигурация информационной базы – “Бухгалтерия предприятия 2.0”.

Настройка FTP ресурса.

Настроим FTP на примере HCube: Заходим на сайт hcube.ru. Вкладка Хостинг, FTP Хостинг (http://www.hcube.ru/hosting/ftp/). Выбираем минимальный тарифный план FTP -10, этого будет достаточно для обмена между узлами распределенной информационной базы. Можно заказать пробный период 15 дней, нажимаем “Пробуем”. Далее нам необходимо зарегистрироваться:

Указываем имя пользователя и пароль для доступа в личный кабинет. После того как заявка принята, ждем письмо на указанную электронную почту с реквизитами доступа к FTP . Информация о конфигурации Вашей услуги хостинга: ****************************************************************
Логин хостинга: user725
Пароль хостинга: ffUXP3CDU
IP-адрес хостинга: 85.10.207.234

****************************************************************
Панель управления для ФТП хостинга https://cp.hcube.ru/manager/ispmgr

Ждем, когда состояние станет “Активен”.

Настройка плана обмена.

Необходимо определить центральный узел базы данных. Центральным узлом выберем рабочее место, находящееся в офисе. С центральным узлом будут обмениваться два других. Настроим центральный узел. Для этого в ИБ необходимо зайти под пользователем с полными правами. В основном меню программы выбрать пункт «Операции / Планы обмена…» . В планах обмена стандартной конфигурации “Бухгалтерия предприятия 8” уже созданы 7 стандартных планов обмена: Открываем план «Полный» . В нем находится одна предопределенная пустая запись. Эта запись описывает текущий узел. Предопределенную, т.е. добавленную на уровне конфигурации запись удалить нельзя, но ее можно исправить. Нажимаем изменить: поле «Наименование» может быть произвольным, например «Центральный узел» . «Код» тоже может быть произвольным, например «01» , жмем «ОК» . Текущий узел описан, теперь необходимо описать подчиненные узлы. Добавляем новые элементы с именем «Узел 1» и кодом «02» и «Узел 2» с кодом «03» . Получаем три узла:
В РИБ может быть много подчиненных узлов и обмен будет производиться между одним центральным узлом и каждым из подчиненных узлов. Теперь физически создадим подчиненный узел (новую базу данных). Для этого необходимо встать на строчку узла «Узел 1» и нажать на значок «Создать начальный образ…» или выбрать это действие из меню:
Система предложит выбрать тип информационной базы (ИБ). Необходимо выбрать «На данном компьютере…» . Затем указать каталог, в котором будет создана новая ИБ. После этого в указанном каталоге будет создана новая база и в эту базу будут перенесены все данные из главной базы. Сразу стоит отметить, что новая ИБ не является точной копией исходной. В ней свои настройки (свой список пользователей и т.д.), переносятся только данные и модифицированные планы обмена, т.е. в новой ИБ останутся только два узла «Центральный узел» и «Узел 1» . Если исходная база данных большая и в ней работают пользователи, при создании начального образа возможны коллизии, поэтому операцию создания нового образа рекомендуется проводить в монопольном режиме. Если в центральном узле было описано несколько подчиненных узлов, операцию по созданию начального образа ИБ необходимо провести для каждого узла, т.е. будет создано столько новых ИБ, сколько было описано узлов в исходной базе. Тоже сделаем для «Узел 2» . В момент создания начального образа, в главной базе будет создана таблица синхронизации объектов главной базы с этим узлом. В общем случае таких таблиц создается по количеству подчиненных узлов. При создании начального образа узла устанавливается признак синхронизации с узлом. Теперь базы данных подчиненных узлов необходимо скопировать на рабочие места «Узел 1» и «Узел 2» . После этого на трех компьютерах будут одинаковые (в смысле данных) информационные базы.

Настройки обменов распределенной информационной базы.

В данной задаче у нас общий случай, когда все три базы данных являются рабочими, т.е. документы вводятся и изменяются в трех базах. Перейдем в меню «Сервис / Распределенная информационная база (РИБ) / Настроить узлы РИБ» . Настроим обмен между Центральным узлом и Узлом 1 . На Вкладке «Распределенные информационные базы» добавляем новый элемент, назовем его «Офис – Узел 1» (где «Офис» это наш Центральный узел). Выбираем в реквизите «Узел» – «Узел 1» . В поле «Тип обмена» выбираем «Обмен через FTP ресурс» . Заполняем реквизиты, которые пришли нам в письме на почту: «Адрес» , «Пользователь» , «Пароль» . Вкладки «Интерактивный обмен» и «Автоматический обмен» пока не заполняем, сделаем это после основных настроек обмена во всех узлах. Далее по аналогии создадим новый элемент по настройке обмена между Центральным узлом и Узлом 2.
Зайдем в ранее созданный начальный образ (информационная база) Узла 1 и создадим настройки «Узел 1 – Офис» . Сделаем тоже в Узле 2. На вкладке «Интерактивный обмен» мы можем определить: необходимо ли нам и выгружать и загружать данные, либо что-то одно. На вкладке«Автоматический обмен» можно добавить новый элемент для настройки автоматического обмена. Здесь мы можем задать расписание для конкретного обмена, например для «Офис – Узел 1» , и/или обмен по событиям.

При выборе пользователя в настройках обмена по событиям необходимо также указать данного пользователя в «Настройках программы» на вкладке «Обмен данными» .
Обмен в нашем примере будет выполняться только в том случае, если в базу зашли под указанным в настройках «Обмена по событиям» пользователем. Также нужно указать «Префикс узла для распределенной информационной базы» для корректной нумерации документов. С помощью префикса мы сможем видеть: каким узлом создавался документ, а также избежать дублирования номеров документов. Для удобной работы в Распределенной информационной базе необходимо тщательно продумать цикл обмена узлов друг с другом, расписание обмена и/или обмен по событиям под конкретную задачу.

October 25th, 2016

Между настройкой и поддержкой РИБ на 2 узла и на 10 большой разницы нет, а вот когда число удаленных точек переваливает за сотню, приходится решать уже совсем другие вопросы

Исходные данные:

Конфигурация: Розница 2.2
Платформа 1С: 8.3.7.1970



Срок проекта: год.



Архитектура:

Сперва определились со схемой РИБ. Было принято решение ориентироваться на схему "звезда", пока это будет возможно; при достижении технологических ограничений - снежинка.





Ограничния:
- 2 ГБ ОЗУ
- 1 физический процессор


Из всего вышеперечисленного напрягает в осном ограничение на максимальный объём БД.

Но это всего лишь означает что нужно гработно организовать процедуру её очистки от устаревших данных на местах.

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


Основные настройки

Со времен УТ 10.3, на которой у меня состоялся первый проект внедрения РИБ на 60 узлов, конечно "утекло много воды".

1С не стояли на месте. Розница 2.2 теперь учитывает необходимость выборочной выгрузки данных.
В базу магазина будет выгружаться только та информация которая имеет к нему отношение:
- Все справочники (кроме специализированных)
- Документы по данному магазину

Другой вопрос что так или иначе добавление узла в базу означает добавление ещё одной записи в таблицу регистрации на каждый общий элемент при его записи.





1) Нужно разделить на отдельные сценарии синхронизации на выгрузку и загрузку
Смысл в том, что выгрузка проходит долго и с блокировками, а загрузка достаточно беспроблемно. При этом часто бывает что данные нам нужно оперативно получать из розничных точек, отдавая при этом только несколько раз в день.

2) Выделить проблемные магазины и убрать их из общего сценария синхронизации. На них могут быть большие выгрузки - тормозиться при этом будет весь обмен, включая другие узлы. После решения проблем они доабвляются обратно

3) Создать несколько сценариев отправки и получения данных. Но тут главное поймать правильный баланс их количества.
(ещё с версии 8.1).
Следовательно параллельность в выгрузке РИБ ограничена. На практике получается запускать параллельно 2-3 сценария.


Что пришлось доработать

Самый главный косяк в штатной логике 1С РИБ - это обновления

Ещё одной проблемой обмена становятся регистры сведений. Выгрузка в XML каждой записи регистра сведений создаёт отдельный узел XML со служебными элементами и т.п.. Кроме того, функция "ВыбратьИзменений()" для регистра сведений в котором 100 записей получит результирующую таблицу в 100 строк, в то же время, есдли это справочник у которого 100 строк в табличной части выберется только одна запись. А это время монопольной блокировки. Так что если в РС много записей, которые регулярно регистрируются к обмену в другие магазины то это конечно правильне представить в виде справочника с табличной частью, который в крайнем случае при записи может формировать строки этого же регистра. В любом случае, .

Ещё одна важная деталь - Зачем? Дисконтных карт скопилось уже близко к 3 млн. Для работы с ними используется внешняя online система. Если продолжать передавать дисконтные карты на все магазины - это в разы увеличит обмены, кроме того может привести к превышению базой объёма в 10 ГБ.

Часть механизмов реализована online обращением в центральную базу: остатки в других магазинах, возврат по чеку из другого магазина, проверка валидности подарочного сертификата.


Тиражирование


Создание начального узла РИБ штатным образом сделало бы невозможным тиражирование в принципе.
Поэтому новый узел создаётся следующим образом :


2) Эта база обменивается в РИБ всеми общими данными но не получает специализированных (документов)


5) База для магазина готова.

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


Преимущества тонкого клиента

Два существенных преимущества Розницы 2.2 (Тонкого клиента) которые "согрели душу":








Поддержка и обновления




1) Обновлять руками магазинов (не очень правильно, могут не получить изменения, будут звонки и проблемы) -так было ранее

3) Написать *.cmd или 1С скрипт для обновления или взять готовый. Как показывает практика такое решение всегда половинчатое (нестабильное), а функциональности в нём получится заложить немного.

Какие у нас были задачи:


2) При обновлении возможно интерактивное взаимодействие с пользователем (сообщения, подтверждение, прогресс бар).








Основные функции:




4) Проверка состояния агентов
5) Отчеты об обновлениях
6) резервное копирование

















Вот так, к примеру, выглядит сообщение об ошибке после обновления:

Таким образом у проекта появились неплохие шансы быть завершенным успешно. По крайней мере на середине пути "полёт нормальный".

Если придём ещё к каким-либо решениям которые могут показаться интересными напишу отдельно

P.S. и самое главное: Правльное планирование дальнейшей поддержки - один из ключевых факторов дальнейшего успеха подобных проектов. :)

October 25th, 2016

Между настройкой и поддержкой РИБ на 2 узла и на 10 большой разницы нет, а вот когда число удаленных точек переваливает за сотню приходится решать уже совсем другие вопросы.

Итак, исходные данные:

Конфигурация: Розница 2.2
Платформа 1С: 8.3.7.1970
Ориентировочное число узлов в конце проекта: 200
Ресурсы оборудования в центре: без существенных ограничений
Оборудование на точке: обсуждаемый вопрос.
Срок проекта: год.

Архитектура:

Сперва определились со схемой РИБ. Было принято решение ориентироваться на схему "звезда", до той
В торговых точках используется клиент-серверный вариант работы, с выделенным сервером, под управлением ОС Windows.
Сервер 1С будет использован в варианте "Сервер 1С МИНИ" https://1c.ru/news/info.jsp?id=17577
Сервер СУБД - MS SQL Express 2008 R2.

SQL Express 2008 R2 - последняя на текущий момент времени версия данной линейки SQL Server.
Ограничния:

2 ГБ ОЗУ
- 1 физический процессор
- 10 ГБ максимальный объём базы

Из всего вышеперечисленного напрягает конечно в осном ограничение на максимальный объём БД. Но собственно это всего лишь означает что нужно будет гработно организовать процедуру её очистки от устаревших данных на местах.

Под сервер 1С и MS SQL выделяется отдельный сервер. На него будет ложиться основная нагрузка по обменам и проведению операций.
Конечные клиентские компьютеры не заменяются, потому как будут работать с тонким клиентом и нагрузка на низ будет минимальной.
Сервер в магазине - просто мощьный ПК. Но обязательным условием является наличие диска SSD - на котором расположены базы MS SQL .
Также сервер будет обсепечивать возможность проведения регламентных операций в ночное время и доступ к базе магазина без отрыва от работы.

Основные настройки

Со времен УТ 10.3 на которой у меня состоялся первый проект внедрения РИБ на 60 узлов конечно "утекло много воды". 1С не стояли на месте. Розница 2.2 теперь учитывает необходимость выборочной выгрузки данных.
В базу магазина будет выгружаться только та информация которая к немиу имеет отношение:
- Все справочники (кроме отдельных)
- Документы по данному магназину
Регистрация данных происходит по правилам регистрации, всё что можно кэшируется. Существенных замедлений именно на регистрации не наблюдается.
Другой вопрос что так или иначе добавление узла в базу означает добавление ещё одной записи на каждый общий элемент для всех баз.

В настройке самой выгрузки ничего специфичного нет. Есть некоторые нюансы принастройке сценариев синхронизации:

1) Нужно разделить на отдельные сценарии синхронизации выгрузку и загрузку
Смысл в том, что выгрузка проходит долго и с блокировками, а загрузка достаточно безпроблемно. При этом часто бывает что данные нам нужно оперативно получать из розничных точек, отдавая при этом только несколько раз в день.

2) Выделить проблемные магазины и убрать их из общего сценария синхронизации. На них могут быть большие выгрузки - тормозиться при этом будет весь обмен, включая другие узлы

3) Создать несколько сценариев отправки и получения для отправки и получения данных. Но тут главное баланс.
Некоторые вещи в 1С не меняются. Тот самый метод "ВыбратьИзменения" может выполняться только последовательно (ещё с версии 8.1).
Следовательно параллельность в выгрузке РИБ ограничена. На практике получаетсы выгружать единовременно 2-3 сценария.
Что касается сценариве получения - тут возможна куда большая параллельность, если нужна конечно.

Что пришлось доработать

Конечно грустно и печально, но пришлось основательно влазить в БСП. Самый главный косяк в штатной логике 1С - это обновления . После обновления появляется примерно такое окошко:

Это всё происходит в монопольном режиме. Кроме всего прочего, система ещё будет пытаться сделать обмен после обновления в монопольном режиме. К чему это все приводит - не трудно догадаться.
Весь этот период времени магазин не может работать, на кассе стоят покупатели, компания теряет деньги.

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

Ещё одна важная деталь - из обмена польностью исключены дисконтные карты, а физлица - только сотрудники конкретного магазина. Зачем? Дисконтных карт скопилось уже близко к 3 млн. Для работы с ними используется внешняя online система. Если продолжать передавать дисконтные карты на все магазины - это в разы увеличит обмены, кроме того может привести к превышению базой объёма в 3ГБ.

Часть механизмов реализована online обращением в центральную базу: остатки в других магазинах, возврат по чеку из другого магазина, проверка валидности подарочного сертификата.

Тиражирование

Конечно тиражирование ведётся ускоренными темпами.
Создание начального узла РИБ штатным образом конечно сделало бы невозможным тиражирование.
Поэтому новый узел создаётся следующим образом:

1) Существует отдельная база с фейковым магазином
2) Эта база обменивается в РИБ всеми общими данными но не получает специализированных
3) Когда хотим создать новую базу - просто копируем эту
4) Потом устанавливаем настройки - магазин, префикс и т.п.
5) База для магазина готова.

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

Преимущества тонкого клиента

два существенных преимущества которые "согрели душу".

1) Нет необходимости менять весь компьютерный парк в торговых точках. 90% операций выполяется на сервере, а сервер туда привозится "относительно мощный компьютер"

2) Техника имеет свойства отказываться работать, особенно часто это происходит с вновь установленным или уже изношенным оборудованием.
В этом случае действия теперь предельно просты - магазин переключается на работу в центральной базе.
Этот процесс занимает не более 5-10 минут, таким образом торговля не прерывается даже при существенных проблемах с оборудованием.

Поддержка и обновления

Наконец дошли до самого интересного пункта - как же всё это поддерживать и обновлять?
Для нас обновления тоже долгое время были делеммой:

1) Обновлять руками магазинов (не очень правильно, могут не получить изменения, будут звонки и проблемы)
2) Обновлять силами технической поддержки (нет столько ресурсов)
3) Написать *.cmd для обновления или взять готовый. Как показывает практика такое решение всегда половинчатое (нестабильное), а функциональности в нём немного.

Какие у нас были задачи:

1) Обновление должно проходить в нескольких режимах и урпавляться централизованно
2) При обновлении возможно интерактивное взаимодействие с пользователем.
3) Обязательно должны приходить отчеты о состоянии и ошибках обновления
4) Должно быть резервное копирование
5) Система обновления должна уметь без проблем обновлять саму себя.
6) Система должна быть расширяема без особых проблем.

Конечно задачи вышли далеко за перечень решаемых простыми методами. Поскольку без автоматизации с таким количеством конечных точек не обойтись, а ничего более-менее готового со схожим функционалом мы не нашли
пришлось заняться разработкой ПО, которое со временем приобрело название MU (MagicUpdater).

Основные функции:

1) Динамическое обновление базы (команда или по расписанию)
2) Статическое обнволение базы (команда или по расписанию)
3) автоматическое агентов на конечных компьютерах при их модификации
4) Проверка состояния агентов
5) Отчеты об обновлениях
6) резервное копирование
7) Административные действия с сервером 1C и MS SQL
8) Закрытие всех клиентских приложений 1С на компьютерах сети
9) Статическое обновление с акцептом на главной кассе
10) Отображение описания модификаций после обновления
11) Настройка порядка действий
12) Выполнение всех этих действий по расписанию

Примерная схем взаимодейтсвия:

Где MU Агент - это служба, устанавливается и настраивается в магазине. Собственно она с центра получает команда на выполнение определенных дланных.
MU Сервер - Сервер, который принимает все запросы к системе.
MU монитор - то что видят рядовые сотрудники технической поддержки - используется для просмотра логов и постановки заданий на обновление, либо прочих.

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

А вот таким образом мы осуществляем отправку команд на клиенсткие компьютеры

Приложения конечно не 1С-ные, но с достаточно приличным набором интерфейсных возможностей. Вот так, к примеру, выглядит отбор по дате:

Теперь к дальнейшему тиражированию готовы. Правльное планирование дальнейшей поддержки - один из ключевых факторов дальнейшего успеха подобных проектов.

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

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

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

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

В данной статье мы рассмотрим настройку распределенной базы данных для 1С:Бухгалтерия 3.0. Несмотря на это, инструкция подойдет и для большинства других конфигураций 1С 8.3.

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

Главная информационная база

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

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

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

В открывшемся окне из меню выберем пункт «Полный…». Он позволит нам указать любую информационную базу 1С для произведения синхронизации.

В первом окне подключения подчиненной базы, которая расположена в территориально удаленном офисе, отметим флагом, что подключение будет производиться через локальный или сетевой каталог. В нашем случае это «D:\DB\InfoBase». Так же заранее проверим возможность записи в него.

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

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

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

Подчиненный узел РИБ

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

В рамках нашего примера в главную базу были добавлены две номенклатурные позиции: «Брус» и «Доска». После синхронизации они попали в подчиненную базу. Как вы можете увидеть на рисунке ниже, им присвоился префикс «БГ». Остальным двум позициям («Токарный станок» и «Поддон») присвоен префикс «БП», так как они были заведены непосредственно в подчиненной базе.

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

РИБ - распределенная информационная база, представляющая из себя древовидную конструкцию, ветвями которой являются отдельные развернутые базы 1С Предприятия. Эти базы называют узлами распределенной информационной базы (далее просто узлы). Между этими узлами образован обмен информацией для синхронизации всех узлов (конфигураций и баз).

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

Базовые принципы работы РИБ

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

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

Как уже было сказано выше, механизм РИБ достигается за счет использования планов обмена. но чтобы тот или иной план мог использоваться в этой иерархической структуре, у него должно быть активировано свойство "Распределенная информационная база".

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

Прием и формирование сообщений обмена в РИБ устанавливаются одной командой

Планыобмена. ЗаписатьИзменения(ЗаписьСообщения, 0 )

Содержимое читается посредством команды

Вывод

Можно смело говорить, что механизм РИБ в основном состоит из механизма универсального обмена с некоторыми отличительными особенностями, которые присутствуют только в структуре РИБ.