Integrar o SAP Business One com o Adobe Commerce Cloud usando middleware é ligar os dois sistemas através de uma camada intermédia que recebe, valida, transforma e reenvia cada mensagem. O Adobe Commerce funciona sobre uma fila de mensagens e o SAP Business One responde pelo Service Layer, e é o middleware que absorve a diferença de ritmo entre ambos.
Para a empresa, a razão é prática: um catálogo grande, picos de encomendas e um ERP que não pode ser sobrecarregado pedem uma ligação que aguente falhas sem perder dados. Tratamos estes projetos na nossa área de integração de SAP com ecommerce, e este guia explica onde o middleware é necessário e como o desenhar.
Vê aqui o que o Adobe Commerce Cloud traz de base, como funcionam os endpoints em massa e a fila, que papel tem o middleware, que dados vão em cada sentido e uma lista de verificação.
O que é o Adobe Commerce Cloud e o que significa para a integração?
O Adobe Commerce Cloud é o Adobe Commerce alojado numa plataforma gerida, com implementação orientada por Git. Segundo a documentação da Adobe, a plataforma é um serviço automatizado em que cada envio de código dispara a construção e a implementação, e inclui infraestrutura preparada com PHP, MySQL, Redis ou Valkey, uma fila de mensagens (RabbitMQ ou ActiveMQ) e motores de pesquisa suportados. Funciona em regiões da AWS e da Azure.
Para a integração, o que importa é que a fila de mensagens já existe de origem. Isso permite receber grandes volumes de operações sem bloquear a loja, mas também significa que parte do processamento é assíncrona: o pedido é aceite e processado depois.
O SAP Business One, por seu lado, expõe os dados pelo Service Layer. Segundo a formação oficial da SAP, as operações seguem o mesmo modelo em todos os objetos: POST cria, GET lê, PATCH atualiza e DELETE apaga. É esta diferença de ritmo entre uma loja assíncrona e um ERP síncrono que justifica o middleware.
Como funcionam os endpoints em massa do Adobe Commerce?
Os endpoints em massa agrupam várias chamadas do mesmo tipo num único pedido e colocam cada uma na fila como mensagem separada. Segundo a documentação da Adobe, na versão alojada em cloud e on-premises, o caminho inclui /async/bulk antes de /V1, por exemplo POST /rest/{código da vista}/async/bulk/V1/products.
Há quatro pontos da documentação que condicionam o desenho da integração:
- A resposta devolve um identificador do lote (bulk_uuid) e, por cada item, o estado “accepted”, que significa apenas que o pedido entrou na fila.
- O consumidor async.operations.all processa as mensagens, e por omissão são as tarefas agendadas que o arrancam.
- É necessário ter o RabbitMQ instalado e configurado para usar a API em massa na versão PaaS.
- Pedidos duplicados podem ser aceites na fila e só falhar depois, no processamento.
A consequência é clara: “aceite” não é “concluído”. O middleware tem de verificar o resultado do processamento e não dar o envio por feito só porque a API respondeu bem.
Que papel tem o middleware entre o SAP Business One e o Adobe Commerce?
O middleware é o sítio onde se decide o que enviar, quando, em que formato e o que fazer se falhar. Sem ele, cada sistema chama o outro diretamente e qualquer indisponibilidade deixa dados a meio. Com ele, há cinco funções que cumpre:
- Receber a mensagem de um sistema e guardá-la antes de a enviar.
- Transformar campos, unidades, códigos de imposto e estados de um modelo para o outro.
- Controlar o ritmo, para não sobrecarregar o Service Layer nem a fila da loja.
- Repetir o que falhou e impedir duplicados com uma chave por mensagem.
- Registar tudo e avisar a pessoa certa quando algo precisa de intervenção.
O middleware pode ser uma plataforma de integração contratada ou um serviço desenvolvido para o caso. A escolha depende do número de fluxos, da equipa técnica disponível e do custo de manutenção a longo prazo, não do que parece mais moderno.
Como autenticar e proteger a ligação?
A autenticação depende da versão do Adobe Commerce. Segundo a documentação da Adobe, as aplicações de terceiros autenticam-se com OAuth 1.0a nas versões em cloud e on-premises, enquanto o Adobe Commerce como serviço usa o Adobe Identity Management Service, com pedidos assinados por um token de acesso.
Do lado do SAP Business One, o acesso ao Service Layer deve usar um utilizador técnico dedicado, com as permissões mínimas para os objetos que a integração toca. Evite partilhar a conta de um colaborador, porque quando essa pessoa mudar de funções a integração pára.
Guarde as credenciais no cofre do middleware, nunca no código nem em ficheiros de configuração partilhados.
Como tratar o stock com várias origens?
Se a loja usa várias origens de inventário, o stock tem de ser atribuído a cada origem, não só ao produto. A documentação da Adobe indica que, para atribuir origens em massa, a quantidade inicial é zero e as quantidades se acrescentam depois com POST /V1/inventory/source-items.
A mesma documentação avisa que remover origens em massa apaga os dados de inventário desses produtos e pode afetar as quantidades vendáveis e as reservas de encomendas por processar, e recomenda concluir primeiro essas encomendas e expedições. Se todas as origens forem removidas de um produto, esse produto deixa de poder ser vendido.
Por isso, a integração nunca deve remover origens como forma de corrigir stock. Deve atualizar quantidades, e as mudanças de estrutura devem ser feitas à mão, com revisão.
Que dados vão em cada sentido?
Cada dado tem um sistema mestre, e o outro apenas o recebe:
| Dado | Sistema mestre | Sentido | Nota |
|---|---|---|---|
| Artigos e SKU | SAP | SAP para loja | Um SKU por artigo |
| Preços | SAP | SAP para loja | Em lote, com verificação |
| Stock por origem | SAP | SAP para loja | Só atualizar quantidades |
| Encomendas | Adobe Commerce | Loja para SAP | Chave anti-duplicado |
| Faturas e expedição | SAP | SAP para loja | A loja apenas mostra |
| Clientes | Definir | Ambos | Chave por NIF |
Duas decisões merecem destaque antes de desenhar os fluxos: quem manda nos clientes e se o stock enviado é o físico ou o disponível depois de reservas.
Lista de verificação antes de arrancar
Se faltar uma resposta nesta lista, resolva-a antes de começar:
- Cada dado tem um sistema mestre escrito e aprovado.
- A versão do Adobe Commerce e o modelo de autenticação estão confirmados.
- A fila de mensagens e o consumidor estão ativos e monitorizados.
- O middleware verifica o resultado do processamento, não só a aceitação.
- Há uma chave por mensagem para impedir duplicados.
- O utilizador técnico do SAP tem permissões mínimas.
- Existe ambiente de ensaio do SAP e do Adobe Commerce.
- Está escrito o que acontece quando o SAP ou a loja ficam indisponíveis.
Como trabalhamos na Avafa
Começamos por mapear dados, volumes e responsáveis, e só depois decidimos se o projeto precisa de middleware e de que tipo. Revemos o desenho dos fluxos antes de qualquer desenvolvimento, para que a camada intermédia não se torne mais um sistema por gerir. Se quiser ver como abordamos estes projetos, comece pela página de integração SAP com ecommerce.
Guias relacionados do mesmo cluster
Estes guias comparam a mesma ligação com outras plataformas e outros ERP:
- SAP S/4HANA com Adobe Commerce para empresas
- SAP Business One com Magento: mapeamento e pagamentos
- Odoo com Adobe Commerce para grandes projetos
- SAP Business One com SAP Commerce Cloud
- SAP Business One com WooCommerce
Perguntas frequentes
É obrigatório usar middleware?
Não é obrigatório, mas é recomendável quando há volume, várias origens de stock ou necessidade de repetir envios falhados. Para um catálogo pequeno e poucos fluxos, uma ligação mais simples pode bastar.
Uma resposta “accepted” da API significa que o pedido foi concluído?
Não. Segundo a documentação da Adobe, “accepted” significa que o pedido foi adicionado à fila de mensagens. O resultado só se conhece depois do processamento.
Quem processa as mensagens da fila no Adobe Commerce Cloud?
Segundo a Adobe, o consumidor async.operations.all trata as mensagens assíncronas e em massa e, por omissão, é arrancado pelas tarefas agendadas. Convém monitorizá-lo.
Como evito encomendas duplicadas no SAP?
Guarde, no middleware, a referência da encomenda da loja e o número do documento criado no SAP, e consulte-os antes de reenviar. A documentação da Adobe refere que duplicados podem entrar na fila, por isso o controlo tem de existir do lado da integração.
Posso corrigir stock removendo origens em massa?
Não é recomendável. A documentação da Adobe avisa que essa ação apaga dados de inventário e pode afetar reservas de encomendas por processar. Corrija quantidades, não a estrutura.