Переход с привычной «Конвертации данных 2.1» на версию 3.x (технология Enterprise Data) требует от разработчика смены парадигмы. Если в версии 2.1 мы привыкли работать с XML-файлами правил, которые загружаются непосредственно в узел обмена, то в версии 3.0 вся логика сосредоточена в программном коде модуля менеджера обмена. В этой статье мы подробно разберем, как эффективно дорабатывать такие обмены, сохраняя при этом возможность беспрепятственного обновления типовых конфигураций.
Рассмотрим ситуацию: вам необходимо добавить новый реквизит или изменить логику обработки документа. Первое побуждение — зайти в модуль МенеджерОбменаЧерезУниверсальныйФормат и внести правки напрямую. Однако при первом же обновлении конфигурации ваши изменения будут затерты типовым кодом вендора. Выясним, как этого избежать.
Проанализируем три наиболее эффективные стратегии доработки:
Мой_МенеджерОбмена). Чтобы система начала использовать его, необходимо через расширение переопределить функцию, отвечающую за выбор модуля менеджера для конкретного обмена.Одной из главных проблем, описанных пользователями, является риск автоматического переключения обмена на новую версию формата после обновления. В технологии Enterprise Data базы «договариваются» о версии формата при установке соединения: используется максимально высокая версия, поддерживаемая обоими участниками.
Разберем по шагам, как зафиксировать версию формата и защитить логику обмена:
Проанализируем механизм выбора версии. Если база-источник после обновления стала поддерживать формат 1.17, а база-приемник все еще на 1.15, обмен пойдет по версии 1.15. Но как только вы обновите и вторую базу, система автоматически переключится на 1.17. Если ваш кастомный код в расширении был жестко привязан к процедурам версии 1.15, обмен может «сломаться».
Чтобы установить контроль, выполните следующие действия в расширении:
ПриОпределенииВерсийФормата).&Вместо, чтобы жестко ограничить список возвращаемых версий только той, под которую написаны ваши доработки.Пример программной фиксации версии в расширении:
&Вместо("ДоступныеВерсииФормата")
Функция Мой_ДоступныеВерсииФормата()
Результат = Новый Массив;
Результат.Добавить("1.15"); // Фиксируем версию, чтобы обновление не переключило нас на 1.17
Возврат Результат;
КонецФункции
Многие разработчики сталкиваются с тем, что при выгрузке модуля из КД 3.1 текст кода отличается от исходного (появляются лишние переносы строк, меняется порядок процедур). Разберемся, стоит ли обращать на это внимание.
Важно понимать, что КД 3.1 — это скорее «генератор скелета». Она незаменима, когда нужно:
ПКО) для сложных объектов.Однако «филигранную» настройку логики (сложные условия, заполнение дополнительных реквизитов) проще делать уже в самом коде через расширение. Если вы решили использовать КД 3.1 для серьезных доработок, рекомендуется полностью заменять текст модуля в расширении на сгенерированный код, а не пытаться совмещать их построчно.
Рассмотрим практический пример из обсуждения: сверка документов между любыми конфигурациями и синхронизация номенклатуры с характеристиками при передаче в конфигурацию, где учет по характеристикам не ведется (например, «Бухгалтерия предприятия»).
Выясним причину возможных ошибок: в универсальном формате Номенклатура и Характеристики — это разные сущности. Если просто отправить данные, в приемнике может возникнуть дублирование или потеря аналитики.
Для решения этой задачи необходимо использовать обработчики событий в модуле менеджера:
Наименование формата.GUID (уникальному идентификатору), но если объекты создавались в базах независимо, нужно настроить поиск по артикулу или комбинации полей.Посмотрим на пример кода в обработчике отправки данных:
Процедура ПКО_Справочник_Номенклатура_Отправка_ПриОтправкеДанных(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена)
// Если у номенклатуры есть характеристика, добавим ее в описание
Если ЗначениеЗаполнено(ДанныеИБ.Характеристика) Тогда
ДанныеXDTO.Наименование = Строка(ДанныеИБ.Наименование) + " (" + Строка(ДанныеИБ.Характеристика) + ")";
КонецЕсли;
КонецПроцедуры
Если вам катастрофически не хватает стандартных полей формата Enterprise Data, не стоит пытаться «впихнуть» данные в неподходящие по смыслу теги. Правильный путь — создание расширения XDTO-пакета.
Разберем алгоритм:
Номенклатура).Это позволит вам передавать любые специфические данные, сохраняя при этом совместимость с типовыми механизмами обмена.
Подводя итог, можно выделить золотое правило работы с Конвертацией данных 3.0: используйте мощь кода, но не забывайте о поддержке.
Для простых правок используйте расширения с аннотациями &После. Для масштабных изменений структуры используйте Конвертацию данных 3.1 для генерации базы кода, но фиксируйте версию формата программно, чтобы ваши усилия не обнулились после очередного патча от фирмы 1С. Всегда тестируйте обмен на копиях баз, так как ошибки в формате ED часто проявляются только на этапе загрузки (десериализации) данных в приемнике.