← На главную

При переходе с конфигурации «Конвертация данных 2.1» на «Конвертацию данных 3.0» разработчики часто сталкиваются с непониманием базовых принципов работы новой системы. Типичная ситуация: на руках есть привычный архив с файлами ExchangeRules.xml, CorrespondentExchangeRules.xml и RegistrationRules.xml, однако попытка загрузить их в базу КД 3.0 заходит в тупик. Разберем по шагам, почему эти файлы не подходят для КД 3.0, как устроен обмен через универсальный формат EnterpriseData и как правильно настроить интеграцию между базами.

В чем принципиальная разница между КД 2.0 и КД 3.0

Выясним причину, по которой файлы правил из архива невозможно напрямую использовать в КД 3.0:

1. Файлы ExchangeRules.xml и CorrespondentExchangeRules.xml — это готовые правила конвертации данных (ПКО, ПКС, алгоритмы), выгруженные исключительно из конфигурации «Конвертация данных 2.1». Механизм КД 2.0 основан на выгрузке правил в файл формата XML, который затем считывается универсальной обработкой или планом обмена БСП. В КД 3.0 концепция полностью изменена: правила конвертации формируются в виде чистого программного кода на встроенном языке 1С и помещаются непосредственно в общий модуль конфигурации.
2. Файл RegistrationRules.xml — это правила регистрации объектов на узлах плана обмена. В отличие от правил конвертации, правила регистрации по-прежнему используются подсистемой обмена данными БСП в виде XML. Их можно настраивать как в КД 2.0, так и в блоке правил регистрации КД 3.0, а затем загружать в макет соответствующего плана обмена или регистр сведений ПравилаДляОбменаДанными.

Таким образом, если перед нами стоит задача загрузить и отредактировать имеющиеся файлы ExchangeRules.xml, для этого обязательно потребуется развернуть информационную базу Конвертация данных 2.1. Конфигурация КД 3.0 с такими файлами правил конвертации не работает.

Где находится менеджер обмена в конфигурациях на базе БСП

Рассмотрим, как устроен механизм EnterpriseData внутри конфигурации. В КД 3.0 правила описывают трансформацию данных между метаданными конкретной базы и универсальной схемой XML (XDTO-пакетом EnterpriseData). Результатом работы в КД 3.0 является сгенерированный программный код, который встраивается в конфигурацию.

Для выполнения обмена БСП использует специальный общий модуль. В типовых решениях (например, 1С:ERP, 1С:Комплексная автоматизация, 1С:Управление торговлей) этот модуль обычно называется МенеджерОбменаЧерезУниверсальныйФормат (или имеет суффикс версии формата). Если же мы изучаем демонстрационную базу библиотеки стандартных подсистем (БСП), обратим внимание на имена объектов метаданных: в демо-базе БСП модуль называется с префиксом — _ДемоМенеджерОбменаЧерезУниверсальныйФормат.

Именно в этот модуль переносится код процедур инициализации правил конвертации (обработчики событий, таблицы соответствия объектов и свойств), сгенерированный обработкой выгрузки правил из КД 3.0.

Схема интеграции самописной конфигурации с типовой программой

Проанализируем задачу: одна база является полностью самописной, а вторая — типовой конфигурацией 1С, находящейся на официальной поддержке. Требуется настроить обмен данными между ними. Стоит ли использовать КД 3.0 в таком сценарии?

Это классический и наиболее эффективный сценарий для внедрения технологии EnterpriseData. Разберем его преимущества:

1. Типовую базу не нужно дорабатывать. В типовой конфигурации 1С уже есть готовый, отлаженный механизм загрузки и выгрузки универсального формата. Нам не придется создавать правила загрузки для сотен типовых реквизитов и табличных частей.
2. Правила разрабатываются только для одной базы. В КД 3.0 настраиваются правила только для связки: Метаданные самописной базы ↔ Схема EnterpriseData. База-приемник в проекте КД 3.0 вообще не участвует.
3. Простота отладки. Поскольку код правил находится внутри общего модуля, разработчик может использовать стандартные точки останова отладчика 1С в конфигураторе, что значительно ускоряет поиск ошибок по сравнению с интерпретируемым кодом в КД 2.0.

Пошаговый порядок настройки обмена в КД 3.0

Разберем по шагам последовательность действий при разработке синхронизации:

1. Подготовка самописной базы. В самописную конфигурацию необходимо внедрить подсистемы БСП «Обмен данными» и «Базовая функциональность», а также добавить план обмена для синхронизации с составом необходимых объектов.
2. Выгрузка структуры метаданных. С помощью специальной внешней обработки выгрузки (входит в комплект поставки КД 3.0) выгружаем структуру метаданных нашей самописной базы в файл XML.
3. Загрузка данных в КД 3.0. В базу КД 3.0 загружаем:
   • XDTO-пакет схемы универсального формата нужной версии (например, EnterpriseData_1_8_2);
   • Полученный XML-файл со структурой метаданных самописной конфигурации.
4. Создание правил конвертации. В КД 3.0 создаем правила выгрузки и загрузки объектов: сопоставляем документы и справочники самописной базы с соответствующими XDTO-типами формата EnterpriseData.
5. Перенос кода в конфигурацию. Обработкой выгрузки из КД 3.0 генерируем модуль обмена и вставляем полученный программный код в тело общего модуля менеджера обмена нашей самописной базы.
6. Настройка правил регистрации. При необходимости создаем правила регистрации объектов для плана обмена, чтобы в очередь на выгрузку попадали только нужные данные.

Что делать, если в самописной базе есть уникальные данные

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

1. Использование дополнительных реквизитов без изменения схемы. Большинство объектов универсального формата содержат узел ДополнительныеРеквизиты. В КД 3.0 можно настроить передачу нестандартных полей именно в эту структуру. Если база-приемник использует механизм дополнительных реквизитов БСП, данные заполнятся автоматически без снятия базы с поддержки.
2. Трансформация в схожие сущности. Нетиповой документ на уровне правил конвертации КД 3.0 можно сопоставить с универсальным типовым объектом формата (например, с операцией или базовым расчетным документом).
3. Расширение схемы EnterpriseData. Если конфигурацию-приемник разрешено дорабатывать, формат можно расширить через механизм расширений XDTO-пакетов. Однако в этом случае алгоритмы чтения нового XDTO-типа в модуле менеджера базы-приемника потребуется дописать вручную.