Integração SAP em 2026: BAdIs, IDoc, OData e Arquitetura de Interfaces

Integração de sistemas SAP é o conjunto de padrões, tecnologias e decisões arquiteturais que garantem que módulos como SD, MM, FI, TM e EWM — além de sistemas externos — troquem dados de forma confiável, rastreável e sustentável. Em projetos de implantação e evolução SAP, as interfaces representam tipicamente 30 a 40% do esforço total de desenvolvimento RICEFW. Errar a camada de integração significa retrabalho caro, dados inconsistentes entre tabelas como VBAK/VBAP e /SCMTMS/D_FRO_I, e integrações que se tornam "caixas pretas" impossíveis de manter. Este guia técnico apresenta os padrões, ferramentas e armadilhas que todo arquiteto SAP precisa dominar em 2026.

Por que a Integração SAP Ainda é o Gargalo Número 1 dos Projetos

Muitas consultorias relatam que a maioria dos atrasos em go-live não vem da configuração do módulo em si, mas das interfaces. Os motivos são conhecidos:

• Dependências entre times: o time de TM termina o Freight Order, mas o time de FI ainda não validou a integração contábil via FSD (Freight Settlement Document).
• Documentação fragmentada: especificações funcionais de interface escritas em Word, desalinhadas do código ABAP real.
• Ambiguidade de ownership: quem é dono da BAdI /SCMTMS/IF_EM_FRO_H_EA — o time TM ou o time de EWM?
• Ausência de contratos de interface: sem um acordo formal de estrutura de payload, versionamento de IDoc ou esquema OpenAPI, cada mudança se torna um incêndio.

O resultado é um catálogo RICEFW cheio de interfaces com status "em análise" semanas antes do cut-over.

Os Quatro Paradigmas de Integração no Ecossistema SAP

Antes de escolher a tecnologia, é preciso entender o paradigma correto para cada cenário:

1. Integração Síncrona (Request-Reply)

Usada quando o sistema chamador precisa da resposta imediata para continuar o processo. Exemplos típicos: consulta de estoque em tempo real via RFC/BAPI, validação de crédito no ciclo Order-to-Cash, ou chamada a um microserviço externo durante o salvamento de um Freight Order.

Tecnologias SAP: RFC clássico, BAPI, OData V2/V4, REST API via SAP Integration Suite.

2. Integração Assíncrona (Fire-and-Forget)

Ideal quando o volume é alto e a latência é aceitável. O sistema envia a mensagem e continua processando sem esperar resposta imediata.

Tecnologias SAP: IDoc (Intermediate Document), qRFC, SAP Event Mesh, Advanced Event Mesh no BTP.

3. Integração por Eventos (Event-Driven Architecture)

Ganhou espaço com o SAP BTP. Um evento de negócio — como a criação de um Freight Order — dispara automaticamente fluxos em sistemas downstream sem acoplamento direto.

Tecnologias SAP: SAP Event Mesh, Enterprise Messaging, SAP Integration Suite com triggers baseados em Business Events.

4. Integração em Lote (Batch)

Ainda relevante para volumes massivos com janelas de processamento noturnas: carga de faturas, atualização de cotações de frete, sincronização de cadastros.

Tecnologias SAP: IDOC_INPUT_*, programas ABAP batch, SAP Data Services, CPI iFlows com schedule.

SAP Integration Suite: o Hub Central em 2026

O SAP Help Portal documenta o SAP Integration Suite (antigo CPI — Cloud Platform Integration) como a plataforma de integração estratégica da SAP para cenários cloud-to-cloud, cloud-to-on-premise e on-premise-to-on-premise.

Os componentes principais que o arquiteto SAP precisa conhecer:

Componente	Função Principal	Cenário Típico
Cloud Integration (CPI)	Orquestração de mensagens com iFlows	EDI com transportadoras, integração TMS↔ERP
API Management	Gateway, throttling, segurança de APIs	Exposição de OData do S/4HANA para apps externos
Event Mesh	Broker de eventos assíncronos	Notificações de status de Freight Order em tempo real
Integration Advisor	Mapeamento de padrões B2B (EDIFACT, X12)	NF-e, CT-e com parceiros logísticos
Trading Partner Management	Gerenciamento de parceiros EDI	Integração com embarcadores e 3PLs

Para projetos SAP TM integrados a sistemas de embarcadores, o Integration Advisor com suporte a CT-e (Conhecimento de Transporte Eletrônico) é particularmente relevante no contexto brasileiro.

IDoc vs API REST: Como Decidir na Prática

Essa é uma das discussões mais recorrentes em projetos greenfield S/4HANA. A resposta depende de três critérios:

1. Origem e destino do dado

• Sistema SAP legado ↔ S/4HANA: IDoc ainda é o caminho com menor risco e maior rastreabilidade.
• Sistema externo moderno ↔ S/4HANA: OData V4 ou REST via Integration Suite.
• Microserviço em BTP ↔ S/4HANA: Event-driven com Event Mesh.

2. Volume e frequência

• Alto volume, baixa latência exigida: IDoc assíncrono ou batch.
• Baixo volume, resposta em tempo real: OData/REST síncrono.

3. Necessidade de rastreabilidade

• IDoc tem rastreabilidade nativa (WE02, WE05, BD87). REST/OData exige implementação de log de auditoria adicional.

Uma decisão arquitetural documentada com esses três critérios evita discussões tardias no projeto e facilita a geração de Especificações Funcionais coerentes.

BAdIs e User Exits: Extensibilidade sem Modificação

Quando a integração não é entre sistemas externos, mas entre módulos SAP, a camada de extensibilidade via BAdI é o mecanismo correto. O SAP Community tem farta documentação sobre BAdIs no contexto de S/4HANA, mas os princípios fundamentais para arquitetos são:

• BAdI clássica (SE18/SE19): usada em sistemas ECC e S/4HANA on-premise. Permite enriquecer ou redirecionar lógica de negócio sem modificar o standard.
• BAdI no contexto RAP (ABAP RESTful Application Programming Model): para extensões em objetos de negócio no S/4HANA Cloud, a extensibilidade segue o modelo Key User e Developer Extensibility com BAdIs expostas via ABAP Environment.
• Enhancement Spots: agrupam BAdIs relacionadas. No SAP TM, o Enhancement Spot /SCMTMS/ES_FRO concentra pontos de extensão do Freight Order.

O erro mais comum é implementar lógica de integração diretamente em User Exits de SD (como USEREXIT_SAVE_DOCUMENT_PREPARE) em vez de usar a BAdI correta com interface bem definida. O resultado é código difícil de testar e documentar.

Para uma visão mais ampla sobre automação de fluxos com extensibilidade SAP, veja o artigo Automatizar Fluxos de Processo SAP: Guia Técnico 2026.

CDS Views como Contratos de Dados para Integração

Uma mudança arquitetural significativa em S/4HANA é o uso de CDS Views (Core Data Services) como camada de abstração de dados para integração. Em vez de expor tabelas transparentes diretamente (VBAK, LIKP, /SCMTMS/D_FRO_I), o padrão moderno é:

1. Criar uma CDS View com anotações @OData.publish: true ou @Consumption.semanticObject.
2. Versionar essa view como contrato de interface.
3. Consumir via OData no Integration Suite ou em apps Fiori.

Isso tem um impacto direto na rastreabilidade: qualquer mudança na estrutura de dados da CDS View é um breaking change contratual, não uma mudança silenciosa em tabela.

A combinação CDS View + RAP + OData V4 é o stack de integração recomendado pela SAP para novos desenvolvimentos em S/4HANA 2023+. Consulte a SAP Fiori Design Guidelines para entender como essa camada se conecta à experiência do usuário final.

Erros Comuns na Especificação de Interfaces SAP

Na prática de projetos, alguns padrões de falha se repetem com frequência:

1. Especificação funcional sem mapeamento de campos: o documento descreve o fluxo em alto nível, mas não mapeia campo a campo entre os sistemas, deixando para o desenvolvedor ABAP "deduzir" a transformação.
2. Ausência de tratamento de erros: a especificação documenta o happy path, mas não define o que acontece quando o sistema receptor está indisponível ou retorna erro de validação.
3. Ignorar o contexto de mandante: em ambientes multi-mandante, filtros de mandante em IDocs e RFC destinations precisam ser explicitados.
4. Não documentar dependências de customizing: uma interface de Freight Order pode depender de configurações em /SCMTMS/CUST que precisam existir no sistema receptor antes da primeira mensagem.
5. Testar apenas o caminho de sucesso: casos de teste de integração precisam cobrir mensagens duplicadas, campos obrigatórios ausentes e timeouts.

Esse tipo de lacuna na documentação é exatamente o que a OrkestraFlow resolve com geração automática de Especificações Funcionais de Interface e catálogo de GAPs RICEFW — incluindo o mapeamento de campos e os fluxos de exceção.

Para entender como IA pode apoiar esse processo de mapeamento, veja também o artigo Mapeamento de Processos SAP: Guia Técnico 2026 para Consultores.

Como Estruturar o Catálogo de Interfaces em um Projeto SAP

Um catálogo de interfaces bem estruturado é o alicerce da governança de integração. Os campos mínimos recomendados:

• ID da interface (ex: INT-TM-FI-001)
• Sistema origem / Sistema destino
• Módulo SAP envolvido (ex: TM → FI)
• Objeto de negócio (ex: Freight Settlement Document)
• Paradigma (síncrono / assíncrono / evento / batch)
• Tecnologia (IDoc / OData / RFC / CPI iFlow)
• Frequência e volume estimado
• Owner funcional / Owner técnico
• Status (a especificar / em desenvolvimento / em teste / em produção)
• BAdI ou Enhancement Spot associado (quando aplicável)
• Riscos identificados

Manter esse catálogo atualizado manualmente em planilhas é o que transforma revisões de arquitetura em sessões de arqueologia. Ferramentas que integram o catálogo RICEFW com as especificações funcionais eliminam esse problema estruturalmente.

Conclusão

Integração de sistemas SAP em 2026 não é mais um tema periférico de projeto — é disciplina central de arquitetura. A escolha entre IDoc, OData, RFC e Event Mesh não é arbitrária: cada paradigma tem seus casos de uso, e documentar essa decisão com critérios claros é responsabilidade do arquiteto. CDS Views como contratos de dados, BAdIs corretamente especificadas e um catálogo RICEFW vivo são os pilares que separam projetos que escalam dos que viram legado antes do go-live.

A complexidade da integração SAP não vai diminuir. O que pode mudar é a qualidade da documentação, a velocidade de especificação e a rastreabilidade de cada decisão arquitetural — e é exatamente aí que a automação inteligente faz diferença.

Começar 5 dias grátis na OrkestraFlow e veja como gerar Especificações Funcionais de Interface, catálogo RICEFW e fluxos de processo visuais com IA que entende a terminologia SAP de verdade.