Прекращение поддержки xml-обменов в 1С

Что меняется в обменах 1С

Фирма «1С» постепенно отказывается от механизма регулярных обменов, построенных на правилах конвертации XML. Изменения затрагивают Библиотеку стандартных подсистем и Библиотеку синхронизации данных, а вместе с ними — современные типовые конфигурации, использующие соответствующие механизмы. В частности, планируется исключение обработки «КонвертацияОбъектовИнформационныхБаз», которая является частью классического подхода к обменам по правилам XML.

Для разработчиков и администраторов 1С здесь важно правильно понять саму суть изменения. Речь не идет о полном запрете XML. Формат продолжит использоваться в некоторых сценариях, а сама технология XML не исчезает из платформы.

Проблема касается именно регулярных обменов, построенных на правилах конвертации XML, которые обычно называют КД2. Если такой обмен сегодня ежедневно передает данные между двумя информационными базами, рассчитывать на его бесконечную работу после обновлений БСП уже не стоит. Такой сценарий необходимо заранее пересмотреть.

Почему 1С уходит от классических XML-правил

У технологии КД2 есть очевидный недостаток: правила обмена тесно связаны со структурой конфигураций. Разработчик фактически описывает, как объекты одной базы преобразовать в объекты другой базы, какие реквизиты переносить, как искать соответствия и какие преобразования выполнять.

Поэтому изменение метаданных в одной из баз способно повлиять на весь обмен. Обновили конфигурацию — изменился объект, реквизит или структура данных — и существующие правила могут потребовать корректировки.

Для сопровождения крупных информационных систем это становится серьезной проблемой. Обменов может быть десятки, конфигурации регулярно обновляются, а каждое изменение требует проверки совместимости правил.

Еще одна причина — сопровождение и безопасность

Классический механизм обмена постепенно перестал соответствовать тому подходу, который «1С» использует в новых технологиях синхронизации.

Отдельный вопрос связан с программным кодом внутри правил конвертации. При выполнении обмена такой код может использовать механизмы Выполнить() и Вычислить(). В зависимости от сценария это создает дополнительные риски с точки зрения контроля выполняемого кода и безопасности серверного приложения.

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

XML полностью не исчезает

Здесь есть важный нюанс, который легко упустить из-за формулировки «1С прекращает поддержку XML».

XML как формат остается. В частности, фирма «1С» сохраняет внешнюю обработку «УниверсальныйОбменДаннымиXML». Она предназначена прежде всего для разовых операций.

Например, если необходимо один раз перенести данные между базами, выполнить первоначальную загрузку или передать определенный набор информации, универсальный XML-обмен по-прежнему может использоваться.

То есть ситуация выглядит не так:

«XML больше не будет работать».

Правильнее говорить:

регулярный обмен по классическим правилам конвертации XML выводится из стандартного механизма 1С, а разовые операции через универсальный XML-обмен сохраняются.

Это принципиальная разница.

Что будет с разовыми переносами

Для разовых миграций ситуация значительно спокойнее.

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

Готовые обработки для начального переноса также ориентированы на этот сценарий. Поэтому сам по себе отказ от регулярных XML-обменов не означает, что привычные инструменты миграции данных внезапно перестанут существовать.

Основное изменение касается другого класса задач — когда обмен должен работать постоянно и автоматически: например, каждый час передавать заказы, остатки или документы из одной базы в другую.

Вариант первый: перейти на EnterpriseData

Для новых регулярных обменов фирма «1С» предлагает использовать формат EnterpriseData.

EnterpriseData тоже основан на XML, но принцип его работы отличается от классических правил КД2. В центре находится не структура конкретной конфигурации, а унифицированное представление бизнес-объектов.

Упрощенно схему можно представить так:

База А → EnterpriseData → База Б

При этом обе информационные базы работают с единым форматом. Не требуется создавать отдельное описание преобразования непосредственно между внутренними структурами каждой конкретной пары конфигураций.

Когда EnterpriseData действительно удобен

Если обмен строится между распространенными типовыми конфигурациями — например, УТ, БП, ЗУП, ERP, КА или Розницей, — первым делом стоит проверить возможность использования EnterpriseData.

Современные типовые решения 1С уже поддерживают этот формат, поэтому во многих стандартных сценариях не требуется создавать обмен с нуля.

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

Как попробовать перейти на EnterpriseData

Начинать миграцию имеет смысл не с полного отказа от старого обмена, а с тестирования.

• Шаг 1. Определите, какие данные реально передаются между базами.
• Шаг 2. Проверьте, представлены ли необходимые объекты и реквизиты в EnterpriseData.
• Шаг 3. Настройте тестовый обмен и сравните результат с текущим XML-обменом.
• Шаг 4. Отдельно проверьте нестандартные документы, дополнительные реквизиты и специфическую бизнес-логику.

В Библиотеке синхронизации данных предусмотрен механизм перехода существующих настроек на новый вариант обмена. Но полностью автоматического решения для любого нестандартного обмена ожидать не стоит: сначала нужно убедиться, что EnterpriseData действительно покрывает конкретный сценарий.

Если EnterpriseData не подходит

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

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

Один из вариантов — написать собственный обмен.

В источнике регламентное задание будет отбирать новые и измененные данные, формировать пакет и передавать его получателю. В качестве формата можно использовать XML, JSON, CSV или другой согласованный вариант.

Получающая база принимает пакет, разбирает его и выполняет необходимые преобразования. При этом разработчик самостоятельно определяет, как искать соответствия справочников, что делать с ошибками и как фиксировать результаты.

Собственный обмен дает свободу, но требует разработки

При таком подходе придется самостоятельно решить достаточно много задач:

• определять изменившиеся объекты;
• реализовать выгрузку и загрузку;
• организовать транспорт данных;
• вести журнал обмена;
• обрабатывать ошибки;
• реализовать повторную отправку;
• контролировать дублирование;
• организовать первоначальную загрузку;
• поддерживать механизм после изменений в конфигурации.

Поэтому собственный механизм оправдан тогда, когда стандартные технологии действительно не подходят.

Если же существующий обмен на КД2 уже работает и устраивает бизнес, переписывать его только ради самого факта перехода на другую технологию может быть не самым рациональным решением.

Что делать с уже работающим XML-обменом

И здесь появляется третий вариант — МС:Автообмен от MoscowSoft.

Если у вас уже есть готовые правила конвертации КД2, но нет желания самостоятельно разрабатывать новый механизм регулярного запуска обмена, необязательно сразу переписывать всю интеграцию.

МС:Автообмен позволяет автоматизировать регулярный обмен по существующим правилам XML.

Это особенно актуально для ситуаций, когда текущий обмен технически устраивает, но его нужно запускать автоматически по расписанию.

Подробнее о МС:Автообмен

Как работает МС:Автообмен

Принцип достаточно простой: существующие правила КД2 остаются основой обмена, а МС:Автообмен берет на себя его регулярный запуск.

В конфигурации задаются подключения к информационным базам, выбираются необходимые правила обмена и настраивается расписание.

Например, можно организовать сценарий, при котором изменения выгружаются и загружаются каждый час. Пользователю не требуется каждый раз вручную запускать «УниверсальныйОбменДаннымиXML».

Получается следующая схема:

База А → правила КД2 → МС:Автообмен → База Б

При этом сами базы не требуется дорабатывать только для того, чтобы организовать запуск обмена по расписанию.

Главное преимущество — не нужно сразу переписывать работающий обмен

Представим типичную ситуацию.

Компания несколько лет использует обмен между двумя базами. Правила КД2 уже разработаны, протестированы и учитывают множество особенностей конкретной конфигурации.

После новости об изменениях со стороны 1С возникает вопрос: что делать?

Можно полностью переписать обмен на EnterpriseData. Можно разработать собственный механизм. А можно сохранить существующие правила и вынести автоматизацию их запуска в отдельное решение.

Для многих проектов третий вариант оказывается гораздо менее трудоемким.

Особенно если обмен сложный, но при этом бизнес не требует срочного перехода на новую архитектуру.

МС:Автообмен находится на поддержке разработчика

Еще один практический момент — наличие поддержки продукта со стороны разработчика.

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

МС:Автообмен — готовый продукт MoscowSoft, который развивается и поддерживается разработчиком.

Поэтому его можно рассматривать не просто как «обработку для запуска XML», а как способ вынести задачу автоматизации обмена из собственного проекта и не поддерживать соответствующую инфраструктуру самостоятельно.

Что нужно для работы МС:Автообмен

Есть важное ограничение: МС:Автообмен не создает правила конвертации КД2 автоматически.

Если между двумя базами нет правил, описывающих преобразование данных, сначала необходимо разработать их или использовать готовые правила.

Зато если КД2 уже существует, МС:Автообмен может использовать эти правила для автоматического выполнения обмена.

Поэтому перед внедрением стоит разделить две задачи:

• Правила КД2 определяют, какие данные и каким образом преобразуются.
• МС:Автообмен автоматизирует регулярное выполнение этого обмена.

Это разные уровни одной задачи, и смешивать их не стоит.

Настройка регулярного обмена

Общий сценарий можно представить следующим образом.

• Шаг 1. Установить МС:Автообмен.
• Шаг 2. Создать регламентный обмен между базами.
• Шаг 3. Указать необходимые правила конвертации КД2.
• Шаг 4. Настроить способ передачи данных.
• Шаг 5. Задать расписание выполнения — например, раз в час или один раз в сутки.
• Шаг 6. Запустить обмен и контролировать результаты выполнения.

Таким образом, пользователь получает регулярную автоматическую обработку существующего обмена вместо постоянного ручного запуска.

Когда МС:Автообмен особенно полезен

На практике решение стоит рассматривать в первую очередь в трех случаях.

Первый — есть работающий обмен КД2. Правила уже разработаны и проверены, поэтому нет смысла немедленно переписывать всю бизнес-логику.

Второй — требуется регулярный запуск. Данные необходимо синхронизировать по расписанию, а не загружать вручную.

Третий — нет желания самостоятельно разрабатывать инфраструктуру обмена. Вместо собственной обработки, регламентных заданий, журналирования и дополнительной логики можно использовать готовый продукт, который поддерживает разработчик.

При этом переход на EnterpriseData никуда не исчезает из списка вариантов. Для новых интеграций и стандартных обменов между типовыми конфигурациями это по-прежнему направление, которое имеет смысл рассматривать в первую очередь.

Какой вариант выбрать

Универсального ответа здесь нет. Выбор зависит прежде всего от того, что именно уже работает в информационной системе.

Если нужно организовать новый регулярный обмен между типовыми конфигурациями, логично начать с EnterpriseData.

Если данные специфичны, конфигурации сильно доработаны и стандартные форматы не закрывают необходимые сценарии, можно рассматривать собственную разработку.

Если же существует готовый и проверенный обмен на КД2, который пока нет смысла переписывать, практичным вариантом может стать МС:Автообмен. Он позволяет сохранить существующие правила XML и автоматизировать их регулярное выполнение, причем продукт находится на поддержке у разработчика.

Что делать владельцам XML-обменов уже сейчас

Самое неудачное решение — просто ждать, пока очередное обновление покажет, что обмен больше не работает.

Гораздо разумнее провести инвентаризацию.

• Шаг 1. Найдите все регулярные обмены. Составьте список информационных баз, между которыми выполняется синхронизация.
• Шаг 2. Определите технологию каждого обмена. Отдельно выделите обмены КД2, EnterpriseData и собственные механизмы.
• Шаг 3. Разделите регулярные и разовые операции. Разовые переносы не требуют такой же срочной перестройки, как постоянные синхронизации.
• Шаг 4. Для типовых обменов проверьте EnterpriseData. Возможно, часть существующих интеграций уже можно перевести на стандартный механизм.
• Шаг 5. Для сложных КД2 оцените стоимость переписывания. Иногда разработка нового обмена действительно оправдана. Но если правила создавались годами и содержат большое количество специфической логики, такой переход может потребовать значительных ресурсов.
• Шаг 6. Рассмотрите МС:Автообмен как промежуточный или долгосрочный вариант. Если задача заключается именно в том, чтобы продолжить использовать имеющиеся XML-правила без ручного запуска, готовое решение может оказаться существенно проще собственной разработки.

Не забудьте про тестовый контур

Перед обновлением БСП или БСД обязательно стоит проверить работу обменов на тестовой базе.

Особенно важно протестировать сценарий с той версией библиотек, в которой ожидается удаление соответствующих механизмов. Нужно проверить не только факт запуска обмена, но и конечный результат: состав переданных объектов, соответствия справочников, документы, суммы, остатки и обработку ошибок.

Если обмен критичен для бизнеса, лучше заранее иметь понятный план перехода, а не искать решение уже после неудачного обновления рабочей базы.

Какие технические изменения ожидаются

Если свести изменения к нескольким пунктам, картина выглядит следующим образом:

• из стандартных библиотек удаляется механизм регулярного обмена по правилам конвертации XML;
• обработка «КонвертацияОбъектовИнформационныхБаз» должна исчезнуть из соответствующих версий;
• связанные с классическим XML-обменом API и объекты будут постепенно помечаться устаревшими и исключаться из новых версий БСП и БСД;
• «УниверсальныйОбменДаннымиXML» сохраняется для разовых операций;
• для регулярной синхронизации фирма «1С» рекомендует EnterpriseData;
• существующие XML-обмены можно либо перевести на новый механизм, либо заменить собственной разработкой;
• еще один вариант для уже существующих КД2 — автоматизировать их выполнение с помощью МС:Автообмен.

Планируемые изменения связаны с версиями Библиотеки синхронизации данных и Библиотеки стандартных подсистем. Конкретные сроки зависят от выхода прикладных релизов, поэтому ориентироваться только на номер версии библиотеки без проверки актуальной информации перед обновлением не стоит.

Главное — не путать отказ от КД2 с отказом от XML

Для специалиста 1С это, пожалуй, главный вывод.

XML как формат никуда не исчезает. Меняется место, которое XML-обмен занимает в архитектуре типовых решений 1С.

Для разовых переносов остается универсальный XML-обмен. Для новых регулярных интеграций развивается EnterpriseData. Для специфических задач остается возможность самостоятельной разработки.

А если в системе уже есть работающий обмен КД2 и задача заключается не в полной перестройке интеграции, а в том, чтобы продолжить автоматически выполнять существующие правила, стоит отдельно рассмотреть МС:Автообмен.

Это позволяет не бросаться сразу в переписывание большого обмена, а решить конкретную практическую задачу — автоматизировать регулярное выполнение уже существующих XML-правил — с использованием готового продукта, который поддерживается разработчиком.

МС:Автообмен на сайте sky1c.ru

Что делать дальше

Оптимальная стратегия — не выбирать технологию «на будущее» вслепую, а сначала разобрать существующие обмены.

Для каждого из них стоит ответить на три вопроса: можно ли его перевести на EnterpriseData, насколько дорого будет переписать его самостоятельно и можно ли сохранить текущие правила КД2 с помощью МС:Автообмена.

В результате часть обменов, вероятно, имеет смысл перевести на EnterpriseData, часть — оставить на существующих правилах с автоматизацией, а для наиболее специфичных сценариев разработать собственный механизм.

Главное — провести эту работу до того, как обновление поставит вас перед фактом.

Если у вас уже есть XML-обмены КД2 и вы не уверены, какой вариант будет рациональнее именно для вашей конфигурации, можно обратиться к специалистам MoscowSoft за консультацией, аудитом существующих обменов или настройкой МС:Автообмена.

Следите за новыми материалами sky1c.ru — разбираем изменения платформы 1С, интеграции и практические задачи разработки без лишней теории.