Администрирование · 10 мин
Как работают планы обмена в 1С
Как устроены планы обмена в 1С: состав узлов, регистрация изменений, сообщения обмена, настройка распределённой базы и решение типичных проблем.
План обмена — это объект конфигурации 1С, который описывает, какие данные и между какими базами должны синхронизироваться. Без него невозможно организовать ни распределённую информационную базу (РИБ), ни обмен между «Управлением торговлей» и «Бухгалтерией», ни выгрузку в мобильное приложение. План обмена отвечает на три вопроса: какие объекты участвуют в обмене, куда они отправляются и как система отслеживает, что именно изменилось.
Механизм построен на трёх китах: состав плана обмена (перечень типов объектов), узлы (участники обмена) и регистрация изменений. Когда пользователь записывает документ или элемент справочника, входящий в состав плана, платформа автоматически помечает этот объект как изменённый для конкретных узлов. При следующем сеансе обмена выгружаются только накопленные изменения, а не вся база целиком — это ключевая идея, обеспечивающая приемлемую скорость синхронизации.
Данные передаются в виде сообщений обмена — XML-файлов с номерами, которые позволяют узлам контролировать, какие сообщения отправлены и какие приняты. Если сообщение потерялось или не подтверждено, узел-отправитель сформирует его повторно. Такая квитирование делает обмен устойчивым к сбоям канала связи.
Из чего состоит план обмена
Каждый план обмена включает три обязательных элемента. Первый — состав: перечень типов объектов метаданных (справочников, документов, регистров сведений), которые будут участвовать в синхронизации. Объект, не входящий в состав, никогда не попадёт в сообщение обмена, даже если пользователь изменил его.
Второй элемент — узлы. Это записи самого плана обмена, каждая из которых представляет одну базу-участницу. У любого плана есть предопределённый узел «Этот узел», обозначающий текущую базу; остальные узлы создаются вручную или при настройке обмена. Узел хранит код, наименование, номера отправленных и принятых сообщений.
Третий элемент — таблицы регистрации изменений. Для каждого узла платформа ведёт служебный учёт: какие объекты изменились и ещё не выгружены. Посмотреть зарегистрированные изменения можно через стандартную обработку «Регистрация изменений для обмена данными».
Как платформа регистрирует изменения
Регистрация происходит автоматически в момент записи объекта. Когда документ проводится, справочник изменяется или запись регистра обновляется, платформа проверяет, входит ли тип объекта в состав какого-либо плана обмена. Если входит — в таблицу регистрации изменений добавляется ссылка на объект для каждого узла, кроме текущего.
Важный нюанс: регистрируется факт изменения, а не сами данные. В сообщение обмена попадёт актуальное состояние объекта на момент выгрузки. Если товар отредактировали пять раз подряд, в узел уйдёт одна финальная версия, а не пять промежуточных. Это экономит трафик, но означает, что история изменений между сеансами обмена в другой базе не восстанавливается.
Разработчик может управлять регистрацией программно: подписаться на события «При записи», отключить авторегистрацию для отдельных узлов или вручную зарегистрировать объект методом ПланыОбмена.ЗарегистрироватьИзменения(). Это используется, когда нужно выгрузить объект по условию, не предусмотренному стандартной логикой.
Как формируются и передаются сообщения обмена
Сообщение обмена — это XML-файл определённой структуры. В заголовке указываются коды узлов-отправителя и получателя, а также номер сообщения. Тело содержит выгруженные объекты и, при необходимости, информацию об удалении данных. Нумерация сквозная для каждой пары узлов: первое сообщение имеет номер 1, второе — 2 и так далее.
При записи сообщения платформа выбирает все зарегистрированные изменения для узла-получателя, сериализует объекты в XML и очищает регистрацию — но только после того, как узел-приёмник подтвердит получение. Подтверждение передаётся в обратном сообщении: в его заголовке указан номер принятого сообщения. Если подтверждения нет, изменения будут выгружены повторно.
Способ транспорта сообщений план обмена не определяет. Это может быть файловый каталог, FTP, веб-сервис, COM-соединение, электронная почта или прямое подключение через механизм EnterpriseData. Транспорт настраивается отдельно — в типовых конфигурациях через помощник настройки синхронизации данных.
- 1Пользователь изменяет объект — платформа регистрирует изменение для узлов
- 2При выгрузке изменения сериализуются в XML-сообщение с очередным номером
- 3Сообщение передаётся в базу-приёмник выбранным транспортом
- 4Приёмник читает сообщение, записывает объекты и отвечает подтверждением
- 5Отправитель, получив подтверждение, очищает регистрацию изменений
Распределённые информационные базы: главный и подчинённый узлы
Распределённая информационная база (РИБ) — частный случай обмена через планы обмена с жёсткой иерархией. Есть главный узел и один или несколько подчинённых. Данные могут передаваться в обе стороны, но изменения конфигурации идут только сверху вниз: из главного узла в подчинённые.
Создать подчинённый узел можно только из главного: для этого в главной базе создают узел и формируют начальный образ — файл со слепком базы, из которого разворачивается периферийная копия. С этого момента базы связаны: подчинённая «знает» своего главного, а главный ведёт учёт сообщений для каждого подчинённого.
Обновление конфигурации в РИБ имеет особенности. Сначала конфигурацию обновляют в главном узле, затем изменения вместе с очередным сообщением обмена уходят в подчинённые базы. Пока подчинённый узел не примет обновление конфигурации, работа в нём после смены структуры метаданных может быть заблокирована. Поэтому обновление РИБ из нескольких баз требует координации по времени.
Обмен между разными конфигурациями
Планы обмена применяются и для синхронизации разных продуктов — например, «Управление торговлей» с «Бухгалтерией предприятия». Здесь структуры данных не совпадают, поэтому поверх планов обмена работает дополнительный слой — правила конвертации. В типовых решениях это либо правила обмена для «Конвертации данных», либо формат EnterpriseData.
Логика такая: план обмена по-прежнему отвечает за регистрацию изменений и транспорт сообщений, а правила конвертации описывают, как объект одной конфигурации преобразуется в объект другой. Например, документ «Реализация товаров и услуг» из торговли превращается в «Реализацию (акты, накладные)» в бухгалтерии с подстановкой соответствий счетов учёта и номенклатуры.
При настройке такого обмена критично выровнять нормативно-справочную информацию: если контрагент или номенклатура сопоставлены неправильно, документы в приёмнике будут созданы с дублями или пустыми ссылками. Поэтому первые сеансы обмена всегда делают в тестовом режиме с ручной проверкой сопоставления объектов.
Варианты организации обмена
Подходит для филиалов на одной конфигурации. Простая настройка, но жёсткая связь узлов и сложности с обновлением.
Для обмена между разными конфигурациями 1С. Гибкие правила, но требует сопоставления справочников.
Для нестандартных сценариев и старых конфигураций. Максимальная гибкость, но правила нужно писать и поддерживать вручную.
Типичные проблемы и как их диагностировать
Самая частая жалоба — «данные не приходят». Диагностику начинают с регистрации изменений: если объект не зарегистрирован для узла, он и не выгрузится. Причины: объект не входит в состав плана, изменение произошло до настройки обмена, регистрацию очистили вручную. Решение — зарегистрировать объект принудительно через обработку регистрации изменений.
Вторая группа проблем — коллизии: один и тот же объект изменён в обеих базах между сеансами. В типовых синхронизациях действует правило «главный узел важнее» или «кто последний записал» в зависимости от настроек. В РИБ при коллизии изменения главного узла обычно приоритетнее. Чтобы коллизий было меньше, разграничивают права: например, номенклатуру редактируют только в центральной базе.
Третья группа — ошибки при загрузке сообщения: нарушение ссылочной целостности, несовпадение версий конфигурации, ошибки в правилах конвертации. Такие ошибки видны в протоколе обмена и журнале регистрации. Пока сообщение не загружено корректно, подтверждение не отправится, и отправитель будет повторять выгрузку — очередь сообщений начнёт расти.
Как проверить, что обмен работает
Изменённые объекты видны в списке регистрации для узла
Список пуст при наличии правок — объект не в составе плана
Номер отправленного растёт, принятый подтверждается обратным сообщением
Номер отправленного растёт, принятый не меняется — сообщения не доходят
Сеансы завершаются без ошибок, объекты сопоставлены
Ошибки загрузки, несопоставленные ссылки, дубли элементов
Частые вопросы
Чем план обмена отличается от правил обмена?
План обмена — объект конфигурации, который хранит список узлов, состав данных и регистрацию изменений. Правила обмена — это алгоритм преобразования объектов (обычно XML-файл или правила КД), который нужен только при обмене между разными конфигурациями. План обмена работает всегда, правила — только в неоднородных обменах.
Можно ли выгрузить данные, которые менялись до настройки обмена?
Да. Нужно вручную зарегистрировать нужные объекты для узла через обработку «Регистрация изменений для обмена данными» или программно. После регистрации объекты попадут в ближайшее сообщение обмена.
Что произойдёт, если удалить зарегистрированное изменение?
Объект просто не будет выгружен в этот раз. Сами данные в базе не пострадают, но если объект больше никто не изменит, в узел-приёмник он не попадёт никогда — регистрация очистится без выгрузки.
Сколько узлов может быть в одном плане обмена?
Жёсткого ограничения платформа не накладывает, но на практике каждый узел — это отдельная таблица регистрации изменений и отдельный поток сообщений. При большом числе узлов растут объём служебных данных и время выгрузки, поэтому топологию обмена проектируют заранее.
Можно ли настроить обмен без плана обмена?
Технически данные можно передавать через COM, веб-сервисы или файлы произвольного формата, но тогда регистрацию изменений, нумерацию сообщений и контроль доставки придётся реализовывать самостоятельно. План обмена даёт всё это из коробки, поэтому для регулярной синхронизации его используют практически всегда.
Что важно запомнить
План обмена задаёт состав данных и список узлов, платформа автоматически регистрирует изменения и упаковывает их в нумерованные XML-сообщения с подтверждением доставки. Контролируйте регистрацию изменений, номера сообщений и протоколы обмена — это три точки, по которым диагностируется любая проблема синхронизации.