Разработчики 1С часто сталкиваются с ситуацией, когда при настройке обмена данными между конфигурациями (например, Бухгалтерия предприятия и ERP Управление предприятием) с помощью технологии Конвертации данных 2.1 (КД 2.1) и планов обмена синхронизация завершается успешно и без ошибок, но данные в базе-приемнике так и не появляются. При этом ручная выгрузка через обработку УниверсальныйОбменДаннымиXML отрабатывает корректно, и все элементы переносятся.
В этой статье мы подробно разберем, почему так происходит, выясним роль системных регистров БСП в планах обмена, а также рассмотрим по шагам, как правильно организовать строго односторонний обмен данными без зацикливания и накопления очереди регистрации.
Когда мы нажимаем кнопку "Синхронизировать", и система рапортует об успешном завершении сеанса без критических ошибок в журнале регистрации, это означает лишь одно: транспортный контейнер был доставлен и прочитан. Однако сами бизнес-данные могли либо вообще не попасть в файл выгрузки, либо были проигнорированы или не записаны в приемнике. Рассмотрим подробнее основные причины такого поведения.
1. Несовпадение кодов узлов в источнике и приемнике
Для того чтобы обмен в рамках технологии Библиотеки стандартных подсистем (БСП) работал корректно, коды узлов планов обмена в обеих базах должны строго зеркально соответствовать друг другу. В базе-источнике (например, БП) код предопределенного узла (Этот узел) должен совпадать с кодом узла-корреспондента в базе-приемнике (ERP). И наоборот. Если коды узлов не совпадают, БСП при чтении файла обмена не сможет идентифицировать отправителя и проигнорирует пакет с данными.
2. Отсутствие регистрации изменений объектов
В отличие от универсального обмена, где мы выгружаем данные за период или по произвольному отбору, обмен через планы обмена выгружает только те объекты, изменения которых были зарегистрированы на узле-получателе. Если вы записали элемент справочника (например, Организации или Валюты), но авторегистрация для данного объекта в плане обмена отключена или настроена неверно в правилах регистрации (RegistrationRules.xml), то объект не попадет в файл выгрузки. Файл обмена будет содержать только технический заголовок с номерами сообщений, и загрузка в приемнике пройдет «вхолостую».
3. Отсутствие регистра сведений «Соответствия объектов информационных баз» в составе плана обмена
Это одна из самых частых и неочевидных ошибок при проектировании собственных планов обмена в конфигураторе. Регистр сведений СоответствияОбъектовИнформационныхБаз (СОИБ) используется БСП для хранения связей между уникальными идентификаторами (GUID) объектов в источнике и приемнике.
Если этот регистр не включен в состав вашего плана обмена в конфигураторе, то:
Чтобы решить эту проблему, обязательно откройте конфигуратор, перейдите в свойства вашего плана обмена, откройте вкладку Состав и установите флажок напротив регистра сведений СоответствияОбъектовИнформационныхБаз с режимом авторегистрации Запретить (так как регистрировать изменения самого регистра сопоставления, как правило, не требуется).
---
Представим задачу: нам необходимо настроить обмен так, чтобы данные (например, справочники и документы) переносились исключительно в одну сторону — из БП в ERP. При этом из ERP в БП ничего передаваться не должно.
Просто отключить выгрузку на стороне ERP в настройках расписания регламентных заданий — это грубейшая ошибка. В механизме БСП каждый сеанс обмена требует подтверждения (квитирования) получения сообщений. Если ERP не будет отправлять ответные сообщения в БП, то БП никогда не узнает, что ее данные успешно загружены в ERP. В результате БП при каждом следующем сеансе будет бесконечно выгружать всю накопленную историю изменений, что приведет к росту размера XML-файлов, перегрузке каналов связи и зависанию системы.
Для корректной работы одностороннего обмена на базе БСП необходимо использовать концепцию "пустых правил". Разберем по шагам, как подготовить такой комплект правил.
Нам необходимо создать файл правил конвертации данных ExchangeRules.xml для ERP, который не содержит никаких правил выгрузки данных (ПВД) и правил конвертации объектов (ПКО).
Для этого выполним следующие действия в конфигурации "Конвертация данных 2.1":
ExchangeRules.xml.Полученный файл в текстовом редакторе должен выглядеть примерно следующим образом:
<?xml version="1.0" encoding="UTF-8"?>
<ПравилаОбмена>
<ВерсияФормата РежимСовместимости="РежимСовместимостиСБСП20">2.01</ВерсияФормата>
<Ид>732e86ab-fc36-4d2b-9a1a-8deac171acc7</Ид>
<Наименование>Пустые правила ERP - БП</Наименование>
<ДатаВремяСоздания>2024-11-20T12:00:00</ДатаВремяСоздания>
<Источник ВерсияПлатформы="8.3" ВерсияКонфигурации="2.5" СинонимКонфигурации="1С:ERP Управление предприятием">ERP</Источник>
<Приемник ВерсияПлатформы="8.3" ВерсияКонфигурации="3.0" СинонимКонфигурации="Бухгалтерия предприятия">БухгалтерияПредприятия</Приемник>
<Параметры/>
<Обработки/>
<ПравилаКонвертацииОбъектов/>
<ПравилаВыгрузкиДанных/>
<ПравилаОчисткиДанных/>
<Алгоритмы/>
<Запросы/>
</ПравилаОбмена>
Когда ERP будет выполнять свою часть обмена, она инициализирует этот файл правил, поймет, что объектов для выгрузки нет, и сформирует исходящий файл, содержащий только квитанцию с номером принятого сообщения от БП. БП считает эту квитанцию и очистит свою таблицу зарегистрированных изменений.
Чтобы в базе ERP изменения объектов не регистрировались на узле обмена и не тратили ресурсы СУБД, необходимо отключить авторегистрацию. Это делается двумя путями, которые лучше использовать совместно:
Запретить.RegistrationRules.xml для ERP. В нем укажем элементы состава плана обмена, но для каждого элемента пропишем <Авторегистрация>false</Авторегистрация> или в обработчиках событий регистрации укажем безусловный отказ: Отказ = Истина;.Пример структуры файла правил регистрации с отключенной авторегистрацией:
<?xml version="1.0" encoding="UTF-8"?>
<ПравилаРегистрации>
<ВерсияФормата>2.01</ВерсияФормата>
<Ид>3e1d5b9d-6273-11ea-ab29-08606e6b3bf6</Ид>
<Наименование>Правила регистрации ERP (пустые)</Наименование>
<ПланОбмена Имя="ИмяВашегоПланаОбмена">ПланОбменаСсылка.ИмяВашегоПланаОбмена</ПланОбмена>
<СоставПланаОбмена>
<Элемент>
<Тип>СправочникСсылка.Организации</Тип>
<Авторегистрация>false</Авторегистрация>
</Элемент>
<Элемент>
<Тип>СправочникСсылка.Контрагенты</Тип>
<Авторегистрация>false</Авторегистрация>
</Элемент>
</СоставПланаОбмена>
</ПравилаРегистрации>
В БСП комплект правил для каждой базы загружается в виде ZIP-архива, который должен содержать три файла:
ExchangeRules.xml — правила выгрузки из текущей базы.RegistrationRules.xml — правила регистрации объектов в текущей базе.CorrespondentExchangeRules.xml — правила выгрузки из противоположной базы (базы-корреспондента). Это необходимо для того, чтобы база могла передать эти правила партнеру при первом сеансе связи, либо использовать их для сопоставления структуры входящих данных.Таким образом, мы должны сформировать два архива со следующей структурой файлов:
Архив для БП (Отправитель данных):
ExchangeRules.xml — реальные правила конвертации БП -> ERP (содержащие ПКО, ПВД для справочника Организации, Валюты и т.д.).RegistrationRules.xml — реальные правила регистрации для БП, которые автоматически регистрируют изменения организаций при их записи.CorrespondentExchangeRules.xml — пустые правила выгрузки из ERP (созданные на Шаге 1).Архив для ERP (Получатель данных):
ExchangeRules.xml — пустые правила выгрузки из ERP (созданные на Шаге 1).RegistrationRules.xml — пустые правила регистрации для ERP (созданные на Шаге 2).CorrespondentExchangeRules.xml — реальные правила конвертации БП -> ERP (копия файла ExchangeRules.xml из БП).---
Для того чтобы локализовать возможные ошибки и убедиться, что односторонний обмен работает стабильно и корректно, проведем тестирование по шагам.
Запустим обе информационные базы. Перейдем в раздел администрирования синхронизации данных и создадим новую настройку обмена через универсальный формат или по правилам обмена (в зависимости от используемой БСП). Настроим подключение через локальный или сетевой каталог. Убедимся, что коды узлов прописались зеркально.
Зайдем в настройки синхронизации данных в БП, перейдем в меню загрузки правил для обмена и загрузим наш подготовленный ZIP-архив для БП. Повторим аналогичную процедуру в ERP, загрузив туда архив с "пустыми" правилами выгрузки.
Перед началом тестирования важно убедиться, что таблицы регистрации изменений пусты. Для этого в обеих базах откроем обработку Регистрация изменений для обмена данными (ее можно найти через функции для технического специалиста).
Если на узлах зарегистрированы какие-либо объекты, выделим корневой узел дерева регистрации, нажмем правую кнопку мыши и выберем пункт Отменить регистрацию всех объектов.
В базе БП откроем справочник Организации. Создадим новый тестовый элемент (например, "ООО Тест-Обмен") или внесем незначительное изменение в существующую карточку организации (например, добавим пробел в наименовании) и запишем объект.
Снова откроем обработку регистрации изменений в БП и проверим, что напротив справочника Организации появилась цифра 1. Это подтверждает, что авторегистрация в источнике отработала штатно.
Запустим процесс синхронизации в БП. Дождемся окончания выгрузки. Не запуская загрузку в ERP, перейдем в каталог обмена на диске и найдем сформированный файл обмена (обычно он имеет имя вида Message_БП_ERP.xml).
Откроем его любым текстовым редактором (например, Notepad++) и найдем узел данных. Мы должны физически увидеть структуру нашей организации в XML-формате:
<Объект Тип="СправочникСсылка.Организации">
<Ссылка>
<Свойство Имя="Код" Тип="Строка"><Значение>000000001</Значение></Свойство>
<Свойство Имя="Наименование" Тип="Строка"><Значение>ООО Тест-Обмен</Значение></Свойство>
</Ссылка>
<ЛогикаЗагрузки>БезСозданияНовых</ЛогикаЗагрузки>
</Объект>
Если данные организации присутствуют в файле, значит, первый этап (регистрация и выгрузка из источника) завершен успешно.
Запустим синхронизацию данных в ERP. Дождемся успешного окончания процесса чтения данных.
Теперь проверим два момента:
Организации в ERP. Убедимся, что новая организация "ООО Тест-Обмен" появилась в списке.Соответствия объектов информационных баз. В списке записей должна появиться новая строка, связывающая уникальный идентификатор (GUID) организации из БП с GUID созданной организации в ERP для нашего узла обмена. Наличие этой записи гарантирует, что при последующих изменениях этой организации в БП система обновит существующий элемент в ERP, а не создаст дубль.Запустим выгрузку из ERP. Поскольку мы настроили пустые правила, ERP сформирует файл обмена Message_ERP_БП.xml, в котором не будет никаких бизнес-данных, а только квитанция с подтверждением номера обработанного сообщения от БП.
Запустим загрузку в БП. БП считает файл-подтверждение, поймет, что ERP успешно получила тестовую организацию, и автоматически удалит запись о ее регистрации. Открыв обработку регистрации изменений в БП, мы должны увидеть абсолютно пустое дерево регистрации.
Таким образом, мы получили замкнутый, стабильный цикл одностороннего обмена. БП отправляет измененные данные, ERP их принимает, отправляет обратно пустую квитанцию, БП очищает свою очередь отправки. Очередь регистрации не растет, файлы обмена остаются минимального размера, а данные гарантированно доставляются в приемник.