Ir para o conteúdo

SAP Integration Suite: decisões e trade-offs em produção

O SAP Integration Suite não é só o CPI com outro nome, e as decisões que as equipes erram raramente são de tecnologia. Este guia cobre os componentes, a migração do PI/PO, os limites dos legados, os testes e as lacunas de responsabilidade por trás da maioria das falhas de interface.

Arquiteto de integração SAP revisando um diagrama de fluxo de mensagens e logs de erro em dois monitores
Índice
  1. O que mudou para 2026
  2. Os componentes e o que cada um faz
  3. Conteúdo padrão versus desenvolvimento customizado
  4. Integração em programas complexos
  5. Sistemas legados e integração com terceiros
  6. Testando as interfaces como a produção vai usá-las
  7. O que o Integration Advisor faz e o que não faz
  8. Documentação e governança depois do go-live
  9. 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.

Saindo do PI/PO em ondas, antes que o prazo acabeConclua as ondas enquanto ainda há tempo. Uma virada forçada sob pressão de prazo leva mais tempo e custa mais.
  1. Onda 1Fluxos SAP para SAP de baixo riscoDimensione cada cenário antes, com o Migration Assessment
  2. Onda 2B2B e EDI
  3. Onda 3Fluxos de pedidos de alto volume
  4. 2027Fim da manutenção padrão do PI/PO 7.5Fim do ano. Planeje as ondas para terminar antes disso
  5. 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.

ComponentePapelO que dá errado quando é mal usado
Cloud Integration (CPI)Fluxos de mensagens, roteamento e transformação; o padrão para a maioria dos iFlowsEnfiar tudo no CPI, inclusive APIs e eventos, deixa o ambiente difícil de suportar e de testar
API ManagementGoverna a exposição de APIs: segurança, limites de taxa, analyticsSe for ignorado, as chamadas ponto a ponto se multiplicam; a governança é difícil de adaptar depois
Event MeshMensageria assíncrona para gatilhos desacopladosFilas sem acompanhamento crescem em silêncio, sem alertar ninguém
Integration AdvisorPropostas de mapeamento para formatos B2B como EDIFACT, X12 e IDocAs equipes presumem alta cobertura; uma equipe esperava 80% e chegou perto de 40%
Open ConnectorsConectores prontos para aplicações de terceiros em nuvemMudanças em APIs externas quebram os conectores em silêncio, a menos que alguém monitore
Migration Assessment e ferramentasDimensiona e migra cenários do PI/POTratados 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:

  1. O cenário é SAP para SAP e está próximo do processo de referência da SAP
  2. O fluxo é simples e majoritariamente em uma só direção
  3. Você consegue conviver com o mapeamento da SAP e só estende pelos pontos de saída (exits) previstos

Escolha um desenvolvimento customizado quando:

  1. Anos de decisões internas afastaram o processo do modelo da SAP
  2. Há roteamento condicional, lógica de várias etapas ou peculiaridades de legados
  3. 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:

  1. Um backlog de integração compartilhado, visível para todas as frentes de trabalho
  2. Um dono nomeado para cada interface, acompanhado ao longo da entrega
  3. Pontos de coordenação entre as frentes antes de cada grande implantação
  4. 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
  5. 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.

RiscoProblema comumO que fazer no desenho
Limites síncronosO legado trava sob chamadas em paraleloUse mensageria assíncrona; escalone as chamadas pelo Event Mesh ou pelo Cloud Integration
Incompatibilidade de protocoloO legado rejeita REST ou OAuth, ou estoura o tempo no SOAPConfirme protocolos e timeouts antes de o desenho começar
Limites de taxa de APIJobs em lote excedem o throttling de terceirosLimite a vazão no API Management; acrescente lógica de espera no iFlow
Expiração de tokenOs fluxos falham em silêncio nas janelas de baixo movimentoPrograme os ciclos de renovação e monitore a expiração
Formatos rígidosPayloads dinâmicos quebram o parsing do legadoValide com amostras reais de produção
Sem plano de contingênciaTransferências de arquivos falham sem nova tentativa e os dados ficam presosFaç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:

  1. Volumes de dados realistas com usuários concorrentes
  2. Interrupções de serviço e comportamento de recuperação
  3. Timeouts e novas tentativas entre o middleware e os back ends
  4. Jobs em lote rodando junto com chamadas em tempo real
  5. 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.

Noel D'Costa

Escrito por

Noel D'Costa

25 anos em programas de ERP SAP e Oracle nos setores de aviação, governo, finanças, varejo e manufatura. Formação em finanças. Ajudo equipes de liderança a definir o escopo de transformações com honestidade, recuperar programas em dificuldade e construir sistemas que sobrevivem ao primeiro ano em produção.

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.