Как настроить свой (нетиповой) обмен данными на базе КД 2.0 в современных конфигурациях 1С?

← На главную

Многие разработчики, привыкшие к простоте настройки обменов в старых конфигурациях, таких как «Управление торговлей 10.3», сталкиваются с проблемой при попытке внедрить нетиповой обмен на базе «Конвертации данных 2.0» в современные решения, например, в УТ 11.4. Проблема в том, что после создания нового плана обмена и правил для него, в стандартном интерфейсе синхронизации данных просто нет возможности выбрать этот новый обмен. Система предлагает только типовые варианты или обмены через формат Enterprise Data (КД 3.0).

Давайте разберемся, как правильно интегрировать свой план обмена в современные конфигурации, построенные на Библиотеке стандартных подсистем (БСП), и какие существуют альтернативные подходы.

Основное решение: Правильная интеграция с Библиотекой стандартных подсистем (БСП)

Ключевая особенность современных конфигураций — это то, что все механизмы обмена, включая их отображение в пользовательском интерфейсе, управляются подсистемой «Обмен данными» из БСП. Чтобы система «увидела» наш новый план обмена, мы должны явно его «зарегистрировать» в этой подсистеме. Просто создать объект в конфигураторе недостаточно. Проанализируем по шагам, что нужно сделать.

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

Доработка переопределяемого модуля. Самый важный шаг — это внесение изменений в общий модуль ОбменДаннымиПереопределяемый. Этот модуль специально предназначен для адаптации и расширения типового функционала обменов без изменения основного кода БСП. Нас интересует процедура ПриОпределенииПлановОбмена (в более старых версиях БСП могла называться ПолучитьПланыОбмена, но суть та же).

В этой процедуре нужно добавить описание нашего плана обмена в массив ПланыОбмена. Каждое описание — это структура, содержащая ключевую информацию для БСП.

Посмотрим на пример:

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


Процедура ПриОпределенииПлановОбмена(ПланыОбмена) Экспорт

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

    // Добавляем наш нетиповой план обмена
    СтруктураНастроек = Новый Структура;
    СтруктураНастроек.Вставить("ИмяПланаОбмена", "ОбменССамописнойКонфигурацией");
    СтруктураНастроек.Вставить("Представление", НСтр("ru = 'Обмен с самописной конфигурацией'"));
    СтруктураНастроек.Вставить("ИспользоватьПомощникСозданияНастройкиОбмена", Истина);
    СтруктураНастроек.Вставить("ИмяОбработкиМастераНастройки", "МастерНастройкиОбменаДанными");
    СтруктураНастроек.Вставить("ИмяМакетаПравилОбмена", ""); // Указываем, если правила в макете
    СтруктураНастроек.Вставить("ОбработчикЗагрузкиПравил", "ОбменДаннымиСервер.ЗагрузитьПравилаОбменаПоУмолчанию");
    
    // Важный флаг, который позволит загружать свои правила из файла
    СтруктураНастроек.Вставить("ВозможностьРучнойЗагрузкиПравил", Истина);
    
    ПланыОбмена.Добавить(СтруктураНастроек);

КонецПроцедуры

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

Дополнительные доработки. Чтобы все заработало корректно, может потребоваться еще несколько небольших правок. Например, чтобы работала кнопка «Загрузить комплект правил», нужно добавить имя нашего плана обмена в обработчик соответствующей глобальной команды (например, ЗагрузитьКомплектПравил). Также может потребоваться создать свои подписки на события для более тонкой настройки регистрации объектов.

Важно: Механизм подключения новых планов обмена подробно описан в документации к самой Библиотеке стандартных подсистем. Всегда полезно сверяться с ней при работе с актуальной версией БСП.

Альтернативный подход 1: Регламентное задание и универсальная обработка

Если нет желания или возможности вносить изменения в конфигурацию, можно пойти другим путем, который не интегрируется в стандартный интерфейс БСП, но решает задачу автоматического обмена. Этот метод можно назвать «классическим».

Используем план обмена для регистрации. План обмена все равно создается, но его единственная задача — отслеживать измененные объекты (механизм регистрации изменений).
Создаем обработку обмена. Пишется своя внешняя обработка, либо используется стандартная Универсальный обмен данными в формате XML. В этой обработке указывается наш узел обмена и файл с правилами, созданными в КД 2.0.
Настраиваем регламентное задание. Создается регламентное задание, которое по расписанию (например, каждый час) будет запускать нашу обработку обмена. Обработка будет выполнять выгрузку зарегистрированных изменений в файл, отправлять его (например, на FTP или по почте) и загружать ответный файл.
Очистка регистрации. Важный момент: в этом сценарии нужно самостоятельно позаботиться об очистке регистрации изменений после успешной выгрузки, чтобы не отправлять одни и те же данные повторно. Обычно это делается вызовом метода УдалитьРегистрациюИзменений.

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

Альтернативный подход 2: Переход на современные технологии

Стоит задуматься, а является ли КД 2.0 лучшим инструментом для поставленной задачи в современных реалиях? Рассмотрим более актуальные варианты.

КД 3.0 и формат Enterprise Data

Для интеграции типовых конфигураций с нетиповыми фирма «1С» предлагает технологию «Конвертация данных 3.0» и универсальный формат обмена Enterprise Data. Идея в том, что вам не нужно создавать прямые правила «УТ <-> Самописка». Вместо этого вы делаете только одни правила: «Самописка <-> Enterprise Data». А типовая конфигурация УТ уже «из коробки» умеет работать с этим форматом.

Преимущества:

Это стандартный, поддерживаемый фирмой «1С» механизм.
При обновлении УТ вам не нужно будет адаптировать правила, так как формат Enterprise Data стабилен.
В типовых конфигурациях уже есть готовые HTTP-сервисы и другие инструменты для работы с этим форматом.

HTTP-сервисы и JSON

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

Сценарий выглядит так:

На стороне УТ создается HTTP-сервис с методами, например, createProduct или postDocument.
Самописная конфигурация при изменении данных формирует JSON-объект и отправляет его HTTP-запросом на соответствующий метод сервиса в УТ.
Сервис в УТ принимает запрос, разбирает (десериализует) JSON и программно создает или изменяет нужные объекты (номенклатуру, документы).