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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

мини-программе по работе с потоком данных) или наборе джоб; контроль версий; шифрование потоков; наличие визуального интерфейса для разработки; поддержка асинхронного режима; наличие механизма трансформации сообщений и поддерживаемые им форматы; способ трансформации; стоимость лицензирования.