Как правильно расширить XDTO-пакет и управлять версиями обмена в 1С, чтобы избежать проблем при обновлениях конфигурации?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← К списку

При работе с обменом данными в 1С, особенно при использовании универсального формата EnterpriseData, часто возникает необходимость расширить типовой XDTO-пакет или зафиксировать определенную версию обмена. Это позволяет адаптировать систему под специфические требования бизнеса, добавлять новые сущности или свойства, при этом сохраняя возможность получать обновления типовой конфигурации без потери доработок. Давайте вместе разберем основные подходы к решению этой задачи, проанализируем их преимущества и недостатки, и выясним, какой метод лучше применить в той или иной ситуации.

Подход 1: Создание собственной копии XDTO-пакета и фиксация версии обмена

Один из наиболее радикальных, но при этом надежных способов обеспечения независимости от типовых обновлений — это создание собственной копии типового XDTO-пакета и фиксация обмена на этой копии. Рассмотрим подробнее, как это реализовать.

Шаг 1: Копирование типового XDTO-пакета.

Мы берем существующий типовой XDTO-пакет (например, EnterpriseData_1_8_6), который используется в вашей конфигурации, и создаем его копию. При этом крайне важно присвоить этой копии собственный префикс (например, sal_EnterpriseData_1_8_6). Это действие позволит нам полностью контролировать содержимое пакета и вносить в него любые необходимые изменения, не опасаясь, что они будут перезаписаны при обновлении.

Шаг 2: Переопределение процедуры получения доступных версий формата.

Для того чтобы система обмена данными начала использовать нашу копию пакета, необходимо переопределить стандартную процедуру, которая возвращает список доступных версий формата обмена. Эта процедура находится в общих модулях:

  1. Для конфигураций, таких как Бухгалтерия Предприятия (БП), мы работаем с общим модулем ОбменДаннымиПереопределяемый и его процедурой ПриПолученииДоступныхВерсийФормата.
  2. Для конфигураций типа ERP, Комплексная Автоматизация (КА) или Управление Торговлей 11 (УТ11), мы обращаемся к общему модулю ОбменДаннымиЛокализация и его процедуре ПриПолученииДоступныхВерсийФормата.

Мы используем расширение конфигурации для того, чтобы перекрыть эту процедуру. В расширении мы создаем свою версию процедуры, используя директиву &Вместо. Внутри этой процедуры мы указываем нашу кастомную версию формата и собственный менеджер обмена.

Посмотрим на пример кода, который демонстрирует это:


&Вместо("ПриПолученииДоступныхВерсийФормата")
Процедура sal_ПриПолученииДоступныхВерсийФормата(ВерсииФормата)
    // Вставляем нашу собственную версию формата и менеджер обмена.
    // "1.8.6.sal" - это наш уникальный синоним версии, который мы присвоили.
    // sal_МенеджерОбменаЧерезУниверсальныйФормат - это наш собственный общий модуль-менеджер обмена.
    ВерсииФормата.Вставить("1.8.6.sal", sal_МенеджерОбменаЧерезУниверсальныйФормат);
    
    // Если требуется сохранить возможность использования типовых версий,
    // можно вызвать оригинальную процедуру или добавить их вручную.
    // Например, так:
    // ОригинальныйПриПолученииДоступныхВерсийФормата(ВерсииФормата);
КонецПроцедуры

Обратите внимание, что мы используем уникальный синоним версии (например, 1.8.6.sal) и указываем собственный общий модуль-менеджер обмена (например, sal_МенеджерОбменаЧерезУниверсальныйФормат). Этот менеджер будет содержать всю логику выгрузки и загрузки данных для нашей кастомной версии формата.

Преимущества данного подхода:

  1. Полная независимость от типовых обновлений: Наш XDTO-пакет и логика обмена остаются неизменными, даже если в типовой конфигурации появится новый пакет EnterpriseData_1_9_0.
  2. Полный контроль над пакетом: Мы можем добавлять, изменять или даже удалять элементы в нашей копии пакета без каких-либо ограничений.
  3. Гибкость в развитии: При выходе новых типовых версий (например, 1.9.0) мы можем экспортировать их в файлы, сравнить с нашей версией (1.8.6.sal) с помощью внешних инструментов, перенести необходимые изменения и добавить их в наш существующий пакет. Таким образом, у нас всегда будет актуальный пакет со всеми нашими доработками.

Недостатки данного подхода:

  1. Ручное слияние изменений: При каждом значительном обновлении типового формата нам придется вручную сравнивать и переносить изменения, что может быть трудоемко.
  2. Дублирование кода: Весь код менеджера обмена нам придется поддерживать самостоятельно, что увеличивает объем доработок.

Подход 2: Использование механизма расширения XDTO-пакета платформы 1С

Платформа 1С предлагает специальный механизм для расширения XDTO-пакетов, который позволяет добавлять новые сущности или свойства к существующим типовым пакетам EnterpriseData без снятия конфигурации с поддержки. Это более "аккуратный" способ адаптации обмена.

Назначение и принцип работы:

Расширения XDTO-пакетов предназначены исключительно для добавления новых элементов к типовому пакету. Мы можем, например, добавить свойство ПометкаУдаления или Проведен для существующих типов объектов, если они отсутствуют в типовом формате, или создать совершенно новые типы объектов.

Важно понимать, что расширение XDTO-пакета и расширение конфигурации — это разные сущности. Расширение XDTO-пакета создается как новый XDTO-пакет, который указывает на расширяемый типовой пакет через директивы импорта, позволяя ссылаться на его базовые объекты.

Ограничения механизма:

С помощью данного механизма мы можем только расширять состав пакета (добавлять новые элементы). Мы не можем удалить или переименовать существующие элементы типового пакета. Если нам требуется изменить структуру типовых элементов, этот подход не подойдет.

Создание и настройка:

Для создания расширения XDTO-пакета необходимо:

  1. Создать новый XDTO-пакет в конфигурации.
  2. Добавить в него директивы импорта для расширяемого типового формата (например, EnterpriseData_1_8_6).
  3. Определить новые типы объектов и их свойства или добавить новые свойства к существующим типам, которые будут "наследоваться" от типовых.

Например, если мы хотим добавить поле ИдентификаторИсточника к стандартному типу СправочникКонтрагенты, мы создадим расширяющий XDTO-пакет, который будет содержать описание этого поля для указанного типа.

Использование в принимающей базе:

Крайне важно устанавливать то же самое расширение в базу-приемник. Состав и порядок объектов в XDTO-пакете отправки и получения данных должны совпадать для корректной синхронизации.

Особенности при обновлении формата:

Если типовая конфигурация обновляется и появляется новая версия формата EnterpriseData (например, 1_9_0), и нам нужно добавить новые сущности уже к этой новой версии, то нам потребуется создать новое расширение XDTO-пакета, которое будет указывать на EnterpriseData_1_9_0 как на расширяемый пакет. Это означает, что для каждой новой версии типового формата, которую мы хотим расширить, мы будем иметь отдельное расширение.

Преимущества данного подхода:

  1. Сохранение поддержки: Конфигурация остается на поддержке, что упрощает типовые обновления.
  2. Точечные доработки: Мы изменяем только то, что нам необходимо добавить, не затрагивая основной пакет.
  3. Чистота типового кода: Основной XDTO-пакет остается типовым, что облегчает его анализ.

Недостатки данного подхода:

  1. Ограниченность: Можно только добавлять новые элементы, но нельзя изменять или удалять существующие.
  2. Множественность расширений: Для каждой новой версии типового формата может потребоваться свое расширение, что усложняет управление.
  3. Сложность разработки: Механизм расширения XDTO-пакетов может быть достаточно геморройным в освоении и использовании.

Подход 3: Передача дополнительных данных через поле AdditionalInfo

В некоторых случаях, когда нет необходимости вносить структурные изменения в XDTO-пакет, но требуется передать небольшое количество дополнительных данных, мы можем использовать специальное поле AdditionalInfo.

Что такое AdditionalInfo?

AdditionalInfo — это поле, которое передается с каждым объектом в составе пакета обмена. В него можно записать произвольные данные в формате XML-строки или другого сериализуемого значения. Это своего рода "конверт" для дополнительной информации.

Случаи применения:

ИТС рекомендует использовать AdditionalInfo в следующих ситуациях:

  1. Когда нет времени на выпуск новой версии формата (например, для срочной поддержки законодательства).
  2. Для обхода критических ошибок, блокирующих синхронизацию, без изменения структуры XDTO.
  3. Для передачи небольшого количества дополнительных значений для объекта, если изменение XDTO-пакета не является оптимальным решением.

Например, если нам нужно передать только одно-два дополнительных свойства для справочника, мы можем сериализовать их в XML и поместить в AdditionalInfo, а затем десериализовать на принимающей стороне.

Преимущества данного подхода:

  1. Независимость от версий пакетов: Мы не изменяем структуру XDTO-пакетов, поэтому этот подход менее чувствителен к их обновлениям.
  2. Быстрота реализации: Для небольших объемов данных это может быть самым быстрым способом реализации.
  3. Простота: Не требует глубоких знаний механизма XDTO-пакетов или их расширений.

Недостатки данного подхода:

  1. Неудобство для больших объемов данных: Если необходимо передать много новых свойств или эти свойства разбросаны по нескольким объектам формата, работа через AdditionalInfo может стать громоздкой и неудобной.
  2. Сложность отслеживания: Со временем изменения в модуле менеджера обмена, связанные с обработкой AdditionalInfo, будут накапливаться, усложняя анализ и поддержку.
  3. Отсутствие строгой структуры: Данные в AdditionalInfo не имеют строгой схемы XDTO, что может привести к ошибкам при некорректной сериализации/десериализации.

Сравнение подходов и общие рекомендации

Итак, мы рассмотрели три основных подхода к модификации обмена данными в 1С. Давайте сведем их в общую картину, чтобы нам было легче выбрать оптимальное решение.

Краткое сравнение:

  1. Копирование XDTO-пакета и фиксация версии:
    • Плюсы: Полный контроль, независимость от обновлений, любые изменения.
    • Минусы: Ручное слияние при обновлениях, дублирование кода менеджера обмена.
    • Когда использовать: Когда требуется глубокая модификация структуры типового пакета, удаление или переименование элементов, или когда вы хотите иметь полный и независимый контроль над форматом обмена.
  2. Расширение XDTO-пакета платформы:
    • Плюсы: Сохранение поддержки, точечное добавление новых элементов, чистота типового кода.
    • Минусы: Можно только добавлять, нельзя изменять/удалять, для каждой новой версии ED нужно новое расширение, сложность.
    • Когда использовать: Когда нужно добавить новые свойства или сущности к типовому пакету, не изменяя существующие элементы, и при этом сохранить конфигурацию на поддержке.
  3. Передача данных через AdditionalInfo:
    • Плюсы: Независимость от версий пакетов, быстрота для небольших данных, простота.
    • Минусы: Неудобство для больших объемов, сложность поддержки со временем, отсутствие строгой схемы.
    • Когда использовать: Для срочных, небольших изменений, когда не требуется модификация структуры XDTO-пакета, и когда нет времени на создание новой версии формата.

Общие рекомендации:

Выбор конкретного подхода всегда зависит от ваших задач, сроков, объема изменений и требований к дальнейшей поддержке системы. Внимательно проанализируйте ситуацию, прежде чем принимать решение.

← К списку