Работа с инструментом Конвертация данных 3.1 (КД 3.1) существенно отличается от привычной многим версии 2.1. КД 3.1 предлагает более системный подход. Основное различие заключается в том, что логика обмена теперь базируется на технологии EnterpriseData и размещается непосредственно в коде конфигурации, а не во внешнем XML-файле. В данной статье мы подробно разберем, как правильно интегрировать выгруженные из КД 3.1 правила, как использовать возможности расширений для сохранения поддержки конфигурации и как эффективно отлаживать процесс обмена.
После того как в конфигурации Конвертация данных 3.1 настроены правила для отправителя и приемника, необходимо получить программный код, который будет управлять процессом трансформации данных в формат XDTO. Рассмотрим последовательность действий:
Многие разработчики на начальном этапе совершают ошибку, вставляя этот код напрямую в типовой общий модуль МенеджерОбменаЧерезУниверсальныйФормат. Это затрудняет последующее обновление конфигурации. Разберем более правильный подход с использованием механизмов расширений.
Чтобы не изменять типовую конфигурацию и сохранить возможность ее беспрепятственного обновления, рекомендуется использовать расширения. Проанализируем, как правильно переопределить модуль менеджера обмена.
Создадим в расширении новый общий модуль. Имя модулю лучше давать осмысленное, соответствующее версии формата, например: МенеджерОбмена_Собственный_1_15. В этот модуль мы вставляем весь текст, который выгрузили из КД 3.1. Убедитесь, что у модуля установлены свойства Сервер и Вызов сервера. При работе с методами платформы и БСП вам может очень пригодиться справочник по методам БСП, где собраны примеры использования стандартных подсистем.
Теперь нам нужно указать системе, что при обмене данными через определенную версию формата необходимо использовать именно наш новый модуль. Для этого мы будем использовать переопределяемый модуль платформы. Рассмотрим пример кода, который необходимо добавить в расширение для модуля ОбменаДаннымиПереопределяемый:
Процедура ПриПолученииДоступныхВерсийФормата(ВерсииФормата) Экспорт
// Если мы хотим переопределить стандартную логику для версии 1.15
ВерсииФормата.Вставить("1.15", МенеджерОбмена_Собственный_1_15);
// Также можно добавить поддержку новой, кастомной версии
ВерсииФормата.Вставить("1.17_custom", МенеджерОбмена_Собственный_1_17);
КонецПроцедуры
Разберем, что происходит в этом фрагменте. Переменная ВерсииФормата является структурой, где ключом выступает номер версии EnterpriseData, а значением — имя модуля менеджера. Заменяя или добавляя значения в эту структуру, мы гибко управляем логикой обмена.
В КД 3.1 правила обмена (ПО) и правила регистрации (ПРО) — это две разные сущности. Если ПО отвечают за то, как данные преобразуются, то ПРО определяют, какие именно объекты должны уйти в обмен. Проанализируем ситуацию с регистрацией:
В отличие от модуля менеджера, правила регистрации не нужно вставлять в код. В КД 3.1 они выгружаются в отдельный XML-файл. Чтобы они заработали, выполним следующие шаги в пользовательском режиме (1С:Предприятие):
Важный нюанс: Если вы планируете использовать авторегистрацию объектов при записи, убедитесь, что в правилах регистрации корректно настроены фильтры. Если стандартных средств недостаточно, можно использовать расширение, которое позволяет выполнять регистрацию или удаление объектов из плана обмена с формы, что значительно упрощает работу администратора.
Одним из главных преимуществ перехода на КД 3.1 является простота отладки. Поскольку весь код обмена теперь находится в обычном модуле 1С, мы можем использовать стандартный отладчик Конфигуратора. Однако здесь есть свои тонкости, которые мы сейчас выясним.
Основная сложность заключается в том, что синхронизация данных обычно выполняется в фоновом задании. Чтобы точка останова сработала, необходимо правильно настроить подключение. Специально для тех, кто только начинает работать с этими механизмами, будет полезна статья фоновые задания для новичков, где описаны нововведения последних версий платформы. Для настройки отладки:
ПКО_..._Выгрузка_...).Существует и альтернативный способ, который позволяет отлаживать код в текущем сеансе без участия фоновых заданий. Для этого удобно использовать типовую обработку Регистрация изменений для обмена.
Проанализируем ситуацию, когда вам необходимо добавить в обмен поле, которого нет в стандартном формате EnterpriseData. В КД 3.1 вы можете легко добавить это поле в структуру, но при выгрузке 1С выдаст ошибку несоответствия схеме. Выясним причину:
Механизм XDTO строго проверяет данные на соответствие пакету, описанному в конфигурации. Если вы расширяете состав передаваемых данных, вам необходимо выполнить два действия:
EnterpriseData_1_15) и добавить туда ваше новое поле.Без расширения XDTO-пакета даже идеально написанный код в модуле менеджера не позволит передать нестандартные данные.
Подводя итог, можно сказать, что работа с КД 3.1 требует более глубокого понимания архитектуры 1С и механизмов расширений, чем работа с КД 2.1. Однако взамен разработчик получает высокую скорость обмена и удобные инструменты диагностики. В сложных распределенных системах иногда имеет смысл рассматривать обмены через брокеры для более гибкого управления очередями сообщений. Рассмотрим еще несколько советов для успешной работы:
ПКО_... отвечают за конвертацию объекта, а ПОД_... — за выборку данных. Разделение этой логики помогает быстрее находить нужный участок кода.