Синхронизация данных между 1С и внешними информационными системами — одна из самых востребованных задач современного разработчика. Часто возникает ситуация, когда для внешней базы данных уже поднят Rest Api (например, на базе протокола OData), и нам необходимо настроить обмен с 1С. Основная сложность заключается в том, что привычный многим инструмент «Конвертация данных 2.0» (КД 2.0) жестко завязан на метаданные двух баз 1С и обмен через файлы XML. В случае с произвольным REST-интерфейсом готового универсального решения «из коробки» в самой платформе не предусмотрено. Однако это не означает, что нам придется писать тысячи строк кода для разбора каждого JSON-пакета.
В этой статье мы разберем современные архитектурные подходы, которые позволяют максимально приблизиться к логике «правил конвертации» при работе с HTTP-сервисами, и выясним, какие инструменты помогут минимизировать рутину.
Если ваша задача — построить надежную и масштабируемую систему интеграции, мы рекомендуем обратить внимание на 1С:Шину. Это программный продукт, который выступает посредником (брокером) между различными информационными системами. В отличие от написания кода внутри конфигурации, настройка в «Шине» происходит визуально.
Рассмотрим, как это работает в контексте нашей задачи:
external_id из JSON внешней базы соответствует полю Идентификатор в 1С».Преимущество: Логика трансформации данных выносится за пределы кода конфигурации 1С. Это максимально близко к концепции «Конвертации данных», но реализовано на уровне сервисной шины.
Разберем подход, который предлагает сама фирма «1С» для современных версий платформы 1С v8.3. В отличие от КД 2.0, версия Конвертация данных 3.0 работает через универсальный формат обмена — EnterpriseData, основанный на XDTO.
Проанализируем алгоритм реализации:
XDTO-пакет, описывающий структуру данных внешнего API.XDTO-пакетом и внутренними объектами 1С (справочниками, документами).XDTO. Затем вызываем типовые механизмы БСП (Библиотеки стандартных подсистем), которые по правилам КД 3.0 автоматически создают или обновляют объекты в базе.Посмотрим на пример кода, как может выглядеть инициализация обмена через XDTO:
Чтение = Новый ЧтениеJSON;
Чтение.УстановитьСтроку(СтрокаJSONИзREST);
ДанныеXDTO = ФабрикаXDTO.ПрочитатьJSON(Чтение, ФабрикаXDTO.Тип("http://v8.1c.ru/edi/erp_exchange", "ExternalObject"));
// Далее данные передаются в механизм КД 3.0
ОбменДаннымиСервер.ВыполнитьЗагрузкуОбъектаПоПравилам(ДанныеXDTO);
Если внешняя база данных предоставляет интерфейс OData, мы можем использовать механизм платформы Внешние источники данных. Это позволяет работать с таблицами другой базы так, будто это обычные справочники 1С.
Разберем ситуацию подробнее. Штатно 1С подключается к внешним базам через ODBC. Существуют специальные драйверы (например, от компании CData или аналогичные решения на Python/Node.js, проксирующие запросы), которые «представляют» OData-интерфейс как обычный SQL-источник. Подключив такой источник, мы сможем использовать привычный Запрос к внешней базе и даже использовать СхемаКомпоновкиДанных для построения отчетов напрямую по внешнему API без написания кода обработки HTTP-запросов.
Если внешний API отдает данные в формате XML, мы можем применить технологию XSLT. Это мощный декларативный язык преобразования XML-документов. Вместо того чтобы писать цикл Для Каждого Строка Из Данные Цикл, мы создаем один файл правил (шаблон .xslt), который преобразует «чужой» XML в формат, понятный 1С (например, в формат сообщения обмена или в структуру, пригодную для СериализаторXDTO).
Выясним, как это реализовать в 1С:
Трансформация = Новый ПреобразованиеXSL;
Трансформация.ЗагрузитьИзСтроки(ТекстПравилXSLT);
РезультатXML = Трансформация.ПреобразоватьИзСтроки(ВходящийXMLОтREST);
// Теперь РезультатXML имеет структуру, которую 1С понимает "родными" методами
Преимущество: Высокая скорость обработки и четкое отделение правил маппинга от программного кода.
Современные REST-интерфейсы часто сопровождаются документацией в формате Swagger (OpenAPI). Существуют инструменты (генераторы кода), которые на основе этого файла могут автоматически создать модули 1С с описанием всех структур и методов внешнего API. Это избавляет программиста от ручного создания Структура и Соответствие для каждого запроса.
Проанализируем этот путь: мы получаем описание API в формате JSON, прогоняем его через скрипт-генератор, и на выходе получаем готовый общий модуль 1С, где для каждого метода API уже создана функция с типизированными параметрами. Нам остается только вызвать эти функции в нужных местах бизнес-логики.
Хотя прямой кнопки «Сделать как в КД 2.0 для REST» в конфигураторе 1С не существует, мы выяснили, что существует как минимум пять зрелых архитектурных подходов, позволяющих избежать «лапшекода»:
Выбор конкретного метода зависит от объема данных и ваших требований к гибкости настройки правил обмена. Мы рекомендуем начинать с анализа протокола обмена: если это OData, то механизмы 1С:Шины или XDTO-пакеты будут наиболее эффективным решением.