← На главную

Работа с обменами в КД 3.0 часто ставит перед разработчиком сложные задачи, особенно когда возникает необходимость добавить в обмен объект, которого изначально не было в формате EnterpriseData. Рассмотрим подробнее, как подойти к этой задаче, оценим риски и разберем доступные стратегии реализации.

Понимание ограничений формата EnterpriseData

Прежде всего, важно уяснить, что КД 3.0 — это архитектурное решение, базирующееся на жестком контракте между системами. Формат EnterpriseData (ED) является единым стандартом. Механизм AdditionalInfo, который часто упоминается в документации, предназначен для передачи дополнительных реквизитов внутри уже существующих объектов, но он не позволяет «подложить» в обмен целый новый справочник.

Вариант 1: Прямая модификация пакета XDTO

Самый очевидный, но трудоемкий путь — это правка пакета XDTO. Если мы выбираем этот путь, нам необходимо:

1. Внести изменения в пакет EnterpriseData, добавив в него новый тип справочника.
2. Актуализировать правила конвертации данных, чтобы они учитывали новый объект.
3. Провести доработку алгоритмов сериализации и десериализации.

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

Вариант 2: Использование правил КД 2.1 для нестандартных задач

Если справочник является специфическим, самописным или редко меняющимся, часто нецелесообразно «ломать» формат EnterpriseData. Рассмотрим вариант гибридного обмена:

• Типовые документы и справочники продолжаем передавать через КД 3.0.
• Для нового справочника создаем отдельный план обмена или внешнюю обработку, работающую на правилах КД 2.1 (формат XML).

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

Вариант 3: Маппинг (переиспользование) существующих объектов

Иногда можно пойти по пути «подмены». Если в структуре EnterpriseData уже существует справочник, который по своей сути близок к вашему (например, какой-то универсальный классификатор или справочник дополнительных сведений), его можно использовать как «транспортный контейнер».

Рассмотрим по шагам логику реализации такого обмена:

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

Этот способ требует очень аккуратной работы с Правилами конвертации, но он позволяет обойтись без правок XDTO.

Анализ рисков и рекомендации

При выборе метода передачи нового объекта мы всегда должны задавать себе вопрос: «Как часто этот объект будет меняться?» Если обмен постоянный и структура справочника нестабильна, правка XDTO — это «путь в никуда», так как затраты на поддержку быстро превысят стоимость разработки. В таком случае, лучше выносить обмен специфических данных во внешние механизмы или использовать КД 2.1.

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