Промежуточный шлюз между корпоративными системами: как связать 1С, CRM, ERP и внешние сервисы без хаоса

Как перестать переносить данные вручную и построить управляемый обмен между учётными системами

Промежуточный шлюз — это отдельный программный слой, который стоит между корпоративными системами (1С, CRM, ERP, сайтом, складом, банком, госсервисами) и берёт на себя преобразование форматов, маршрутизацию запросов, авторизацию и обработку ошибок. Он становится нужен, когда прямых точечных интеграций набирается больше двух-трёх и их поддержка превращается в отдельный проект. В простых случаях достаточно API-шлюза или очереди сообщений, при пяти и более системах с высокими требованиями к отказоустойчивости чаще оправдана интеграционная шина (ESB) [1]. Для госсистем и передачи персональных данных действуют дополнительные требования — от криптографии СМЭВ до 152-ФЗ.

Зачем компании вообще нужен шлюз между системами

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

Похожий сценарий разбирают интеграторы на примере торговой компании, которая продаёт через сайт и несколько маркетплейсов: без синхронизации остатков в реальном времени происходит одновременная продажа одного и того же товара на разных площадках, что ведёт к отменам заказов и потере доверия клиентов [2].

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

По оценке, которую приводят интеграторы 1С со ссылкой на данные TAdviser, среди российских компаний среднего бизнеса чаще всего запрашивают интеграцию 1С с маркетплейсами, CRM и онлайн-кассами, а в крупном бизнесе фокус смещается на комплексные проекты с ERP-системами и построение единой информационной среды на базе решений класса ESB [3].

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

Что такое интеграционный шлюз простыми словами

Если убрать терминологию, шлюз — это переводчик и диспетчер между системами. Удобная бытовая аналогия — работа аэропорта-хаба: рейсы из разных городов прилетают в один хаб, а пассажиры пересаживаются и летят дальше, вместо того чтобы для каждой пары городов существовал отдельный прямой маршрут. Так же и шлюз принимает запросы от многих систем и распределяет их дальше, вместо того чтобы каждая система была напрямую связана с каждой [1].

Более формально, интеграционная шина или API-шлюз относятся к классу промежуточного программного обеспечения (middleware) — инструментов, которые переводят данные из одного формата в другой и управляют их маршрутизацией, позволяя взаимодействовать системам, которые не могут общаться напрямую. Типичный пример: при оформлении заказа на сайте данные через API-шлюз попадают в CRM, а оттуда через интеграционную шину — в ERP, где формируется отгрузочный документ [4].

Идея шлюза не нова: ещё в конце 1990-х годов технология шлюзов (gateways) описывалась как способ прозрачно связать разнородные базы данных без переписывания прикладной логики, а размещение шлюза как отдельного набора фоновых процессов не сказывалось заметно на производительности основной системы [5]. Современный шлюз решает похожую задачу для гораздо большего числа протоколов — не только для баз данных, но и для REST, SOAP, файлового обмена и очередей сообщений.

Стоит различать несколько базовых стилей интеграции систем: обмен файлами, работу через общую базу данных, вызов метода API (или удалённый вызов процедур) и обмен сообщениями через шину предприятия или брокер сообщений. Эти стили применяются как для связи подсистем одной корпоративной платформы, так и для подключения устаревших или самописных систем [6]. Шлюз в узком смысле обычно реализует именно API-стиль и стиль обмена сообщениями, добавляя к ним функции безопасности и наблюдаемости.

Как устроен шлюз изнутри: протоколы, паттерны, надёжность

Функции API-шлюза

На практике «шлюз» чаще всего означает API-шлюз (API Gateway) — единую точку входа для запросов к нескольким внутренним сервисам. К его типовым функциям относят маршрутизацию запросов к нужному сервису, ограничение частоты запросов и управление квотами для защиты систем от перегрузки, а также трансформацию протоколов — например, преобразование между SOAP и REST или между XML и JSON, что особенно важно при подключении устаревших систем к современным клиентам [7].

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

Сама по себе выдача токена не заменяет отдельный уровень защиты: для промышленного REST API дополнительно нужна многоуровневая оборона, охватывающая транспортный уровень (шифрование канала), аутентификацию и авторизацию, проверку входных данных запроса и защиту инфраструктуры на уровне самого шлюза и межсетевого экрана уровня приложений [9].

Синхронный и асинхронный обмен

Не всякий обмен данными стоит делать синхронным вызовом через REST. Там, где важно гарантировать доставку и пережить временную недоступность одной из систем, используют очереди сообщений и брокеры — например, RabbitMQ или Kafka. Брокеры сообщений обеспечивают надёжную доставку данных между частями системы, определяют через механизм маршрутизации, куда доставить сообщение, и хранят его в очереди до момента обработки получателем, не требуя, чтобы обе стороны обмена работали синхронно [10].

Паттерны надёжности — не опция, а требование

Промышленный шлюз, который просто перекладывает данные из одной системы в другую, работает только пока всё идёт по плану. В реальности сеть теряет пакеты, системы уходят на перезагрузку, а один и тот же запрос может прийти дважды.

Поэтому в схему обмена заранее закладывают устойчивые архитектурные решения: повторные попытки при сбое, тайм-ауты, ограничение нагрузки на внешний сервис, автоматическое отключение проблемного направления обмена (circuit breaker), идемпотентную обработку, дедупликацию повторяющихся сообщений, буферизацию потока данных, согласованную фиксацию изменений и события (transactional outbox), а также сквозной мониторинг состояния обмена. В промышленном контуре это не дополнительные удобства, а обязательные свойства проектируемой интеграции [11].

Отдельно стоит пояснить идемпотентность — свойство операции, при котором повторное выполнение с теми же входными данными приводит к тому же результату, что и первый успешный вызов. На практике устойчивые интеграции строятся на модели доставки «минимум один раз» и компенсируют возможные дубликаты именно идемпотентной обработкой на стороне приложения, поскольку гарантировать доставку «ровно один раз» сквозь несколько систем в реальных распределённых проектах практически невозможно [12].

Российская специфика: импортозамещение, госсистемы, 152-ФЗ

Реестр отечественного ПО и рынок ESB

С уходом ряда западных интеграционных платформ рынок российских ESB-решений заметно расширился: сегодня на нём одновременно присутствуют около десятка заметных продуктов, и выбор между ними стал отдельной задачей для ИТ-директора. Среди упоминаемых отраслевыми обзорами отечественных платформ — «1С:Интеграция КОРП», DATAREON Platform, Entaxy, ION ESB и ряд других решений [13]. Часть таких продуктов последовательно включается в Единый реестр российских программ для электронных вычислительных машин и баз данных, который ведёт Минцифры; этот реестр служит официальным подтверждением российского происхождения программного обеспечения для организаций, которым такое подтверждение требуется по закону [14].

При выборе решения стоит учитывать, что сроки обязательной совместимости продуктов из реестра с российскими операционными системами переносились поэтапно, а для более сложного («тяжёлого») софта финальный срок сдвинут на 2026 год [15]. Практический вывод для бизнеса — при выборе шлюза заранее проверять актуальный статус продукта в реестре и уточнять требования по совместимости, особенно если организация относится к субъектам критической информационной инфраструктуры или работает с государственными заказчиками.

Госсистемы: СМЭВ, ЕСИА, маркировка

Если шлюз должен обмениваться данными не только между внутренними системами, но и с государственными сервисами — например, через СМЭВ 3 — вступают в силу отдельные технические требования. Подключение и взаимодействие для организаций-участников выполняется через специальный шлюзовой модуль (API Gateway), а к концу 2026 года требуется дополнительно реализовать поддержку протокола OpenID Connect с подтверждением соответствия требованиям ФСБ по влиянию на используемые средства криптографической защиты. Для аутентификации в СМЭВ также требуется усиленная квалифицированная электронная подпись, выданная аккредитованным удостоверяющим центром [16].

Для организации, которая не готова развёртывать и обслуживать собственный шлюз для СМЭВ, распространён вариант подключения через универсального оператора — например, через облачную платформу провайдера, которая берёт на себя техническую инфраструктуру и круглосуточную поддержку, избавляя заказчика от необходимости разворачивать собственный шлюз [17].

Похожая логика применима и к другим государственным информационным системам с обязательной интеграцией, например к системе маркировки «Честный знак»: сложность там обычно не в самом факте вызова API, а в сопутствующих задачах — настройке криптографии для подписи запросов, обработке кодов ошибок и статусов, а также в сопоставлении данных между учётной системой предприятия и государственным информационным ресурсом [18].

152-ФЗ и передача персональных данных

Если через шлюз проходят персональные данные клиентов, сотрудников или контрагентов, проект подпадает под требования 152-ФЗ. До запуска важно определить цель и состав данных, ограничить доступ, настроить журналирование действий и проверить сроки хранения. В технические логи лучше передавать идентификаторы операций, а не полные карточки людей.

Регулирование в этой области продолжает меняться: с сентября 2025 года действуют обновлённые требования к обезличиванию персональных данных, а также обязанность операторов в установленных случаях передавать обезличенные данные в государственную информационную систему по запросу Минцифры [20]. Практически это означает, что при проектировании шлюза нужно заранее определить, какие поля являются персональными данными, требуется ли шифрование канала передачи и не покидают ли данные территорию России при использовании облачного посредника.

Универсального ответа здесь нет — многое зависит от класса информационной системы и категории обрабатываемых данных, поэтому эту часть стоит прорабатывать вместе со специалистом по защите информации.

Точка-точка, ESB или API-шлюз — как выбрать архитектуру

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

При этом у ESB есть и обратная сторона: по мере распределения интеграционной логики между разными системами усложняются сопровождение и поиск неисправностей, а диагностика и поддержка требуют более высокой квалификации команды и зрелых эксплуатационных процессов [21]. Поэтому решение обычно принимается не «ESB против API-шлюза» абстрактно, а исходя из числа систем, частоты изменений в интеграциях и наличия ресурсов на сопровождение:

• 2–3 системы, стабильные форматы данных — точечная интеграция через REST API одной системы к другой, без отдельного промежуточного слоя.
• 3–5 систем, нужна единая авторизация и мониторинг — облегчённый API-шлюз или готовая платформа с набором коннекторов.
• 5 и более систем, разные протоколы, высокие требования к отказоустойчивости — полноценная ESB или комбинация «шина плюс очередь сообщений».

Практические этапы создания шлюза

Разработка шлюза — это, по сути, разработка отдельной информационной системы, и её удобно вести по классической схеме проектов на базе ГОСТ 34. Техническое задание фиксирует цели создания системы и требования к автоматизации и служит основой для последующего тестирования и приёмки; сдача проекта завершается приёмочными испытаниями, на которых проверяется соответствие техническому заданию, анализируются результаты и устраняются выявленные проблемы, после чего оформляется акт о вводе в эксплуатацию и начинается опытно-промышленная эксплуатация [22].

На практике для интеграционного проекта имеет смысл выделить следующие шаги:

1. Инвентаризация систем и данных. Какие системы участвуют, какие данные передаются, кто инициатор обмена и какие из данных относятся к персональным.
2. Выбор архитектуры и протокола. Синхронный REST, асинхронная очередь сообщений, файловый обмен — или их комбинация в зависимости от критичности и объёма данных.
3. Проектирование безопасности. Схема авторизации (OAuth 2.0, ключи API, сертификаты), при необходимости — согласование с требованиями 152-ФЗ и, для госсистем, с требованиями СМЭВ и ЕСИА.
4. Разработка и сопоставление справочников. Отдельная и часто недооценённая по трудоёмкости задача: у разных систем не совпадают структуры данных — например, товарная номенклатура в 1С и карточки товаров на сайте, — и для этого пишется отдельный слой преобразования.
5. Реализация паттернов надёжности. Повторные попытки, идемпотентность, очередь недоставленных сообщений, журнал обмена закладываются на этапе разработки, а не добавляются постфактум.
6. Интеграционное тестирование. Проверяется не только каждый модуль отдельно, но и корректность взаимодействия компонентов на всех точках соприкосновения — от быстрой проверки сразу после сборки до полноценного системного тестирования готового решения; такое тестирование выявляет именно ошибки взаимодействия модулей и внешних систем, а не логики каждой системы по отдельности [23].
7. Опытная эксплуатация. Запуск на ограниченном контуре с ведением журнала замечаний, после чего оформляется акт и система переводится в промышленную эксплуатацию.

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

Ограничения, ошибки и риски

• Недооценка сопоставления справочников. Разная структура данных между системами — частая причина затягивания проекта; для неё нужен отдельный продуманный слой преобразования, а не «быстрый скрипт».
• Отсутствие идемпотентности. Без неё повторная отправка запроса при сетевом сбое может создать задвоенные заказы, платежи или документы.
• Игнорирование лимитов и условий доступа стороннего API. Наличие документированного API ещё не означает, что доступ открыт без ограничений: заранее нужно выяснять, требуется ли регистрация, договор, тестовая среда и какие операции доступны конкретной организации.
• Смешение персональных данных с техническими логами. Если в журнал обмена по умолчанию попадают ФИО или номера телефонов, это расширяет периметр, подпадающий под требования 152-ФЗ, и повышает требования к его защите.
• ESB «на вырост» без реальной необходимости. Разворачивать полноценную шину ради связи двух систем — избыточно; это удорожает и усложняет проект без соразмерной пользы.
• Точечные интеграции без плана на рост. Обратная ошибка — плодить прямые связи между системами, каждая из которых становится точкой отказа при малейшем изменении формата данных у одной из сторон.

Как выбрать между готовым решением и разработкой

Если задача типовая — синхронизировать остатки с маркетплейсом, подключить платёжный шлюз, выгрузить данные телематики в 1С, — зачастую достаточно готового коннектора или сервиса с заранее известной ценой и сроком, без разработки собственной шины. Например, для интеграции данных телематики Wialon с 1С или TMS на рынке уже есть отработанный сценарий: сопоставление объектов транспорта по внутреннему коду или госномеру, регулярная загрузка данных с сохранением часового пояса и позиции последнего обмена, а также контрольная сверка нескольких рейсов перед сдачей — то есть уже решённая точечная задача, а не проект с нуля [24].

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

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

Как проверить шлюз перед рабочим запуском

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

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

Вывод

Промежуточный шлюз — это не единый продукт, а спектр решений: от простого REST-коннектора между двумя системами до полноценной ESB с очередями сообщений и мониторингом. Выбор архитектуры зависит от количества систем, критичности данных и наличия ресурсов на сопровождение. В российских условиях к типовым инженерным вопросам добавляются регуляторные: статус решения в реестре отечественного ПО, требования при подключении к госсистемам вроде СМЭВ, и обязательства по 152-ФЗ при передаче персональных данных. Эти требования стоит закладывать на этапе проектирования, а не исправлять постфактум.

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

Источники

[1] 7tech-integra.ru — Интеграция приложений предприятия с помощью интеграционной шины ESB — https://7tech-integra.ru/blog/obzor-technologiy/integratsiya-prilozheniy-predpriyatiya

[2] kt-team.ru — Как API-интеграция автоматизирует бизнес: CRM, 1С, маркетплейсы и рост — https://www.kt-team.ru/blog/crm-1c-marketplace-api-integration-profit-boost

[3] kt-team.ru — Интеграция 1С с CRM, сайтом и маркетплейсами: кейсы и технологии обмена — https://www.kt-team.ru/blog/how-1c-integration-improves-efficiency

[4] exolve.ru — Что такое системная интеграция — https://exolve.ru/blog/chto-takoe-sistemnaya-integratsiya/

[5] osp.ru — Шлюзы как средство интеграции баз данных — https://www.osp.ru/os/1999/02/179696

[6] systems.education — Технологии интеграции: Общая БД, Файловый обмен, SOAP/REST — https://systems.education/integrations-fundamentals-one

[7] appmaster.io — API-шлюз (глоссарий) — https://appmaster.io/glossary/api-gateway

[8] elma365.com — OAuth 2.0 — что это и как работает — https://elma365.com/ru/baza-znaniy/oauth-2-0/

[9] moluch.ru — Атаки на API: анализ уязвимостей и методы защиты REST-сервисов — https://moluch.ru/archive/621/135770

[10] habr.com — Брокеры сообщений Kafka и RabbitMQ в реальной жизни — https://habr.com/ru/companies/T1Holding/articles/968394/

[11] apni.ru — Паттерны надёжности при интеграционном взаимодействии информационных систем — https://apni.ru/article/15446-patterny-nadyozhnosti-pri-integracionnom-vzaimodejstvii-informacionnyh-sistem

[12] spirzen.ru — Идемпотентность и семантика доставки — https://spirzen.ru/encyclopedia/2-system-network/2-09-osnovy-integratsionnogo-vzaimodeystviya/133

[13] xn--90agcqfex5h.xn--p1ai (Белый код) — Обзор российских ESB-решений 2026 — https://белыйкод.рф/esb/

[14] reestr.digital.gov.ru — Единый реестр российских программ для ЭВМ и баз данных — https://reestr.digital.gov.ru/reestr/

[15] tadviser.ru — Минпромторг запустил программу субсидирования расходов на внедрение российского ПО — https://www.tadviser.ru/index.php/Статья:Импортозамещение_информационных_технологий_в_промышленности

[16] rcngroup.ru — ЕСИА и СМЭВ — требования к ИБ при подключении к системе — https://rcngroup.ru/blog/esia-i-smjev-trebovanija-k-ib-pri-podkljuchenii-k-sisteme/

[17] cleverence.ru — Как подключить организацию к СМЭВ: инструкция, технические детали и советы — https://www.cleverence.ru/articles/it-i-razrabotka/-podklyuchenie-organizatsii-k-smev-poshagovaya-instruktsiya/

[18] 5factor.ru — True API «Честного знака»: подключение, авторизация и обмен данными — https://5factor.ru/resources/true-api-chestnogo-znaka-podklyuchenie-avtorizacziya-i-obmen-dannymi

[19] consultant.ru — Федеральный закон «О персональных данных» от 27.07.2006 № 152-ФЗ — https://www.consultant.ru/document/cons_doc_LAW_61801/

[20] cisoclub.ru — Изменения в законе 152-ФЗ о персональных данных и обязательные меры безопасности — https://cisoclub.ru/izmenenija-v-zakone-152-fz-o-personalnyh-dannyh-i-objazatelnye-mery-bezopasnosti/

[21] techforward.ru — Как связать данные, процессы и команды с помощью интеграции ИТ-систем — https://techforward.ru/news/integraciya-it-sistem

[22] leantech.ai — Сдача проекта по ГОСТ 34. Этапы разработки ПО от написания ТЗ до ввода в опытно-промышленную эксплуатацию — https://leantech.ai/gost34

[23] tquality.ru — Интеграционное тестирование: виды, методы и лучшие практики QA — https://tquality.ru/blog/integracionnoe-testirovanie/

[24] 5factor.ru — Интеграция Wialon с 1С или TMS — https://5factor.ru/uslugi/integracii-i-avtomatizaciya/integraciya-wialon-1c-tms/