При настройке двустороннего обмена данными между конфигурациями разных поколений — например, 1С:Управлением торговым предприятием (УТП) на обычных формах и современной базой на базе Библиотеки стандартных подсистем (БСП) — разработчики часто сталкиваются с неприятным эффектом. Файл выгрузки из БСП-базы начинает бесконечно расти, в него попадают объекты, которые уже давно были успешно перенесены, а в XML-структуре накапливаются странные узлы ИнформацияОРегистрацииОбъекта. Рассмотрим, почему это происходит и как привести механизм обмена в порядок.
Разберем основной механизм работы планов обмена в 1С. Когда одна база (отправитель) выгружает данные, она помечает в своей таблице регистрации изменений, в какое сообщение (номер сообщения) попали эти данные. Эти записи будут оставаться в таблице регистрации до тех пор, пока база-отправитель не получит от базы-получателя квитанцию (подтверждение).
Квитирование работает через заголовок XML-файла. В нем передаются два ключевых атрибута:
НомерСообщения — текущий номер выгрузки.НомерПринятого — номер сообщения, которое отправитель успешно загрузил от своего партнера.Проанализируем ситуацию автора: если база на БСП постоянно выгружает старые объекты, это означает, что она «не знает», что база УТП их уже получила. В таблице регистрации БСП эти объекты висят с номерами сообщений (например, 10, 11, 12), а УТП в ответном файле не присылает информацию о том, что она приняла сообщение №12. В итоге БСП при каждой новой выгрузке снова и снова включает в файл всё, что не было подтверждено.
Узлы ИнформацияОРегистрацииОбъекта специфичны для подсистемы обмена данными БСП. Посмотрим, для чего они нужны. БСП использует их для синхронизации объектов по уникальным идентификаторам (GUID), когда базы пытаются сопоставить объекты друг другу без создания дублей.
Если эти узлы накапливаются и постоянно присутствуют в выгрузке, это следствие той же проблемы: база БСП не получила сигнал о том, что соответствие установлено и объект успешно принят на стороне УТП. Пока «круг не замкнется» (выгрузка — загрузка — подтверждение в ответном сообщении), БСП будет считать свою миссию невыполненной.
В процессе обмена участвуют два разных регистра сведений. Рассмотрим, как они взаимодействуют в гибридной схеме:
СоответствиеОбъектовДляОбмена — это типовой регистр старых конфигураций (УТП, УПП 1.3). Его использует «классическая» обработка обмена.СоответствияОбъектовИнформационныхБаз — это регистр БСП. Его используют современные механизмы обмена.Как было отмечено в обсуждении, это нормальная ситуация, когда каждая база пишет в свой «родной» регистр. Однако важно, чтобы код загрузки в УТП корректно отрабатывал входящие данные от БСП и фиксировал номер принятого сообщения в объекте ПланОбменаМенеджер. Если в УТП используется стандартная обработка УниверсальныйОбменДаннымиXML, она может не обновлять номер принятого сообщения автоматически, если это не прописано в логике вызова.
Первым делом проверим, что именно УТП сообщает базе БСП. Откроем файл выгрузки из УТП в текстовом редакторе и найдем секцию заголовка. Нас интересует атрибут Confirmation (или НомерПринятого в зависимости от формата).
Если в этом поле постоянно стоит «0» или число, которое не увеличивается от обмена к обмену, значит, УТП не фиксирует номер сообщения, полученного от БСП. Выясним причину в коде.
Для того чтобы база БСП очистила свою таблицу регистрации, нам нужно в базе УТП после успешной загрузки данных выполнить код, который обновит НомерПринятогоИнформационнойБазой. Рассмотрим пример того, как это должно выглядеть в процедуре завершения обмена в УТП:
// Получаем узел обмена, с которым работаем
УзелОбменаОбъект = ПланыОбмена.НашПланОбмена.НайтиПоКоду("КодБСП").ПолучитьОбъект();
// Предположим, НомерСообщенияИзФайла мы получили из заголовка загруженного XML
Если НомерСообщенияИзФайла > УзелОбменаОбъект.НомерПринятого Тогда
УзелОбменаОбъект.НомерПринятого = НомерСообщенияИзФайла;
УзелОбменаОбъект.Записать();
КонецЕсли;
Как только вы запишете этот номер в узел на стороне УТП, при следующей выгрузке из УТП в БСП этот номер попадет в заголовок файла. БСП прочитает его и автоматически удалит все записи из своей таблицы регистрации, номера сообщений которых меньше или равны этому числу.
Поскольку вы используете правила, написанные в Конвертации данных 2.1, проанализируем настройки ПВД (Правил выгрузки данных). В БСП-базе убедитесь, что в правилах не стоит принудительная выгрузка объектов вне зависимости от регистрации изменений. Но, как показывает практика, в 99% случаев проблема именно в квитировании (подтверждении номера сообщения).
Если в БСП-базе все равно остаются «зависшие» изменения, мы можем очистить их принудительно с помощью стандартной обработки «Регистрация изменений для обмена» или программно, чтобы «начать жизнь с чистого листа»:
Узел = ПланыОбмена.НашПланОбмена.НайтиПоКоду("КодУТП");
ПланыОбмена.УдалитьРегистрациюИзменений(Узел);
Важный момент: после такой очистки файл обмена станет пустым. Но как только в БСП произойдет изменение объекта, он снова попадет в регистрацию и будет выгружаться до тех пор, пока УТП не подтвердит его получение корректным номером сообщения в заголовке.
Подведем итог нашему исследованию. Для решения проблемы разрастания файла необходимо выполнить следующие действия:
НомерПринятого соответствующего узла плана обмена.СоответствиеОбъектовДляОбмена и СоответствияОбъектовИнформационныхБаз) — они могут сосуществовать, если каждый программный модуль обмена работает со своим регистром. Главное — обеспечить общую логику квитирования через заголовки файлов.Следуя этим шагам, мы добьемся того, что файл обмена будет содержать только актуальные изменения, а узлы ИнформацияОРегистрацииОбъекта перестанут дублироваться и раздувать объем передаваемых данных.