Integrar o SAP S/4HANA com o Salesforce Commerce Cloud é ligar o ERP, onde vivem preços, stock e documentos, à plataforma de comércio da Salesforce que serve a montra digital. Neste guia falamos do B2C Commerce, a variante pensada para vendas a consumidores e a clientes empresariais com catálogo próprio. A ligação não vem feita: constrói-se com as APIs de cada lado e, quase sempre, com uma camada intermédia.
Para a empresa, o que está em jogo é a fiabilidade. Uma encomenda que não chega ao ERP, um preço desatualizado ou um stock que não corresponde ao armazém custam mais do que o próprio projeto quando o volume cresce. Na Avafa tratamos estas ligações dentro da nossa área de integração de SAP com ecommerce, e este guia resume o que decidir antes de começar.
Cobrimos as APIs da plataforma, a autenticação, os dados que devem circular, os riscos mais comuns e uma lista de verificação.
Que APIs do Salesforce Commerce Cloud se usam na integração?
A Salesforce disponibiliza a B2C Commerce API, também chamada Commerce API ou SCAPI, um conjunto de APIs REST para montras, ferramentas de gestão e integrações. Segundo a documentação oficial, estas APIs estão disponíveis sem custo adicional para os clientes do B2C Commerce e dividem-se em dois grupos com usos diferentes.
| Grupo | Para quê | Autenticação |
|---|---|---|
| — | — | — |
| Shopper APIs | Navegação, carrinho e checkout | SLAS (OAuth 2.1) |
| Admin APIs | Produtos, encomendas e inventário | Token do Account Manager |
As Shopper APIs são desenhadas para volume elevado e suportam utilizadores anónimos. As Admin APIs servem a gestão e as integrações de retaguarda, têm um uso mais moderado e permitem leitura e escrita. Numa ligação ao ERP, o trabalho pesado costuma passar pelas Admin APIs, porque é aí que se mantêm produtos, preços, inventário e encomendas.
A documentação da Salesforce também refere um guia de migração desde o OCAPI, a interface anterior, o que indica que a SCAPI é a direção para novos projetos. Se a plataforma já tem integrações antigas em OCAPI, convém perguntar o que existe e planear a migração em separado.
Como se autentica a integração?
Cada grupo de APIs tem o seu mecanismo, e a camada intermédia tem de guardar as credenciais com cuidado. Nas Shopper APIs, a autenticação passa pelo SLAS, que emite tokens de acesso com validade limitada. Nas Admin APIs, o acesso depende de um token obtido através do Account Manager, a ferramenta onde a equipa de TI cria utilizadores e gere o acesso às instâncias.
Na prática, isto traz duas tarefas ao projeto. A primeira é criar um cliente de API dedicado à integração, com permissões só para o que precisa. A segunda é tratar a renovação dos tokens no fluxo, porque um token expirado não deve ser confundido com uma falha do ERP.
Como se liga o S/4HANA do lado do ERP?
Do lado da SAP, a documentação do S/4HANA descreve APIs OData para documentos como as ordens de venda (Sales Order, A2X), que a camada intermédia pode chamar para criar e consultar pedidos. A versão exata da API depende da edição do S/4HANA, em nuvem ou instalada em servidores próprios, por isso o desenho deve ser confirmado na documentação da edição em uso.
A camada intermédia fica entre os dois e faz três coisas: converte formatos, regista o que já foi enviado e trata os erros. Pode ser uma plataforma de integração ou desenvolvimento à medida. O que não deve acontecer é ligar as duas APIs sem nenhum ponto central de registo e monitorização.
Que dados devem ir em cada sentido?
Cada dado deve ter um único sistema mestre. Este é o ponto de partida que usamos no levantamento:
| Dado | Sistema mestre | Sentido |
|---|---|---|
| — | — | — |
| Preços e condições | S/4HANA | ERP para plataforma |
| Stock disponível | S/4HANA | ERP para plataforma |
| Dados base do produto | S/4HANA ou PIM | Origem para plataforma |
| Conteúdo e imagens | PIM ou Commerce Cloud | Origem para plataforma |
| Encomendas | Commerce Cloud | Plataforma para ERP |
| Estado de expedição e fatura | S/4HANA | ERP para plataforma |
Se o catálogo é grande e as descrições são trabalhadas fora do ERP, o habitual é separar funções: o S/4HANA fica com preço, stock e documentos, e um PIM ou a plataforma com a descrição comercial. Misturar as fontes é a causa mais comum de dados sobrepostos.
Que riscos tem esta integração e como se evitam?
Os riscos mais frequentes estão no processo e no controlo de erros, não na tecnologia:
| Risco | Medida preventiva |
|---|---|
| — | — |
| Encomenda falha no ERP sem aviso | Alertas e fila de reprocessamento |
| Preço diferente do contrato | Fonte única de preços no ERP |
| Stock desfasado da montra | Frequência de atualização definida |
| Credenciais de API expostas | Cliente dedicado e permissões mínimas |
| Integrações antigas em OCAPI | Inventário e plano de migração |
O primeiro risco merece atenção. Sem monitorização, uma encomenda rejeitada por um campo em falta pode ficar parada dias. Um bom desenho define quem recebe o alerta, como se corrige o dado e como se reenvia o pedido, sem que seja preciso mexer à mão na base de dados.
O segundo é típico de quem vende a empresas. Quando cada cliente tem condições próprias, a plataforma deve consultar o preço no ERP, ou receber uma réplica atualizada, em vez de manter uma tabela paralela.
Em tempo real ou por lotes?
Depende do dado, e a regra prática é perguntar o que acontece se chegar com atraso. A disponibilidade de um artigo de grande rotação justifica um fluxo mais rápido. Para a maior parte dos preços e do stock, uma atualização agendada chega e é mais fácil de monitorizar. O tempo real acrescenta complexidade e custo de operação, por isso convém reservá-lo para o que o cliente sente de imediato.
Lista de verificação antes de arrancar o projeto
- Confirmar que a plataforma em uso é o B2C Commerce e que a SCAPI está disponível.
- Confirmar a edição e a versão do S/4HANA e as APIs standard para ordens de venda.
- Definir o sistema mestre de cada dado: preço, stock, produto, cliente e encomenda.
- Escrever o mapeamento de campos, incluindo unidades, moedas e impostos.
- Criar um cliente de API dedicado e definir quem guarda as credenciais.
- Inventariar integrações antigas em OCAPI e decidir o que migrar.
- Definir o tratamento de erros: quem recebe o alerta e como se reprocessa.
- Testar o ciclo completo: encomenda, alteração, cancelamento, expedição e fatura.
- Atribuir um responsável pela monitorização depois da entrada em produção.
Se um ponto não tem resposta, o projeto ainda não está pronto, e é mais barato descobri-lo agora.
Como trabalhamos na Avafa
Começamos por mapear dados e responsáveis, e só depois escolhemos a forma de ligação. Revemos o desenho dos fluxos e as regras de propriedade de cada dado antes de qualquer desenvolvimento, para que o projeto não arranque com um conflito entre fontes. Para ver como abordamos este trabalho, comece pela página de integração de SAP com ecommerce.
Guias relacionados do mesmo cluster
Se a plataforma de destino ainda não está decidida, estes guias comparam o mesmo ERP com outras opções:
- SAP S/4HANA com WooCommerce: quando compensa e riscos
- SAP S/4HANA com SAP Commerce Cloud
- SAP S/4HANA com BigCommerce
- SAP S/4HANA com Adobe Commerce para empresas
- Microsoft Dynamics 365 com Salesforce Commerce Cloud
Perguntas frequentes
O Salesforce Commerce Cloud tem ligação nativa ao SAP S/4HANA?
Não de forma que dispense trabalho. A ligação faz-se pelas APIs de cada plataforma, com uma camada intermédia. Convém confirmar na documentação de cada fornecedor o que existe à data do projeto.
Devo usar a SCAPI ou o OCAPI?
Para projetos novos, a SCAPI. A documentação da Salesforce inclui um guia de migração desde o OCAPI, o que indica essa direção. Integrações antigas devem ser inventariadas e migradas com plano.
Que API se usa para ler e escrever encomendas?
Depende do caso. As Admin APIs servem a gestão de encomendas e inventário, e as Shopper APIs cobrem o carrinho e o checkout. O desenho deve indicar qual usar em cada fluxo.
Quem deve ser o mestre dos dados de preço?
O S/4HANA, na maior parte dos casos B2B, porque é aí que vivem os contratos e as condições por cliente. O importante é que a regra esteja escrita.
Quanto tempo demora um projeto destes?
Depende do número de fluxos e da qualidade dos dados no ERP. Em vez de uma estimativa genérica, convém fazer primeiro o levantamento e o mapeamento de dados.