SAP Integration Suite: решения и компромиссы в продуктивной среде

SAP Integration Suite представляет собой интеграционную платформу SAP на SAP BTP: Cloud Integration (бывший CPI), API Management, Event Mesh, Integration Advisor, Open Connectors и инструменты миграции с PI/PO. Она служит стандартным middleware для облачных программ S/4HANA и путём ухода с PI/PO, основная поддержка которого заканчивается в 2027 году. Задержки интерфейсов редко вызваны технологией. Их причины: неясное владение, непроверенные допущения о legacy-системах и тестирование, рассчитанное на то, чтобы пройти, а не на то, чтобы найти сбои. Руководство адресовано руководителям по интеграции, архитекторам и руководителям программ. В нём разобрано, для чего нужен каждый компонент, стандартный и заказной контент, миграция PI/PO, риски legacy и тестирования и управление после go-live.

Для PI/PO идёт обратный отсчёт. SAP Process Integration и Process Orchestration 7.5 находятся в основной поддержке до конца 2027 года. Необязательная расширенная поддержка действует до конца 2030 года, после чего поддержка SAP прекращается. Маршрут описан в эталонной архитектуре миграции SAP. В Integration Suite входит приложение Migration Assessment, которое оценивает каждый сценарий PI/PO, а в Cloud Integration есть инструменты миграции на основе мастеров. Мигрируйте волнами: сначала малорисковые потоки между системами SAP, в середине B2B и EDI, в конце потоки заказов с большим объёмом. Вынужденный cutover под давлением срока занимает больше времени и стоит дороже.

1. Волна 1Малорисковые потоки между системами SAPСначала оцените каждый сценарий через Migration Assessment
2. Волна 2B2B и EDI
3. Волна 3Потоки заказов с большим объёмом
4. 2027Заканчивается основная поддержка PI/PO 7.5Конец года. Спланируйте волны так, чтобы завершить до этой даты
5. 2030Заканчивается необязательная расширенная поддержкаКонец года. После этого поддержка SAP прекращается

Источник: Даты поддержки SAP и эталонная архитектура миграции, проверено в октябре 2026 года

Проверьте, что покрывает ваш облачный договор. Договоры RISE и GROW обычно включают кредиты SAP BTP, которыми можно оплатить Integration Suite. Выясните, какую редакцию и какие объёмы сообщений покрывает ваш пакет подписки, прежде чем сравнивать Integration Suite с MuleSoft или Boomi только по функциям. Экономика уже включённой платформы меняет сравнение.

ИИ приходит поэтапно. Cloud Integration предлагает генерацию потоков с помощью генеративного ИИ в редакции Premium с середины 2024 года. Она создаёт структуру iFlow (шаги, каналы, подпроцесс исключений), но не маппинги и не скрипты. Редакция Enhanced от SAP, запущенная в марте 2026 года, добавляет генерацию потока по текстовому описанию и оптимизацию скриптов, а Joule в Integration Suite SAP планировала вывести в общую доступность в третьем квартале 2026 года. Полезно для стандартных потоков. Сложной оркестрации с глубокой бизнес-логикой по-прежнему нужны старшие архитекторы.

Integration Suite представляет собой набор сервисов. От того, подходящий ли сервис выбран для задачи, зависит, насколько устойчив ландшафт.

Компонент	Роль	Что идёт не так при неправильном использовании
Cloud Integration (CPI)	Потоки сообщений, маршрутизация и преобразование; вариант по умолчанию для большинства iFlow	Всё, что запихнули в CPI, включая API и события, становится трудно поддерживать и тестировать
API Management	Управляет публикацией API: безопасность, лимиты запросов, аналитика	Если пропустить, множатся прямые вызовы между системами; управление трудно ввести задним числом
Event Mesh	Асинхронный обмен сообщениями для слабосвязанных триггеров	Неотслеживаемые очереди тихо растут, никого не предупреждая
Integration Advisor	Предложения по маппингам для B2B-форматов, таких как EDIFACT, X12 и IDoc	Команды рассчитывают на высокое покрытие; одна команда ждала 80 %, а получила около 40 %
Open Connectors	Готовые коннекторы к сторонним облачным приложениям	Изменения во внешних API молча ломают коннекторы, если за ними никто не следит
Migration Assessment и инструменты миграции	Оценивают и переносят сценарии PI/PO	Их воспринимают как разовую оценку, а не как рабочий план миграции

Команды, которые считают Integration Suite «CPI с надстройками», часто игнорируют API Management и Event Mesh. Это работает, пока не нагоняет сложность. Подробнее о самом Cloud Integration в моём руководстве по SAP CPI.

Готовый интеграционный контент SAP действительно полезен, когда процесс стандартный. Подключение S/4HANA к SAP Ariba или SuccessFactors со стандартными процессами часто ложится чисто. Реальные процессы редко остаются в рамках эталонных линий SAP.

Выбирайте стандартный контент, когда:

1. сценарий связывает системы SAP и близок к эталонному процессу SAP
2. поток простой и в основном односторонний
3. вас устраивает маппинг SAP, и вы расширяете его только через предусмотренные точки расширения

Выбирайте заказную разработку, когда:

1. годы внутренних решений увели процесс от модели SAP
2. в процессе есть условная маршрутизация, многошаговая логика или особенности legacy-систем
3. серьёзные изменения нарушили бы условия поддержки SAP для стандартного пакета

Принимайте это решение на этапе Blueprint. Если оно принимается поздно, команды обнаруживают посреди проекта, что «стандартный» iFlow изменён так сильно, что перестал соответствовать условиям поддержки SAP, и перестраивают его под давлением go-live. Я видел проекты, которые теряли недели, потому что команды считали, что стандартный контент справится сразу и с нестандартными структурами основных данных, и с дополнительными полями, и с аутентификацией legacy-систем. Он не справился. Анализ, который должен был проходить на проектировании, пришёлся на UAT.

В крупных программах SAP интеграция часто первой оказывается в зазоре между потоками работ. Интерфейсы пересекают границы команд, но координацией никто не владеет. Я видел, как две проектные команды строили отдельные интеграции для одного и того же бизнес-партнёра, направленные на одну и ту же конечную точку, и не знали друг о друге. Ни одна из них не узнала об этом до UAT. Это структурный сбой, а не технический.

Заранее выстройте централизованное управление интеграцией:

1. Общий бэклог интеграции, видимый каждому потоку работ
2. Именованный владелец каждого интерфейса, за которым следят на протяжении всей поставки
3. Контрольные точки координации между потоками работ перед каждым крупным развёртыванием
4. Анализ зависимостей интерфейсов до любых обязательств по go-live, с последовательностью общих конечных точек и очередей в плане cutover
5. Автоматизированное развёртывание между средами, с документированными учётными данными для каждого ландшафта

Самые трудные проблемы интеграции редко связаны с современными платформами. Они связаны со старыми системами в центре критичных процессов.

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

Несовпадения протоколов встречаются часто и обнаруживаются поздно. Вы проектируете с OAuth2 и REST, а legacy-система говорит на SOAP с жёстко заданным таймаутом 30 секунд и плохо обрабатывает обновление токенов.

У одного клиента поток в middleware падал каждую пятницу, потому что токен, выданный сторонней системой расчёта зарплаты, истекал раз в неделю. Никто не замечал этого до второго цикла UAT. Подобные причуды встречаются часто и съедают сроки.

В таблице перечислены риски, которые нужно проверить до заморозки дизайна.

Риск	Типичная проблема	Что делать на этапе проектирования
Ограничения синхронных вызовов	Legacy-система зависает при параллельных вызовах	Используйте асинхронный обмен; разносите вызовы по времени через Event Mesh или Cloud Integration
Несовпадение протоколов	Legacy-система отвергает REST или OAuth либо обрывается по таймауту на SOAP	Подтвердите протоколы и таймауты до начала проектирования
Лимиты запросов API	Пакетные задания превышают ограничения стороннего сервиса	Ограничивайте поток в API Management; добавьте логику ожидания в iFlow
Истечение токенов	Потоки тихо падают в непиковые окна	Запланируйте циклы обновления и следите за сроком действия
Жёсткие форматы	Динамическое содержимое сообщений ломает разбор в legacy-системе	Проверяйте на реальных образцах из продуктива
Нет запасного варианта	Передача файлов обрывается без повтора, и данные застревают	Буферизуйте в middleware; встройте повторные попытки и оповещения в iFlow

Версию этих проблем для интеграции между облаками смотрите в моём материале о том, почему интеграция ERP с Salesforce не работает и как это исправить.

Интеграция ломается не так, как это проверяют функциональные тесты. Она ломается из-за тайминга, когда пересекаются фоновые задания и когда данные приходят большим объёмом, а не по одному. Функциональный тест доказывает, что транзакция проводится и сообщение появляется в журнале. Он не доказывает, что произойдёт, когда первый расчёт зарплаты отправит поток IDoc. На одном проекте IDoc, который выглядел чистым при системно-интеграционном тестировании, остановил очередь, когда пошли реальные объёмы расчёта зарплаты. Нашло это только нагрузочное тестирование.

Тестирование интерфейсов должно охватывать:

1. реалистичные объёмы данных при одновременной работе пользователей
2. перебои в работе сервисов и поведение при восстановлении
3. таймауты и повторные попытки в middleware и серверных системах
4. пакетные задания, работающие одновременно с вызовами в реальном времени
5. конец месяца и другие пиковые периоды

В средах разработки всё чисто. Дедлоки, состояния гонки и троттлинг проявляются в UAT и предпродуктивной среде, где работают другие системы и окна пакетных заданий, поэтому нагрузочные тесты проводите там. Чётко разделите ответственность: функциональные команды проверяют бизнес-результаты по всему потоку, интеграционные команды отвечают за журналы, повторные попытки и потоки исключений, а руководители проектов подтверждают покрытие. Сторону нагрузки разбирает моё руководство по тестированию производительности SAP.

Integration Advisor предлагает маппинги для структурированных B2B-форматов. Для партнёров, которые строго следуют соглашениям, он действительно экономит время на настройке. Для корпоративных интеграций с legacy-системами, заказными полями, условной логикой и недокументированными правилами он остаётся отправной точкой.

Одна команда, с которой я работал, ожидала покрытия маппингов на 80 %. Фактическое покрытие составило около 40 %. Остальное пришлось дорабатывать, согласовывать с бизнесом и тестировать вручную.

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

После go-live интеграция деградирует, когда документация расходится с реальностью, а владение не оформлено. Полезная документация охватывает маппинги полей и логику преобразований, а также сведения об аутентификации: конечные точки, обновление токенов и ротацию учётных данных. Она охватывает также обработку ошибок, правила резервных вариантов и ожидаемые объёмы в критичные окна, такие как конец месяца и расчёт зарплаты. Проверка простая: сможет ли человек, который придёт в команду поддержки на следующей неделе, разобраться со сбоящим интерфейсом только по документации?

У каждого интерфейса, даже с малым объёмом, должен быть именованный владелец, отвечающий за мониторинг, эскалацию и изменения жизненного цикла. Без него сбои переходят между командами Basis, middleware и функциональными командами, пока бизнес ждёт. После hypercare мониторинг, как правило, затухает. Выстройте регулярные проверки журналов ошибок, формальную передачу из проекта в поддержку и уровни сервиса, согласованные между бизнесом и ИТ. Забытая интеграция стоит за многими задержанными проводками, пропавшими счетами и несогласованной финансовой отчётностью, которые всплывают через недели после go-live.

Что такое SAP Integration Suite и чем он отличается от CPI?

Cloud Integration, ранее SAP Cloud Platform Integration (CPI), является одной из возможностей Integration Suite. Набор добавляет API Management для управляемой публикации API и Event Mesh для асинхронного обмена сообщениями. В него входят также Integration Advisor для предложений по B2B-маппингам, Open Connectors для сторонних облачных приложений и инструменты оценки и миграции для PI/PO. Команды, которые считают его CPI с новым названием, часто пропускают API Management и Event Mesh и позже расплачиваются за это пробелами в управлении.

Когда заканчивается поддержка SAP PI/PO?

SAP Process Integration и Process Orchestration 7.5 находятся в основной поддержке до конца 2027 года. Клиенты могут оформить необязательную расширенную поддержку до конца 2030 года, после чего поддержка SAP прекращается. В Integration Suite входят приложение Migration Assessment для оценки каждого сценария и инструменты миграции, которые переносят артефакты в полуавтоматическом режиме. Начните с плана волн, а не ждите срока.

Когда в интеграции SAP использовать стандартный контент, а когда заказную разработку?

Используйте стандартный контент, когда сценарий связывает системы SAP, близок к эталонному процессу SAP и относительно прост. Выбирайте заказную разработку, когда процесс ушёл от модели SAP, когда особенности legacy-систем требуют особой обработки или когда условная и многошаговая логика заставила бы сильно менять стандартный пакет. Решайте на этапе Blueprint: перестройка чрезмерно изменённого стандартного потока под давлением go-live обходится дороже, чем чистая заказная разработка.

Что вызывает сбои интеграции SAP в сложных программах?

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

Как структурировать интеграционное тестирование для SAP Integration Suite?

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

Как управлять интеграцией SAP после go-live?

Назначьте каждому интерфейсу именованного владельца, отвечающего за мониторинг, эскалацию и изменения. Поддерживайте документацию в актуальном состоянии: маппинги, аутентификацию и ротацию учётных данных, обработку ошибок и ожидаемые объёмы. И выстройте долгосрочную модель поддержки с регулярными проверками журналов ошибок, формальной передачей из проекта в поддержку и согласованными уровнями сервиса. Интеграция, которая становится невидимой, оказывается заброшенной.