Plataforma · Personalização do Sana Commerce

Personalize o Sana Commerce sem quebrar a próxima atualização.

A ProjectThunder, certificada pela Sana, personaliza o Sana Commerce Cloud e o 9.x dentro do framework suportado: temas, add-ons, o SDK, scripting de front-end, campos personalizados e integrações. O objetivo é simples. Faça dele o seu, e mantenha-o atualizável.

O que você pode personalizar

Quase tudo o que importa, sem tocar no core.

A Sana dá espaço real para moldar a loja por meio de pontos de extensão suportados. O segredo é saber qual alavanca puxar, para que o resultado combine com a sua marca e com os seus compradores enquanto a plataforma continua se atualizando por baixo. Veja como abordamos os projetos no Sana Commerce Cloud de modo geral.

Tema e UX

  • Tema personalizado construído sobre o design system da Sana: layout, tipografia, cor e estilo de componentes alinhados à sua marca.
  • Injeção de HTML, CSS e JavaScript a partir do Sana Admin para um comportamento de front-end direcionado em toda a loja.
  • Conteúdo e merchandising pelo CMS: landing pages, navegação e apresentação de produtos.
  • Trabalho responsivo e acessível testado em web e mobile, rumo ao WCAG 2.1 AA.

Add-ons e SDK

  • Add-ons personalizados via SDK do Sana Commerce Cloud para recursos que o produto padrão não traz.
  • Pontos de extensão documentados em vez de edições no core, para que o add-on permaneça na trilha de atualização da Sana.
  • Cadência de SDK com suporte de longo prazo para que as versões do add-on cheguem em um cronograma previsível.
  • Etapas de checkout personalizadas, lógica de loja e fluxos específicos do comprador.

Integrações

  • Pagamento: Sana Pay e gateways de terceiros por meio de padrões de add-on suportados.
  • Impostos: integrações com provedores (por exemplo Vertex ou Avalara) sem reescrever a lógica fiscal na loja.
  • Busca: a nativa da Sana, ou busca externa conectada para catálogos B2B profundos.
  • PIM e dados: conectores que alimentam a loja com conteúdo de produto enriquecido.

Fluxos e campos personalizados

  • Campos personalizados trazidos do ERP ou da Sana para produtos, contas e pedidos.
  • Padrões de pedido B2B: recompra, aprovações, multiendereço, nuances de hierarquia de contas.
  • Aprimoramentos no portal da conta: anexos de documentos, visões do histórico de pedidos, visibilidade do status de crédito.
  • Configuração primeiro, código apenas onde a configuração realmente não alcança.
Seguro para atualizações por design

Por que ficar dentro do framework importa.

O Sana Commerce Cloud se atualiza automaticamente a cada duas semanas, aproximadamente. Essa cadência é um recurso, não um incômodo, mas só se as suas personalizações forem construídas para acompanhá-la. A linha entre personalização suportada e mudança arriscada no core é o que define tudo.

Personalização suportada

  • Temas, conteúdo de CMS e injeção de HTML, CSS e JavaScript pelo Sana Admin.
  • Add-ons construídos sobre o SDK e os pontos de extensão e APIs documentados.
  • Configuração e campos personalizados em vez de código bifurcado.
  • Resultado: a loja continua recebendo as atualizações e correções automáticas da Sana.

Mudanças arriscadas no core

  • Editar ou bifurcar o código core da Sana para forçar um comportamento que o framework não expõe.
  • Personalizações que a Sana não consegue atualizar por você, o que pode tirar um projeto da trilha de atualização automática.
  • Acoplamento oculto a internals que uma versão posterior da Sana pode mudar sem aviso.
  • Resultado: cada atualização vira um merge manual e arriscado em vez de uma atualização silenciosa em segundo plano.
Como fazemos

Nossa regra: configuração primeiro, depois pontos de extensão, o core quase nunca.

01

Mapeamos o requisito para uma alavanca.

Antes de escrever código, verificamos se configuração, uma mudança de tema, uma injeção ou um add-on adequado podem entregá-lo. A maioria das coisas pode ser feita sem tocar no core.

02

Construímos sobre APIs documentadas.

Quando o código é necessário, usamos o SDK e os pontos de extensão da Sana, não detalhes internos que uma versão futura poderia mudar. Isso mantém o trabalho na trilha de atualização.

03

Sinalizamos o trade-off com honestidade.

Se um pedido realmente exigir uma mudança no core, nós dizemos, explicamos o custo de atualização e buscamos uma alternativa suportada antes que alguém se comprometa a manter um fork.

Onde ajudamos

O que uma colaboração de personalização cobre.

Tema Sana personalizado e trabalho de design system
Injeção de HTML / CSS / JavaScript e scripting de front-end
Desenvolvimento de add-ons personalizados com o SDK da Sana
Integrações de pagamento, impostos, busca e PIM
Campos personalizados do ERP e da Sana para produtos, contas, pedidos
Ajuste de fluxos B2B: recompra, aprovações, hierarquias
Revisão de segurança para atualizações das personalizações existentes
Coordenação com o seu parceiro de implementação de ERP ou Sana
Retainer pós-lançamento e suporte gerenciado
Perguntas

Personalização do Sana Commerce, respondida.

As personalizações vão quebrar nas atualizações da Sana?

Não deveriam, se forem construídas do jeito certo. O Sana Commerce Cloud publica atualizações automáticas a cada duas semanas, aproximadamente. O trabalho feito por meio de pontos de extensão suportados (temas, injeção de HTML, CSS e JavaScript, configuração, campos personalizados e add-ons que usam as APIs documentadas) acompanha essas atualizações. Onde os projetos entram em apuros é ao editar o código core da Sana, que a Sana não consegue atualizar por você e que tira você da trilha de atualização automática. Mantemos as mudanças dentro do framework para que a plataforma possa continuar se atualizando por baixo delas.

Vocês personalizam o Sana Commerce Cloud e o on-premises 9.x?

Sim, ambos, embora a abordagem seja diferente. No Sana Commerce Cloud trabalhamos por meio do SDK, do framework de add-ons, dos temas e das injeções do Sana Admin, e preferimos os pontos de extensão para que a loja permaneça em atualizações automáticas. O on-premises Sana Commerce 9.x permite personalização mais profunda em nível de código, mas é um ciclo de vida diferente: os add-ons não são mais atualizados para o 9.3, então tratamos o trabalho em 9.x como um build estável a manter, e não como um SaaS em atualização contínua. Se você está no 9.x e pesando uma mudança para o Cloud, diremos com honestidade se as suas personalizações migram de forma limpa. Veja a nossa comparação de plataformas se você também estiver avaliando outras opções.

Vocês conseguem construir um add-on personalizado?

Sim. Construímos add-ons personalizados com o SDK do Sana Commerce Cloud para recursos que o produto padrão não cobre: um provedor de pagamento ou de impostos sob medida, um conector para um PIM ou serviço de busca, uma etapa de checkout personalizada, ou lógica de loja específica de como os seus compradores fazem pedidos. Construímos sobre pontos de extensão e APIs documentados em vez de aplicar patch no core, rodamos o add-on na cadência de SDK com suporte de longo prazo da Sana, e o testamos contra staging antes que ele chegue à produção.

Vocês trabalham com o nosso parceiro de ERP?

Sim, e fazemos isso com frequência. Muitos projetos da Sana envolvem um parceiro de implementação de ERP ou de Sana à parte, que é dono do lado do SAP ou do Microsoft Dynamics. Encaixamos como o time de web, design e desenvolvimento: cuidamos da loja, do tema, dos add-ons e das integrações de front-end, e coordenamos com o seu parceiro de ERP os contratos de dados e o mapeamento de campos. Somos uma agência de web e desenvolvimento certificada pela Sana, não uma revenda de ERP, então ficamos à vontade para dividir o trabalho em vez de ser donos de cada camada. Saiba mais sobre trabalhar com o nosso time de agência Sana Commerce.

Personalização do Sana Commerce

Tem uma personalização em mente?

Diga o que você precisa que a loja faça. Diremos se ela vive em um tema, uma injeção, um add-on ou (raramente) algo mais profundo, e a manteremos segura para atualizações.

877.609.9029
Inicie uma conversa