Примерно три года назад я впервые столкнулась с задачей интегрировать две системы: ERP‑систему с 1С. На тот момент у меня не было ни опыта, ни документации, ни ментора, который сказал бы: «делай вот так». Были только задача и желание разобраться. Эта статья про мой опыт, совершенные ошибки и принятые решения. Надеюсь, она будет вам полезна и сэкономит вам время и нервы.
Архитектура интеграции
Как мы решили строить обмен
Задача звучала просто: нужно было организовать двусторонний автоматизированный обмен данными между ERP‑системой и 1С в разных конфигурациях: Бухгалтерия, Управление торговлей, Комплексная автоматизация, Розница.
Мы выбрали микросервисную архитектуру. Микросервис принимает запросы, трансформирует данные, обрабатывает файл загрузки из 1С и формирует файл выгрузки. Это позволило нам не трогать ядро ERP‑системы, чтобы при изменениях в интеграции — любая доработка касалась только микросервиса.
Почему два протокола — это нормально
Одно из первых решений, которое мы приняли — это использовать разные протоколы для выгрузки и загрузки данных.
Так как при выгрузке документов необходимо выгружать справочники, на которые ссылается выгружаемый документ, то для выгрузки из ERP в 1С мы выбрали GraphQL:
-
Гибкость в построении запросов: позволяет получать большие массивы данных одним запросом, а в интеграции с 1С для выгрузки одного документа необходимо запрашивать данные из нескольких таблиц
-
Позволяет использовать узлы для выгрузки связанных документов и справочников (например, документ заказ покупателя содержит товары, контрагента и организацию, данные о которых необходимо выгружать в связке с заказом покупателя)
-
Позволяет запрашивать только нужные поля (иногда для выгрузки справочника достаточно выгрузить только обязательные поля)
Для загрузки данных из 1С в ERP мы выбрали REST API:
-
REST поддерживает создание, изменение и удаление данных (в отличие от GraphQL, который работает только на чтение)
Вывод: не нужно выбирать один инструмент на все случаи. Используйте сильные стороны каждого. Существуют интеграции, в которых используются и GraphQL, и REST API для выгрузки данных (например, один справочник запрашивается с помощью GraphQL, а другой — REST API). Все зависит от особенностей интеграции и реализуемых бизнес‑процессов.
Маппинг данных — одна из самых сложных частей
Маппинг данных — это когда ты пытаешься объяснить системе: «Вот это поле в ERP соответствует вот этому полю в 1С». И если у тебя 50 полей, а у 1С — 50 других полей с другой логикой, эта задача становится нетривиальной.
Я столкнулась с тем, что разные конфигурации 1С живут своей жизнью. То, что работает в «Бухгалтерии», может не работать в «Управлении торговлей». Один документ может по‑разному выгружаться в разные конфигурации 1С.
Подход к задаче маппинга
Сначала я составила таблицу соответствия документов и справочников для каждой конфигурации отдельно. Затем составила аналогичную таблицу соответствия полей. Потом нашла общий знаменатель — минимальный набор документов и справочников, который есть во всех конфигурациях и выгружается одинаково. Аналогично с полями в документах. Для специфичных справочников/документов сделала отдельную обработку, но таких, как правило, было не так много.
Главный урок: если ты не продумаешь маппинг на этапе анализа, ты будешь переписывать его на этапе тестирования. А это дорого и больно.
EnterpriseData — что это и как с ним работать
EnterpriseData — это универсальный XML‑формат для обмена бизнес‑данными, разработанный фирмой 1С.
Главная идея: формат описывает бизнес‑сущности (документы, справочники) в виде, понятном и ERP, и 1С.
Ключевая особенность: формат не зависит от структуры конкретной информационной базы. Этот формат является универсальным и позволяет обмениваться данными между разными системами и конфигурациями 1С, не перестраивая их архитектуру.
Информация для справки: Сейчас формат EnterpriseData имеет более 10 версий. Как правило, глобальные изменения в формате наблюдаются редко. В основном это изменения добавочного характера, то есть появляется поддержка нового необязательного поля в одном или нескольких документах, реже: какое‑либо поле в новых версиях начинает описывается в виде отдельного справочника.
Как работает обмен через EnterpriseData
Схема обмена через формат EnterpriseData:
-
Стороннее приложение формирует XML‑файл в формате EnterpriseData
-
В заголовке файла указывается служебная информация (кто отправил, порядковые номера получаемого и отправляемого файлов, время отправки, GUID интеграции, список документов, участвующих в обмене)
-
Файл передаётся в 1С одним из следующих способов:
-
файловый каталог
-
FTP (Микросервис кладет файл на FTP, 1С обращается к FTP, обрабатывает файл и загружает ответный файл с данными)
-
веб‑сервис
-
-
1С обрабатывает файл и формирует файл‑ответ о с сообщением о том, что данные приняты или не приняты. Также если в 1С есть измененные или новые документы/справочники, то 1С отправляет данные о них в этом же файле‑ответе
Важные нюансы:
-
Если вам нужна только односторонняя передача (например, из интернет‑магазина в «1С: Бухгалтерию»), можно использовать упрощённый вариант: реализовать выгрузку XML‑файла из ERP, далее загружать его вручную
-
Важно учитывать при выборе конфигурации для клиента: Фреш‑версии 1С поддерживают только ручную загрузку файла, то есть идея реализации автоматизированной выгрузки и обмена в обе стороны отпадает
Практический пример: структура EnterpriseData
Документ в формате EnterpriseData описывается через XML‑схему. Вот упрощённая структура для справочника Номенклатура
<Справочник.Номенклатура> <КлючевыеСвойства> <Ссылка>0c8913dd-ea5e-11e0-a0cd-e1cb4ed5f6e4</Ссылка> <НаименованиеПолное>Обычный товар</НаименованиеПолное> <КодВПрограмме>00-089100</КодВПрограмме> <Артикул>000321</Артикул> <Наименование>Обычный товар</Наименование> <Группа> <Ссылка>0c8813d8-ea5e-11e0-a7cd-e0cb4ed5f6e4</Ссылка> <Наименование>Товары</Наименование> <КодВПрограмме>00-891</КодВПрограмме> <Группа> <Ссылка>fad620c2-c719-11e4-9ec3-bcaec56cc100</Ссылка> <Наименование>Торговая деятельность</Наименование> <КодВПрограмме>00-89</КодВПрограмме> </Группа> </Группа> </КлючевыеСвойства> <ТипНоменклатуры>Товар</ТипНоменклатуры> <ЕдиницаИзмерения> <Ссылка>2609357a-c180-90e4-a7a9-123d884fd00d</Ссылка> <ДанныеКлассификатора> <Код>01</Код> <Наименование>Штука</Наименование> </ДанныеКлассификатора> </ЕдиницаИзмерения> <СтавкаНДС>НДС22</СтавкаНДС> <ДанныеАлкогольнойПродукции> <АлкогольнаяПродукция>false</АлкогольнаяПродукция> <ВидАлкогольнойПродукции xsi:nil="true" /> <ИмпортнаяАлкогольнаяПродукция>false</ИмпортнаяАлкогольнаяПродукция> <ОбъемДАЛ xsi:nil="true" /> <ПроизводительИмпортер xsi:nil="true" /> <Крепость xsi:nil="true" /> </ДанныеАлкогольнойПродукции> <КодТРУ xsi:nil="true" /> <ЦеноваяГруппа> <Ссылка>0ae4894e-ef12-11e4-92f1-0000008b35ac</Ссылка> <Наименование>Обычные товары</Наименование> </ЦеноваяГруппа> <ВидНоменклатуры> <Ссылка>0c6013c6-ea5e-11e0-a7cd-e0cb4ed5f6e4</Ссылка> <Наименование>Товары обычные</Наименование> <ТипНоменклатуры>Товар</ТипНоменклатуры> <ИспользоватьСерии>true</ИспользоватьСерии> <ИспользоватьСрокГодностиСерии>false</ИспользоватьСрокГодностиСерии> <ИспользоватьХарактеристики>false</ИспользоватьХарактеристики> </ВидНоменклатуры> <ПризнакПредметаРасчета>Товар</ПризнакПредметаРасчета> <Весовой>false</Весовой> <Маркируемый>false</Маркируемый> <ПодакцизныйТовар>false</ПодакцизныйТовар> <ПрослеживаемыйТовар>false</ПрослеживаемыйТовар> <ОбщиеСвойстваОбъектовФормата> <ДополнительныеРеквизиты> <Строка> <ЗначениеСвойства> <ЗначениеДополнительногоРеквизитаСсылка> <Наименование>5</Наименование> <Ссылка>0c6013cc-ea5e-98e0-a7cd-e0cb4ed5f6e4</Ссылка> <Владелец> <Наименование>Число элементов</Наименование> <Ссылка>0c0000c7-ea5e-11e0-a7cd-e0cb4ed5f6e4</Ссылка> <ЭтоДополнительноеСведение>false</ЭтоДополнительноеСведение> </Владелец> </ЗначениеДополнительногоРеквизитаСсылка> </ЗначениеСвойства> <Свойство> <Наименование>Число элементов</Наименование> <Ссылка>0c0000c7-ea5e-11e0-a7cd-e0cb4ed5f6e4</Ссылка> <ЭтоДополнительноеСведение>false</ЭтоДополнительноеСведение> </Свойство> </Строка> </ДополнительныеРеквизиты> </ОбщиеСвойстваОбъектовФормата></Справочник.Номенклатура>
Каждый объект (любой документ или справочник) содержит тег <КлючевыеСвойства>, который содержит в себе основные параметры объекта. Кроме того, этот тег содержит тег <Ссылка>, в котором хранится guid — идентификатор объекта, по которому система идентифицирует объект. Если объект уже выгружался ранее, то далее необходимо выгружать этот объект с тем же guid, чтобы избежать дублирования.
Грабли, на которые мы наступали
№ 1 Разные конфигурации 1С — разные правила
Каждая конфигурация имеет свою логику документооборота. Например, в 1С‑Бухгалтерия нет документа Заказ клиента, но он есть в 1С‑Управление Торговлей (УТ). Если взять один и тот же документ и выгрузить его в формате EnterpriseData как <Документ.ЗаказКлиента>, то в 1С‑Бухгалтерию этот документ выгрузится как Счет покупателю, а в 1С‑УТ — Заказ клиента.
Решение: Указывать в какую конфигурацию 1С выгружаются данные, чтобы система понимала как описать ей тот или иной документ.
№ 2 Версии формата EnterpriseData
Клиент обновил 1С, вместе с которой и обновился формат обмена EnterpriseData до 1.15 версии, а ERP продолжала обмениваться в 1.11 версии.
Решение: Формат постоянно обновляется. Необходимо не обновлять формат, именно добавлять поддержку новых форматов для поддержки интеграции у всех пользователей.
№ 3 Избыточная синхронизация
В типовом обмене 1С отправляет на загрузку все документы, в том числе и те, которые не участвуют в бизнес‑процессе.
Решение: Микросервис обрабатывает только нужные документы, игнорируя остальные. Но данное решение не совсем оптимально, так как 1С тратит время и ресурсы на выгрузку всех данных. Поэтому в настройках интеграции на стороне 1С в настройках интеграции можно выбрать список типов документов, которые будут выгружаться из 1С.
Заключение
Интеграция с 1С — это всегда про большие данные. Файлы обмена могут быть огромными. Документов — тысячи. Справочников — десятки тысяч записей. Всё это одновременно загружает систему, и если не продумать архитектуру, она просто встанет.
Микросервисная архитектура в этом случае является оптимальным вариантом. Выделенный сервис‑посредник берёт на себя всю нагрузку по обработке файлов: он получает данные из ERP, преобразовывает их в формат EnterpriseData XML‑файл, считывает файл‑ответ от 1С и обновляет данные в ERP. Ядро ERP при этом не тормозит, не перегружается и продолжает работать стабильно. Любые доработки касаются только микросервиса — это снижает риски для всей системы.
Формат EnterpriseData — отдельная история. Он сложный для восприятия. В нём много тегов, вложенных элементов, правил. Но у него есть два важных преимущества. Во‑первых, он универсален — подходит для любых конфигураций 1С. Во‑вторых, его не нужно переписывать каждый раз. Поддерживать EnterpriseData несложно: достаточно отслеживать новые версии и добавлять поддержку новых полей. Это понятная, предсказуемая работа.
Если коротко: выбирайте микросервисы, чтобы выдержать нагрузку. Используйте EnterpriseData, чтобы не переписывать интеграцию с нуля под каждую конфигурацию.
ссылка на оригинал статьи https://habr.com/ru/articles/1050250/