Migrando uma loja virtual com mais de 4 milhões de SKU’s para Vtex

Hoje gostaria de compartilhar um projeto que foi um grande desafio, superado pelas ações conjuntas entre a we.digi e cliente.
Um cenário que apresentou diversos pontos críticos: grande quantidade de produtos a serem importados, pouquíssimo tempo para a conclusão do projeto devido a fatores mandatórios, grande quantidade de sku’s de um mesmo produto, superando o limite Vtex de 50 sku’s por produto, dentre outros.

Sobre o cliente

A Urban Arts é uma grande galeria de arte online. Trabalha com mais de 6 mil artistas independentes do Brasil e do mundo.
Seu acervo conta hoje com mais de 130 mil artes autorais, exclusivas e com tiragens limitadas.

O desafio

Nosso cliente já possuía uma loja virtual em uma plataforma bem conhecida no mercado, uma grande empresa que devido a fatores cuja explicação foge ao escopo deste texto, está prestes a encerrar suas atividades, impondo uma realidade bem complexa a muitos de seus clientes que precisarão migrar de plataforma rapidamente.

Até perto da conclusão do projeto não sabíamos ao certo em que dia a loja atual do cliente simplesmente sairia do ar, poderia ser a qualquer momento. Assim, precisaríamos rapidamente reconstruir sua loja na plataforma Vtex, migrando todos os produtos.

Para ganharmos tempo, e devido à urgência, ficou decidido que o layout da nova loja seria o mesmo da loja atual. Ou seja, para esta etapa apenas replicaríamos o layout da loja atual e eventuais melhorias seriam discutidas em etapas posteriores.

No catálogo de produtos tínhamos mais de 120 mil itens cadastrados, e cada item possuía uma enorme quantidade de skus, em muitos casos, esse número ultrapassava 60 variações, superando o limite de 50 Skus da plataforma Vtex.

Em resumo, o cenário era que tínhamos que migrar mais de 4 milhões de sku’s rapidamente e adicionalmente propor uma modelagem de dados capaz de manter o relacionamento entre um produto e seus sku’s, levando em consideração o limite de 50 sku’s por produto existente na plataforma Vtex.

As soluções

Antes do início do projeto chegamos a uma modelagem que garantiria o relacionamento entre os produtos e seus sku’s e permitiria ao cliente ter a navegabilidade pretendida na loja.
E sobre a navegabilidade, apenas os produtos tidos como “principais”, ou seja, o primeiro sku de cada produto, deveria estar visível na vitrine da loja. As demais variações de cada produto somente seriam acessíveis na tela de detalhe do produto principal, momento em que, através de combos de seleção, o usuário poderia decidir qual variação do produto comprar.
Esse comportamento era vital, pois em uma vitrine com mais de 4 milhões de produtos haveria muita repetição de itens.

Iniciamos então os testes de importação, e neste momento escolhemos as API’s da Vtex para levar esses dados à plataforma.
Previamente ja havíamos instruído o cliente sobre como e em que formato nos enviar seu catálogo de produtos e, ao iniciar a importação, embora funcionando muito bem, percebemos que a velocidade com que as informações eram enviadas à Vtex não seria suficiente para atender nosso prazo.
Obviamente a Vtex possui regras quanto ao envio de dados, o que é perfeitamente compreensível, pois trata-se de uma forma de garantir segurança e performance a seus clientes.

Neste momento, percebemos que a forma mais rápida de enviar esses dados seria com a utilização de planilhas, no layout Vtex, contendo as informações que estávamos enviando via API devidamente formatadas. O processo, embora manual, permitia enviar grandes números produtos, estoque, preços e imagens mais rapidamente do que consumindo os serviços soap e rest Vtex. Porém, manipular essa enorme quantidade de produtos em planilhas poderia gerar bastante trabalho manual – um risco ao prazo, além de grande propensão a erros.

Entendemos então que precisaríamos automatizar o processo de geração dessas planilhas ao máximo, aumentando a velocidade e diminuindo riscos de eventuais erros na manipulação desses dados.
Nossos programadores então escreveram inúmeros scripts com esse objetivo: ler os dados enviados pelo cliente e gerar as planilhas Vtex de tal forma que seria necessário apenas submetê-las à Vtex.

Assim foi feito, porém percebemos que nossa modelagem utilizava muitos campos de sku para armazenar as especificações dos mesmos. Ironicamente, as planilhas de campos de sku são, em termos de quantidade de registros enviados, as mais restritivas: para cada envio somente 1000 linhas podem existir na planilha.

Para se ter uma dimensão da quantidade de dados, cada sku teria 5 campos, multiplicados por mais de 4 milhões de skus e dividido por mil, número máximo que uma planilha poderia ter para cada envio. Teríamos que enviar mais de 20 mil planilhas para Vtex, algo impraticável.

Neste ponto foi necessário discutir algo ja bastante sólido do projeto: a modelagem dos dados. Ja havia ocorrido uma reunião em que profissionais de layout e de integração com o ERP foram instruídos sobre a modelagem adotada, e neste ponto, isso mudaria.

Decidimos então remover o uso dos campos de produtos e skus e utilizar o poderoso Master Data da Vtex. Entidades de dados foram criadas para armazenar os dados e permitir o relacionamento entre eles.
Mais que isso, a performance do Master Data permitiu rápido envio dos dados, ótima performance na interface com o usuário na loja e via API um meio de o ERP acessar e gerenciar essas informações.

A we.digi construiu também um middleware para atuar como intermediário entre o ERP do cliente e a loja virtual. A motivação foi justamente “traduzir” os dados cadastrados no sistema de gestão para o formato esperado pela loja, enviando as informações corretamente ao Master Data, e em sentido oposto, informar o ERP sobre pedidos ocorridos traduzindo-os para os produtos correspondentes. Com isso conseguimos evitar customizações do ERP.
Dois serviços foram então implementados: Um para enviar os produtos inseridos e atualizados para a loja Vtex e outro para enviar os pedidos realizados na loja para o sistema de gestão.

Tudo voltava aos trilhos. A modelagem recém-adotada trouxe benefícios que nos permitiram enviar os dados em tempo satisfatório, seguro e em consonância com nosso prazo.

Ao final de todo processo, rotinas programadas acessaram as api’s Vtex apenas como forma de validar as informações enviadas.

Conclusão:

Durante o projeto nosso cliente acompanhou bem de perto cada decisão, avanço, desafio a ser superado e juntos conseguimos atingir o objetivo em aproximadamente 3 semanas.

Terminou por ser um ótimo desafio em que pudemos atestar todo o poder da plataforma Vtex e sua capacidade de entregar alta performance, mesmo em cenários além do padrão.

O que nosso cliente tem a dizer sobre nós

“Nossa loja virtual estava em uma plataforma com previsão de ser descontinuada em poucos dias, precisávamos de profissionais que pudessem nos ajudar a escolher uma nova e que fossem capazes de assumir essa demanda.
Através da we.digi pudemos conhecer melhor o que a Vtex tinha a oferecer e como poderia acolher nossa loja.
Sabíamos dos desafios que enfrentaríamos: um grande volume de informação a ser migrada, bem como o pouco tempo que tínhamos para fazer essa migração antes que a loja atual ficasse fora do ar.
Iniciado o projeto, foi recriado o layout da antiga loja e mais de 4 milhões de skus foram migrados. Em aproximadamente 30 dias ja estávamos em condições de publicar nossa nova na plataforma Vtex.
Agradecemos à we.digi pelo comprometimento e parceria, parceria essa que segue até hoje.”

Raphael Martins – Urban Arts