SAP CPI: что это, архитектура и переход с PI/PO

SAP CPI (Cloud Platform Integration) является облачным промежуточным ПО SAP для связи систем SAP и не-SAP. Сегодня он называется Cloud Integration и является основной функцией SAP Integration Suite на SAP Business Technology Platform (SAP BTP).

Он передаёт сообщения между приложениями, преобразует их формат и направляет нужному получателю. Если у вас всё ещё работает SAP PI/PO, время имеет значение: основная поддержка SAP NetWeaver 7.5, в состав которого входит PI/PO, заканчивается в конце 2027 года.

В этом руководстве: что делает CPI, как устроена его архитектура, чем он отличается от PI/PO и как спланировать переход. Оно написано для руководителей по интеграции и ИТ-директоров, а не только для разработчиков.

Я видел, как команды месяцами строили хрупкие самописные скрипты для связи систем SAP и не-SAP. Поначалу что-то работает. Потом обновление системы меняет имя поля, или выходит новая версия API, или трафик удваивается.

Скрипт тихо ломается. Никто не знает об этом, пока отчёт не подтянет устаревшие данные или заказ не пролежит необработанным три дня.

CPI заменяет это управляемыми, многократно используемыми интеграционными потоками. Не потому, что так проще (часто это не так), а потому, что архитектура рассчитана на мониторинг и сопровождение. Мелкие решения, принятые на ранней стадии проектирования CPI, превращаются в технический долг быстрее, чем ожидает большинство команд.

Мой совет любой компании, которая всё ещё работает на SAP PI/PO: переходить на SAP Integration Suite. Самый частый провал интеграции, который я вижу: на интеграцию тратят слишком мало времени.

Собственное руководство SAP по миграции описывает Cloud Integration как функцию для проектирования и выполнения интеграционных потоков в облачных, локальных и гибридных средах. Она охватывает сценарии «приложение с приложением» (A2A), «бизнес с бизнесом» (B2B) и «бизнес с государством» (B2G). Большинство консультантов по-прежнему называют её «CPI» или «SAP CI», и это нормально.

SAP Integration Suite объединяет Cloud Integration с другими функциями. Основные из них: API Management, Event Mesh, Integration Advisor, Trading Partner Management, Open Connectors и Migration Assessment.

Что делает CPI: передаёт данные между системами, преобразует форматы сообщений, направляет их нужному получателю, обрабатывает ошибки и повторные попытки. Он связывает системы SAP (S/4HANA, SuccessFactors, Ariba) и платформы не-SAP (Salesforce, Workday, ServiceNow) через стандартные адаптеры.

Чего он не делает: не хранит данные долгосрочно, не заменяет ERP и не служит ETL-инструментом для массовой миграции данных. Он создан для сообщений в реальном или почти реальном времени. Использование его как хранилища данных или инструмента миграции позже приводит к проблемам архитектуры.

CPI и SAP BTP: BTP является платформой целиком: разработка приложений, данные, AI, аналитика и интеграция. CPI является одним из сервисов на ней. Архитектор BTP проектирует решения на нескольких сервисах; специалист по CPI отвечает за потоки, адаптеры, маппинги и подключения.

На схеме ниже показаны сценарии интеграции, для которых создан CPI. Облако с облаком, локальная система с облаком, бизнес с бизнесом (B2B), бизнес с государством (B2G) и подключения пользователей и устройств.

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

CPI работает как мультитенантный облачный сервис на SAP BTP. Платформой управляет SAP, поэтому собственные интеграционные серверы поддерживать не нужно. Если поток должен выполняться внутри вашей сети, Edge Integration Cell служит дополнительной гибридной средой выполнения: вы проектируете и отслеживаете поток в облаке, а выполняется он в вашей сети.

Поток сообщений на практике

В основе лежит iFlow (интеграционный поток). Каждая интеграция в CPI моделируется как iFlow, и каждый iFlow передаёт сообщение от источника к получателю в три этапа:

1. Адаптер отправителя. Принимает сообщение из исходной системы по SOAP, REST, OData, IDoc, SFTP, JMS, AS2 или другому протоколу.
2. Шаги обработки. Маппинг, преобразование формата (например, JSON в XML), маршрутизация по содержимому, вызовы других систем, шифрование и обработка ошибок.
3. Адаптер получателя. Отправляет обработанное сообщение получателю.

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

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

Компоненты архитектуры SAP CPI

В таблице каждому компоненту сопоставлена его роль в архитектуре.

Компонент	Что делает	Роль в архитектуре
Среда выполнения интеграционных потоков	Выполняет iFlow	Отвечает за маршрутизацию, маппинг, преобразование и безопасность во время выполнения
Веб-дизайнер	Графический редактор для создания, настройки и развёртывания iFlow	Здесь разработчики моделируют потоки; сложная логика всё равно требует Groovy или JavaScript
Адаптеры	SOAP, REST, OData, IDoc, JDBC, SFTP, JMS, AS2 и адаптеры для конкретных SaaS	Подключают облачные и локальные системы
Безопасность	OAuth 2.0, SAML, TLS, управление сертификатами и ключами	Защищает учётные данные и сообщения при передаче
Мониторинг и эксплуатация	Журналы сообщений, сведения об ошибках, повторные попытки, оповещения	Позволяет группам поддержки находить и устранять сбои
Готовый контент	Интеграционные пакеты от SAP в SAP Business Accelerator Hub	Ускоряет стандартные сценарии за счёт проверенного контента
SAP Cloud Connector	Защищённый туннель из вашей сети в SAP BTP	Обеспечивает доступ к локальным системам, не открывая их в интернет
Edge Integration Cell	Дополнительная среда выполнения в вашем собственном ЦОД или частном облаке	Для потоков, которые должны оставаться локальными

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

Сейчас почти каждый план интеграции определяют три даты.

1. 2027Заканчивается основная поддержка PI/POКонец года, для SAP NetWeaver 7.5
2. 2028Прекращается работа Cloud Integration в Neo31 декабря. Тенанты Neo переходят на Cloud Foundry
3. 2030Заканчивается расширенная поддержка PI/POКонец года. Последний рубеж для любой системы PI/PO

Источник: SAP Note 1648480 и SAP Knowledge Base Article 3355661

1. Ресурс PI/PO заканчивается. SAP Note 1648480 устанавливает основную поддержку SAP NetWeaver 7.5, в состав которого входит PI/PO, до конца 2027 года, а расширенную до конца 2030 года. 1 января 2028 года система не остановится, но каждый следующий год её содержание будет обходиться дороже.
2. Neo закрывается. SAP Knowledge Base Article 3355661 подтверждает, что Cloud Integration в среде SAP BTP Neo прекращает работу 31 декабря 2028 года. Ранним тенантам CPI на Neo нужно перейти в мультиоблачную среду (Cloud Foundry), и этот переход сам по себе является небольшим проектом.
3. У гибридных сценариев есть ответ. Edge Integration Cell выполняет потоки Integration Suite внутри вашей сети. Это снимает самую частую причину, по которой команды оставались на PI/PO.

О коммерческой стороне: если у вас RISE with SAP, проверьте, какие права на SAP BTP уже включены в ваш контракт, прежде чем покупать мощности Integration Suite отдельно.

PI (Process Integration) и PO (Process Orchestration) являются локальным промежуточным ПО SAP. Вот как они соотносятся с CPI.

Фактор	SAP PI/PO	SAP CPI (Integration Suite)
Развёртывание	Локально, на ваших серверах	Облако на SAP BTP; Edge Integration Cell для локальной среды выполнения
Затраты на сопровождение	Высокие: патчи, обновления, администрирование серверов	Ниже: платформой управляет SAP
Расширяемость	Глубокая доработка; обновляться сложнее	Модульность; более быстрые обновления; меньше низкоуровневого контроля
Лицензирование	Лицензия плюс собственная инфраструктура	Подписка на SAP BTP, по редакциям
Направление инвестиций	Только сопровождение, новых функций нет	Активная разработка
Окончание основной поддержки	Конец 2027 года (расширенная до конца 2030 года)	Не применимо (облачный сервис)

В руководстве SAP по миграции Cloud Integration рассматривается как основная замена, потому что покрывает большую часть того, что делает PI/PO. Узнайте у SAP, как тарифицируется ваша редакция, и смоделируйте это на реальных объёмах сообщений до миграции. Некоторые компании обнаруживают, что их интеграционный трафик выше, чем они думали.

Миграция не является автоматической конвертацией. Адаптеры в PI и CPI ведут себя по-разному, а обработка ошибок, которая работала в PI, в CPI может вести себя иначе. Одни потоки нужно перестраивать, другие переносятся с небольшими изменениями.

SAP предоставляет два официальных инструмента:

1. Migration Assessment. Функция Integration Suite, которая подключается к вашей системе PO, извлекает интеграционные сценарии и оценивает трудозатраты на их перенос. Настройка описана в учебном руководстве SAP.
2. Migration Tooling. Функция Cloud Integration, которая полуавтоматически переносит объекты интегрированной конфигурации (ICO) из PO в iFlow. С её помощью можно перенести только сценарии со статусом оценки «Ready to migrate» или «Adjustment required».

В SAP Learning прямо сказано, что единого пути миграции для всех клиентов нет, и многие на время перехода параллельно используют PI/PO и Integration Suite. Инструменты сокращают механическую работу. Решения о том, что перестраивать, а что выводить из эксплуатации, они не принимают.

Вот план по волнам, который я использую как отправную точку. Подстройте волны под свой реестр.

Волна	Что переносится	Почему в таком порядке	Ответственный	Критерии выхода
0. Реестр	Каждый интерфейс PI: частота, объём, адаптер, критичность, владелец	Нельзя спланировать то, что не посчитано	Руководитель по интеграции	Реестр подписан владельцами со стороны бизнеса
1. Низкий риск	Потоки SAP-SAP со стандартным контентом	Проверяет операционную модель и мониторинг	Руководитель по интеграции	Две недели стабильной работы в продуктиве, путь через PI выведен из эксплуатации
2. Партнёры	Потоки B2B и EDI с ключевыми торговыми партнёрами	Нужны окна тестирования с партнёрами и согласованное переключение	Руководитель по интеграции вместе с закупками и продажами	Каждый партнёр подтверждает в письменном виде
3. Высокий риск	Высоконагруженные, регулируемые или критичные для выручки потоки	Переносятся последними, с наибольшим числом репетиций	Архитектор интеграции	Нагрузочный тест пройден; откат на PI отрепетирован
4. Вывод из эксплуатации	PI/PO отключается	Прекращается оплата двух платформ	ИТ-директор	Все потоки перенесены или выведены; лицензии прекращены

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

Интеграционное тестирование съедает время. Планируйте регрессионное тестирование с B2B-партнёрами и системами не-SAP заранее, потому что они ломаются тихо. В моём руководстве по тестированию SAP описано, как выстроить циклы интеграционного и регрессионного тестирования.

Если переход с PI/PO является частью программы S/4HANA, согласуйте оба плана. В моём руководстве по миграции с ECC на S/4HANA описаны пути и сроки со стороны ERP.

Сценарии, которые я вижу чаще всего:

1. S/4HANA и SuccessFactors. Организационные данные, численность и изменения вознаграждения. Стандартный интеграционный контент SAP покрывает типичные сценарии; самописные потоки обрабатывают отклонения.
2. Устаревшая система закупок и SAP Ariba. Заказы на поставку уходят, подтверждения и счета возвращаются. Обычно в обе стороны.
3. Финансовые данные в SAP Analytics Cloud. Передача данных из ECC или систем не-SAP в SAC.
4. Salesforce и SAP. Закрытые сделки поступают в SAP для исполнения, выставления счетов и обновления запасов. В моём материале о том, почему не работает интеграция Salesforce с ERP, разобраны ошибки проектирования.

Если интеграционные работы в вашей программе уже отстают, в материале о задержках поставки SAP Integration Suite разобраны типичные причины. В обзоре интеграционных платформ SAP варианты сравниваются бок о бок.

Что такое SAP CPI и как он называется сейчас?

SAP CPI расшифровывается как Cloud Platform Integration. Сейчас это функция Cloud Integration в SAP Integration Suite на SAP BTP, наряду с API Management, Event Mesh и инструментами интеграции с партнёрами. «CPI» остаётся повседневным названием для разработки интеграционных потоков.

Что такое SAP CI?

SAP CI является сокращением от SAP Cloud Integration, текущего названия того, что раньше называлось SAP CPI. Оба термина обозначают одну и ту же функцию внутри SAP Integration Suite.

Является ли SAP CPI промежуточным ПО?

Да. CPI является облачным промежуточным ПО: он находится между системами, преобразует и маршрутизирует сообщения, обрабатывает ошибки и повторные попытки. Он заменяет локальное промежуточное ПО, такое как SAP PI/PO, и не хранит бизнес-данные долгосрочно.

Чем SAP CPI отличается от SAP PI/PO?

PI/PO является локальным промежуточным ПО, которое вы сами устанавливаете, обновляете и эксплуатируете. CPI является облачным сервисом на SAP BTP, которым за вас управляет SAP, а новые адаптеры и контент поступают централизованно. Edge Integration Cell покрывает потоки, которые должны оставаться локальными.

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

Основная поддержка SAP NetWeaver 7.5, в состав которого входит PI/PO, заканчивается в конце 2027 года. Расширенная поддержка доступна до конца 2030 года. Для переноса сценариев в Integration Suite SAP предлагает Migration Assessment и Migration Tooling.

SAP CPI и SAP BTP это одно и то же?

Нет. SAP BTP является платформой: разработка приложений, данные, аналитика, AI и интеграция. CPI является сервисом интеграции на ней.

При планировании работ бюджет и навыки различаются: архитектор BTP работает на нескольких сервисах, специалист по CPI отвечает за потоки, адаптеры и маппинги.

Если вы планируете переход с PI/PO или проектируете интеграцию для новой программы S/4HANA, начните с реестра интерфейсов. Если вам нужен второй взгляд на план, прежде чем вы на него согласитесь, свяжитесь со мной.