При переходе с классических обменов на обычных формах к современной подсистеме «Синхронизация данных» в составе Библиотеки стандартных подсистем (БСП) разработчики часто сталкиваются с изменением структуры файлов правил. Если раньше нам было достаточно одного файла XML, созданного в «Конвертации данных 2.0», то теперь при выгрузке комплекта правил мы видим три файла: ExchangeRules.xml, RegistrationRules.xml и загадочный CorrespondentExchangeRules.xml. Рассмотрим подробнее, какую роль играет каждый из них и почему современный механизм обмена стал именно таким.
Для начала проанализируем, что представляет собой каждый файл в архиве, который подготавливается для настройки синхронизации:
Разберем ситуацию: почему раньше нам хватало одного файла, а теперь их три? В старой парадигме (обработка «Универсальный обмен данными в формате XML») мы вручную загружали правила в каждую базу. В новой архитектуре БСП реализован принцип «одного окна».
Главная задача файла CorrespondentExchangeRules.xml — обеспечение автоматической синхронизации логики обмена между двумя базами без участия администратора на второй стороне. Проанализируем, как это работает по шагам:
Представим, что мы обмениваемся данными между Управление торговлей (УТ) и Бухгалтерия предприятия (БП). Мы внесли изменения в правила в базе УТ (например, добавили проброс нового реквизита). Если мы загрузим обновленный комплект правил только в УТ, база БП «не узнает», как правильно обрабатывать новые данные, пока мы не зайдем в неё и не загрузим правила вручную.
Однако, благодаря наличию CorrespondentExchangeRules.xml, система работает иначе:
CorrespondentExchangeRules.xml, который по сути является зеркальным отражением правил для БП.Таким образом, администратору достаточно обновить правила в одной «мастер-базе», а вторая сторона подтянет их самостоятельно при следующем сеансе связи.
Рассмотрим ситуацию, описанную в практике многих разработчиков: «Я изменил правила в источнике, но база-приемник все равно работает по-старому, хотя файл корреспондента я тоже обновил». Выясним причину такого поведения.
В БСП существует строгая иерархия приоритетов использования правил:
Чтобы база-приемник начала использовать CorrespondentExchangeRules.xml из входящего сообщения, в настройках синхронизации должен быть активирован механизм использования «поставляемых» правил. Если же правила были загружены в базу-приемник вручную как «индивидуальные», они могут иметь приоритет, и автоматическое обновление не произойдет. Также важно помнить, что БСП сравнивает версии правил (номер версии указывается в заголовке XML). Если номер версии в файле корреспондента не увеличился, база может проигнорировать обновление.
Особенно критичным наличие CorrespondentExchangeRules.xml становится при работе в модели SaaS (например, 1C:Fresh) или при обмене через Web-сервисы. В таких сценариях у пользователя часто нет физического доступа к файловой системе сервера, чтобы «подложить» файл правил. Весь обмен метаданными и алгоритмами происходит внутри потока данных. Система обменивается правилами внутри самого сообщения, обеспечивая целостность процесса конвертации на обеих сторонах.
Проанализируем, как правильно готовить такие правила в программе «Конвертация данных 2.1». При сохранении правил для БСП программа предлагает выгрузить именно архив (zip-пакет). Рассмотрим содержимое типичного кода выгрузки, который генерирует такие структуры.
Если вы столкнулись с необходимостью программно определить, какие правила используются в данный момент, можно обратиться к регистру сведений ПравилаДляОбменаДанными (в разных версиях БСП название может незначительно отличаться). Там хранятся двоичные данные самих XML-файлов.
Рассмотрим пример того, как система проверяет наличие обновлений в модуле обмена данными:
// Фрагмент логики проверки правил в БСП
Если ИнформацияОПравилахВСообщении.ВерсияПравил > ТекущаяВерсияПравил Тогда
ОбновитьПравилаИзОбъекта(ИнформацияОПравилахВСообщении.ДанныеПравил);
ЗаписатьЛогСобытия("Правила обмена были автоматически обновлены из входящего сообщения");
КонецЕсли;
Важный нюанс: файл CorrespondentExchangeRules.xml — это не просто копия ExchangeRules.xml. Это правила, «вывернутые» относительно текущей базы. То, что для текущей базы является ПВД (Правилом выгрузки данных), для корреспондента будет неактуально, зато ему критически важны ПКО (Правила конвертации объектов) для входящих типов данных.
Иногда возникает задача подружить современную базу на управляемых формах (например, БП 3.0) и старую базу на обычных формах (например, УТ 10.3). Здесь стандартный механизм «Синхронизации данных» с тремя файлами может вызвать сложности. Рассмотрим два пути решения:
V8Exch82.epf (Универсальный обмен данными в формате XML). Её можно подключить как внешнюю обработку и работать по старинке с одним файлом правил.CorrespondentExchangeRules.xml часто остается типовым и не используется активно, так как вся логика сосредоточена в одном месте.Выясним, почему автор в Сообщении 10 не заметил влияния файла корреспондента. Он изменил правила в источнике, не обновляя CorrespondentExchangeRules.xml, и загрузка в приемнике все равно сработала. Это произошло потому, что он выполнял обмен через каталог, и в приемнике уже были загружены соответствующие правила вручную. Система просто использовала локальную копию правил загрузки, проигнорировав (или не получив) блок обновления из транспортного сообщения.
Подводя итог, можно сказать, что CorrespondentExchangeRules.xml — это транспортный контейнер для доставки логики обмена на «ту сторону». Это избавляет разработчика от необходимости двойной работы по ручной загрузке файлов в обе базы и минимизирует риск рассинхронизации алгоритмов, когда одна база уже знает о новом поле, а вторая — еще нет. В современных реалиях 1С это стандарт обеспечения надежности и удобства администрирования распределенных систем.