
Índice
- O que mudou para 2026
- Os componentes e o que cada um faz
- Conteúdo padrão versus desenvolvimento customizado
- Integração em programas complexos
- Sistemas legados e integração com terceiros
- Testando as interfaces como a produção vai usá-las
- O que o Integration Advisor faz e o que não faz
- Documentação e governança depois do go-live
- Perguntas frequentes
O SAP Integration Suite é a plataforma de integração da SAP no SAP BTP: o Cloud Integration (o antigo CPI), mais API Management, Event Mesh, Integration Advisor, Open Connectors e ferramentas para migrar do PI/PO. É o middleware padrão dos programas S/4HANA em nuvem e o caminho de saída do PI/PO, cuja manutenção padrão termina em 2027. Os atrasos em interfaces raramente vêm da tecnologia. Vêm de responsabilidade pouco clara, de premissas não testadas sobre sistemas legados e de testes desenhados para passar, não para encontrar falhas. Este guia é para líderes de integração, arquitetos e gerentes de programa. Ele cobre para que serve cada componente, conteúdo padrão versus customizado, a migração do PI/PO, os riscos de legados e de testes e a governança depois do go-live.
O PI/PO está com o relógio correndo. O SAP Process Integration e o Process Orchestration 7.5 estão em manutenção padrão até o fim de 2027. A manutenção estendida opcional vai até o fim de 2030, e depois disso o suporte da SAP termina. A arquitetura de referência de migração da SAP descreve o caminho. O Integration Suite inclui uma aplicação Migration Assessment, que dimensiona cada cenário do PI/PO, e ferramentas de migração guiadas por assistente no Cloud Integration. Migre em ondas: primeiro os fluxos SAP para SAP de baixo risco, no meio o B2B e o EDI e, por último, os fluxos de pedidos de alto volume. Uma virada forçada sob pressão de prazo leva mais tempo e custa mais.
- Onda 1Fluxos SAP para SAP de baixo riscoDimensione cada cenário antes, com o Migration Assessment
- Onda 2B2B e EDI
- Onda 3Fluxos de pedidos de alto volume
- 2027Fim da manutenção padrão do PI/PO 7.5Fim do ano. Planeje as ondas para terminar antes disso
- 2030Fim da manutenção estendida opcionalFim do ano. Depois, o suporte da SAP termina
Fonte: Datas de manutenção da SAP e arquitetura de referência de migração, verificadas em outubro de 2026
Verifique o que o seu contrato de nuvem cobre. Os contratos RISE e GROW costumam incluir créditos do SAP BTP que podem pagar o Integration Suite. Confirme qual edição e quais volumes de mensagens o seu direito de uso cobre antes de comparar o Integration Suite com o MuleSoft ou o Boomi apenas por funcionalidades. A economia de uma plataforma incluída muda a comparação.
A IA está chegando em etapas. O Cloud Integration oferece geração de fluxos por IA generativa na edição Premium desde meados de 2024. Ela produz a estrutura de um iFlow (etapas, canais, subprocesso de exceção), não os mapeamentos nem os scripts. A edição enhanced da SAP, lançada em março de 2026, acrescenta a geração de fluxos a partir de texto e a otimização de scripts, e a SAP planejou a disponibilidade geral do Joule no Integration Suite para o terceiro trimestre de 2026. Útil para fluxos padrão. A orquestração complexa, com lógica de negócio profunda, ainda precisa de arquitetos seniores.
O Integration Suite é um conjunto de serviços. Usar o certo para cada trabalho define quão bem o ambiente se sustenta.
| Componente | Papel | O que dá errado quando é mal usado |
|---|---|---|
| Cloud Integration (CPI) | Fluxos de mensagens, roteamento e transformação; o padrão para a maioria dos iFlows | Enfiar tudo no CPI, inclusive APIs e eventos, deixa o ambiente difícil de suportar e de testar |
| API Management | Governa a exposição de APIs: segurança, limites de taxa, analytics | Se for ignorado, as chamadas ponto a ponto se multiplicam; a governança é difícil de adaptar depois |
| Event Mesh | Mensageria assíncrona para gatilhos desacoplados | Filas sem acompanhamento crescem em silêncio, sem alertar ninguém |
| Integration Advisor | Propostas de mapeamento para formatos B2B como EDIFACT, X12 e IDoc | As equipes presumem alta cobertura; uma equipe esperava 80% e chegou perto de 40% |
| Open Connectors | Conectores prontos para aplicações de terceiros em nuvem | Mudanças em APIs externas quebram os conectores em silêncio, a menos que alguém monitore |
| Migration Assessment e ferramentas | Dimensiona e migra cenários do PI/PO | Tratados como uma estimativa pontual, em vez de um plano de migração de trabalho |
As equipes que tratam o Integration Suite como “CPI com extras” costumam ignorar o API Management e o Event Mesh. Funciona até a complexidade alcançá-las. Meu guia do SAP CPI aprofunda o próprio Cloud Integration.
O conteúdo de integração pronto da SAP é realmente útil quando o processo é padrão. Conectar o S/4HANA ao SAP Ariba ou ao SuccessFactors com processos padrão costuma ser um encaixe limpo. Os processos reais raramente ficam dentro das linhas de referência da SAP.
Escolha o conteúdo padrão quando:
- O cenário é SAP para SAP e está próximo do processo de referência da SAP
- O fluxo é simples e majoritariamente em uma só direção
- Você consegue conviver com o mapeamento da SAP e só estende pelos pontos de saída (exits) previstos
Escolha um desenvolvimento customizado quando:
- Anos de decisões internas afastaram o processo do modelo da SAP
- Há roteamento condicional, lógica de várias etapas ou peculiaridades de legados
- Uma modificação pesada quebraria o alinhamento de suporte da SAP para o pacote padrão
Tome a decisão na fase de blueprint. Quando ela é tomada tarde, as equipes descobrem no meio do projeto que um iFlow “padrão” foi tão modificado que perdeu o alinhamento de suporte, e o refazem sob a pressão do go-live. Já vi projetos perderem semanas porque as equipes presumiram que o conteúdo padrão absorveria, de uma vez só, estruturas customizadas de dados mestre, campos extras e autenticação legada. Não absorveu. A análise que pertencia ao desenho aconteceu durante o UAT.
Em grandes programas SAP, a integração costuma ser a primeira coisa a cair entre as frentes de trabalho. As interfaces cruzam as fronteiras entre as equipes, mas ninguém é dono da coordenação. Já vi duas equipes de projeto construírem integrações separadas para o mesmo parceiro de negócio, apontando para o mesmo endpoint, sem saber uma da outra. Nenhuma descobriu até o UAT. Isso é uma falha estrutural, não técnica.
Estabeleça cedo uma governança central de integração:
- Um backlog de integração compartilhado, visível para todas as frentes de trabalho
- Um dono nomeado para cada interface, acompanhado ao longo da entrega
- Pontos de coordenação entre as frentes antes de cada grande implantação
- Uma revisão das dependências de interface antes de qualquer compromisso de go-live, com endpoints e filas compartilhados sequenciados no plano de cutover
- Implantação automatizada entre ambientes, com as credenciais documentadas por ambiente
Os problemas de integração mais difíceis raramente estão nas plataformas modernas. Estão nos sistemas mais antigos, no meio de processos críticos.
Os ERPs legados muitas vezes não conseguem tratar chamadas síncronas concorrentes. Envie cinco chamadas de API em paralelo e o servidor fica lento, congela ou descarta dados em silêncio. A integração assíncrona só ajuda se o sistema receptor souber processar uma fila, e muitos não sabem.
As incompatibilidades de protocolo são comuns e descobertas tarde. Você desenha com OAuth2 e REST; o sistema legado fala SOAP, com um timeout fixo de 30 segundos, e trata mal a renovação de tokens.
Em um caso de cliente, um fluxo de middleware falhava toda sexta-feira porque o token emitido por um sistema de folha de pagamento de terceiros expirava toda semana. Ninguém percebeu até o segundo ciclo de UAT. Peculiaridades como essa são comuns e consomem os cronogramas.
A tabela lista os riscos a verificar antes do congelamento do desenho.
| Risco | Problema comum | O que fazer no desenho |
|---|---|---|
| Limites síncronos | O legado trava sob chamadas em paralelo | Use mensageria assíncrona; escalone as chamadas pelo Event Mesh ou pelo Cloud Integration |
| Incompatibilidade de protocolo | O legado rejeita REST ou OAuth, ou estoura o tempo no SOAP | Confirme protocolos e timeouts antes de o desenho começar |
| Limites de taxa de API | Jobs em lote excedem o throttling de terceiros | Limite a vazão no API Management; acrescente lógica de espera no iFlow |
| Expiração de token | Os fluxos falham em silêncio nas janelas de baixo movimento | Programe os ciclos de renovação e monitore a expiração |
| Formatos rígidos | Payloads dinâmicos quebram o parsing do legado | Valide com amostras reais de produção |
| Sem plano de contingência | Transferências de arquivos falham sem nova tentativa e os dados ficam presos | Faça buffer no middleware; inclua nova tentativa e alertas nos iFlows |
Para a versão entre nuvens desses problemas, veja meu texto sobre por que a integração do ERP com o Salesforce falha.
A maioria das falhas de integração em programas SAP se explica por lacunas de responsabilidade, não por tecnologia. Sem uma responsabilidade definida para o monitoramento de mensagens, as novas tentativas e a resolução de erros, até iFlows bem desenhados falham em silêncio em produção.
A integração não quebra do jeito que os testes funcionais verificam. Ela falha sob pressão de tempo, quando jobs em segundo plano se sobrepõem e quando as entradas chegam em volume, e não uma a uma. Um teste funcional prova que uma transação é lançada e que uma mensagem aparece no log. Não prova o que acontece quando a primeira folha de pagamento envia uma enxurrada de IDocs. Em um projeto, um IDoc que parecia limpo no teste de integração de sistemas (SIT) travou a fila quando chegaram os volumes reais da folha. Só o teste de carga encontrou o problema.
Os testes de interface precisam cobrir:
- Volumes de dados realistas com usuários concorrentes
- Interrupções de serviço e comportamento de recuperação
- Timeouts e novas tentativas entre o middleware e os back ends
- Jobs em lote rodando junto com chamadas em tempo real
- Fechamento mensal e outros períodos de pico
Os ambientes de desenvolvimento são limpos. Deadlocks, condições de corrida e throttling aparecem no UAT e no pré-produção, onde os outros sistemas e as janelas de lote estão ativos; por isso, rode os testes de carga ali. Divida a responsabilidade com clareza: as equipes funcionais validam os resultados de negócio em todo o fluxo, as equipes de integração são donas dos logs, das novas tentativas e dos fluxos de exceção, e os líderes de projeto confirmam a cobertura. Meu guia de testes de performance no SAP cobre o lado da carga.
O Integration Advisor propõe mapeamentos para formatos B2B estruturados. Para parceiros que seguem convenções rígidas, economiza um tempo real de configuração. Para integrações corporativas com sistemas legados, campos customizados, lógica condicional e regras não documentadas, é um ponto de partida.
Uma equipe com a qual trabalhei esperava 80% de cobertura de mapeamento. A cobertura real ficou em torno de 40%. O resto precisou ser customizado, validado com o negócio e testado manualmente.
Ele não resolve a lógica de negócio que se acumulou informalmente ao longo dos anos (condições de pagamento, categorias de preço, convenções de unidade), as regras condicionais baseadas no contexto do negócio, nem as exceções fora do formato padrão. Isso exige a contribuição das áreas funcionais. Sem ela, as interfaces ficam tecnicamente mapeadas e logicamente erradas em casos específicos.
A integração se degrada depois do go-live quando a documentação fica defasada e a responsabilidade não é formal. Uma documentação útil cobre os mapeamentos de campos e a lógica de transformação, além de detalhes de autenticação, como endpoints, renovação de tokens e rotação de credenciais. Cobre também o tratamento de erros, as regras de contingência e as expectativas de volume para janelas críticas, como o fechamento mensal e a folha de pagamento. O teste: alguém que entrasse na equipe de suporte na semana que vem conseguiria diagnosticar uma interface com falha apenas com a documentação?
Toda interface, mesmo de baixo volume, precisa de um dono nomeado para monitoramento, escalonamento e mudanças ao longo do ciclo de vida. Sem ele, as falhas ficam passando entre as equipes de Basis, de middleware e as funcionais enquanto o negócio espera. Depois do hypercare, o monitoramento tende a se esvaziar. Construa revisões regulares dos logs de erro, uma passagem formal do projeto para o suporte e níveis de serviço acordados entre o negócio e a TI. A integração negligenciada está por trás de muitos dos lançamentos atrasados, das faturas ausentes e dos relatórios financeiros desalinhados que surgem semanas depois do go-live.
O que é o SAP Integration Suite e em que ele difere do CPI?
O Cloud Integration, antes chamado de SAP Cloud Platform Integration (CPI), é uma capacidade dentro do Integration Suite. O pacote acrescenta o API Management, para a exposição governada de APIs, e o Event Mesh, para mensageria assíncrona. Inclui também o Integration Advisor, para propostas de mapeamento B2B, o Open Connectors, para aplicações de terceiros em nuvem, e ferramentas de avaliação e migração do PI/PO. As equipes que o tratam como um CPI com nome novo costumam pular o API Management e o Event Mesh, e pagam por isso depois, em lacunas de governança.
Quando termina o suporte ao SAP PI/PO?
O SAP Process Integration e o Process Orchestration 7.5 estão em manutenção padrão até o fim de 2027. Os clientes podem contratar manutenção estendida opcional até o fim de 2030, e depois disso o suporte da SAP termina. O Integration Suite inclui uma aplicação Migration Assessment para dimensionar cada cenário e ferramentas de migração para mover os artefatos de forma semiautomática. Comece com um plano de ondas, em vez de esperar o prazo.
Quando a integração SAP deve usar conteúdo padrão e quando desenvolvimento customizado?
Use o conteúdo padrão quando o cenário é SAP para SAP, está próximo do processo de referência da SAP e é relativamente simples. Construa sob medida quando o processo se afastou do modelo da SAP, quando peculiaridades de legados exigem tratamento específico ou quando lógica condicional e de várias etapas forçaria mudanças pesadas no pacote padrão. Decida na fase de blueprint; refazer um fluxo padrão excessivamente modificado sob a pressão do go-live custa mais do que um desenvolvimento customizado limpo.
O que causa as falhas de integração SAP em programas complexos?
Principalmente causas estruturais. Nenhum dono nomeado para o monitoramento e a resolução de erros, e assim as falhas ficam passando entre as equipes. Duas frentes de trabalho construindo integrações que compartilham um endpoint ou uma fila sem saber. Sistemas legados que não aguentam chamadas concorrentes, descobertos só sob carga. E testes que rodam limpos de forma isolada, mas nunca simulam a sobreposição de lotes nem o volume de pico.
Como estruturar os testes de integração do SAP Integration Suite?
Além dos testes funcionais, cubra volumes realistas, como o primeiro fechamento mensal ou a primeira folha de pagamento. Teste jobs em lote rodando junto com interfaces em tempo real, a recuperação quando um sistema a jusante está indisponível e os limites de taxa de terceiros durante cargas em massa. Rode testes de carga e de performance em ambientes parecidos com a produção, porque sistemas de desenvolvimento limpos escondem os problemas.
Como governar a integração SAP depois do go-live?
Dê a cada interface um dono nomeado para monitoramento, escalonamento e mudanças. Mantenha a documentação atualizada: mapeamentos, autenticação e rotação de credenciais, tratamento de erros e expectativas de volume. E construa um modelo de suporte de longo prazo, com revisões regulares dos logs de erro, uma passagem formal do projeto para o suporte e níveis de serviço acordados. A integração que se torna invisível é negligenciada.
Próximo passo
Está conduzindo um programa de ERP agora?
Se este artigo tocou num programa em que você está envolvido agora, uma conversa de 30 minutos costuma render mais do que outra semana de análise interna.




