Integrar o Plytix com o Adobe Commerce é fazer com que o catálogo tratado no PIM chegue à loja sem reescritas manuais. A ajuda do Plytix não documenta um conector próprio para o Adobe Commerce, por isso a ligação constrói-se com ficheiros de canal, com a importação da própria plataforma ou com a API de comércio, quase sempre com uma camada intermédia.
Para uma marca média, o ganho está em tempo e consistência. Quando descrições, atributos e imagens vivem em vários ficheiros, cada lançamento exige retrabalho e as lojas por país divergem. Com um fluxo definido, a equipa de produto edita num só lugar e a loja recebe as alterações de forma previsível.
Este guia compara as três vias possíveis, explica as regras da Adobe para importação e para a API em lote e termina com uma lista de verificação. Faz parte do nosso trabalho de integração de catálogos e PIM.
Que formas existem de ligar o Plytix ao Adobe Commerce?
Existem três: feed ou ficheiro importado, importação nativa e API em lote. Todas partem do mesmo princípio, em que o Plytix é a origem dos dados de produto e o Adobe Commerce o destino.
No Plytix, os canais geram ficheiros CSV, XLSX, XML ou NDJSON, e os webhooks e as ligações via Make ou Zapier permitem reagir a eventos. Para o Magento, a ajuda do Plytix documenta um feed por URL lido por uma extensão de terceiros, a Wyomind. Como o Adobe Commerce e o Magento Open Source partilham a base de importação, a lógica aplica-se, mas deve ser validada na sua versão e no seu tipo de alojamento.
Na Adobe, a importação de dados aceita produtos, preços avançados, clientes e fontes de stock. A API REST oferece ainda pontos de entrada em lote, pensados para volumes maiores.
Como funciona a importação nativa do Adobe Commerce?
A importação nativa carrega um ficheiro CSV na administração e valida-o antes de gravar. Em Sistema > Transferência de dados > Importar, escolhe-se o tipo de entidade, o comportamento e o ficheiro, e o botão Check Data indica os erros antes de se avançar.
Os comportamentos são adicionar ou atualizar, substituir e eliminar. O primeiro cria produtos novos e atualiza os existentes, e permite alterar todos os campos exceto o SKU. O segundo apaga os dados existentes e perde as referências, e dá erro se o SKU do ficheiro não existir. Por isso, para o dia a dia, a escolha habitual é adicionar ou atualizar.
A documentação da Adobe dá três avisos úteis. O limite do ficheiro depende do php.ini e, por omissão, é de 2 MB. Ficheiros com marca de ordem de bytes UTF-8 podem causar falhas. E, em catálogos grandes, convém retirar as colunas de categorias e url_key quando não mudam, porque incluí-las regenera os reescritos de URL de todos os produtos.
O que muda com a API em lote?
Os pontos de entrada em lote enviam muitos pedidos de uma vez, mas a resposta apenas confirma que ficaram em fila. Segundo a documentação da Adobe, o pedido é dividido em entidades e cada uma segue como mensagem para a fila. O resultado final só se conhece quando as mensagens são processadas.
- O caminho para produtos usa o segmento async/bulk: em PaaS e instalações próprias vem antes de V1, e em SaaS vem depois.
- Em PaaS ou instalação própria é preciso instalar e configurar o RabbitMQ antes de usar a API em lote.
- Em SaaS, as filas funcionam automaticamente.
- Pedidos duplicados entram na fila e só falham mais tarde, no processamento.
- Os pedidos GET não são suportados.
- Sem código de loja na rota, a atualização aplica-se apenas à loja predefinida; o código all abrange todas.
Isto tem uma consequência prática: quem constrói a ligação tem de registar o identificador do lote e verificar o estado de cada item, em vez de assumir sucesso quando a resposta chega.
Como tratar várias lojas e idiomas?
Cada vista de loja deve receber o seu próprio conteúdo, e o ficheiro ou o pedido tem de indicar claramente a que vista pertence cada valor. Na API em lote, o código de loja na rota limita a operação a essa loja; sem código, só a loja predefinida é atualizada.
Para marcas que vendem em Portugal e em Espanha, isto significa manter textos, unidades e moedas separados por canal no Plytix. Misturar idiomas num único campo é o erro mais comum e o mais difícil de corrigir depois da carga, porque obriga a repetir a importação.
Importação, feed ou API: qual escolher?
Esta é a matriz de decisão que usamos como ponto de partida nos projetos de catálogo.
| Via | Automação | Quando faz sentido |
|---|---|---|
| Importação nativa CSV | Manual | Carga inicial e correções |
| Feed com extensão | Agendada | Alterações frequentes, um destino |
| API em lote com middleware | Total | Vários países e regras próprias |
Para uma marca média com poucas lojas, a importação com ficheiro costuma bastar. A API em lote compensa quando o catálogo muda todos os dias, existem várias vistas de loja ou o mesmo conteúdo segue também para marketplaces.
Que dados devem ser tratados com cuidado?
| Dado | Risco | Cuidado |
|---|---|---|
| SKU | Alteração depois da carga | Congelar antes de começar |
| Categorias | Reescritos de URL | Importar só quando mudam |
| Imagens | Caminhos inválidos | Testar os endereços |
| Idiomas | Valores na vista errada | Mapear por vista de loja |
O Plytix deve mandar nos textos, atributos e imagens. Preço e stock pertencem à plataforma ou ao ERP, e o canal do PIM não os deve sobrescrever. Definir isto por escrito, campo a campo, evita a maior parte dos conflitos.
Lista de verificação antes de arrancar
- Confirmar a versão e o tipo de alojamento: SaaS, PaaS ou instalação própria.
- Fixar a lista de SKUs e os atributos obrigatórios.
- Definir qual sistema é o mestre de cada campo.
- Mapear atributos do Plytix para atributos do Adobe Commerce.
- Preparar um ambiente de ensaio com cópia do catálogo.
- Importar um grupo pequeno e rever o relatório de erros.
- Combinar quem acompanha as falhas e com que periodicidade.
Como trabalhamos na Avafa
Começamos pelo mapeamento de atributos e pela decisão de qual via compensa, e só depois construímos o fluxo. Testamos num ambiente de ensaio, validamos o relatório de erros e deixamos o processo documentado para a equipa de produto. Se precisa de apoio com a loja, veja a nossa agência de SEO para Magento e Adobe Commerce ou fale connosco sobre integração de catálogos.
Guias relacionados do mesmo cluster
Estes guias tratam combinações próximas e ajudam a comparar sistemas:
- Plytix com Magento: feed, Wyomind e limites
- Plytix com BigCommerce
- Akeneo como PIM do Adobe Commerce
- Bluestone PIM com Adobe Commerce
- Brandfolder com Adobe Commerce
- Celum com Adobe Commerce para vários países
Perguntas frequentes
O Plytix tem conector oficial para o Adobe Commerce?
A ajuda do Plytix não documenta um. Para Magento descreve um feed por URL com a extensão Wyomind, de um fornecedor terceiro, e as restantes opções passam por ficheiros ou por uma camada intermédia.
Preciso do RabbitMQ para usar a API em lote?
Em PaaS e instalações próprias, sim: a Adobe indica que é preciso instalar e configurar o RabbitMQ, o gestor de mensagens predefinido. Em SaaS, as filas funcionam automaticamente.
A API em lote diz-me se a importação correu bem?
A resposta confirma apenas que cada pedido ficou em fila. É necessário guardar o identificador do lote e verificar depois o estado de cada item.
Posso importar só as alterações?
Sim. O comportamento adicionar ou atualizar cria produtos novos e atualiza os existentes, mantendo o SKU como chave. Os campos de valores múltiplos, como categorias, não são removidos se faltarem no ficheiro.
Vale a pena automatizar logo no início?
Nem sempre. Se o catálogo é pequeno e muda pouco, uma importação manual bem validada pode chegar durante os primeiros meses. A automação compensa quando as alterações são frequentes, e convém desenhá-la só depois de o mapeamento de atributos estar estável e a equipa saber quem corrige os erros.
Quanto tempo demora um projeto destes?
Depende do número de atributos, das vistas de loja e do estado do ambiente de ensaio. Só se pode estimar depois do mapeamento, por isso evitamos prazos genéricos.