Как организовать обмен данными между 1С:ERP и самописной конфигурацией?

← На главную

При интеграции 1С:ERP с самописными решениями часто возникает вопрос: какой механизм выбрать, если нужно передавать не все данные, а лишь ограниченный набор справочников с определенными фильтрами? В этой статье мы подробно разберем несколько стратегий обмена, от использования стандартных инструментов Библиотеки стандартных подсистем (БСП) до современных REST-технологий.

Вариант 1. Использование интерфейса OData (REST API)

Если нам необходимо максимально быстро получить данные из ERP, не внося изменений в ее конфигурацию, проанализируем возможности OData. Это автоматический интерфейс, который платформа 1С предоставляет для доступа к данным через HTTP. Для двух справочников это может быть самым быстрым решением.

Разберем последовательность действий:

Публикация базы: Настроим публикацию 1С:ERP на веб-сервере (IIS или Apache), установив флажок "Публиковать стандартный интерфейс OData".
Настройка состава: В коде или через специальную обработку укажем, какие именно справочники будут доступны. Это делается с помощью метода УстановитьСоставСтандартногоИнтерфейсаOData().
Запрос данных: Из самописной базы будем выполнять GET-запросы. Например, чтобы получить только определенные реквизиты и отфильтровать группы, используем параметры $select и $filter.

Рассмотрим пример формирования запроса из самописной конфигурации:


Соединение = Новый HTTPСоединение("server_address", , "user", "password");
Запрос = Новый HTTPЗапрос("/erp_base/odata/standard.odata/Catalog_Контрагенты?$select=Description,INN&$filter=IsFolder eq false");
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
    // Обработка JSON ответа
КонецЕсли;

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

Вариант 2. HTTP-сервис и JSON (Push-модель)

Если мы хотим, чтобы данные уходили в самописную базу сразу после записи в ERP, разберем вариант с созданием собственного HTTP-сервиса в базе-приемнике и подписки на события в ERP.

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

Проанализируем шаги реализации:

В самописной базе создаем HTTP-сервис с шаблоном для приема данных.
В ERP создаем Общий модуль и Подписку на событие ПриЗаписи для нужных справочников.
Внутри подписки проверяем условия (например, входит ли элемент в нужную группу) и сериализуем объект в JSON.

Пример кода для сериализации объекта в JSON в ERP:


ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
НастройкиСериализации = Новый НастройкиСериализацииJSON;
СериализоватьОбъект(ЗаписьJSON, Источник.Ссылка, НастройкиСериализации);
СтрокаJSON = ЗаписьJSON.Закрыть();

// Далее отправка через HTTPЗапрос в самописную базу

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

Вариант 3. Планы обмена и Конвертация данных 2.0 (КД2)

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

Разберем по шагам, как заставить этот механизм работать, если в самописной базе БСП "не видит" настройки:

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

Важный момент: использование планов обмена автоматически решает проблему удаления объектов. Если объект удален в ERP, в плане обмена зафиксируется "удаление объекта", и приемник сможет корректно обработать эту ситуацию.

Проблема настройки БСП в самописной конфигурации

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

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

Сравнение подходов: что выбрать?

Проанализируем ситуацию в зависимости от масштаба задачи:

Если данных очень мало (единицы в день): Подойдет OData или простой GET-запрос из приемника по расписанию. Это минимум кода и поддержки.
Если важна оперативность (Real-time): Оптимален HTTP-сервис в приемнике и Подписка на событие в ERP. Это обеспечит мгновенное обновление справочников.
Если данных много и важна надежность: Выбираем Планы обмена. Это позволит не потерять изменения при сбое связи и эффективно передавать только дельту (измененные данные).

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

Таким образом, для задачи выгрузки двух справочников из ERP в самописную базу наиболее сбалансированным решением будет создание HTTP-сервиса или использование плана обмена с правилами КД2, в зависимости от требований к фиксации удалений и объема передаваемых данных.