← На главную

Задача переноса нестандартных документов, не входящих в стандартный формат EnterpriseData (ED), часто возникает при доработке систем на основе БСП. Давайте детально разберем, какие подходы существуют, в чем их архитектурные преимущества и какие «подводные камни» ждут разработчика на этом пути.

Вариант 1: Использование существующего формата «как есть» (Метод «Коробка из под гвоздей»)

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

1. Выберите в формате EnterpriseData объект, который не используется в вашем текущем обмене или максимально близок по структуре к вашему документу.
2. Доработайте правила конвертации данных (ПКО) в обеих базах.
3. В принимающей базе, используя механизмы ПОД (Правила обработки данных), по определенному признаку (например, по уникальному префиксу в Идентификаторе или реквизите) перехватите загрузку и направьте её в ваш самописный объект.

Преимущества: Не требуется изменение состава пакетов XDTO, что сохраняет совместимость с типовыми конфигурациями.

Недостатки: Код становится менее прозрачным, так как логика обмена «замаскирована» под другие объекты.

Вариант 2: Расширение пакета XDTO с созданием нового пространства имен

Если проект подразумевает долгосрочную поддержку, лучше создать новый пакет XDTO на основе типового, присвоив ему уникальное пространство имен (например, вместо версии 1.10 создать 1.102).

Разберем процесс по шагам:

1. В конфигураторе создайте новый пакет XDTO, скопировав структуру типового и добавив в него описание вашего документа.
2. Установите данный пакет во всех участвующих в обмене конфигурациях.
3. Настройте правила конвертации, используя новые типы данных.

Важное предостережение: Механизм EnterpriseData крайне чувствителен к структуре XML. Если принимающая база не знает о вашем расширении пакета, при получении сообщения произойдет ошибка разбора (XDTO Validation Error). Поэтому изменения должны быть синхронизированы во всех узлах обмена.

Вариант 3: Использование классического КД 2.0 для специфических задач

Если обмен данными происходит исключительно между двумя самописными конфигурациями, возникает логичный вопрос: а нужен ли здесь КД 3.1? КД 2.0 часто оказывается более гибким и простым инструментом для переноса данных между конфигурациями, не претендующими на универсальность формата EnterpriseData.

Когда стоит выбрать КД 2.0:

• Вам не требуется обмен с типовыми конфигурациями «из коробки».
• Вы хотите упростить процесс написания правил и их отладки.
• Обмен происходит только между двумя конкретными базами, и их структура часто меняется.

Анализ рисков при изменении пакетов XDTO

Приняв решение о внесении изменений в XDTO, вы должны осознавать следующие риски:

• Сложность обновлений: При обновлении версии БСП вам придется проверять, не конфликтуют ли ваши изменения с новыми стандартами пакетов обмена.
• Потеря совместимости: Если вы добавите в обмен базу, которая не «знает» о вашем расширенном пакете, обмен с ней станет невозможен.
• Служебная информация: Современные механизмы БСП обмениваются данными о поддерживаемых версиях форматов в заголовке сообщения. При нарушении соответствия структур система может отклонить пакет на этапе первичной проверки.

Рекомендация по реализации

Для минимизации проблем при доработке обмена рекомендуем использовать Расширения конфигурации. Вынесите в расширение:

• Новый или измененный пакет XDTO.
• Модули менеджеров обмена, содержащие правила конвертации.

Это позволит вам обновлять основную конфигурацию, не теряя написанный код обмена. Однако помните: архитектурно «чистым» решением в КД 3.1 считается использование только типовых форматов. Любое отклонение — это осознанный технический долг, который потребует внимания при каждом обновлении конфигураций.

Если ваша задача — обмен между двумя самописными базами, оцените трудозатраты на КД 2.0. Возможно, это сэкономит вам время, избавив от необходимости постоянной поддержки целостности пакетов XDTO.