SAP CPI: o que é, sua arquitetura e a migração do PI/PO

O SAP CPI (Cloud Platform Integration) é o middleware em nuvem da SAP para conectar sistemas SAP e não SAP. Hoje ele se chama Cloud Integration, a capacidade central do SAP Integration Suite na SAP Business Technology Platform (SAP BTP).

Ele move mensagens entre aplicações, transforma o formato delas e as roteia para o destino certo. Se você ainda usa o SAP PI/PO, o relógio importa: a manutenção principal do SAP NetWeaver 7.5, que inclui o PI/PO, termina no fim de 2027.

Este guia mostra o que o CPI faz, como a sua arquitetura funciona, como ele se compara ao PI/PO e como planejar a migração. Foi escrito para líderes de integração e CIOs, não só para desenvolvedores.

Já vi equipes passarem meses construindo scripts customizados e frágeis para conectar sistemas SAP e não SAP. No início, algo funciona. Depois, uma atualização de sistema muda o nome de um campo, ou sai uma nova versão de API, ou o tráfego dobra.

O script quebra em silêncio. Ninguém percebe até que um relatório traga dados desatualizados ou um pedido fique parado sem processamento por três dias.

O CPI substitui isso por fluxos de integração gerenciados e reutilizáveis. Não porque seja mais simples (muitas vezes não é), mas porque a arquitetura foi feita para ser monitorada e mantida. Pequenas decisões tomadas no início do desenho do CPI se acumulam em dívida técnica mais rápido do que a maioria das equipes imagina.

Meu conselho a qualquer empresa que ainda esteja no SAP PI/PO é migrar para o SAP Integration Suite. A falha de integração mais comum que vejo é não dedicar tempo suficiente à integração.

O guia de migração da própria SAP descreve o Cloud Integration como a capacidade para desenhar e executar fluxos de integração em ambientes de nuvem, on-premise e híbridos. Ele cobre cenários aplicação a aplicação (A2A), empresa a empresa (B2B) e empresa a governo (B2G). A maioria dos consultores ainda o chama de “CPI” ou “SAP CI”, e tudo bem.

O SAP Integration Suite reúne o Cloud Integration com outras capacidades. As principais são API Management, Event Mesh, Integration Advisor, Trading Partner Management, Open Connectors e Migration Assessment.

O que o CPI faz: move dados entre sistemas, transforma formatos de mensagem, roteia para o destino certo e trata erros e novas tentativas. Ele conecta sistemas SAP (S/4HANA, SuccessFactors, Ariba) e plataformas não SAP (Salesforce, Workday, ServiceNow) por meio de adaptadores padrão.

O que ele não faz: armazenar dados a longo prazo, substituir um ERP ou servir de ferramenta de ETL para migração de dados em massa. Ele foi feito para mensagens em tempo real ou quase real. Usá-lo como data warehouse ou ferramenta de migração causa problemas de arquitetura mais adiante.

CPI versus SAP BTP: o BTP é a plataforma inteira: desenvolvimento de aplicações, dados, AI, analytics e integração. O CPI é um serviço dentro dela. Um arquiteto de BTP desenha entre os serviços; um especialista em CPI é dono dos fluxos, adaptadores, mapeamentos e da conectividade.

O diagrama abaixo mostra os cenários de integração para os quais o CPI foi feito. Nuvem a nuvem, on-premise a nuvem, empresa a empresa (B2B), empresa a governo (B2G) e conexões com usuários e dispositivos.

Entender a arquitetura do CPI não é só para desenvolvedores. Na minha experiência, as equipes que entendem como o CPI trata a integração no nível estrutural costumam fazer escolhas de desenho melhores logo de início.

O CPI roda como um serviço em nuvem multitenant no SAP BTP. A SAP opera a plataforma, então você não mantém servidores de integração próprios. Quando um fluxo precisa rodar dentro da sua própria rede, o Edge Integration Cell é um runtime híbrido opcional: você desenha e monitora na nuvem e executa o fluxo na sua própria rede.

O fluxo de mensagens na prática

No centro está o iFlow (fluxo de integração). Toda integração no CPI é modelada como um, e cada iFlow leva uma mensagem de uma origem a um destino em três etapas:

1. Adaptador emissor. Recebe a mensagem do sistema de origem via SOAP, REST, OData, IDoc, SFTP, JMS, AS2 ou outro protocolo.
2. Etapas de processamento. Mapeamento, conversão de formato (de JSON para XML, por exemplo), roteamento baseado em conteúdo, chamadas a outros sistemas, criptografia e tratamento de erros.
3. Adaptador receptor. Envia a mensagem processada ao seu destino.

Os fluxos rodam de forma síncrona ou assíncrona, conforme o caso de uso. Nem sempre é óbvio qual escolher, então teste os dois com volumes reais.

O monitoramento tem um papel grande. Você tem logs de processamento de mensagens, trace e mensagens persistidas, cada um com uma finalidade diferente. Durante testes ou depuração, costumo alternar entre trace e persist, dependendo de quão fundo preciso ir.

Componentes da arquitetura do SAP CPI

A tabela relaciona cada componente à sua função na arquitetura.

Componente	O que faz	Papel na arquitetura
Runtime de fluxos de integração	Executa os iFlows	Cuida de roteamento, mapeamento, transformação e segurança em tempo de execução
Designer web	Editor gráfico para construir, configurar e implantar iFlows	Onde os desenvolvedores modelam os fluxos; lógica complexa ainda exige Groovy ou JavaScript
Adaptadores	SOAP, REST, OData, IDoc, JDBC, SFTP, JMS, AS2 e adaptadores específicos de SaaS	Conectam sistemas em nuvem e on-premise
Segurança	OAuth 2.0, SAML, TLS, gestão de certificados e chaves	Protege credenciais e mensagens em trânsito
Monitoramento e operações	Logs de mensagens, detalhes de erros, novas tentativas, alertas	Permite às equipes de suporte encontrar e corrigir falhas
Conteúdo pré-empacotado	Pacotes de integração entregues pela SAP no SAP Business Accelerator Hub	Acelera cenários padrão com conteúdo testado
SAP Cloud Connector	Túnel seguro da sua rede para o SAP BTP	Alcança sistemas on-premise sem expô-los à internet
Edge Integration Cell	Runtime opcional no seu próprio data center ou nuvem privada	Para fluxos que precisam ficar on-premise

Scripts Groovy tratam a lógica que as etapas gráficas não conseguem. Costumo sugerir que isso seja mantido leve, porque scripts em excesso levam a problemas de manutenção mais tarde. Os pacotes são versionados, então nenhuma mudança entra em produção fora de um pacote implantado.

Três datas orientam quase todo plano de integração hoje.

1. 2027Fim da manutenção principal do PI/POFim do ano, para o SAP NetWeaver 7.5
2. 2028Descontinuação do Cloud Integration no Neo31 de dezembro. Os tenants Neo migram para o Cloud Foundry
3. 2030Fim da manutenção estendida do PI/POFim do ano. A última parada para qualquer sistema PI/PO

Fonte: SAP Note 1648480 e SAP Knowledge Base Article 3355661

1. O PI/PO está ficando sem estrada. A SAP Note 1648480 fixa a manutenção principal do SAP NetWeaver 7.5, que inclui o PI/PO, até o fim de 2027, com manutenção estendida até o fim de 2030. O sistema não para em 1º de janeiro de 2028, mas cada ano depois disso custa mais para mantê-lo.
2. O Neo está fechando. O SAP Knowledge Base Article 3355661 confirma que o Cloud Integration no ambiente SAP BTP Neo será descontinuado em 31 de dezembro de 2028. Os tenants de CPI mais antigos no Neo precisam migrar para o ambiente multicloud (Cloud Foundry), e essa migração é um pequeno projeto à parte.
3. O híbrido tem resposta. O Edge Integration Cell executa fluxos do Integration Suite dentro da sua própria rede. Isso elimina o motivo mais comum que as equipes davam para continuar no PI/PO.

Sobre a parte comercial: se você está no RISE with SAP, verifique qual direito de uso do SAP BTP o seu contrato já inclui antes de comprar capacidade do Integration Suite separadamente.

O PI (Process Integration) e o PO (Process Orchestration) são o middleware on-premise da SAP. Veja como eles se comparam ao CPI.

Fator	SAP PI/PO	SAP CPI (Integration Suite)
Implantação	On-premise, nos seus servidores	Nuvem no SAP BTP; Edge Integration Cell para um runtime on-premise
Esforço de manutenção	Alto: patches, upgrades, gestão de servidores	Menor: a SAP opera a plataforma
Extensibilidade	Customização profunda; upgrade mais difícil	Modular; atualizações mais rápidas; menos controle de baixo nível
Licenciamento	Licença mais a sua própria infraestrutura	Assinatura no SAP BTP, por edição
Direção do investimento	Só manutenção, sem novas funcionalidades	Desenvolvimento ativo
Fim da manutenção principal	Fim de 2027 (estendida até o fim de 2030)	Não se aplica (serviço em nuvem)

O guia de migração da SAP trata o Cloud Integration como o principal substituto porque ele cobre a maior parte do que o PI/PO faz. Pergunte à SAP como a sua edição é medida e depois modele isso contra os seus volumes reais de mensagens antes de migrar. Algumas empresas descobrem que o tráfego de integração é maior do que pensavam.

A migração não é uma conversão automática. O comportamento dos adaptadores difere entre PI e CPI, e um tratamento de erros que funcionava no PI pode se comportar de outra forma no CPI. Alguns fluxos precisam ser reconstruídos; outros migram com pequenas mudanças.

A SAP oferece duas ferramentas oficiais:

1. Migration Assessment. Uma capacidade do Integration Suite que se conecta ao seu sistema PO, extrai os cenários de integração e estima o esforço para migrá-los. O tutorial da SAP cobre a configuração.
2. Migration Tooling. Uma funcionalidade do Cloud Integration que semiautomatiza a migração de objetos de configuração integrada (ICOs) do PO para iFlows. Só cenários avaliados como “Ready to migrate” ou “Adjustment required” podem ser migrados com ela.

O SAP Learning é claro ao dizer que nenhum caminho de migração serve para todos os clientes, e muitos operam o PI/PO e o Integration Suite em paralelo durante a migração. As ferramentas reduzem o trabalho mecânico. Elas não fazem os julgamentos sobre o que reconstruir e o que aposentar.

Este é o plano em ondas que uso como ponto de partida. Ajuste as ondas ao seu próprio inventário.

Onda	O que migra	Por que nesta ordem	Responsável	Critérios de saída
0. Inventário	Cada interface do PI: frequência, volume, adaptador, criticidade, responsável	Você não consegue planejar o que não contou	Líder de integração	Inventário aprovado pelos donos do negócio
1. Baixo risco	Fluxos SAP a SAP com conteúdo padrão	Comprova o modelo operacional e o monitoramento	Líder de integração	Duas semanas estável em produção, caminho do PI aposentado
2. Parceiros	Fluxos B2B e EDI com os principais parceiros comerciais	Exige janelas de teste com os parceiros e cutover coordenado	Líder de integração com compras e vendas	Cada parceiro confirma por escrito
3. Alto risco	Fluxos de alto volume, regulados ou críticos para a receita	Migram por último, com mais ensaios	Arquiteto de integração	Teste de volume aprovado; retorno ao PI ensaiado
4. Desativação	Desligamento do PI/PO	Para de pagar por duas plataformas	CIO	Todos os fluxos migrados ou aposentados; licenças encerradas

Mantenha um caminho de retorno ao PI em cada onda até que o novo fluxo tenha rodado sem erros em produção. A ordem importa: comprove o modelo operacional em fluxos de baixo risco antes de mexer nas interfaces que carregam receita.

Os testes de integração são onde o tempo desaparece. Planeje cedo os testes de regressão com parceiros B2B e destinos não SAP, porque esses quebram em silêncio. Meu guia de testes SAP mostra como estruturar os ciclos de integração e de regressão.

Se a migração do PI/PO faz parte de um programa S/4HANA, alinhe os dois planos. Meu guia de migração do ECC para o S/4HANA cobre os caminhos e os prazos do lado do ERP.

Os cenários que vejo com mais frequência:

1. S/4HANA para SuccessFactors. Dados organizacionais, quadro de pessoal e mudanças de remuneração. O conteúdo de integração padrão da SAP cobre os cenários comuns; fluxos customizados tratam os desvios.
2. Compras legado para SAP Ariba. Pedidos de compra saindo, confirmações e faturas voltando. Normalmente bidirecional.
3. Dados financeiros para o SAP Analytics Cloud. Levar dados do ECC ou de sistemas não SAP para o SAC.
4. Salesforce para SAP. Negócios fechados fluindo para o SAP para atendimento, faturamento e atualização de estoque. Meu texto sobre por que as integrações entre Salesforce e ERP falham cobre os erros de desenho.

Se o trabalho de integração já está atrasando no seu programa, os atrasos na entrega do SAP Integration Suite explica as causas habituais. A visão geral das plataformas de integração SAP compara as opções lado a lado.

O que é o SAP CPI e como ele se chama agora?

SAP CPI significa Cloud Platform Integration. Hoje ele é a capacidade Cloud Integration do SAP Integration Suite no SAP BTP, ao lado de API Management, Event Mesh e ferramentas de integração com parceiros. “CPI” continua sendo o nome do dia a dia para a construção de fluxos de integração.

O que é o SAP CI?

SAP CI é a abreviação de SAP Cloud Integration, o nome atual do que antes era o SAP CPI. Os dois termos se referem à mesma capacidade dentro do SAP Integration Suite.

O SAP CPI é um middleware?

Sim. O CPI é um middleware em nuvem: fica entre os sistemas, transforma e roteia mensagens e trata erros e novas tentativas. Ele substitui middlewares on-premise como o SAP PI/PO e não armazena dados de negócio a longo prazo.

Qual a diferença entre o SAP CPI e o SAP PI/PO?

O PI/PO é um middleware on-premise que você instala, atualiza e opera por conta própria. O CPI é um serviço em nuvem no SAP BTP que a SAP opera para você, com novos adaptadores e conteúdos chegando de forma centralizada. O Edge Integration Cell cobre os fluxos que precisam ficar on-premise.

Quando termina o suporte ao SAP PI/PO?

A manutenção principal do SAP NetWeaver 7.5, que inclui o PI/PO, termina no fim de 2027. A manutenção estendida está disponível até o fim de 2030. A SAP oferece o Migration Assessment e a Migration Tooling para ajudar a migrar os cenários para o Integration Suite.

O SAP CPI é o mesmo que o SAP BTP?

Não. O SAP BTP é a plataforma: desenvolvimento de aplicações, dados, analytics, AI e integração. O CPI é o serviço de integração dentro dela.

Na definição do escopo, orçamento e competências são diferentes: um arquiteto de BTP trabalha entre os serviços, um especialista em CPI é dono dos fluxos, adaptadores e mapeamentos.

Se você está planejando a migração do PI/PO ou desenhando a integração de um novo programa S/4HANA, comece pelo inventário de interfaces. Se quiser uma segunda opinião sobre o plano antes de se comprometer com ele, entre em contato.