Узел плана обмена 1С: что это и как работает

Узел плана обмена — это сущность в 1С, которая представляет конкретную информационную базу, участвующую в обмене данными. Каждая база, которая отправляет или получает данные через план обмена, описывается отдельным узлом: у него есть код, наименование и настройки регистрации изменений. Благодаря узлам система понимает, какие данные уже переданы конкретной базе, а какие ещё нужно отправить.

План обмена описывает состав обмена: какие справочники, документы и регистры будут синхронизироваться. Узлы же отвечают за адресацию — кому именно эти данные отправляются. Один план обмена может включать несколько узлов: например, центральная база управления и три базы торговых точек. Каждая пара «узел — узел» ведёт собственную историю обмена через номера сообщений.

Механизм узлов лежит в основе распределённых информационных баз (РИБ), типовых синхронизаций между конфигурациями и обменов с периферийными системами. Понимание того, как устроен узел, необходимо при настройке обмена, устранении коллизий и восстановлении синхронизации после сбоев.

Как устроен узел плана обмена

Технически узел хранится как объект метаданных «План обмена», а конкретные узлы — это его элементы, похожие на элементы справочника. У каждого узла есть уникальный код и наименование. Именно код используется при идентификации баз при обмене: если коды не совпадают с ожидаемыми, база откажется принимать сообщение.

Особое место занимает предопределённый узел «Этот узел» — он описывает текущую информационную базу. В распределённой базе центральный узел помечается как главный, а остальные — как подчинённые. У подчинённого узла главный узел указывает на центральную базу, и такая связь определяет направление репликации: изменения конфигурации идут только от главного узла к подчинённым.

Дополнительно узел хранит два важных счётчика: номер отправленного сообщения и номер принятого сообщения. Эти номера — основа квитирования: система отслеживает, какие пакеты доставлены и подтверждены, и не пересылает уже принятые данные. Если счётчики сбились, обмен останавливается или начинает передавать лишние данные.

Главный и подчинённый узлы: в чём разница

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

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

Вне РИБ, при обмене между разными конфигурациями (например, «Управление торговлей» и «Бухгалтерия»), понятие «главный/подчинённый» обычно не используется — узлы равноправны, а правила переноса данных задаются внешними правилами конвертации. Однако механизм регистрации изменений по узлам работает одинаково.

Регистрация изменений: как узел узнаёт, что отправлять

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

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

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

Как создать и настроить узел на практике

Типовой сценарий — создание подчинённого узла РИБ. В главной базе открывают список узлов плана обмена, создают новый элемент, задают ему код (например, «МСК» для московского филиала) и наименование. Затем выполняют команду создания начального образа подчинённой базы: система формирует файл развёртывания, из которого на удалённой площадке создаётся подчинённая база.

После развёртывания начального образа подчинённая база уже «знает» свой узел и главный узел. Дальше настраивается транспорт сообщений: обмен через каталог, FTP, электронную почту или прямое подключение. В типовых конфигурациях для этого используется помощник настройки синхронизации данных.

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

1. 1
   Откройте план обмена в главной базе и создайте новый узел с уникальным кодом
2. 2
   Задайте настройки состава выгружаемых данных для узла, если план обмена это поддерживает
3. 3
   Выполните команду создания начального образа подчинённой базы
4. 4
   Разверните образ на удалённой площадке и проверьте, что узел корректно определён как подчинённый
5. 5
   Настройте транспорт обмена и выполните первый сеанс отправки и получения сообщений
6. 6
   Проверьте, что номера отправленных и принятых сообщений увеличились в обеих базах

Типичные проблемы с узлами и их диагностика

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

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

Третья проблема — «зависший» обмен из-за того, что подчинённая база не применила обновление конфигурации. Пока обновление не принято, обмен данными блокируется. Диагностируется по сообщению в журнале регистрации и решается запуском конфигуратора в подчинённой базе для завершения обновления.

Границы безопасной работы и когда нужен специалист

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

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

Частые вопросы об узлах планов обмена

Чем узел плана обмена отличается от самого плана обмена?

План обмена — это описание состава и правил обмена: какие объекты участвуют и как строится топология. Узел — конкретный участник, отдельная база. Один план обмена содержит множество узлов, по одному на каждую базу-участницу.

Можно ли удалить узел, если база больше не используется?

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

Почему обмен остановился с ошибкой о неверном номере сообщения?

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

Сколько узлов может быть в одном плане обмена?

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

Что такое начальный образ подчинённого узла?

Это файл развёртывания, созданный главным узлом, из которого создаётся подчинённая база. Он содержит конфигурацию, данные в составе плана обмена и корректную привязку к главному узлу. Создавать подчинённую базу простым копированием файла нельзя — связь узлов не установится.

Нужны ли узлы при обмене через универсальный формат (EnterpriseData)?

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