При настройке синхронизации между различными конфигурациями «1С:Предприятие 8.3» (например, между «1С:ERP», «1С:Управление торговлей» или «1С:Бухгалтерия») разработчики часто сталкиваются с задачей организации одностороннего обмена. Сценарий кажется простым: данные должны передаваться из базы-источника в базу-приемник, но любые изменения, внесенные в приемнике, ни в коем случае не должны возвращаться обратно.
На практике стандартная настройка сценариев обмена часто преподносит неприятные сюрпризы, когда при ручном запуске синхронизации измененные в приемнике данные все равно «прилетают» в источник. В этой статье мы подробно разберем, почему так происходит, как устроен механизм обмена изнутри и какими способами можно гарантированно настроить односторонний обмен данными.
В Библиотеке стандартных подсистем (БСП), которая лежит в основе всех современных конфигураций 1С, существует механизм настройки сценариев обмена. Там можно четко определить действия для каждого узла: например, для одного узла указать только «Отправка данных», а для другого — только «Получение данных».
Проанализируем ситуацию, с которой сталкиваются многие специалисты: мы настроили сценарий, оставив для источника только отправку, а для приемника — только получение. Но стоит пользователю зайти в узел обмена и нажать кнопку «Синхронизировать» вручную, как измененный объект из приемника благополучно регистрируется и переносится в источник. Почему это происходит?
Дело в особенностях реализации БСП. Настройки сценариев обмена применяются исключительно при автоматическом обмене по расписанию (через регламентные задания РегламентноеЗадание.СинхронизацияДанных). Когда пользователь запускает синхронизацию интерактивно (вручную по кнопке), система игнорирует ограничения сценария и выполняет полный цикл обмена: сначала выгрузку данных из текущей базы, а затем загрузку входящего файла. Именно поэтому ручной запуск полностью ломает концепцию одностороннего обмена, настроенную через сценарии.
Прежде чем перейти к вариантам решения, рассмотрим важную архитектурную деталь платформы 1С. Мы не можем просто физически заблокировать отправку любых сообщений из базы-приемника в базу-источник (например, запретив запись файлов обмена на сетевой диск). Механизм обмена спроектирован так, что источнику жизненно важно получать ответные файлы от приемника. Этот процесс называется квитированием.
Когда база-источник выгружает пакет данных, она присваивает сообщению определенный номер и ожидает от приемника подтверждения получения именно этого номера сообщения. Если база-источник отправила пакет, но не получила назад файл-ответ с квитанцией, она считает эти данные недоставленными. При каждой следующей синхронизации источник будет повторно выгружать все те же самые данные. Это приведет к лавинообразному росту размера файлов обмена, перегрузке процессора и критическому замедлению работы всей системы.
Правильное решение: база-приемник должна отправлять ответный файл в базу-источник. Однако этот файл должен быть «пустым» с точки зрения бизнес-данных — он должен содержать только номера принятых сообщений (технические квитанции) и не нести в себе никаких изменений справочников или документов.
---
Рассмотрим самый простой и правильный с точки зрения поддержки конфигурации способ. В современных версиях БСП настроить запрет выгрузки данных из базы-приемника можно интерактивно, не прибегая к конфигуратору или сторонним обработкам. Разберем этот процесс по шагам:
При такой схеме авторегистрация объектов на узле обмена в базе-приемнике полностью прекращается. При ручном или автоматическом обмене система будет формировать технический файл, содержащий только квитанции о приеме данных от источника, а измененные справочники и документы приемника отправляться обратно не будут.
---
Бывают ситуации, когда стандартных интерактивных настроек БСП не хватает. Например, если нам нужно разрешить выгрузку обратно только одного конкретного справочника (допустим, «Контрагенты»), а все остальные объекты и документы жестко заблокировать. В этом случае нам на помощь приходит механизм Правил регистрации объектов (ПРО). Этот способ является «золотым стандартом» для разработчиков 1С.
Посмотрим на пример реализации этого подхода по шагам:
Перед обработкой для каждого правила регистрации пропишем следующий код:
// Блокируем регистрацию изменений объекта для данного узла обмена
Отказ = Истина;
Для справочников важно также проанализировать режим их выгрузки. Если в правилах конвертации для справочника установлен режим «Выгружать всегда», то простая очистка регистрации может не сработать, так как объект может «подтянуться» по ссылкам из других документов. Поэтому режим выгрузки таких справочников в КД следует переключить в положение «Выгружать по ссылке» или «Не выгружать».
После этого, даже если пользователи будут вручную создавать и редактировать документы и справочники в базе-приемнике, они физически не смогут зарегистрироваться на узле обмена и никогда не попадут в базу-источник.
---
Рассмотрим еще один экспресс-метод, который упоминали участники обсуждения. Он подходит для быстрого разграничения прав на уровне документов, когда нет возможности оперативно менять правила регистрации или лезть в конфигуратор.
Мы можем использовать стандартный механизм дат запрета изменения данных совместно с настройками синхронизации:
01.03.2020).Однако помните, что этот способ имеет существенные ограничения. Он отлично работает для документов (которые жестко привязаны к временной шкале), но абсолютно бесполезен для справочников. Справочники не имеют реквизита даты, поэтому изменения в них будут продолжать мигрировать между базами без каких-либо препятствий.
---
Отдельно проанализируем ситуацию интеграции крупных систем, упомянутую в обсуждении (например, «1С:ERP Управление предприятием» и «1С:Документооборот 2.1»). В старых редакциях «1С:Документооборот 2.1» действительно отсутствует полноценный план обмена через универсальный формат EnterpriseData (ED).
Если перед вами стоит задача связать эти две системы, классический обмен файлами — далеко не самое лучшее решение. Рекомендуется использовать механизм бесшовной интеграции:
Если же вы используете современную линейку «1С:Документооборот 3.0» и новые редакции «1С:ERP 2.5», то там механизмы интеграции уже существенно модернизированы и поддерживают современные стандарты обмена данными, что значительно облегчает жизнь разработчикам и администраторам систем.