# NEOMSA: полный текстовый дамп сайта neomsa.ru Дата сборки: 2026-09-16 Разработчик: АО «Неофлекс Консалтинг» (Neoflex) Контакты: neomsa@neoflex.ru, +7 (495) 984 25 13, 127015, Москва, ул. Вятская, д. 35, стр. 4 --- # NEOMSA: российская интеграционная платформа URL: https://neomsa.ru/ NEOMSA это российская интеграционная платформа корпоративного класса. Шесть продуктов для интеграции систем: APIM, ESB, MQ, Messaging, CI/CD и Container Platform. Каждый продукт внедряется отдельно, все шесть совместимы и объединяются в единую платформу. NEOMSA APIM, NEOMSA Messaging и NEOMSA Container Platform включены в реестр российского ПО. Платформа построена на компонентах с открытым исходным кодом и адаптирована под российские дистрибутивы Linux: РЕД ОС, Astra Linux и другие. Продукт соответствует стандарту информационной безопасности ISO/IEC 27001. Состав платформы: управление API, сервисная шина, брокер сообщений, платформа потокового обмена сообщениями, конвейер DevSecOps, контейнерная платформа. Сферы применения: ИТ и разработка ПО, производство и логистика, здравоохранение, финансы, маркетинг, образование. Часто задаваемый вопрос. Что такое NEOMSA? NEOMSA это российская интеграционная платформа корпоративного класса. Шесть продуктов для интеграции систем: APIM, ESB, MQ, Messaging, CI/CD и Container Platform. --- # NEOMSA APIM: платформа управления API URL: https://neomsa.ru/apim Централизованная платформа управления API для безопасного управления жизненным циклом, архитектурой и монетизацией интерфейсов. Позиционируется как российская замена WSO2 API Manager, Apigee, Kong и MuleSoft. В реестре российского ПО, регистрационный номер 22803. Преимущества: интеграция цифровых продуктов с партнерами и платформами, централизованное управление всеми API, интеграция с существующими системами за счет поддержки разных протоколов, ускорение разработки и вывода сервисов, механизмы аутентификации, авторизации и контроля доступа, гибкая настройка. Функции: - авторизация и безопасность: управление доступом и обработка аутентификации; - интеграция с инструментами аналитики: отслеживание использования API и анализ поведения потребителей; - создание API и автоматическая генерация документации; - горизонтальное масштабирование под рост нагрузки и числа потребителей; - управление полным жизненным циклом API: разработка, тестирование, развертывание, версионирование, вывод из эксплуатации. Документация: руководство по эксплуатации NEOMSA APIM. --- # NEOMSA ESB: сервисная шина предприятия URL: https://neomsa.ru/esb Корпоративная интеграционная платформа для облачной инфраструктуры на базе Apache Camel, реализующая паттерны интеграции EIP. Позиционируется как замена IBM Integration Bus, Oracle Service Bus, MuleSoft и TIBCO. Преимущества: облачная архитектура с масштабируемостью и отказоустойчивостью, оптимизация затрат на инфраструктуру, настройка под конкретные бизнес-процессы, микросервисная архитектура с модульностью и независимым масштабированием компонентов, поддержка Enterprise Integration Patterns, управление данными и интеграционными потоками. Функции: - интеграция приложений и систем разных типов и технологий; - управление жизненным циклом данных: создание, передача, хранение и уничтожение по требованиям безопасности; - маршрутизация и трансформация сообщений; - мониторинг и управление производительностью интеграционных процессов; - механизмы авторизации, аутентификации и безопасности данных. --- # NEOMSA MQ: брокер обмена сообщениями URL: https://neomsa.ru/mq Отказоустойчивый масштабируемый брокер обмена сообщениями для гарантированной доставки данных в целевые системы. Позиционируется как замена IBM MQ, RabbitMQ и ActiveMQ. Функции: - обмен сообщениями в реальном времени между узлами и приложениями; - маршрутизация и фильтрация сообщений по заданным правилам; - поддержка протоколов AMQP, MQTT, STOMP и других; - гарантированная доставка при временных сбоях сети или узлов; - шифрование данных при обмене; - мониторинг производительности обмена и системы в целом; - управление жизненным циклом сообщений: создание, обработка, хранение, удаление; - управление очередями: создание, мониторинг, распределение нагрузки; - API для интеграции с приложениями и сервисами. --- # NEOMSA Messaging: платформа потоковой обработки событий URL: https://neomsa.ru/messaging Распределенная платформа потокового обмена сообщениями в реальном времени. Позиционируется как замена Apache Kafka, Confluent Platform и Pulsar. В реестре российского ПО, регистрационный номер 23599. Функции: - управление сообщениями: отправка, получение, хранение, маркировка; - мониторинг статуса сообщений и аналитика обмена; - валидация сообщений: проверка, хранение и извлечение схем Avro, JSON Schema и Protobuf; - семантика доставки at least once, at most once, exactly once; - уведомления и оповещения о событиях; - групповая рассылка сообщений; - транзакционность для целостности операций в распределенных приложениях; - горизонтальное масштабирование, несколько топологий отказоустойчивости и балансировки нагрузки; - интерфейс централизованного администрирования кластерами. Документация: руководство по эксплуатации NEOMSA Messaging. --- # NEOMSA CI/CD: конвейер DevSecOps URL: https://neomsa.ru/cicd Платформа автоматизации CI/CD и DevSecOps в варианте on-premise. Позиционируется как замена GitLab CI, TeamCity и Azure DevOps. Преимущества: платформа low-code с каталогом типовых сценариев DevSecOps и визуальным редактором; готовые библиотеки для разных движков (Jenkins Shared Library, gitlab-ci, облачные библиотеки Tekton и Argo Workflows); каталог стартовых шаблонов проектов на разных языках; единый стандарт DevSecOps для всех команд, включая распределенные; сквозная автоматизация тестирования; стратегия shift-left. Функции: - анализ безопасности: сканирование исходного и бинарного кода на уязвимости, проблемы лицензирования компонентов с открытым кодом, вредоносные вставки и ошибки конфигурации; - контроль качества образов и запрет развертывания неутвержденных образов по политикам; - хранение артефактов с безопасной доставкой и обновлением; - централизованное управление: передача отчета об уязвимостях в инструментарий CI/CD, уведомления на почту, в мессенджеры и по API; - интеграция с Jenkins, Azure DevOps, Bamboo, GitLab, TeamCity. 10 преднастроенных пайплайнов, готовых к работе. --- # NEOMSA Container Platform: платформа Kubernetes URL: https://neomsa.ru/container-platform Платформа NoOps на базе Kubernetes для разработки и эксплуатации микросервисных приложений. Позиционируется как замена Red Hat OpenShift, Rancher и VMware Tanzu. В реестре российского ПО, регистрационный номер 15521. Преимущества: централизованное управление кластерами с единой аутентификацией, контролем доступа, аудитом, резервным копированием и обновлением; поддержка инструментов DevOps (Jenkins, GitLab, Travis, Prometheus, Grafana, Fluentd, Istio); развертывание в облаке, on-premise и в изолированных контурах; масштабирование кластеров; аутентификация, авторизация и шифрование данных. Функции: - готовый процесс CI/CD с интеграцией GitOps, проверки кода и образов; - вертикальное и горизонтальное масштабирование; - внутренний каталог шаблонов приложений, микросервисов, инфраструктурных компонентов и пайплайнов; - настройка каналов уведомлений: почта, мессенджеры, отправка отчетов по API; - установка собственных библиотек, в том числе в закрытом контуре без доступа к сети; - шифрование и безопасность обмена; - дашборды мониторинга для локализации дефектов; - модуль настраиваемых заглушек для тестирования без готовых внешних сервисов; - тестовая среда для быстрого старта разработки. От установки кластера Kubernetes до старта разработки: 11 минут. Сертификаты совместимости: Astra Linux, РЕД ОС. Документация: руководство пользователя, руководство по установке. --- # Проектный опыт URL: https://neomsa.ru/ Внедрение в банке из ТОП-20. Цели: сокращение срока вывода новых продуктов, расширение ассортимента, единая среда для разработки и эксплуатации. Результат: пилотные сервисы обработки клиентских заявок из внешних источников, микросервисы обработки и верификации кредитных заявок с партнерских сайтов и цифровых каналов банка с интеграцией в CRM, ускорение выпуска банковских продуктов за счет автоматизации доставки релизов. Система дистанционного банковского обслуживания для юридических лиц в микросервисной архитектуре. Цели: управление разработкой и развертыванием микросервисов из Jira, разработка системы ДБО, настройка открытых API и управления API. Результат: построена система ДБО для юридических лиц, сокращено время вывода новых продуктов, внедрено управление API, доступ к интерфейсам получают только авторизованные партнеры банка, реализована возможность разрабатывать открытые API для интеграции сервисов банка с приложениями партнеров. Внедрение в банке из ТОП-5. Цели: универсальный процесс сборки и развертывания микросервисов, настройка процессов DevOps для брокеров сообщений, перенос разработки в банковский контур. Результат: универсальный пайплайн сборки, развертывания и тестирования микросервисов на разных языках, стенды для тестирования и разработки, переход со старого инструмента сборки, кластерные брокеры сообщений с подходами к резервному копированию и восстановлению. Платформа Kubernetes для крупной страховой компании. Цели: безопасная отказоустойчивая платформа эксплуатации микросервисных приложений, быстрое развертывание целевого решения MLOps. Результат: сроки внедрения сокращены более чем в 10 раз, стандартизированы подходы к безопасности, логированию и мониторингу, заказчик получил интерфейс централизованного управления жизненным циклом и расширения инфраструктуры. --- # Партнерская программа URL: https://neomsa.ru/partnership Программа для расширения продуктового портфеля партнера за счет российского ПО, услуг технической поддержки, обучения и сопутствующих сервисов. Ориентирована на развитие продаж и совместную работу с конечными заказчиками на территории России. Модели партнерства: 1. Сублицензионная, для реселлеров и интеграторов. Партнер приобретает лицензии для дальнейшего распространения конечным пользователям. Подходит компаниям, которые ведут продажу программных продуктов через собственный коммерческий контур. 2. Агентская, для консалтинга и агентов. Партнер привлекает клиента и получает вознаграждение за оплаченные лицензии или услуги технической поддержки. 3. Технологическое партнерство, для разработчиков и вендоров. Партнер использует решения в своих проектах и внедрениях у заказчиков, а также при разработке собственных продуктов. Преимущества: консультационная и информационная поддержка, участие в совместных маркетинговых мероприятиях, расширение продуктовой линейки, доступ к техническим и маркетинговым материалам, участие в совместных проектах, рост маржинальности. Подключение занимает от 5 до 10 рабочих дней: заявка, знакомство и презентация продуктов, подписание партнерского соглашения, доступ к материалам и обучению, регистрация первых сделок. Действующие партнеры: Softline, 1С-Бит, Кодерлайн, Quality Lab, ТКУР. --- # О компании URL: https://neomsa.ru/about-company Разработчик NEOMSA компания Neoflex. Neoflex работает с 2005 года, занимается заказной разработкой программного обеспечения, создает собственные платформы и внедряет инструменты искусственного интеллекта. В цифрах: более 1400 сотрудников, 8 центров разработки, более 1000 человеко-лет вложено в собственные программные компоненты, 9 из 10 заказчиков продолжают работать после первого проекта, год основания 2005. Центры разработки: Москва, Санкт-Петербург, Нижний Новгород, Воронеж, Пенза, Самара, Саратов, Краснодар. Юридическое лицо: АО «Неофлекс Консалтинг», ОГРН 1097746303050, ИНН 7701839238, КПП 771401001, основной ОКВЭД 62.01. --- # Как устроен API менеджмент URL: https://neomsa.ru/education/gl0tnh45r1-kak-ustroen-api-menedzhment Раздел: Обучение Дата публикации: 2026-08-01 Статья для архитекторов, тимлидов и инженеров интеграции о составных частях платформ управления API. Какую проблему решает управление API. В организации с сотнями внутренних и партнерских интерфейсов без централизованного управления возникают дублирование сервисов, неконтролируемый доступ, отсутствие защиты от перегрузки и слепая эксплуатация. Управление API это дисциплина управления интерфейсами на всем жизненном пути, от разработки до вывода из эксплуатации. Платформы автоматизируют ее: централизованно применяют политики, ведут каталог сервисов, собирают аналитику. API Gateway. Компонент, через который проходит трафик к API. Сквозные задачи решаются один раз на уровне шлюза, а не в каждом сервисе: проверка прав, ограничение трафика, логирование, трансформация запросов и ответов. Шлюз масштабируется горизонтально добавлением экземпляров. Жизненный цикл и версионирование. Стадии: создание, тестирование, публикация, устаревание, вывод из эксплуатации. Ревизия это зафиксированный снимок конфигурации, по ней происходит развертывание и откат. Версия это контракт с потребителями: при изменении интерфейса выпускается новая версия, старая продолжает работать. Развернуто и опубликовано это разные состояния: развернутый API доступен для тестирования, потребители видят его в каталоге только после перевода в статус публикации. OpenAPI. Стандарт описания REST API в машиночитаемом формате. Спецификация либо генерируется платформой автоматически, либо импортируется при подходе contract first. На спецификации строится подход API as Code: описание хранится в репозитории, проходит ревью и разворачивается через пайплайн. Методы аутентификации. Ключ API: статичная строка без срока жизни и области действия, применим для внутренних сценариев. Базовая аутентификация: логин и пароль в заголовке, используется для совместимости со старыми системами. OAuth 2.0: токен с ограниченным сроком жизни и областью действия, стандарт для партнерских и публичных API. OAuth это протокол получения токенов, JWT это формат токена, подписанный JSON с данными о пользователе, сроке действия и правах; шлюз проверяет подпись локально. mTLS: взаимная проверка сертификатов на уровне TLS, типична для финансового сектора и межбанковских интеграций. Политики. Правило, применяемое к запросу или ответу на уровне шлюза: добавить заголовок, проверить содержимое, трансформировать тело, отклонить запрос. Политики нужны для сквозной логики, а не для бизнес-логики. Ограничение частоты запросов и тарифные планы. Ограничение количества запросов от потребителя за единицу времени (rate limiting). Лимиты задаются на нескольких уровнях: общий на API, на отдельные ресурсы, раздельно для боевого endpoint и песочницы. Поверх лимитов строятся тарифные планы и монетизация. Каталог и песочница. Каталог API, он же портал разработчика, это витрина опубликованных сервисов с поиском, документацией и подключением по принципу самообслуживания. Песочница дает отправить запрос из браузера до подписки. Доступ управляется на двух уровнях: видимость сервисов по ролевой модели и подписка, автоматическая для некритичных API и через согласование для критичных. Аналитика и трассировка. Минимальный набор метрик: объем трафика, разбивка ошибок на 4хх и 5хх, задержки, статистика по потребителям. По задержкам смотрят перцентили p95 и p99, а не средние значения. Трассировка раскладывает запрос на шаги с таймингом каждого и показывает вклад платформы и бэкенда по отдельности. Чек-лист зрелости: трафик проходит через шлюз с централизованными политиками; у каждого API формальный жизненный цикл с ревизиями и версионированием; спецификации OpenAPI актуальны; потребители подключаются через каталог с песочницей; по каждому API видны трафик, ошибки и перцентили задержек. --- # Neoflex представила подход «от API к AI» и AgentOps-платформу на FinCore 2026 URL: https://neomsa.ru/news/z5adl16z81-neoflex-predstavila-podhod-ot-api-k-ai-i Раздел: Новости Дата публикации: 2026-03-06 Спикер: Рамиль Нафиков, лидер продукта NEOMSA APIM На FinCore 2026 представлена платформа NEOMSA APIM для управления API, ИИ-агентами и серверами MCP. Платформа развивает подход «от API к AI» и создавалась с учетом требований Open Banking. Она поддерживает безопасный обмен данными, централизованное управление доступом, аудит операций и выполнение регуляторных требований. Тезис выступления: Open Banking это управляемая среда, в которой контролируется и трафик REST, и взаимодействие ИИ-агентов, сервисов LLM и внешних партнеров. Направление развития в сторону шлюза для ИИ (AI Gateway) и контура AgentOps: контроль и маршрутизация трафика LLM, политики безопасности для ИИ-агентов, мониторинг использования моделей и расхода токенов, централизованное управление жизненным циклом сервисов ИИ, разграничение доступа к функциям ИИ в экосистемах Open Banking. В одном контуре платформа объединяет открытые API финансового рынка, внутренние интеграционные сервисы, ИИ-агентов и серверы MCP, инструменты мониторинга и комплаенса. Концепция управления ИИ-агентами в едином контуре реализована в платформе AgentOps Neoflex Neon. Решения на ее базе: ассистент разработчика, чат-бот для анализа данных и подготовки отчетов на базе LLM, решение для информационной безопасности при работе с ИИ-агентами, ассистент для поиска по корпоративной информации. Видео выступления: https://rutube.ru/video/7f83fd88e14f081fdc24ce928cfb9064/ --- # Российские платформы API Management: обзор и сравнение URL: https://neomsa.ru/news/rossiyskie-platformy-api-management Раздел: Новости Дата публикации: 2026-07-20 Сравнение 5 российских платформ управления API по 13 критериям. Данные на июнь 2026 года, оценки по открытым материалам вендоров. Контекст: пока в компании десяток API, ими управляют вручную; на сотне расходятся версии, у каждого канала своя схема доступа, мониторинг разбросан по командам. При этом зарубежные платформы уходят из ландшафтов, и выбирать замену приходится почти всем крупным компаниям. По оценке Neoflex, объем сегмента к 2030 году дойдет до 5 млрд рублей. Основание оценки: глубинные интервью более чем с 20 представителями компаний из финансов, промышленности, ИТ, торговли и логистики. Два подхода к выбору. Первый: управление API как модуль большой интеграционной платформы, один вендор и один стек, оправдан при готовности строить на нем весь ландшафт. Второй: специализированный продукт под задачу, встает рядом с работающей шиной и брокером без замены остального ландшафта. NEOMSA APIM построен по второму принципу. Дополнительный критерий, который поднимают заказчики: принадлежность вендора. Часть решений принадлежит компаниям, которые сами работают на рынках банков, ритейла и телекома. Сравниваемые платформы: NEOMSA APIM (специализированное решение независимого вендора с криптографией по ГОСТ, монетизацией и шлюзом для ИИ), Platform V Synapse (модуль экосистемной платформы Сбера), MWS Octapi (интеграционная платформа МТС с акцентом на low code и искусственный интеллект), Platformeco (платформа на открытых компонентах Kong и Keycloak), Datareon (решение в области ESB и управления данными для внутренних интеграций). Критерии сравнения. Управление API: полный жизненный цикл, governance, монетизация из коробки, каталог асинхронных API, шлюз для ИИ и управление агентами. Безопасность: криптография по ГОСТ, российский поставщик идентификации, аудит безопасности продукта, отдельный контур защиты внешних API. Эксплуатация и вендор: высокая нагрузка и георезерв, реестр российского ПО, независимость вендора, публичные внедрения в финансовом секторе. --- # Микроинтегратор: интеграционный слой в архитектуре микросервисов URL: https://neomsa.ru/education/mikrointegrator-integracionnyi-sloi Раздел: Обучение Тип: технический разбор NEOMSA APIM состоит из 2 слоев: слоя управления API и интеграционного слоя. В интеграционном слое работают 2 отдельных продукта с разными движками: микроинтегратор на движке Apache Synapse и потоковый интегратор на движке потоковой обработки. Продукты решают разные задачи и взаимозаменяемыми не являются. Статья разводит 2 сущности, которые часто смешивают: среду выполнения, которая разворачивается и масштабируется как единица инфраструктуры, и интеграционный сервис, который представляет собой конфигурацию медиации внутри среды выполнения. Разбираются: точки входа (REST API, прокси-сервис, входящая точка, главная последовательность), транспорт PassThrough и его влияние на профиль нагрузки, медиаторы и последовательности (inSequence, outSequence, faultSequence), шаблоны корпоративной интеграции, endpoint с состояниями Active, Timeout, Suspended, Off и политиками повторов, общий пул соединений по паре host и port, развязка скоростей через Message Store и Scheduled Message Forwarding Processor, ресурсы проекта и реестр, защищенное хранилище Secure Vault, состав интеграционного проекта и композитный артефакт CApp, регистрация в каталоге сервисов и создание прокси на шлюзе. Завершается чек-листом из 7 пунктов перед выводом интеграционного сервиса в промышленную эксплуатацию и блоком из 7 частых вопросов. ## Обучение: что такое APIM ### Что такое APIM (API Management): как работает управление API URL: https://neomsa.ru/education/chto-takoe-apim Дата: 2026-10-04 APIM (API Management) это платформа для публикации, защиты и контроля API компании. Она ставит между потребителями и сервисами единую точку входа. В ней действуют правила доступа, лимиты, учёт вызовов и аудит. Потребители API: внутренние команды, партнёры, мобильные приложения, сервисы с языковыми моделями и ИИ-агенты. Каждый получает доступ только к тем API, на которые оформил подписку. #### Зачем компании APIM Пока API 5–10, их обслуживают вручную: ключи в настройках, описание в вики. Когда API десятки, у каждой команды появляется свой шлюз и свои правила. Партнёр ждёт доступа неделями, а владелец сервиса не знает, кто его вызывает. APIM собирает API в один каталог с общими правилами. Новый потребитель подключается через портал за минуты, без писем и заявок. #### Из чего состоит APIM - Шлюз API принимает запросы, проверяет доступ, применяет лимиты и направляет вызов в нужный сервис. - Портал разработчика показывает каталог API с документацией. Команды и партнёры сами оформляют подписку и получают ключи. - Управление жизненным циклом ведёт API от проектирования до публикации, новых версий и отключения. - Безопасность: OAuth 2.0, mTLS, проверка запросов по схеме, шифрование. - Аналитика и аудит показывают, кто, когда и сколько раз вызывал API, время ответа и ошибки. - Монетизация задаёт тарифы и считает вызовы, если API платные. #### Чем APIM отличается от API Gateway Шлюз API это один компонент APIM. Он обрабатывает трафик. Портал, подписки, версии и аналитику даёт платформа вокруг шлюза. | Задача | API Gateway | APIM | | --- | --- | --- | | Маршрутизация и лимиты | есть | есть | | Проверка доступа | есть | есть | | Каталог API и портал разработчика | нет | есть | | Подписки партнёров и самостоятельное подключение | нет | есть | | Версии и отключение API | нет | есть | | Аналитика по каждому потребителю | частично | есть | | Монетизация | нет | есть | #### Когда компании нужен APIM - API десятки, их публикуют несколько команд. - Партнёры и внешние сервисы подключаются через ваши API. - Банк или ритейлер открывает API клиентам и партнёрам. - Нужно знать, кто вызывает сервис и с какой нагрузкой. - ИИ-агенты и сервисы с языковыми моделями обращаются к внутренним системам. #### APIM и ИИ-агенты ИИ-агент тоже потребитель API: он запрашивает данные и вызывает операции во внутренних системах. Без APIM агенту дают прямой доступ, и его действия никто не учитывает. APIM подключает агента к API через MCP (Model Context Protocol). Агент видит только разрешённые операции, а каждый вызов попадает в аудит. Запросы к языковым моделям идут через тот же контур: маскирование данных, защита от prompt injection, квоты по токенам. #### Как выбрать платформу APIM 1. Протоколы: REST, SOAP, GraphQL, AsyncAPI. 2. Развёртывание в своём контуре: свой ЦОД, частное облако, Kubernetes. 3. Портал разработчика с самостоятельным подключением потребителей. 4. Отказоустойчивость и горизонтальное масштабирование шлюза. 5. Перенос API с текущего шлюза без остановки сервисов. 6. Запись в реестре российского ПО, если закупка идёт по импортозамещению. 7. Техническая поддержка вендора на русском языке. #### NEOMSA APIM NEOMSA APIM: российская платформа управления API от Neoflex. Шлюз, портал разработчика, безопасность, аналитика и контроль запросов к языковым моделям в одной платформе. Каталог API поддерживает REST, WebSocket, WebSub и GraphQL. Включена в реестр российского ПО, запись №22803. Страница продукта: https://neomsa.ru/apim #### Вопросы и ответы В: APIM и API Management это одно и то же? О: Да. APIM сокращение от API Management, по-русски «управление API». В: Можно ли обойтись шлюзом без APIM? О: Можно, пока API мало и все потребители внутри компании. Когда подключаются партнёры и нужен аудит, шлюза не хватает. В: Где развернуть APIM? О: В своём ЦОД, в частном облаке или в кластере Kubernetes. Банки и крупные компании разворачивают APIM в своём контуре. В: Сколько длится внедрение? О: Пилот NEOMSA APIM на нескольких API занимает 4–6 недель. Остальные API переносят поэтапно, текущий шлюз работает параллельно. В: Чем APIM отличается от ESB? О: APIM управляет доступом потребителей к API. ESB связывает системы внутри компании: преобразует форматы и маршрутизирует сообщения. Подробнее: https://neomsa.ru/education/chto-takoe-esb --- ## Обучение: что такое ESB ### Что такое ESB: интеграционная шина предприятия и как она работает URL: https://neomsa.ru/education/chto-takoe-esb Дата: 2026-10-04 ESB (Enterprise Service Bus, сервисная шина предприятия) это слой, через который корпоративные системы обмениваются данными. Каждая система подключается только к шине. Шина принимает сообщение, переводит его в нужный формат и доставляет адресату. Шиной данных также называют канал между процессором и памятью компьютера. ESB к нему отношения не имеет: это программная платформа для интеграции систем. #### Зачем нужна интеграционная шина Без шины системы связывают напрямую. Если 10 систем обмениваются данными каждая с каждой, получается до 45 связей. У каждой свой формат и свой код, и замена одной системы ломает сразу несколько интеграций. С шиной у каждой системы одно подключение: 10 систем, 10 подключений. Новую систему подключают к шине один раз, и она получает данные от остальных. #### Как работает ESB 1. Система отправляет сообщение в шину через адаптер: REST, SOAP, файл, база данных, очередь. 2. Шина проверяет сообщение и преобразует формат, например XML в JSON. 3. Маршрутизатор выбирает получателей по содержимому сообщения. 4. Шина доставляет сообщение через адаптер получателя. 5. Каждый шаг пишется в журнал: видно, где сообщение и почему оно не дошло. Типовые сценарии описывают паттерны EIP (Enterprise Integration Patterns): маршрутизация по содержимому, разделение, агрегация, преобразование. В Apache Camel эти паттерны есть готовыми компонентами. На нём построены NEOMSA ESB, Apache ServiceMix и Red Hat Fuse. #### ESB, SOA и микросервисы SOA (сервисно ориентированная архитектура) делит функции компании на сервисы с описанными интерфейсами. ESB появилась как способ связать эти сервисы между собой. В микросервисной архитектуре сервисы мельче и общаются через API и события. Шина там тоже меняется: интеграционные маршруты разворачивают как отдельные сервисы в Kubernetes и масштабируют каждый по своей нагрузке. #### ESB, APIM и брокер сообщений | Инструмент | Задача | Пример | | --- | --- | --- | | ESB | Связывает системы внутри компании, преобразует форматы, маршрутизирует сообщения | Заказ из интернет-магазина уходит в 1С, складскую систему и CRM | | APIM | Открывает API потребителям и контролирует доступ | Партнёр получает остатки товаров через API | | Брокер сообщений | Доставляет сообщения между системами с гарантией | Платёжное поручение доходит до АБС без потерь | | Потоковая платформа | Передаёт события в реальном времени большими объёмами | События по транзакциям идут в антифрод | #### ESB и iPaaS iPaaS это интеграционная платформа, которую поставщик предоставляет как облачный сервис. ESB разворачивают в своей инфраструктуре. Банкам и промышленным компаниям, которые держат данные в своём контуре, подходит ESB или интеграционная платформа с установкой у себя. #### Когда компании нужна ESB - Десяток систем и больше обмениваются данными в разных форматах. - Интеграции написаны точечно, и каждую поддерживает отдельный разработчик. - Замена одной системы требует переписать несколько интеграций. - Нужен журнал обмена: кто отправил сообщение, где оно сейчас, почему не дошло. - Компания переходит с зарубежной шины на российскую. #### NEOMSA ESB NEOMSA ESB: российская интеграционная шина от Neoflex на Apache Camel. Паттерны EIP, адаптеры к SAP, 1С, Kafka, RabbitMQ и базам данных, работа на РЕД ОС и Astra Linux. В интерфейсе: проекты, маршруты, статусы сообщений и история изменений. Страница продукта: https://neomsa.ru/esb #### Вопросы и ответы В: Что такое ESB простыми словами? О: Посредник между системами компании. Системы отправляют данные в шину, шина переводит их в нужный формат и доставляет адресату. В: ESB и интеграционная шина это одно и то же? О: Да. ESB, сервисная шина предприятия и интеграционная шина: три названия одного класса систем. В: ESB устарела? О: Централизованные шины 2000-х годов плохо масштабировались. Современные шины разворачивают в Kubernetes, где каждый маршрут масштабируется отдельно. В: Чем ESB отличается от брокера сообщений? О: Брокер доставляет сообщение из очереди в очередь и не меняет его. ESB преобразует формат, выбирает получателя и вызывает сервисы. В: Можно ли использовать ESB вместе с APIM? О: Да. ESB связывает внутренние системы, APIM открывает результат партнёрам через API. Подробнее: https://neomsa.ru/education/chto-takoe-apim ## Обучение: интеграция корпоративных систем по отраслям ### Интеграция корпоративных систем в банке, ритейле и на производстве URL: https://neomsa.ru/education/integraciya-korporativnyh-sistem Дата: 2026-10-13 В банке интеграция корпоративных систем строится вокруг контроля внешних вызовов. Партнёры и мобильное приложение обращаются к одним и тем же системам, и каждое обращение нужно авторизовать и записать в журнал. Торговой сети нужно, чтобы цена и остаток совпадали на сайте, в приложении, на кассе и у агрегатора доставки. Завод связывает ERP с производственными системами, которые передают данные потоком событий. Эти задачи закрывают 4 компонента интеграционной платформы: шлюз и управление API, интеграционная шина, брокер сообщений, потоковая передача событий. В NEOMSA каждому компоненту соответствует свой продукт: APIM, ESB, MQ и Messaging. #### Интеграция в банке: API для банков, цифровой рубль и СБП В банке через API работают ДБО, партнёрские сервисы, маркетплейсы, страховые компании и бюро кредитных историй. Каждый вызов проходит авторизацию, попадает под лимит и остаётся в журнале. Что нужно банку от интеграционного слоя: - Открытые API банков: каталог и документация, выдача ключей и токенов участникам через портал разработчика. - Подключение к цифровому рублю. С 1 сентября 2026 года крупнейшие банки обязаны проводить операции клиентов с цифровым рублём. - Интеграция с СБП, процессингом и антифродом. Операция должна пройти за секунды, пока клиент ждёт на экране оплаты. - Обмен между АБС и внутренними системами без потери сообщений. Продукты NEOMSA для финансовых компаний: - NEOMSA APIM: шлюз API с авторизацией OAuth 2.0 и OpenID Connect, лимиты на каждого партнёра, портал разработчика, журнал вызовов. - NEOMSA MQ: очереди с гарантированной доставкой между АБС, процессингом и фронтальными системами. Отечественная замена IBM MQ. - NEOMSA ESB: маршрутизация и преобразование данных между АБС и остальными системами банка. Страховые компании решают похожую задачу: API страховой компании отдают расчёт полиса банкам, маркетплейсам и автодилерам. Здесь работают те же APIM и ESB. #### Интеграция с маркетплейсами и 1С в ритейле, FMCG и HoReCa Торговая сеть продаёт через сайт, приложение, кассы, маркетплейсы и агрегаторы доставки. Все каналы работают с одними и теми же ценами, остатками и заказами. Розница и интернет-торговля. Интеграция с маркетплейсами и агрегаторами доставки строится на общих API каталога, остатков, корзины и статусов заказа. В дни акций лимиты на каждого партнёра защищают ERP и учётные системы от перегрузки. FMCG. Производитель обменивается заказами, отгрузками и остатками с дистрибьюторами и сетями. Часть партнёров работает через EDI, часть через API. Интеграционная шина переводит данные из формата одной системы в формат другой. HoReCa. Рестораны связывают кассовые системы, агрегаторы доставки и программы лояльности. Интеграция iiko и 1С, iiko и агрегатора идёт через шину: каждую систему подключают к ней один раз. Многие компании в этих отраслях ведут учёт в 1С. В NEOMSA ESB есть адаптеры к 1С. Продукты NEOMSA для торговли: - NEOMSA APIM: единый вход для каналов и партнёров, кеш, лимиты, каталог API. - NEOMSA Messaging: события об изменении цен и остатков в реальном времени. - NEOMSA ESB: адаптеры к 1С, маршрутизация и преобразование данных. #### Интеграция ERP, MES и SCADA в промышленности и ТЭК На производстве в одном контуре работают ERP, MES, WMS, системы диспетчеризации и учёта. Предприятия, которые заменяют SAP, на время перехода держат старую и новую учётные системы параллельно. - Интеграция SAP и 1С. В NEOMSA ESB есть адаптеры к SAP и 1С. На время миграции данные двух систем идут через один поток. - Интеграция ERP и MES. Производственные события уходят в ERP через брокер сообщений. Данные из SCADA приходят через MES или шлюз сбора данных, дальше шина распределяет их по системам. - Базы данных. Шина работает с базами данных через адаптеры. - Kafka. Если на предприятии уже работает Kafka, шина подключается к ней через адаптер. NEOMSA Messaging заменяет Kafka там, где нужна российская платформа потоковой передачи событий. - Внешний контур. Портал для поставщиков, покупателей и подрядчиков работает через APIM. #### Интеграция TMS и биллинга, интеграция с ЕГИСЗ: телеком, транспорт, медицина Общая черта этих отраслей: каждый новый партнёр означает новое внешнее подключение со своим ключом, лимитами и мониторингом. - Телеком. Биллинг и OSS/BSS работают с сервисами экосистемы оператора. Корпоративные клиенты получают доступ к услугам связи через API. - Транспорт и логистика. Интеграция TMS и WMS с маркетплейсами, интернет-магазинами, перевозчиками и таможенными сервисами. - Медицина. Интеграция МИС с ЕГИСЗ, со страховыми компаниями по ДМС и с лабораториями. Шина переводит документы в формат каждой системы, брокер сообщений гарантирует доставку при сбоях. #### С чего начать внедрение интеграционной платформы | Отрасль | Первый продукт | Что проверяет пилот | | --- | --- | --- | | Банки и страхование | APIM на партнёрских API | Авторизация, лимиты и журнал вызовов по каждому партнёру | | Платёжные системы | MQ | Доставка сообщений между системами без потерь при сбоях | | Ритейл | Messaging для событий о ценах и остатках | Одна цена и один остаток во всех каналах | | FMCG и HoReCa | ESB с адаптерами 1С | Обмен заказами и остатками с партнёрами без ручных выгрузок | | Промышленность и ТЭК | ESB с адаптерами SAP и 1С | Поток данных между старой и новой учётной системой | | Телеком, транспорт, медицина | APIM для партнёрских подключений | Подключение нового партнёра к готовым API | В линейку NEOMSA также входят NEOMSA Container Platform и NEOMSA CI/CD. Платформа NEOMSA зарегистрирована в реестре российского ПО. #### Вопросы и ответы Можно ли начать с одного продукта NEOMSA? Да. Начать можно с APIM или ESB под одну задачу. Брокер сообщений и потоковую передачу событий подключают позже к тому же контуру. Чем интеграция в банке отличается от интеграции в ритейле? В банке главное: авторизация и журнал каждого внешнего вызова. В ритейле главное: одинаковые цены и остатки во всех каналах и устойчивость к пикам в дни акций. Работает ли NEOMSA с 1С и SAP? Да. В NEOMSA ESB есть адаптеры к 1С и SAP, а также к базам данных и Kafka. Чем заменить IBM MQ и Apache Kafka? IBM MQ, RabbitMQ и ActiveMQ заменяет NEOMSA MQ. Apache Kafka и Confluent Platform заменяет NEOMSA Messaging. Чем брокер сообщений отличается от интеграционной шины? Брокер передаёт сообщения между системами и гарантирует доставку. Шина дополнительно маршрутизирует сообщения, преобразует форматы и вызывает системы через адаптеры. Нужен ли APIM, если уже есть интеграционная шина? Шина связывает внутренние системы. APIM управляет доступом к API: выдаёт ключи, задаёт лимиты, публикует каталог для партнёров. Сколько длится пилот? Сроки зависят от продукта и задачи. Пилот APIM на нескольких API занимает около 3 недель. ## Обучение: что такое брокер сообщений ### Брокер сообщений: что это и как работает URL: https://neomsa.ru/education/chto-takoe-broker-soobshchenij Дата: 2026-10-16 Брокер сообщений принимает сообщение от одной системы, хранит его и передаёт другим системам. Отправитель не ждёт, пока получатель освободится, и не знает, сколько у сообщения получателей. Системы обмениваются данными, даже если одна из них временно недоступна. #### Как работает брокер сообщений В обмене участвуют 3 стороны: производитель (producer), брокер и потребитель (consumer). Производитель публикует сообщение. Брокер кладёт его в очередь или топик и хранит. Потребитель забирает сообщение, когда готов его обработать. Если потребитель недоступен, сообщение ждёт в брокере. #### Модели доставки: очередь и публикация с подпиской - Очередь (point-to-point). Каждое сообщение получает один потребитель. Модель подходит для распределения задач. - Публикация с подпиской (pub/sub). Сообщение получают все подписчики топика. Модель подходит для событий, на которые реагируют несколько систем. #### Гарантии доставки сообщений - At most once: не больше одного раза. Сообщение может потеряться, зато дублей нет. - At least once: хотя бы один раз. Сообщение не потеряется, но может прийти дважды, и получатель должен уметь обрабатывать повторы. - Exactly once: ровно один раз. В Kafka эта гарантия работает в связке с транзакциями внутри кластера. #### Брокер очередей сообщений и платформа потоковой передачи событий Брокер очередей (RabbitMQ, IBM MQ, ActiveMQ) удаляет сообщение после того, как потребитель подтвердил получение. Платформа потоковой передачи событий (Apache Kafka) хранит сообщения в журнале заданное время, независимо от того, прочитали их или нет, и позволяет перечитать историю с любой позиции. #### Брокеры сообщений Kafka и RabbitMQ: сравнение | Критерий | RabbitMQ | Apache Kafka | | --- | --- | --- | | Модель | очереди, маршрутизация через обменники (exchange) | журнал событий, разбитый на партиции | | Хранение | до подтверждения получения | заданный срок или объём, независимо от чтения | | Доставка потребителю | брокер отправляет сообщения сам (push) | потребитель запрашивает сообщения (pull) | | Повторное чтение | в классических очередях нет, в RabbitMQ Streams есть | да, с любой позиции | | Маршрутизация | direct, topic, fanout, headers | по топику и ключу партиции | | Протоколы | AMQP 0-9-1 и AMQP 1.0, через плагины MQTT и STOMP | собственный протокол поверх TCP | | Типичная задача | команды и задачи между сервисами | поток событий, аналитика, обмен данными между многими системами | #### Брокер сообщений и интеграционная шина Брокер доставляет сообщения. Интеграционная шина маршрутизирует их по правилам, преобразует форматы, вызывает системы через адаптеры и собирает многошаговые процессы. Шина часто использует брокер как транспорт. #### Брокеры сообщений в NEOMSA - NEOMSA MQ: брокер очередей с поддержкой протоколов AMQP, MQTT и STOMP. Маршрутизация и фильтрация по правилам, гарантированная доставка при сбоях сети и узлов, шифрование данных. Отечественная замена IBM MQ, RabbitMQ и ActiveMQ. - NEOMSA Messaging: платформа потоковой передачи событий. Семантика доставки at most once, at least once и exactly once, транзакции, реестр схем Avro, JSON Schema и Protobuf, интерфейс для администрирования кластеров. Российская замена Apache Kafka и Confluent Platform. Оба продукта внесены в реестр российского ПО. #### Вопросы и ответы Брокер сообщений и очередь сообщений: одно и то же? Нет. Очередь хранит сообщения, которые ждут обработки. Брокер управляет очередями, топиками и доставкой. Kafka это брокер сообщений? Да, Kafka часто называют брокером сообщений. Точнее её называть платформой потоковой передачи событий: она хранит сообщения после чтения и позволяет перечитывать их. Можно ли использовать Kafka и RabbitMQ вместе? Да. Kafka несёт поток событий между системами, RabbitMQ распределяет задачи внутри отдельных сервисов. Чем заменить IBM MQ? В NEOMSA для этого есть NEOMSA MQ: брокер очередей с гарантированной доставкой при сбоях сети и узлов. ## Обучение: безопасность API ### Безопасность API: защита API, mTLS, rate limiting и OWASP API Top 10 URL: https://neomsa.ru/education/bezopasnost-api Дата: 2026-10-22 В январе 2023 года T-Mobile сообщила, что злоумышленник больше месяца выкачивал через один из её API данные 37 млн клиентов. API при этом работал так, как его настроили: отвечал на запросы, которые ему присылали. Большинство атак на API так и выглядят. Запрос корректный, только идентификатор в нём чужой, токен украден или запросов в тысячу раз больше обычного. Безопасность API (API security) упирается в 4 вопроса. Кто обращается? К каким данным у него доступ? Сколько запросов ему можно отправить? И что останется в журналах, когда придётся разбираться? #### OWASP API Security Top 10 Сообщество OWASP ведёт список самых частых уязвимостей API. Актуальная редакция вышла в 2023 году. Первое место в ней, как и в редакции 2019 года, занимает авторизация на уровне объекта. | № | Уязвимость | Что происходит | |---|---|---| | API1 | Нарушение авторизации на уровне объекта (Broken Object Level Authorization) | Пользователь меняет идентификатор в запросе и получает чужой счёт или заказ | | API2 | Ошибки аутентификации (Broken Authentication) | Слабые токены, нет проверки срока действия, подбор паролей | | API3 | Нарушение авторизации на уровне свойств объекта (Broken Object Property Level Authorization) | API отдаёт или принимает поля, которые клиенту видеть или менять нельзя | | API4 | Неограниченное потребление ресурсов (Unrestricted Resource Consumption) | Нет лимитов на число и размер запросов | | API5 | Нарушение авторизации на уровне функций (Broken Function Level Authorization) | Обычный пользователь вызывает административный метод | | API6 | Неограниченный доступ к бизнес-процессам (Unrestricted Access to Sensitive Business Flows) | Бот скупает товар или массово регистрирует аккаунты | | API7 | Подделка запросов на стороне сервера (Server Side Request Forgery) | API по ссылке из запроса обращается во внутреннюю сеть | | API8 | Ошибки конфигурации (Security Misconfiguration) | Открытые отладочные методы, подробные ошибки, нет TLS | | API9 | Неучтённые API (Improper Inventory Management) | Старые версии и тестовые стенды остаются доступны снаружи | | API10 | Небезопасное потребление сторонних API (Unsafe Consumption of APIs) | Данные от партнёрского API принимаются без проверки | #### Аутентификация и управление токенами и ключами API Аутентификация API проверяет, кто прислал запрос. Авторизация API решает, что ему можно. Их часто путают, хотя ошибаются в них по-разному. Сломанная аутентификация пускает в систему чужого. Сломанная авторизация показывает своему пользователю чужие данные. Самый простой способ аутентификации: ключ API. Он подходит для внутренних интеграций и некритичных сценариев. Ключ сообщает, какое приложение пришло, а про пользователя ничего не знает. И ключи постоянно утекают: их коммитят в репозиторий, пишут в логи, пересылают в мессенджере. Для внешних клиентов берут OAuth 2.0. Приложение получает токен доступа с коротким сроком жизни и конкретным набором прав (scope), а пароль пользователя не видит вовсе. OpenID Connect надстраивается над OAuth 2.0 и добавляет проверку личности. Токены часто выпускают в формате JWT. У такого токена есть цифровая подпись, и шлюз проверяет её сам, без обращения к серверу авторизации. Управление API ключами и токенами держится на 4 привычках. Токены живут недолго. Ключи регулярно меняют. Скомпрометированный ключ отзывают в тот же день. Секреты лежат в хранилище секретов, в коде их быть не должно. #### mTLS: что это и чем отличается от TLS В обычном TLS сертификат показывает только сервер: клиент убеждается, что попал на настоящий сервер банка. В mTLS сертификат предъявляет и клиент. Соединение откроется, только если оба сертификата действительны и выпущены доверенным удостоверяющим центром. Зачем это нужно? Чтобы точно знать, какая система обращается к API. Банк подключает партнёра, процессинг ходит в платёжную систему, сервисы общаются внутри контура по модели нулевого доверия (zero trust). В сертификате mTLS записано имя клиентской системы, и по нему шлюз решает, какие API ей открыть. Сертификаты выпускает корпоративный удостоверяющий центр, и у них есть неприятное свойство: они истекают. Если за сроками никто не следит, обмен с партнёром однажды утром просто встанет. #### API rate limiting: ограничение частоты запросов Ограничение скорости запросов (rate limiting, в некоторых продуктах throttling) защищает API от перегрузки, подбора паролей и ботов. В списке OWASP оно закрывает пункты API4 и API6. Алгоритмов 4, и выбирают их под характер трафика. - Фиксированное окно. Не больше N запросов в минуту. Считать просто, но на стыке двух минут клиент успеет отправить двойную порцию. - Скользящее окно. Считает запросы за последние 60 секунд, поэтому поток получается ровнее. - Корзина токенов (token bucket). Разрешает короткие всплески, пока в корзине есть запас. - Протекающее ведро (leaky bucket). Пропускает запросы с постоянной скоростью, лишние ждут в очереди или отбрасываются. Когда лимит исчерпан, API отвечает кодом HTTP 429 Too Many Requests, а в заголовке Retry-After пишет, через сколько секунд можно повторить. С этим сталкивался почти каждый разработчик. GitHub API присылает сообщение «API rate limit exceeded», Gemini API возвращает 429, когда закончилась квота. Лимит вешают на ключ, пользователя, IP-адрес или отдельный метод. Квоты считают за день или месяц и привязывают к тарифу партнёра. #### Защита данных API Шифрование трафика API начинается с TLS 1.2 и выше. Банки и госсектор используют TLS на российских алгоритмах ГОСТ. Остальное держится на дисциплине команды. API отдаёт клиенту только нужные поля и маскирует персональные данные. Входящие запросы сверяются со схемой OpenAPI. В журналы вызовов не попадают токены, пароли и персональные данные: логи часто читает больше людей, чем имеет доступ к самому API. #### Тестирование безопасности API Тестирование безопасности API складывается из нескольких проверок: - Статический анализ кода и спецификаций OpenAPI. - Динамическое тестирование и фаззинг работающего API. - Тесты авторизации с чужими идентификаторами на каждый объект. Сканер не знает, чей это счёт, поэтому такие тесты пишут вручную. - Инвентаризация. API, которого нет в каталоге, никто не проверяет. Утечку у австралийского оператора Optus в 2022 году связывают с API, открытым без аутентификации. Пострадали данные почти 10 млн клиентов. - Аудит безопасности API. Внешняя команда проверяет API перед выпуском в продакшн и после крупных изменений. #### Системы защиты API: шлюз и WAF Шлюз API проверяет токены, применяет лимиты и пишет журнал вызовов в одной точке, и командам не приходится повторять это в каждом сервисе. WAF для API смотрит на содержимое запросов и отсекает атаки вроде SQL-инъекций. Его ставят перед шлюзом. Защита API от DDoS строится в 2 слоя. Объёмный трафик отсекает сетевой фильтр у провайдера. Лимиты шлюза следят, чтобы один клиент не съел все ресурсы сервиса. Есть и отдельный класс систем защиты API, API firewall. Он сверяет каждый запрос со спецификацией OpenAPI и отклоняет всё, чего в ней нет. У шлюза есть предел. Бизнес-логику он не знает и не проверит, принадлежит ли счёт тому, кто его запрашивает. Защиту от API1 закладывают в сам сервис. #### Безопасность API в NEOMSA APIM - Аутентификация на шлюзе API по OAuth 2.0 и OpenID Connect, в том числе через Keycloak. - Лимиты и квоты на партнёра, приложение и метод. - Каталог API на портале разработчика: все опубликованные API и их версии видны в одном месте. - Мониторинг API: метрики и журналы вызовов в Prometheus и Grafana. Подробнее: https://neomsa.ru/apim #### Вопросы и ответы Чем TLS отличается от mTLS? В TLS сертификат показывает только сервер. В mTLS свой сертификат предъявляет и клиент, поэтому сервер знает, какая именно система к нему подключилась. Что значит ошибка API rate limit exceeded? Приложение отправило больше запросов, чем ему разрешено, и получило код 429. Подождите время из заголовка Retry-After или попросите у владельца API лимит побольше. Достаточно ли шлюза API для защиты? Нет. Шлюз берёт на себя аутентификацию, лимиты и журналы. Права на конкретный объект проверяет сервис, от инъекций защищает WAF, остальное ловят тестами при разработке. Что такое OWASP API Security Top 10? Список 10 самых частых уязвимостей API, который ведёт сообщество OWASP. Актуальная редакция вышла в 2023 году. Как защитить REST API? Основы безопасности REST API: HTTPS с TLS 1.2 и выше, токены OAuth 2.0 вместо статичных ключей, проверка прав на каждый объект, лимиты запросов и проверка входных данных по схеме OpenAPI. Эти 5 практик закрывают пункты API1, API2, API4 и API8 из OWASP API Top 10.