При проектировании интеграционных решений на платформе «1С:Предприятие» разработчики часто сталкиваются с дилеммой выбора формата обмена. В некоторых случаях заказчик ставит жесткое условие: предоставить строгое описание структуры передаваемых данных в виде XDTO-пакетов (XSD-схем) при использовании Web-сервисов. Однако у разработчика уже может быть готовый, отлаженный обмен, построенный на технологии «Конвертация данных 2.0» (КД 2). В этой статье мы подробно разберем, совместимы ли эти две технологии, почему возникает конфликт требований и как решить проблемы производительности обмена без тотального переписывания кода.
Для того чтобы понять суть проблемы, проанализируем внутреннее устройство обеих технологий. Они представляют собой принципиально разные подходы к сериализации данных:
exchange8.xsd (или v8exchange.xsd), но состав самих тегов внутри секции данных напрямую зависит от выгружаемых метаданных конфигурации и настроенных правил обмена (ПКО, ПКС). Если вы измените хотя бы одно правило или добавите реквизит, формат результирующего XML-файла изменится.Именно поэтому стандартная подсистема обмена данными БСП при использовании КД 2 не предполагает работу с индивидуальными XDTO-пакетами. Обмен идет файлами выгрузки стандартного формата, которые передаются через веб-сервисы в виде бинарных данных или простых строк.
Если заказчику требуется полноценный контрактный обмен на основе жестких XSD-схем (например, стандарт EnterpriseData), правильным стратегическим решением будет переход на «Конвертацию данных 3.0» (КД 3). Но что делать, если переписывать обмен с нуля нет времени, а требования заказчика или проблемы производительности нужно решать прямо сейчас? Рассмотрим практические обходные пути.
Если вам обязательно нужно формировать XML-структуру по схеме XDTO, но вы хотите сохранить логику регистрации изменений и транспорт КД 2, мы можем использовать гибридный подход. В этом случае КД 2 выступает «транспортом» и логическим центром, а сами данные упаковываются через XDTO-сериализатор платформы.
Рассмотрим по шагам, как это реализовать:
Шаг 1. В базе-источнике в обработчике ПКС «Перед выгрузкой» мы сериализуем объект 1С в строку XML по схеме XDTO и передаем ее в строковое свойство приемника:
// Сериализуем объект (например, справочник Организации) в формат XDTO
ОбъектXDTO = СериализаторXDTO.ЗаписатьXDTO(Источник);
ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.УстановитьСтроку();
ФабрикаXDTO.ЗаписатьXML(ЗаписьXML, ОбъектXDTO);
// Записываем полученную XML-строку в значение свойства КД 2
Значение = ЗаписьXML.Закрыть();
Шаг 2. В базе-приемнике в обработчике ПКС «После загрузки» (или «Перед записью») мы считываем эту строку и восстанавливаем из нее полноценный объект 1С:
// Восстанавливаем XML-строку обратно в объект через Фабрику XDTO
ЧтениеXML = Новый ЧтениеXML;
ЧтениеXML.УстановитьСтроку(Значение);
ОбъектXDTO = ФабрикаXDTO.ПрочитатьXML(ЧтениеXML);
ПолученныйОбъект = СериализаторXDTO.ПрочитатьXDTO(ОбъектXDTO);
// Далее выполняем заполнение и запись объекта приемника
// ...
Преимущества: Данные передаются в строгом соответствии со схемой XDTO, при этом сохраняется вся инфраструктура регистрации КД 2.
Недостатки: Теряется визуальная наглядность правил обмена в конфигураторе КД 2, усложняется отладка.
Зачастую требование заказчика использовать XDTO продиктовано не столько любовью к схемам, сколько жалобами на низкую скорость обмена и огромный размер пакетов при работе КД 2 через Web-сервисы. В реальном времени, когда баз много, а каналы связи в филиалах слабые, постоянная передача правил обмена и разбор тяжелого XML сильно нагружают систему.
Выясним, как мы можем кардинально ускорить текущий обмен КД 2 без перехода на КД 3.
Главная ошибка стандартных веб-сервисов на КД 2 — передача самого файла правил обмена (xml) при каждом сеансе связи. Это создает колоссальный и абсолютно бессмысленный трафик. Избавимся от этого:
Поскольку файлы обмена КД 2 — это обычные текстовые XML-структуры, они сжимаются архиваторами в 10–15 раз. Передача несжатого XML по сети — непозволительная роскошь.
Реализуем сжатие на стороне источника перед отправкой в веб-сервис:
// Упаковываем сформированный файл обмена КД 2 в ZIP
ИмяФайлаАрхива = ПолучитьИмяВременногоФайла("zip");
Архив = Новый ЗаписьZipФайла(ИмяФайлаАрхива);
Архив.Добавить(ИмяФайлаВыгрузки);
Архив.Записать();
// Читаем архив как двоичные данные
ДвоичныеДанныеАрхива = Новый ДвоичныеДанные(ИмяФайлаАрхива);
// Передаем через Web-сервис в параметре типа base64Binary
ЗначениеДляПередачи = ПолучитьСтрокуBase64ИзДвоичныхДанных(ДвоичныеДанныеАрхива);
На стороне приемника мы выполняем обратную операцию: принимаем строку Base64, преобразуем ее в двоичные данные, сохраняем как временный файл .zip, распаковываем его средствами встроенного языка ЧтениеZipФайла и загружаем чистый XML локально. Это снижает нагрузку на сеть на 90%.
Классические Web-сервисы 1С (работающие по протоколу SOAP) накладывают серьезные системные ограничения на производительность: парсинг тяжелых SOAP-конвертов (Envelope) отнимает много процессорного времени.
Проанализируем альтернативу: HTTP-сервисы работают напрямую с «телом» запроса (HTTP Body) без лишних оберток. Мы можем передавать сжатый ZIP-архив с XML-данными КД 2 обычным POST-запросом. Это ускоряет сериализацию и десериализацию на стороне сервера в разы, убирая накладные расходы веб-сервера.
Выбор оптимального пути зависит от долгосрочных целей вашего проекта: