Optimizely Configured Commerce ou CWS Platform: quem sustenta a integração com o ERP?

Nota editorial: comparativo de arquitetura entre Optimizely Configured Commerce e a CWS Platform, escrito para quem responde como CIO ou CTO. Todo fato sobre Optimizely Configured Commerce vem da documentação pública dele, com o endereço ao lado.

Para o CIO de um distribuidor, a integração com o ERP é o lugar onde o projeto de comércio digital ganha ou perde credibilidade. Se o pedido não chega ao ERP, se o estoque do portal diverge do armazém, se uma atualização de framework quebra o conector, o problema deixa de ser do portal e passa a ser da TI inteira. E o custo dessa peça não está na primeira entrega: está em quem mantém o conector vivo quando o ERP, o framework e a plataforma mudam, cada um no seu ritmo.

Três perguntas separam os desenhos de integração: onde o código do conector roda, em que versão de framework ele depende para continuar suportado, e quem hospeda e paga os ambientes onde esse código é desenvolvido e testado. São perguntas de arquitetura, mas a resposta delas vira linha de orçamento e de risco.

Este comparativo olha para Optimizely Configured Commerce e CWS Platform só por esse ângulo. A comparação sobre regra comercial está em Optimizely Configured Commerce ou CWS Platform: dá para mudar a regra comercial sem abrir chamado?, e a moldura dos modelos de plataforma em os três modelos de plataforma de comércio B2B.

75s

O que o Optimizely Configured Commerce resolve bem

O desenho de integração do Optimizely Configured Commerce é explícito e documentado. O Windows Integration Service opera como um agente instalado dentro do firewall corporativo do cliente, que consulta o site de comércio para executar os jobs de integração e devolve os resultados. Em cada job, pré e pós-processadores rodam no servidor web do Configured Commerce e os processadores de integração rodam no servidor do agente. O fluxo se divide em tarefas Refresh, que puxam do ERP produtos, estoque e clientes, e Submit, que empurram para o ERP pedidos e clientes gerados na loja.

Para quem prefere não abrir o banco do ERP para fora, esse modelo é coerente: o agente fica do lado de dentro, e o acesso direto a banco é usado para grandes volumes enquanto web services tratam a lógica de negócio, como o envio do pedido, segundo a visão geral de tecnologia de integração. Para ERPs em nuvem e conexões com PIM ou armazenamento em nuvem, há a opção de WIS interno, que roda diretamente no Configured Commerce e carrega customizações por Extensions.dll.

Há ainda conectores pré-construídos para SX.e, Prophet 21, Infor A+, Acumatica e FACTS, e o recurso que a documentação chama de Real time pricing and inventory, que consulta preço e estoque no ERP por chamada direta à API ou pelo agente, com timeout padrão de 10 segundos, cache de 60 minutos para preço e envio em lotes de 20 itens. Para uma TI que roda um desses ERPs e domina o ecossistema .NET, é um ponto de partida concreto.

Onde a arquitetura diverge

A divergência que interessa ao CIO está em quem sustenta o código de integração ao longo do tempo. A documentação do próprio fornecedor registra dois pontos:

• limitação registrada na documentação do fornecedor, consultada em 16/10/2026: os conectores de ERP da Optimizely não suportam .NET 8; a Optimizely oferece os conectores de ERP existentes no estado em que estão ("Optimizely's ERP connectors do not support .NET 8.", "Optimizely offers existing ERP connectors in their current state", https://docs.optimizely.com/configured-commerce/docs/erp-connector-implementation).
• limitação registrada na documentação do fornecedor, consultada em 16/10/2026: o parceiro ou time de implementação hospeda todos os ambientes de desenvolvimento e teste ("Your partner/implementation team is responsible for hosting all development and test environments.", https://docs.optimizely.com/configured-commerce/docs/optimizely-configured-commerce-sandbox-vs-production-environment-management-and-performance).

Os dois pontos se encontram no mesmo lugar: o conector é oferecido no estado em que está, a adaptação fica do lado do cliente, e quem adapta também precisa manter os ambientes onde essa adaptação é desenvolvida e testada. A mesma página de implementação de conectores descreve que, sem suporte a .NET 8, a adaptação do código aberto fornecido aos parceiros é manual. Para a TI, isso transforma a integração em ativo próprio, com dívida técnica própria, e o ritmo dessa dívida passa a acompanhar o ritmo do framework.

Na CWS Platform, o desenho é API-first e headless, com APIs REST e webhooks. Tabelas de preço, regras e contratos podem chegar do ERP ou do CRM por API, e a regra comercial fica em parâmetros do Commerce Rules Engine (CDL Workspace), não em código de conector. O cálculo de impostos pode ser delegado ao motor fiscal que o cliente já usa: o imposto vem do ERP.

A decisão técnica é mapear quem é dono de cada linha de código entre o ERP e o portal, e por quanto tempo.

O que muda na operação, pela lente de CIO/CTO

A diferença aparece no calendário da TI. Quando o conector depende de um framework que o fornecedor não leva adiante, cada mudança de versão do runtime vira um pequeno projeto de migração: reescrever ou recompilar, testar contra o ERP, homologar em ambiente próprio, implantar. Quando os ambientes de desenvolvimento e teste são responsabilidade do parceiro, esse projeto tem também custo de infraestrutura e de contrato fora da licença da plataforma.

A segunda consequência é de risco. O recurso de consulta ao ERP no momento do pedido, por definição, depende do ERP responder, e a própria documentação do Windows Integration Service pede que se defina o comportamento de fallback se o ERP falhar. Isso não é problema em si, é um requisito de desenho que precisa ter dono, teste e monitoração.

Quatro perguntas ajudam a levar esse ponto para qualquer avaliação:

1. Em qual versão de framework o conector do seu ERP roda hoje, e qual é o plano quando ela sair de suporte.
2. Quem hospeda e paga os ambientes de desenvolvimento e teste durante os três anos do contrato.
3. Quanto da regra comercial vai ficar dentro do código de integração, e quanto em configuração.
4. O que o portal faz quando o ERP não responde.

Na CWS Platform, a política comercial fica em parâmetros do Commerce Rules Engine (CDL Workspace); tabelas, regras e contratos podem ser configurados na plataforma ou chegar do ERP e do CRM por API, e o CDL Workspace é um só sistema para todo o ecossistema. Todos os clientes rodam a mesma versão, e a cobrança é de licença de plataforma e de licença de integração, sem percentual sobre vendas ou GMV.

Quando escolher o Optimizely Configured Commerce

O Optimizely Configured Commerce atende bem a cenários com estas características:

TI com competência .NET e ERP com conector existente. Escolha essa arquitetura quando o ERP está na lista de conectores pré-construídos e a equipe ou o parceiro tem capacidade de adaptar e manter esse código no framework que a operação exige.

Integração que precisa ficar atrás do firewall. Escolha essa arquitetura quando a política de segurança pede que o acesso ao ERP parta de dentro da rede, com o Windows Integration Service instalado no ambiente do cliente.

Parceiro de implementação já contratado para os ambientes. Escolha essa arquitetura quando a empresa já tem um parceiro que hospeda desenvolvimento e teste e esse custo já está no orçamento.

Quando a CWS Platform é a escolha certa neste cenário

A CWS Platform é a escolha indicada quando a TI quer que a integração transporte dados e a regra comercial fique fora do código.

Integração por API, regra em parâmetros. Escolha essa arquitetura quando o objetivo é reduzir a lógica de negócio dentro do conector. A plataforma é API-first e headless, com APIs REST e webhooks; tabelas de preço, regras e contratos são configurados na plataforma, no princípio de configuração em vez de código, ou recebidos do ERP e do CRM por API, com casas decimais customizáveis.

Imposto onde ele já é calculado. Escolha essa arquitetura quando o ERP ou o motor fiscal da empresa é a fonte do imposto. O cálculo de impostos pode ser delegado ao motor fiscal que o cliente já usa.

Uma versão e um sistema. Escolha essa arquitetura quando a TI prefere não administrar uma versão própria. Todos os clientes rodam a mesma versão, e o CDL Workspace é um só sistema para todo o ecossistema.

Crédito e pedido sob a mesma regra. Escolha essa arquitetura quando a venda a prazo é a regra. O limite de crédito do cliente é mantido na plataforma, concedido no CDL Workspace ou por API, e o mesmo pedido aceita mais de um meio de pagamento.

Por onde continuar

Se a sua pergunta ainda é qual arquitetura serve à sua operação, o caminho é as sete perguntas que separam as arquiteturas de comércio B2B, e a comparação entre modelos está em os três modelos de plataforma de comércio B2B.

Se a decisão depende de entender quanto da sua integração atual é dado e quanto é regra, vale conversar com um especialista da CWS Platform para mapear essa fronteira antes de escolher. A página Quando a Integração Trava Tudo trata da dor por trás deste cenário em profundidade, sem falar de fornecedor nenhum.