Conectar o SAP sem mexer nele: como integrar a loja, o banco e os parceiros sem deixar desenvolvimentos que atrapalhem

Em 1 minuto

Conectar algo ao SAP exige duas decisões: por qual mecanismo se entra e onde vive a lógica de cada canal. O atalho — um programa próprio, acoplado às entranhas do SAP — parece mais rápido e se paga na próxima atualização. O SAP diz isso com as próprias palavras: o que se apoia nas interfaces liberadas por ele é o que melhor aguenta uma atualização. Este artigo explica, em linguagem de comitê, quais portas existem, quando cada uma convém e o que perguntar antes de aprovar a próxima integração.

Imagine uma empresa de porte médio que mantém a contabilidade, o estoque e o faturamento no SAP. É fictícia, mas se parece com muitas. Um dia chegam três pedidos à área de tecnologia, quase ao mesmo tempo:

• O comercial quer que a loja online mande cada pedido ao SAP e consulte o preço e o estoque.
• O financeiro quer que o extrato do banco seja conciliado com o que o SAP tem a receber.
• Vendas quer que um parceiro distribuidor possa mandar os pedidos a partir do próprio sistema.

Os três são razoáveis. E os três escondem a mesma pergunta: onde a conexão vai morar?

A resposta rápida costuma ser «dentro do SAP, do jeito que der»: um programa sob medida que leia o arquivo do banco, uma tabela nova para os pedidos da loja, um ajuste num processo padrão para o parceiro. Funciona, e funciona logo. O custo não aparece no dia da entrega. Aparece no dia em que é preciso atualizar o SAP, e alguém descobre que cada um desses desenvolvimentos precisa ser revisado, testado e, às vezes, refeito.

Este artigo é para quem dirige tecnologia, finanças ou operação numa empresa que tem SAP e precisa conectar mais coisas a ele; o raciocínio vale também para outros ERP de fabricante. Ele defende uma ideia: a conexão se faz pelas portas que o fabricante suporta, e o que é de cada canal, via de regra, vive fora do ERP. Não é só uma preferência de arquitetura: o SAP recomenda separar o que se acrescenta e se apoiar nas interfaces liberadas para reduzir a dívida técnica e facilitar as atualizações [1][2].

Não é um artigo sobre se a conexão deve ser online ou assíncrona; isso está em Online ou assíncrono?. Aqui a pergunta é outra: por qual porta se entra no SAP, e o que fica de fora.

O custo é cobrado na próxima atualização

O SAP repete isso aos clientes há anos, com um nome: núcleo limpo (clean core). A ideia é separar o que cada empresa acrescenta do que o SAP entrega, para que uma atualização não quebre o que foi acrescentado e o que foi acrescentado não quebre a atualização. Uma apresentação pública de consultores do SAP resume assim: as extensões próprias não devem quebrar uma atualização, nem as atualizações uma extensão, e para isso elas são separadas usando as interfaces liberadas do SAP; e convém evitar extensões quando possível (tradução livre) [2].

O material de formação do SAP é ainda mais claro sobre o caminho antigo. Descreve a forma tradicional de programar dentro do SAP como um código «muito acoplado ao sistema», que «podia ser problemático numa atualização» e que por isso era recomendado «como último recurso» (tradução livre) [1]. Hoje, para o SAP S/4HANA, o SAP classifica as extensões em quatro níveis, de A a D: o nível A usa interfaces e pontos de extensão liberados e é o que dá a maior estabilidade ao atualizar, seja fora do SAP ou dentro dele com as ferramentas que o SAP admite; e uma extensão é classificada pela tecnologia de menor nível que usa [1].

Em linguagem de comitê: cada desenvolvimento acoplado às entranhas do SAP é uma dívida que se paga, com juros, nas atualizações. Nem todos podem ser evitados. Mas cada um deveria ter uma razão por escrito. E mesmo com tudo em ordem, cada atualização é testada: o que muda é quanto há para revisar.

As portas que o SAP já tem

O SAP não é fechado. Tem vários mecanismos de integração — aqui os chamamos de portas —, e cada um serve para algo diferente. O comitê não precisa saber como funcionam por dentro; convém saber que existem e perguntar por qual se vai entrar. Quais estão disponíveis, e para quais operações, depende do produto e da versão do SAP que a empresa tem.

E uma porta que não está na lista: escrever direto nas tabelas do SAP. É tentadora porque parece a mais curta, e atrapalha porque pode pular os controles com que o processo de negócio do SAP cuida das próprias informações.

A página técnica do Hábil MDW diz isso numa frase: nos ERP priorizamos as interfaces que o fabricante suporta — no SAP, por exemplo, JCo, OData, IDoc ou REST —, para não deixar desenvolvimentos que atrapalhem a atualização.

O que fica no SAP e o que fica de fora

Entrar pela porta certa é metade do caminho. A outra metade é decidir qual lógica vive no SAP e qual vive fora. Uma regra útil:

• No SAP fica o que o SAP faz bem e o que a lei ou a auditoria pedem ao SAP: a contabilidade, o estoque oficial, o faturamento, o cliente e o material como o ERP os conhece.
• Fora fica o que é de cada canal ou de cada parceiro: o formato do arquivo de cada banco, as regras da loja online, a tradução do que cada distribuidor manda, as novas tentativas, o rastro do que foi enviado e do que o SAP respondeu.

Essas novas tentativas e esse rastro são também o que sustenta a venda no dia em que o ERP não responde; isso está em O ERP caiu no sábado.

O SAP tem um nome para a segunda parte: extensões lado a lado (side-by-side), que rodam fora do ERP e se conectam a ele [2]. Não é a única forma limpa — o SAP também admite extensões dentro do ERP quando o caso pede esse acoplamento e elas são feitas com as ferramentas liberadas por ele [1] —, mas para o que é de cada canal costuma ser a que melhor se encaixa. A vantagem para o negócio é dupla. Fica menos código próprio dentro do ERP, então em cada atualização há menos a revisar. E um canal novo muda sobretudo a camada de fora; no SAP, no máximo, um dado mestre ou uma configuração.

Os três pedidos, resolvidos pela porta certa

Voltemos à empresa fictícia.

A loja online. Cada pedido entra no SAP por uma interface publicada, com um número de referência único que é conferido antes de registrá-lo, para que uma nova tentativa não o duplique: isso não vem com a interface, é projetado. O preço e o estoque são consultados pela mesma via, se a versão do SAP a oferece; se a loja os consulta muitas vezes por minuto, convém que a camada de fora guarde uma cópia, com uma frequência de atualização combinada, para não sobrecarregar o SAP a cada visita. A lógica do carrinho, os cupons e os avisos ao cliente ficam na loja ou na camada de fora, não no SAP.

O banco. O banco manda o extrato como arquivo, no formato dele. A camada de fora o recolhe, valida, traduz e faz a conciliação com o que o SAP tem a receber. Ao SAP chega só o que ele precisa registrar, pela porta oficial. Se amanhã entrar um segundo banco com outro formato, a camada de fora aprende; no SAP, no máximo, cadastra-se a conta.

O parceiro distribuidor. O parceiro entra por uma porta com identidade e permissões próprias, manda os pedidos no formato dele, e a camada de fora os traduz para o pedido que o SAP conhece. Se o parceiro troca de sistema, ajusta-se a tradução; o SAP continua igual.

Nos três casos, o SAP faz o que faz melhor. Quando chegar a hora de atualizá-lo, as três conexões são testadas, mas não há três desenvolvimentos próprios escondidos lá dentro para revisar um a um.

Quando a porta necessária não existe

Às vezes não há uma interface publicada para o que se precisa, sobretudo em versões anteriores do SAP. Isso não obriga a entrar no SAP de cara. O próprio SAP publica um guia para esse caso: envolver uma função clássica — o exemplo é uma BAPI que cria requisições de compra — numa interface própria, pequena e documentada, que é liberada para que o desenvolvimento novo a use; a função por baixo continua clássica, e o SAP a classifica no nível B [1][6]. O mesmo grupo de tutoriais mostra depois como trocar esse invólucro pela interface liberada que o SAP publicou para esse processo [6]. As perguntas frequentes do SAP acrescentam um alerta útil: juntar várias funções clássicas num só invólucro dificulta retirá-lo depois, quando o SAP publicar a interface de uma delas, e mistura responsabilidades (tradução livre) [7].

Em linguagem de comitê: se for preciso entrar por uma porta que não é a de primeiro nível, isso se faz de propósito, num só lugar, com um nome e um dono, e conferindo a cada versão se o SAP já oferece uma alternativa liberada.

Os riscos, em linguagem de negócio

Cinco perguntas para o próximo comitê

1. Quantos desenvolvimentos próprios a empresa tem dentro do SAP para conectar outros sistemas, e quem os conhece? Se ninguém consegue responder com uma lista, esse é o primeiro achado.
2. Na última atualização do SAP, quantos desses desenvolvimentos foi preciso revisar ou refazer, e quanto tempo isso levou?
3. Para a próxima integração a ser aprovada, por qual porta do SAP ela vai entrar? Peça que isso seja dito por escrito: interface publicada, função remota, documento de intercâmbio ou arquivo — e qual processo do SAP o recebe —, e por quê.
4. Alguma coisa escreve direto nas tabelas do SAP? Se a resposta for «acho que não», vale a pena comprovar.
5. Se amanhã entrar um banco ou um parceiro novo, o que é preciso mudar no SAP? Um dado mestre ou uma configuração é normal. Se a resposta for «um programa novo», é provável que a lógica de cada canal esteja morando no lugar errado.

Se várias respostas forem «não sei», tome isso como sinal para fazer o inventário antes de aprovar a próxima integração.

Por onde começar esta semana

Faça o inventário das conexões do SAP. Uma planilha, uma linha por conexão, com cinco colunas:

• Qual sistema se conecta: loja, banco, parceiro, outro?
• Por qual porta entra: interface publicada, função remota, documento de intercâmbio, arquivo ou direto nas tabelas?
• A lógica desse canal vive dentro do SAP ou fora?
• Quem a mantém, e ela está documentada?
• Quebrou, ou foi preciso revisá-la, na última atualização?

A planilha que resultar mostra, com fatos, quais conexões dependem de código próprio dentro do SAP e ajuda a decidir por onde convém começar a tirar lógica. Funciona com qualquer ferramenta, ou com nenhuma.

O que a Hábil faz

Na Hábil construímos sob medida a integração entre o SAP — ou o ERP que a empresa tiver — e o que está ao redor dele: a loja, os bancos, os parceiros e os canais. Fazemos isso entrando pelas portas que o fabricante suporta e deixando de fora o que é de cada canal.

Se o inventário mostrar conexões que dependem de desenvolvimentos próprios dentro do SAP, a proposta está no Hábil MDW. Ele se conecta ao ERP e aos canais da empresa pelas vias que cada um já tem, converte o que chega a uma mesma linguagem e deixa registrado o que aconteceu, quando e quem fez. Nos ERP priorizamos as interfaces que o fabricante suporta, para não deixar desenvolvimentos que atrapalhem a atualização. Bancos, lojas, corretores e distribuidores se conectam com identidade e permissões próprias. O escopo, as portas usadas e a ordem em que se tira lógica do SAP são revisados com o caso da empresa.

A conversa pode começar com o inventário, mesmo pela metade: o que se conecta, por onde entra e o que quebrou na última atualização. Com isso, revisamos juntos por onde convém começar. Escreva para nós pelo WhatsApp; para proteger as informações, não compartilhe por esse meio dados dos sistemas nem dos clientes da empresa: combinaremos na conversa o canal para o caso.

Peça a primeira conversa, sem custo.

Consultadas em 12 de novembro de 2026. Cada referência traz o grau de confiança: alta (fonte primária lida).