Integrar a Salsify com o PrestaShop é usar a Salsify como plataforma de experiência de produto (PXM) e o webservice do PrestaShop como porta de entrada na loja. A Salsify prepara conteúdo, atributos e ativos; o PrestaShop recebe produtos, combinações e imagens através da sua API. Quase sempre é preciso um serviço intermédio que traduza um modelo no outro.
Para a empresa, o que está em causa é manter uma só versão do produto. Sem ela, as descrições, as imagens e os atributos divergem entre a plataforma de conteúdo e a loja, e cada correção tem de ser repetida à mão. Na Avafa tratamos esta ligação na nossa área de integração de PIM com ecommerce.
Neste guia vê como se liga cada lado, que cuidados o webservice do PrestaShop exige, que dados vão em cada sentido, os riscos mais comuns, as vantagens e as limitações do PXM neste cenário e uma lista de verificação antes de arrancar.
Como se liga a Salsify ao PrestaShop?
Liga-se por um serviço que lê o conteúdo na Salsify e o escreve no webservice do PrestaShop. Nas fontes públicas que consultámos não encontrámos um conector dedicado da Salsify para o PrestaShop, pelo que o desenho assume uma integração por API; convém confirmar com a Salsify se existe uma alternativa à medida do seu contrato.
Do lado da Salsify, a página oficial descreve a plataforma como integrável com a restante arquitetura de sistemas da empresa e refere integrações com plataformas de comércio. Na documentação de um conector de terceiros que utiliza a API da Salsify constam operações como iniciar uma exportação, consultar o seu estado e ler produtos individualmente ou em bloco. É esse tipo de operação que o serviço de integração usa para saber o que mudou.
Do lado do PrestaShop, a documentação oficial para programadores explica que o webservice vem desativado por omissão. Ativa-se nos parâmetros avançados, na secção do webservice, e é preciso criar uma chave de acesso. A chave pode ser gerada pelo próprio PrestaShop ou escolhida, e neste caso tem de ter 32 caracteres; a documentação recomenda a chave gerada, por ser mais difícil de adivinhar.
Que cuidados exige o webservice do PrestaShop?
Exige permissões bem definidas e atenção ao formato dos dados. A API fica na raiz da loja, no caminho da API, e a documentação diz que o nome de utilizador é a própria chave de acesso e que não há palavra-passe. Por isso avisa para ter muito cuidado com os direitos de cada chave e com quem a conhece, e indica o cabeçalho de autorização como o método mais seguro.
- as permissões definem-se por recurso, com direitos distintos de leitura, criação, atualização e eliminação; a documentação avisa para não dar todos os direitos de todos os recursos a nenhuma chave;
- o formato por omissão é XML; o JSON está disponível para as respostas, mas desde a versão 8.1 o webservice não consegue ler JSON como entrada;
- o esquema em branco de cada recurso serve de modelo para criar registos, e o esquema de sinopse lista campos, tipos e regras;
- o parâmetro de idioma limita os campos traduzíveis, como descrições, aos idiomas indicados;
- espaços e quebras de linha dentro das etiquetas XML podem estragar um recurso.
Na prática, escreve-se em XML, mesmo que se leia em JSON. O serviço de integração deve gerar o XML sem formatação decorativa e validar a resposta de cada pedido.
Que recursos do PrestaShop a integração usa?
Usa os recursos de catálogo que a documentação lista no webservice. Esta é a nossa matriz de permissões mínimas para uma integração de conteúdo, a ajustar a cada loja.
| Recurso | Para que serve | Direitos |
|---|---|---|
| Produtos | Ficha e descrições | Ler, criar, atualizar |
| Categorias | Árvore da loja | Ler, criar, atualizar |
| Combinações | Variantes por atributo | Ler, criar, atualizar |
| Imagens | Fotografias do produto | Ler, criar |
| Disponibilidades | Stock por produto | Só se a Salsify for mestre |
| Idiomas | Identificar línguas | Só ler |
A linha do stock merece atenção. Normalmente o stock vem do ERP e não da Salsify, por isso a chave de conteúdo não deve ter direitos sobre as disponibilidades. Uma chave com menos direitos limita os estragos se alguma coisa correr mal.
Que dados vão em cada sentido?
Cada dado deve ter um único sistema mestre.
| Dado | Sistema mestre | Sentido |
|---|---|---|
| Descrições e atributos | Salsify | Salsify para loja |
| Imagens | Salsify | Salsify para loja |
| Categorias | Salsify ou ERP | Origem para loja |
| Preços e stock | ERP | ERP para loja |
| Encomendas | PrestaShop | Loja para ERP |
O erro mais comum é deixar a Salsify escrever preços ou stock. Se o ERP os governa, a plataforma de conteúdo não deve ser o intermediário.
Quais são as vantagens e as limitações do PXM neste cenário?
A vantagem é a qualidade e a consistência do conteúdo; a limitação é que a ligação ao PrestaShop é feita por medida. Uma plataforma de conteúdo como a Salsify faz sentido quando o catálogo é grande, há várias equipas a editar e o conteúdo é partilhado com mais canais, como marketplaces e retalhistas.
| Aspeto | Vantagem | Limitação |
|---|---|---|
| Conteúdo | Uma só versão do produto | Exige governação |
| Canais | Reutiliza fichas | Cada canal tem o seu mapeamento |
| PrestaShop | API documentada | Escrita só em XML |
| Custo | Menos retrabalho | Licença e manutenção |
Para uma loja PrestaShop pequena, com poucas referências e uma só equipa, a Salsify pode ser desproporcionada. Nesse caso, a importação por ficheiro do próprio PrestaShop pode resolver com menos custo.
Que riscos tem esta integração e como se evitam?
| Risco | Onde aparece | Prevenção |
|---|---|---|
| Chave com direitos a mais | Alterações indevidas | Permissões por recurso |
| XML mal formatado | Recurso corrompido | Gerar sem espaços |
| Dois mestres do mesmo dado | Textos diferentes | Matriz de mestres escrita |
| Identificadores diferentes | Produtos duplicados | Chave de produto comum |
| Falhas silenciosas | Produtos em falta | Registo e alertas |
A documentação do PrestaShop oferece ainda um mecanismo de cache: se o serviço enviar o valor de controlo guardado da última resposta, a API devolve a indicação de que nada mudou. Usá-lo evita ler de novo recursos inalterados e poupa tempo em catálogos maiores.
Os custos escondidos também contam: manutenção do mapeamento quando surgem novos atributos, testes a cada atualização do PrestaShop ou da plataforma de conteúdo e acompanhamento de erros.
Como testar o acesso antes de desenvolver?
Testa-se chamando o caminho base da API com a chave criada. Segundo a documentação oficial, essa chamada devolve os recursos a que a chave tem acesso, com a indicação dos métodos permitidos em cada um. É a forma mais rápida de confirmar que as permissões estão como se desenhou.
Depois, peça o esquema em branco do recurso de produtos, preencha-o com um produto de teste e envie-o. Se a resposta trouxer o identificador do novo registo, o circuito de escrita funciona. Repita o ensaio com um produto que tenha combinações e outro com várias línguas, porque é aí que o mapeamento costuma falhar.
Lista de verificação antes de arrancar
- Cada dado tem um sistema mestre escrito e aceite.
- Existe um identificador de produto comum, que não muda depois de criado.
- O webservice está ativo e a chave tem apenas os direitos necessários.
- O serviço gera XML limpo, sem espaços entre etiquetas.
- Os idiomas da loja estão mapeados com os da Salsify.
- Há um ambiente de teste com um lote representativo, incluindo combinações.
- A leitura da Salsify trata apenas o que mudou desde a última execução.
- Existe registo de erros e alguém que o lê todos os dias.
Se três ou mais respostas forem negativas, o projeto ainda não está pronto para desenvolvimento.
Como trabalhamos na Avafa
Começamos por mapear dados e responsáveis e só depois definimos o serviço de ligação. Revemos as permissões do webservice e o desenho do fluxo antes de qualquer desenvolvimento. Para ver como abordamos estes projetos, comece pela página de integração de PIM com ecommerce.
Perguntas frequentes
O PrestaShop aceita JSON?
Aceita-o como formato de resposta. Segundo a documentação oficial, desde a versão 8.1 o webservice não consegue ler JSON como entrada, pelo que a escrita se faz em XML.
Como crio a chave do webservice?
Ativa-se o webservice nos parâmetros avançados e adiciona-se uma nova chave, gerada pelo PrestaShop. Depois definem-se as permissões por recurso.
Existe um conector pronto entre a Salsify e o PrestaShop?
Nas fontes públicas que consultámos não encontrámos um, por isso o desenho assume uma integração por API. Confirme com a Salsify se há alternativa ao seu contrato.
Preciso de um middleware?
Não necessariamente. Um serviço próprio pode bastar para dois sistemas. O middleware compensa quando a cadeia inclui ERP, marketplaces e outros canais.
Posso começar por uma parte do catálogo?
Pode, e recomendamos. Uma marca ou uma categoria permite validar o mapeamento antes de abranger tudo.
Guias relacionados do mesmo cluster
Se a plataforma de destino ainda não está decidida, estes guias comparam a Salsify com outras opções: