Integrar o SAP S/4HANA com o Adobe Commerce é ligar o ERP, que manda em preços, stock, clientes e documentos, a uma loja que vende a empresas e a consumidores. A ligação faz-se por APIs: serviços OData do lado do SAP e REST ou GraphQL do lado do Adobe Commerce, quase sempre com uma camada intermédia (middleware) que traduz dados, gere filas e regista erros.
Para o negócio, a diferença vê-se no dia a dia: encomendas que ficam por criar no ERP, stock que não coincide com o armazém e preços negociados que a loja não mostra. Em projetos de maior dimensão, estes desvios custam mais do que a própria integração. Na Avafa tratamos esta ligação dentro da nossa área de integração de SAP com ecommerce.
Neste artigo vê quando compensa integrar, que arquitetura usar, que dados circulam em cada sentido, o que a documentação da Adobe exige em volumes grandes, os riscos mais comuns e uma lista de verificação para validar antes de arrancar.
Quando compensa integrar o SAP S/4HANA com o Adobe Commerce?
Compensa quando o catálogo, os preços ou o stock mudam com frequência e a equipa já gasta tempo a corrigir diferenças à mão. Os sinais mais claros são estes:
- Preços por cliente, contratos ou escalões que hoje só existem no SAP.
- Vários armazéns e necessidade de mostrar stock disponível em tempo útil.
- Encomendas B2B com limites de crédito, aprovações ou condições de pagamento.
- Várias lojas, moedas ou países a partir do mesmo catálogo.
- Um volume de encomendas que já não se consegue digitar no ERP.
Se o catálogo é pequeno, o preço é único e as encomendas são poucas, uma exportação periódica de ficheiros pode chegar. A integração em tempo quase real só se justifica quando o custo do erro manual passa a ser maior do que o custo de a manter.
Como se liga o SAP S/4HANA ao Adobe Commerce?
A arquitetura mais robusta tem três peças: o SAP S/4HANA como fonte de verdade dos dados mestre, uma camada de integração no meio e o Adobe Commerce como montra e canal de encomendas. Ligar os dois diretamente é possível, mas deixa a lógica de erros e de repetição dentro de sistemas que não foram feitos para isso.
No lado do SAP, o S/4HANA expõe os dados por serviços OData. Nas versões em cloud, o acesso externo configura-se com utilizadores, sistemas e acordos de comunicação. Nas escritas, o serviço exige em regra um token CSRF, obtido com um pedido GET prévio que leva o cabeçalho x-csrf-token com o valor fetch.
No lado do Adobe Commerce, existem API REST e GraphQL. Para volumes grandes, a documentação da Adobe descreve pontos de acesso assíncronos e em lote (bulk): o pedido é escrito numa fila de mensagens e um consumidor processa-o depois. O passo a passo que recomendamos é este:
- Definir qual sistema manda em cada dado: artigo, preço, stock, cliente, encomenda.
- Mapear os campos entre os dois sistemas: SKU, unidades de medida, IVA, grupos de clientes e moedas.
- Construir cada fluxo com fila e reenvio seguro, para que repetir uma mensagem nunca duplique uma encomenda.
- Testar com dados reais num ambiente de testes do SAP e num ambiente de staging do Adobe Commerce.
- Ativar a monitorização e uma reconciliação periódica entre os dois sistemas.
Que dados circulam e em que sentido?
Cada dado deve ter um sentido principal e um dono. A tabela mostra a matriz que usamos como ponto de partida; a frequência concreta depende do negócio e valida-se no levantamento.
| Dado | Dono | Sentido | Frequência |
|---|---|---|---|
| Artigos e atributos | SAP ou PIM | SAP para loja | Por alteração |
| Preços e condições | SAP | SAP para loja | Por evento ou lote |
| Stock disponível | SAP | SAP para loja | Frequente, por evento |
| Encomendas | Adobe Commerce | Loja para SAP | Imediata, em fila |
| Clientes | Definir caso a caso | Nos dois sentidos | Na criação e alteração |
| Estados e faturas | SAP | SAP para loja | Por evento |
O que a documentação da Adobe obriga a ter em conta
Os pontos de acesso em lote do Adobe Commerce aceitam pedidos, mas não garantem que o resultado seja positivo. Segundo a documentação da Adobe, a resposta traz um identificador do lote (bulk_uuid) e o estado “accepted”, que confirma apenas que o pedido entrou na fila. Um cliente duplicado, por exemplo, pode ser aceite na fila e falhar depois no processamento.
Por isso a integração tem de consultar o estado das operações e tratar as falhas. Há ainda diferenças de ambiente que mudam o desenho:
- Nas instalações PaaS (cloud ou própria), os pontos de acesso em lote usam o prefixo async/bulk antes de V1 e exigem RabbitMQ instalado, com os consumidores a correr por tarefas cron.
- No Adobe Commerce as a Cloud Service, as filas correm automaticamente, o prefixo vem depois de V1 e o limite de entidades por pedido define-se na configuração da loja.
- Alguns pontos de acesso não existem na versão Cloud Service; a documentação indica, por exemplo, que POST V1/customers não é suportado.
- Os pedidos em lote aceitam POST, PUT e DELETE, mas não GET. As leituras fazem-se à parte.
Em instalações PaaS com várias vistas de loja, o código da vista na rota indica onde se aplica a alteração; sem ele, aplica-se à vista predefinida. Convém decidir isto antes de importar preços e descrições por idioma.
Riscos mais comuns e como evitá-los
| Risco | Como aparece | Como evitar |
|---|---|---|
| Encomendas duplicadas | Duas encomendas iguais no SAP | Chave única e reenvio seguro |
| Stock desfasado | Venda de produto sem disponibilidade | Eventos mais reconciliação diária |
| Preço errado por cliente | Cliente vê preço de tabela | Definir quem calcula o preço |
| Pedido aceite mas falhado | Resposta positiva sem efeito | Consultar estado e fila de erros |
| Alteração de versão | Fluxo deixa de responder | Testar cada atualização em staging |
Em quase todos os projetos, o risco real não está na tecnologia, mas na falta de regras: quem corrige um erro, em quanto tempo e com que informação. Escreva estas respostas antes de arrancar.
Lista de verificação antes de arrancar
- Cada dado tem um dono e um sentido definidos por escrito.
- Os dados mestre do SAP (artigos, unidades, IVA) estão limpos e completos.
- Existe ambiente de testes no SAP e staging no Adobe Commerce.
- Está definido o que acontece quando um pedido falha e quem é avisado.
- O pico de encomendas (campanhas, épocas altas) foi estimado e testado.
- Moedas, IVA e regras de arredondamento estão validados com a contabilidade.
- Há um relatório de reconciliação entre stock e encomendas dos dois sistemas.
- Alguém tem a responsabilidade pelo funcionamento depois da entrada em produção.
Como trabalhamos na Avafa
Começamos por um levantamento dos fluxos antes de escolher tecnologia: o que vive no SAP, o que vive na loja e quem corrige quando os dois divergem. Só depois definimos a camada de ligação e os testes. Se procura apoio neste tipo de projeto, conheça a nossa integração de SAP com ecommerce, onde descrevemos como trabalhamos.
Outras combinações de SAP com ecommerce
Se a plataforma de destino ainda não está decidida, estes guias comparam o mesmo ERP com outras opções:
- SAP S/4HANA e Magento: pedidos, stock e preços
- SAP S/4HANA como retaguarda do PrestaShop
- SAP S/4HANA com BigCommerce
- SAP S/4HANA com SAP Commerce Cloud
- SAP S/4HANA com Salesforce Commerce Cloud
- SAP S/4HANA com WooCommerce: quando compensa e riscos
Perguntas frequentes
Preciso de middleware para integrar o SAP S/4HANA com o Adobe Commerce?
Não é obrigatório, mas é o desenho mais seguro. A camada intermédia concentra filas, repetições, registo de erros e transformação de dados, e evita que a lógica de integração fique espalhada pelos dois sistemas.
Posso começar só pelo stock e pelos preços?
Sim, e é uma boa forma de começar. São os dados que mais erros visíveis causam na loja e permitem validar a ligação antes de acrescentar encomendas e clientes.
Quanto tempo demora a integração?
Depende do número de fluxos, da qualidade dos dados mestre e das regras de preço. O levantamento inicial é o que permite estimar com realismo; prazos dados antes dele costumam falhar.
O que acontece se o SAP estiver indisponível?
A loja deve continuar a aceitar encomendas e guardá-las em fila, reenviando-as quando o SAP voltar. Sem fila, essas encomendas perdem-se ou têm de ser reintroduzidas à mão.
O Adobe Commerce as a Cloud Service muda a integração?
Muda a parte técnica: as rotas dos pontos de acesso em lote são diferentes, as filas são geridas pela plataforma e alguns pontos de acesso não existem. O desenho dos fluxos de dados mantém-se igual.