При работе с двумя информационными базами в системе 1С:Предприятие, одна из которых является типовой конфигурацией (например, 1С:Бухгалтерия 3), а другая — нетиповой (такой как "Аренда"), часто возникает задача по настройке обмена данными. Особенно это актуально, когда версии пакетов Enterprise Data (ED) XDTO существенно отличаются, и есть строгое требование не вносить изменения в типовую конфигурацию. Рассмотрим, как эффективно решить эту задачу, используя современные подходы и инструменты 1С.
Для начала, давайте разберемся, что такое XDTO пакет Enterprise Data и почему он так важен. XDTO пакет Enterprise Data в 1С:Предприятии — это мощный механизм, предназначенный для описания системы типов и значений, которые используются при обмене данными. Он позволяет нам работать не с низкоуровневыми узлами XML, а с более высокоуровневыми прикладными типами данных и встроенными типами платформы, что значительно упрощает разработку и поддержку обменов. Enterprise Data выступает как стандартизированное промежуточное звено, через которое конфигурации обмениваются информацией, особенно при использовании инструмента Конвертация Данных 3.0 (КД3).
Универсальный формат обмена Enterprise Data был создан для обеспечения гибкости и масштабируемости. Его ключевое преимущество состоит в том, что при изменении одной из конфигураций в схеме обмена, нам достаточно скорректировать лишь формат ED, вместо того чтобы переписывать множество XML-файлов правил для каждой пары конфигураций, как это часто бывало в КД2. Это делает ED идеальным решением для обмена данными не только между различными конфигурациями 1С, но и с внешними системами, способными работать с этим форматом.
Один из первоначальных вопросов, который может возникнуть, это: "Можно ли просто перенести пакет XDTO из одной конфигурации в другую и указать его в модуле менеджера плана обмена?" Ответ — нет, это не сработает напрямую. Мы выясним, почему.
Дело в том, что каждый XDTO-пакет, используемый для обмена, тесно связан с логикой преобразования данных, которая прописывается в специфических модулях конфигурации. В частности, для универсального формата обмена, эта логика содержится в модулях, таких как МодульМенеджераОбменаЧерезУниверсальныйФормат или МодульОбменДаннымиXDTO. Код в этих модулях не является универсальным; он уникален для каждой конкретной конфигурации, поскольку отражает её структуру метаданных и правила преобразования данных.
Этот код чаще всего не пишется вручную. Вместо этого он генерируется специализированным инструментом — Конвертацией Данных 3.0 (КД 3). Поэтому, просто скопировав XDTO-пакет, мы не перенесем соответствующую логику обмена, а попытки вручную написать этот код в модуле могут быть чрезвычайно трудоёмкими, подверженными ошибкам и сложными для поддержки, особенно при последующих обновлениях конфигураций.
Для решения нашей задачи основным инструментом станет Конвертация Данных 3.0 (КД 3). Это современное средство для настройки обмена данными, которое меняет подход по сравнению с предыдущими версиями:
КД 3 использует универсальный формат Enterprise Data как посредника.ED, а не переделывать правила для всех связей.КД 3 позволяет сгенерировать программный код для модулей менеджера обмена, который будет выполнять преобразование данных согласно разработанным правилам.Благодаря КД 3 мы можем разработать сложную логику обмена, которая будет корректно работать между типовой и нетиповой конфигурациями, не затрагивая при этом исходный код типовой БП 3.
Разберем процесс настройки обмена по шагам, ориентируясь на нашу задачу: обмен между типовой БП 3 (источник) и нетиповой "Арендой" (приемник), при этом БП 3 не должна быть изменена.
Если в вашей нетиповой конфигурации "Аренда" еще нет подсистемы "Обмен данными" из Библиотеки Стандартных Подсистем (БСП), то ее необходимо внедрить. Эта подсистема предоставляет базовый функционал для организации обмена информацией между базами, включая регистрацию изменений, механизмы транспорта данных и работу с универсальным форматом. Подсистема БСП</codebig> захватит с собой не только необходимые <code>XDTO</codebig>-пакеты, но и модули, которые служат основой для работы с обменом.</p>
<p><strong>Важный нюанс:</strong> Хотя внедрение этой подсистемы из <code>БСП считается одной из самых сложных задач для интеграции, она является фундаментом для современных механизмов обмена, в том числе через Enterprise Data.
Внедрение БСП обычно включает в себя:
КД.Перед началом разработки правил нам необходимо выяснить, какую версию формата Enterprise Data мы будем использовать. Для этого мы находим процедуру ДоступныеВерсииУниверсальногоФормата в обменивающихся конфигурациях (БП 3 и "Аренда"). Используем максимальную версию, которая присутствует в обеих конфигурациях, чтобы обеспечить совместимость и использовать наиболее актуальные возможности формата.
Принцип работы КД 3 кардинально отличается от КД 2. Вместо создания одного файла правил для каждой пары "источник-приемник", в КД 3 мы разрабатываем правила для источника и приемника отдельно.
КД 3 первым делом мы загружаем саму структуру универсального формата Enterprise Data, с которой будем работать.ED, который любой приемник (будь то другая типовая конфигурация 1С или наша "Аренда") мог бы без проблем обработать. Эти правила должны быть максимально универсальными и не должны содержать специфичной логики, завязанной на конкретного получателя. В случае с типовой БП 3, ее стандартный универсальный обмен уже настроен для выгрузки в Enterprise Data, поэтому нам не потребуется его дорабатывать.ED в объекты метаданных "Аренды". Здесь мы можем определить всю необходимую логику сопоставления и трансформации данных, специфичную для "Аренды". Это позволит нам адаптировать "Аренду" для приема данных из типовой БП 3, не внося никаких изменений в саму БП 3.Этот подход позволяет нам не трогать типовую БП 3 доработками. Мы лишь используем ее стандартные возможности по выгрузке в Enterprise Data, а всю адаптацию выполняем на стороне нетиповой "Аренды".
После того как правила обмена разработаны в КД 3, следующим шагом является генерация программного кода. КД 3 позволяет сгенерировать модуль менеджера обмена, который будет содержать всю логику, реализующую разработанные нами правила. Этот модуль, как правило, называется МодульМенеджераОбменаЧерезУниверсальныйФормат или похожим образом.
Enterprise Data. Нам не нужно генерировать для нее новый модуль или изменять существующий.Этот подход позволяет нам использовать возможности КД 3 для автоматического создания сложной логики обмена, избегая ручного написания кода, которое чревато ошибками и сложностями в поддержке.
После внедрения сгенерированных модулей и настройки плана обмена в "Аренде", критически важным этапом является тщательная отладка и тестирование. Мы рекомендуем:
Enterprise Data.XDTO (например, МодульОбменДаннымиXDTO), это, скорее всего, указывает на несоответствия в схемах XDTO, ошибках в правилах преобразования или в регистрации объектов для обмена. Подсистема БСП использует механизм регистрации с помощью подписок на события ПередЗаписью и ПередУдалением, которые вызывают процедуры общего модуля ОбменДаннымиСобытия для регистрации изменений. Убедитесь, что эти подписки настроены корректно для всех объектов, участвующих в обмене.Следует помнить, что данные из сообщения обмена загружаются в произвольном порядке, и к моменту регистрации нужных данных их может еще не быть. Если в обмене участвуют несколько логически связанных таблиц, логика регистрации должна фиксировать к выгрузке данные всех таких таблиц, независимо от того, для какой таблицы она выполняется в данный момент.
Хотя расширения в 1С:Предприятии являются мощным инструментом для адаптации типовых конфигураций без снятия с поддержки, их использование для добавления новых планов обмена или существенной модификации существующих механизмов обмена часто приводит к неразрешимым проблемам. Платформа 1С пока не предоставляет полной поддержки для такого сценария. Поэтому, для нашей нетиповой конфигурации "Аренда", предпочтительнее вносить изменения напрямую (если она не стоит на полной поддержке) или, как мы уже говорили, использовать генерацию КД 3 для создания новых модулей и планов обмена, которые будут существовать наряду с типовыми, не конфликтуя с ними.
Возможно также добавление XDTO-пакета в расширение конфигурации, чтобы расширить состав свойств объектов XDTO. Важно забрать в расширение все XDTO-объекты, которые планируется модифицировать, включая основные объекты формата, даже если в них не добавляется новых свойств.
Настройка обмена данными между типовой 1С:Бухгалтерией 3 и нетиповой конфигурацией с разными версиями XDTO Enterprise Data — это комплексная задача, которую эффективно решать с помощью Конвертации Данных 3.0 и подсистемы "Обмен данными" из БСП. Мы не можем просто перенести XDTO-пакет, так как вся логика обмена генерируется и является уникальной для каждой конфигурации.
Используя КД 3, мы разрабатываем правила отдельно для источника и приемника, что позволяет типовой БП 3 работать без изменений, выгружая данные в универсальный формат Enterprise Data. Вся адаптация и специфическая логика реализуется в нетиповой конфигурации "Аренда" через сгенерированные КД 3 модули. Это обеспечивает гибкость, управляемость и возможность масштабирования обмена в будущем, минимизируя риски при обновлении типовых решений.