BigCommerce e SAP, conectados do jeito certo.

Nada deste projeto pode ser dimensionado até isso ser respondido, porque os três são produtos diferentes com superfícies de integração diferentes. Quem orça “uma integração do BigCommerce com SAP” sem perguntar está orçando um palpite.

O BigCommerce é a ponta fácil. Ele entrega uma API REST e GraphQL documentada, webhooks, listas de preços e grupos de clientes, e o B2B Edition soma contas de empresa e hierarquias. Ele se comporta como um produto SaaS moderno porque é um.

O SAP é onde estão as decisões, e na prática só existem quatro rotas:

• BAPIs e RFC. O caminho clássico, e no ECC muitas vezes o único que alcança a lógica de que você precisa. Síncrono, rápido, e exige uma conexão RFC para dentro do seu ambiente, o que é uma conversa com quem manda no Basis e no firewall.
• IDocs. Documentos assíncronos. Excelentes para o fluxo de pedidos e faturas onde alguns minutos de atraso não incomodam, e completamente errados para “quanto este cliente paga por este item agora”. Muitas lojas que rendem mal rendem mal porque alguém usou IDocs para preço.
• OData via SAP Gateway. A superfície moderna. Padrão no S/4HANA, disponível no ECC se alguém configurar. É aqui que você quer estar quando tem escolha, porque é HTTP, é cacheável e todo desenvolvedor já entende.
• Middleware. SAP Integration Suite, ou um iPaaS de terceiros como Boomi, Celigo, Jitterbit ou MuleSoft. Soma custo e um salto, e compra retentativas, transformação, monitoramento e um lugar para a lógica que não pertence a nenhum dos dois sistemas.

O padrão honesto para a maioria dos projetos B2B: OData ou BAPI para tudo que o comprador espera, IDoc para o fluxo de documentos que pode ser assíncrono, e middleware na frente para que um SAP lento não vire uma loja lenta. Decidir isso cedo já é quase toda a arquitetura.

Tire os diagramas e toda loja B2B faz ao seu ERP as mesmas seis perguntas. Acertar essas seis é o projeto. O resto é decoração.

1. Quem é este cliente. O número de cliente no SAP por trás da conta logada, incluindo sold-to, ship-to e payer quando diferem, o que em B2B acontece o tempo todo.
2. Quanto ele paga. Preço líquido para este cliente, este material, esta quantidade, hoje. Esse é o difícil e ganha uma seção própria abaixo.
3. O que ele pode levar. Não só estoque em mãos. Disponibilidade para promessa, nas plantas de onde aquele cliente é de fato atendido.
4. Registrar o pedido. E devolver um número de documento de vendas real do SAP, não um id de pedido do BigCommerce com a promessa de sincronizar depois.
5. Onde está. Status de entrega e remessa, com rastreio onde a transportadora devolve.
6. Quanto ele deve. Histórico de faturas, itens em aberto, posição de crédito. É isso que transforma uma loja num portal de autoatendimento, e é a parte por que os compradores realmente entram.

A número seis é sempre subestimada. A maioria dos compradores B2B não entra na sua loja para navegar. Entra para repetir um pedido que já fez e para ver quanto deve.

Se vale ler uma seção desta página, é esta.

O SAP não guarda um preço para um cliente e um material que você simplesmente consulta. Ele calcula um, no momento em que você pergunta, usando a técnica de condições: um esquema de preços feito de tipos de condição, avaliado por sequências de acesso contra registros de condição, filtrado por datas de validade. O preço líquido de um cliente pode depender da lista de preços dele, contrato, grupo de material, quantidade, faixas de escala, promoções, acréscimos, frete e impostos, resolvidos numa sequência específica que o seu negócio configurou ao longo de anos.

Você não consegue reimplementar isso numa loja, e não deveria tentar. Toda tentativa em que fomos chamados para socorrer é a mesma história: alguém exportou registros de condição para listas de preços do BigCommerce, ficou certo para a maioria dos clientes, e as exceções viraram um fluxo silencioso de pedidos errados que o financeiro achou semanas depois.

O padrão correto é perguntar ao SAP. Precifique o carrinho no SAP, seja por um BAPI de preços, um pedido de vendas simulado, ou um serviço OData feito para isso, e mostre o que ele devolver. Depois faça engenharia em volta da latência, não em volta da verdade:

• Faça cache agressivo, e por cliente. Um preço é válido para aquele cliente por uma janela razoável. Guarde em cache e invalide nos eventos que de fato o alteram.
• Preço indicativo na listagem, preço exato no carrinho. Catálogo e busca podem servir um preço cacheado ou indicativo. Carrinho, cotação e checkout precisam ser um número vivo do SAP, porque é isso que vai ser faturado.
• Nunca mostre um preço que não pode honrar. Se o SAP não responde e você não tem preço cacheado válido, diga ao cliente que o preço está indisponível no momento e deixe que ele peça uma cotação. Um ERP fora do ar é um incômodo. Um preço errado é uma nota de crédito e um telefonema.
• Sem preço, sem adicionar ao carrinho. Se o SAP não tem preço para aquele cliente e material, desabilite em vez de deixar passar um pedido que vai falhar lá na frente.

Boa parte das empresas que nos fazem essa pergunta está no ECC e tem um programa de S/4HANA em algum ponto do roadmap. O instinto é esperar. Normalmente é a escolha errada, porque a loja está ganhando ou perdendo dinheiro agora e o programa de S/4 vai atrasar.

A escolha certa é construir de um jeito que sobreviva à migração:

• Ponha uma camada de integração no meio. A loja fala com a sua camada; a sua camada fala com o SAP. Quando o SAP mudar por baixo, você reescreve um adaptador e não a loja.
• Defina os seis contratos primeiro nos seus termos. Não nos do SAP. “Obter preço líquido para cliente e material” é uma ideia estável. O BAPI por trás não é.
• Mantenha nomes de campo do SAP fora da loja. Mapeie na fronteira. É a coisa mais barata que você pode fazer hoje para o corte para S/4 passar sem barulho.
• Teste os contratos contra o S/4 antes de o ERP entrar em produção, não depois. Tamanhos de campo, tipos de documento e comportamento de erro mudam, e a loja costuma ser o último sistema que alguém lembra de testar.

Feito assim, a migração para o S/4HANA toca um adaptador e uma rodada de testes. Feito do outro jeito, vira um segundo projeto de loja que você não orçou.

Dos projetos em que entramos depois do fato, em ordem aproximada de frequência:

• O preço foi copiado em vez de perguntado. Coberto acima. É a causa número um de uma loja B2B perder dinheiro em silêncio.
• A loja é tão rápida quanto o SAP. Sem camada de cache, então cada página de produto espera um ERP dimensionado para processos batch e usuários internos.
• Pedidos duplicam. Sem chave de idempotência no envio, uma retentativa ou um clique duplo cria dois documentos de vendas, e ninguém percebe até a expedição perceber.
• Ninguém é dono do caminho de falha. O SAP entra em janela de manutenção e a loja mostra um stack trace ou, pior, um preço zerado.
• O estoque está certo e é inútil. Sincroniza-se o estoque total em vez da disponibilidade para promessa da planta daquele cliente, então o site promete o que não consegue enviar.
• Zero observabilidade. Quando um cliente diz que o preço está errado, ninguém consegue responder o que o SAP devolveu no momento em que ele olhou, e a investigação começa do nada.

Nada disso é exótico. Tudo é mais barato de prevenir do que de descobrir em produção, o que é o argumento para fazer o desenho da integração antes do desenho da loja, e não depois.