Правильная интеграция «1С» с другими системами

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

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

Особенности организации данных в «1С»: задача со множеством переменных

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

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

Как результат — структура данных становится ещё более специфичной и уникальной.

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

Возникает необходимость разобраться со следующими нюансами.

1. К какой системе будет относиться сама интеграция: к «1С» или ко второму «участнику процесса»? От этого зависит, какая из команд разработки будет создавать и перерабатывать интеграцию и на какую систему ляжет нагрузка.
2. В каком формате должны быть переданы и приняты данные? Разные системы потребляют данные в разных форматах. «1С:ERP Управление предприятием» — в EnterpriseData (основан на XML), а, например, Axapta — тоже в XML, но в «чистом». Вроде бы различия минимальны, но они могут повлиять на качество данных. И либо в системе-приёмнике, либо в системе — источнике данных необходимо будет настроить конвертацию в нужный формат.
3. Какие именно данные нужно забирать и отправлять? Как правило, системе-приёмнику не нужно «всё, везде и сразу» — только отдельные поля или записи за определённый период времени. Нужно определить, что это за поля, отделить их от общего массива данных и направить в соответствующие слоты приёмника.
4. Какие именно атрибуты сущности нужно передавать в «1С» и из «1С»? И что делать, если в конечной системе нет нужного значения? Например, атрибуты номенклатуры могут храниться в «1С» как несколько справочников, которые обновляются независимо.

Например, вы передаёте в «1С:Розница» данные о номенклатуре «лампа настольная», у которой значение атрибута-справочника «цвет» — «красный».

Если в справочнике цветов в «1С:Розница» ещё не заведено значение «красный», записать такие данные будет невозможно.

Всё это необходимо учесть уже на этапе первоначальной разработки интеграции. Но и это ещё не всё. «1С» регулярно выпускает релизы и обновляет код своих продуктов. Та организация данных, под которую вы писали свою интеграцию, после любого из обновлений может стать неактуальной. Поменяются названия полей, какие-то поля разделятся на два или объединятся. И все интеграции, связанные с «1С», придётся перерабатывать в соответствии с новыми обстоятельствами.

Изменения могут быть и на стороне второй системы, участвующей в обмене данными, — и интеграцию вновь придётся менять.

Варианты интеграции «1С» и других приложений

По большому счёту существует всего два варианта интеграции «1С» с приложениями в IT-контуре: прямые интеграции и интеграции через сервисную шину предприятия, или ESB (сокр. от англ. enterprise service bus). У каждого из этих подходов есть свои особенности.

Прямые интеграции

Первый (и более предпочтительный, как показывает практика) вариант реализации прямых интеграций — работа через универсальный протокол OData (сокр. от англ. open data protocol). У продуктов «1С», в частности «1С:Предприятие» версии 8.3.5 и новее, предустановлена возможность работы через OData — открытый веб-протокол для запроса, добавления, удаления и обновления данных. OData позволяет выполнять операции с ресурсами при помощи HTTP-запросов и получать ответы в форматах XML и JSON.

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

Чтобы использовать протокол OData, нужно включить его поддержку в настройках «1С». После этого система автоматически создаст REST-интерфейс для обмена данными между «1С» и другими системами. И уже к нему можно будет «присоединить» интеграцию и настроить выгрузку и загрузку данных.

Если же система старше версии 8.3.5 (например, 8.2), воспользоваться универсальным протоколом OData не получится. Придётся писать API и интеграцию для каждой из подключаемых систем.

Казалось бы, в чём подвох? Практика написания API — стандартное решение для настройки «общения» между двумя системами.

Но тут надо учитывать, что API пишут люди. Причём люди разные, с разным опытом и разной логикой. Даже одну и ту же задачу они могут решить по-разному.

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

• написан в своей логике;
• работает по своей логике;
• в будущем должен дорабатываться… да-да, вновь в собственной логике.

После каждого обновления «1С» вашей команде придётся отдельно дорабатывать каждый из API в соответствии со свежими изменениями и внутренней логикой API. В лучшем случае делать это будет тот же специалист, который разрабатывал API, — ему будет проще воссоздать ход своих мыслей при написании кода. В худшем (с точки зрения временны́х затрат) — абсолютно новый специалист, который практикует иные подходы к написанию API.

Проблему «зоопарка» можно решить введением жёстких стандартов написания API (хотя на практике такое срабатывает далеко не всегда) или искусственным уменьшением количества интеграций.

Пример такого сокращения мы видели в одном из проектов. Чтобы сократить «зоопарк» в «1С»-источнике (системе, в которую сохраняли данные о товарах поставщиков), разработчики компании реализовали интеграцию по цепочке.

«Битрикс» собирал из других систем информацию об остатках, ценах, товарах и т. д. и передавал в «1С»-источник. «1С»-источник передавал все данные о товарах в систему «1С», ответственную за офлайн-розницу. Из неё часть первоначальной информации поступала в «1С», ответственную за онлайн-витрину.

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

Резюме

• Напрямую «1С» можно интегрировать с другими системами через протокол OData или через API.
• Протокол OData универсален и позволяет легко обмениваться данными между «1С» и другими системами.
• OData по умолчанию доступен только в относительно новых версиях «1С».
• Написание API в «1С» не регламентировано. Каждый разработчик реализует его исходя из собственного опыта, логики и подходов.
• После обновлений «1С» и других систем придётся менять все API. Если они написаны в разной логике, задача усложняется.
• Уменьшение количества интеграций путём усложнения логики взаимодействия систем фактически делает весь контур более уязвимым к ошибкам.

Интеграция «1С» через шину данных

Если в контуре компании всего два приложения (например, «1С:ERP Управление предприятием» и WMS), можно выбрать интеграцию формата «точка – точка». Вы точно знаете, какие данные и в каком объёме хранятся в «1С», какие — в системе складского учёта, что каждая из систем должна передавать и что — оставлять у себя. Глобальный рост в ближайшие годы не запланирован, как и внедрение других IT-систем.

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

Таким решением является интеграция «1С» и других систем через сервисную шину предприятия.

ESB — это программное решение, которое работает как единый центр обмена сообщениями между информационными системами и приложениями. Сервисная шина забирает из системы-источника информацию в том виде, в котором её удобно передавать источнику, складывает в хранилища или маршрутизирует в брокере сообщений, по необходимости преобразуя информацию в формат для системы-получателя. Программные решения для логирования и мониторинга, которые можно интегрировать в ESB (а в некоторых системах они уже являются частью конфигурации «из коробки»), позволяют отслеживать доставку информации между системами и быстро выявлять и устранять ошибки.

Очень упрощённая и условная схема интеграции систем через ESB выглядит следующим образом.

Каждая из систем что-то отправляет и получает не непосредственно от других систем, а через ESB.

Варианты интеграции через ESB

При этом ESB нельзя назвать «волшебной таблеткой» для интеграции «1С» с чем угодно.

Во-первых, интеграции ещё предстоит правильно спроектировать: разделить домены и потоки информации. Мы писали об этом подробнее в предыдущих статьях — можно ознакомиться с ними, например, здесь→ и здесь→ или перейти на общую страницу блога→ и отсортировать статьи по тегу ESB.

Во-вторых, для создания связи между «1С» и ESB придётся разрабатывать отдельный API на каждую сущность или подключать тот же протокол OData.

Внимательный читатель, который уже имеет дело с IT-контуром, включающим продукт «1С», возразит, что чаще всего «1С» с каждой из систем обменивается не одним-двумя, а пятью и даже десятью потоками данных. И реальная схема обмена данными выглядит несколько сложнее, чем простая паутинка.

Мы не предлагаем при интеграциях через ESB «сливать» весь массив данных через один коннектор и один поток. Более того, крайне не рекомендуем это делать, поскольку так нагрузка на интеграцию возрастает в десятки раз и пропорционально растёт риск сбоев.

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

• если информация по сущности хранится в одной-двух таблицах, лучше использовать протокол JDBC с прямым подключением к базе (без API);
• для более сложной структуры хранения данных (например, если сущность описана одновременно с помощью нескольких дополнительных справочников) придётся писать API и использовать протоколы передачи данных OData, RESTful, SOAP или GraphQL.

Логичный вопрос: если в любом случае придётся писать API, зачем тогда искусственная надстройка в виде ESB?

Преимущества интеграции «1С» через ESB

1. Снижение нагрузки на «1С» и на конечные системы

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

В схеме с ESB дополнительным элементом является только API. Все действия по разделению данных, фильтрации, конвертации происходят внутри слоя ESB.

2. Уменьшение объёма передаваемых данных

В схеме с прямыми интеграциями системы вынуждены передавать одну и ту же информацию неоднократно. Например, информацию о заказах «1С» передаёт в WMS, логистическую программу, CRM, систему расчёта вознаграждений продавцов и т. д. Одни и те же данные приходится транслировать пять, десять, двадцать раз.

С ESB вместо того, чтобы десять раз отправлять информацию о клиентах или заказах в разные системы с разной частотой, «1С» отправляет информацию однократно с заданной регулярностью. И уже системы-получатели забирают эту информацию из хранилища в ESB-слое по отдельной интеграции с такой частотой, которая им необходима.

В практике KT.Team был кейс, когда у клиента была настроена интеграция с тремя системами. Одна отвечала за складские остатки (WMS), вторая — за цены, а третья — за информацию о товарах (PIM). Чаще всего меняются складские остатки: чтобы поддерживать в интернет-магазине актуальные данные, «1С» должна была «ходить» за информацией об остатках раз в 15 секунд (примерно 40 тыс. раз в неделю). Но логика интеграций была настроена так, что «1С» раз в 15 секунд обращалась во все три системы — и получала в ответ 120 тыс. пакетов данных в неделю. Была перегружена и «1С», и остальные системы в контуре.

Когда команда KT.Team построила интеграции через ESB, каждая из систем стала получать и отдавать информацию с необходимой частотой. WMS по-прежнему отправляет информацию о складских остатках раз в 15 секунд. Система, ответственная за цены, передаёт данные раз в час (168 раз в неделю). А вот PIM сократила плановую передачу данных до одного раза в неделю — в 40 тыс. раз. В итоге «1С» стала забирать чуть больше 40 тыс. пакетов данных вместо 120 тыс.!

3. Учёт производительности систем

В логику ESB можно заложить скорость выгрузки и загрузки данных в конечные системы в зависимости от их производительности и суточной динамики загруженности. Например, если днём ваша CRM может принимать 100 транзакций в минуту, а ночью — 500, ESB учтёт эту логику и не перегрузит ваши системы.

4. Своевременное обнаружение ошибок

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

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

Пример построения интеграций между «1С» и другими системами

Так, в одном из недавних проектов для международной компании из сферы e-commerce и ретейл команда KT.Team настраивала интеграции для нескольких систем «1С»: ERP, OMS, UMP, CMS.

Мы внедрили интеграционную шину и реализовали 13 коннекторов для семи потоков данных:

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

Для каждой сущности настроен отдельный коннектор (или несколько, если этого требует логика). Это позволяет более контролируемо передавать данные между системами.

Резюме

• «1С» можно интегрировать с ESB через протокол JDBC (прямое подключение к простым базам) или по API, работающим по протоколам OData, RESTful, SOAP, JDBC или GraphQL (если сущность задана сложной базой со множеством таблиц).
• На каждую сущность нужен отдельный коннектор и отдельный API.
• Интеграция через ESB позволяет «1С» передавать каждую сущность однократно и с заданной частотой вне зависимости от количества систем-получателей.
• Интеграция через ESB снижает нагрузку на системы, сокращает размер кодовой базы, уменьшает общий объём передаваемых данных, учитывает производительность систем, ослабляет связанность систем.

Какую ESB выбрать для интеграции «1С»

Если вы уже изучали вопрос, то, возможно, первым и логичным ответом для вас будет «1С:Шина». Продукт из того же семейства действительно легко интегрируется с «1С:ERP Управление предприятием», «1С:Бухгалтерия», «1С:Зарплата и управление персоналом» и т. д.

Неплохо адаптирована для работы с продуктами «1С» ещё одна российская шина данных — DATAREON.

Но если у вас в контуре есть приложения других вендоров, выбирать шину данных имеет смысл по более широкому спектру параметров, нежели просто совместимость с «1С». Тем более что практика показывает: любую ESB можно легко интегрировать с «1С». Мы, например, работали с Mule в проектах с сотнями коннекторов с «1С» и высокой нагрузкой на шину — и не наблюдали никаких проблем даже в периоды пиковой нагрузки.

При выборе шины наши клиенты обычно обращают внимание на такие параметры:

• наличие коннектора OData для «1С» (встречается крайне редко, в нероссийских ESB готового коннектора, скорее всего, нет);
• наличие ошибок, связанных с low-code-реализацией;
• способ хранения сопутствующей информации о сообщениях;
• возможность выстраивания микросервисной архитектуры обмена с гибким масштабированием;
• возможность замыкания зоны ответственности одного коннектора целиком в одной джобе (т. е. мини-программе по работе с потоком данных) или наборе джоб;
• контроль версий;
• шифрование потоков;
• наличие визуального интерфейса для разработки;
• поддержка асинхронного режима;
• наличие механизма трансформации сообщений и поддерживаемые им форматы;
• способ трансформации;
• стоимость лицензирования.

Если вам нужна интеграция продуктов «1С» с другими системами и вы не уверены, с помощью какой ESB это можно реализовать, — напишите нам в форму.

‍