Integrar o OpenText DAM com o Magento é pôr as imagens aprovadas no OpenText Media Management (OTMM) na galeria de cada produto, de forma repetível e sem carregamentos manuais. Num catálogo complexo, com milhares de produtos e várias imagens por produto, o difícil não é enviar uma imagem: é enviar todas, confirmar o resultado e corrigir só o que falhou.
Na Avafa tratamos estes projetos na nossa área de integração de DAM com ecommerce. Este guia concentra-se no que muda quando o catálogo é grande: o formato do pedido à API, o tempo que cada envio demora, o desenho de uma carga em lotes e a forma de confirmar que a loja ficou igual ao DAM.
As indicações de plataforma seguem a documentação para programadores da Adobe. Se a loja usa Adobe Commerce em vez de Magento, também temos um guia sobre integrar o OpenText DAM com Adobe Commerce.
Como recebe o Magento as imagens de produto por API?
O Magento aceita imagens de produto pela API REST, com um pedido POST ao endpoint de media do produto, identificado pelo SKU. Segundo o tutorial da Adobe, o corpo do pedido inclui o tipo de media, a etiqueta, a posição, o estado desativado e os papéis da imagem. O conteúdo vai em base64, com o tipo MIME e o nome do ficheiro.
A resposta devolve o identificador da nova imagem. O exemplo da Adobe usa o âmbito default no caminho do pedido, e a verificação faz-se atualizando a página do produto no administrador para ver se a imagem aparece.
A Adobe avisa que o pedido pode demorar cerca de 30 segundos, consoante o alojamento. A página também não indica um limite de tamanho do ficheiro, pelo que esse valor deve ser testado no ambiente de cada projeto em vez de assumido.
O que muda num catálogo complexo?
Muda o volume, e o volume muda a arquitetura. Um cálculo simples mostra porquê: 10.000 produtos com 5 imagens são 50.000 pedidos. Se cada um demorasse os 30 segundos que a Adobe indica como referência e corressem em série, a carga levaria mais de 17 dias. Na prática os pedidos são mais rápidos, mas o cálculo explica porque é que uma passagem única não funciona.
A tabela seguinte resume como ajustamos a estratégia ao volume. Os limiares são orientações nossas, não valores da Adobe.
| Volume | Estratégia | Cuidado principal |
|---|---|---|
| Até 500 produtos | Carga única supervisionada | Validar uma amostra |
| De 500 a 10.000 | Lotes com fila | Repetir só os falhados |
| Mais de 10.000 | Lotes paralelos controlados | Limitar a carga no servidor |
| Atualizações diárias | Só ativos alterados | Guardar a data da última carga |
Em qualquer dos casos, o primeiro passo é medir. Contar produtos, imagens por produto e atualizações por semana dá o volume real, e é com esse número, e não com uma estimativa, que se escolhe a estratégia e se dimensiona o servidor que vai receber os pedidos.
Como se desenha uma carga em lotes?
Uma carga em lotes divide o catálogo em grupos pequenos, processa cada grupo de forma independente e regista o resultado de cada pedido. Assim, um erro num produto não bloqueia os restantes.
- Listar no OTMM os ativos com estado aprovado e a data da última alteração.
- Agrupar os ativos por SKU e dividir os SKUs em lotes de tamanho fixo.
- Para cada SKU, comparar as imagens do OTMM com as que já estão na galeria.
- Enviar apenas as imagens em falta ou alteradas, com os papéis e a posição corretos.
- Guardar o resultado de cada pedido, incluindo o código de erro e o identificador do ativo.
- Repetir os falhados no ciclo seguinte e alertar quando o mesmo SKU falha várias vezes.
O passo três é o que evita duplicados. Sem comparar primeiro, cada execução acrescenta imagens que já existem e a galeria enche-se de cópias.
Que dados do OTMM devem acompanhar cada imagem?
- SKU: a chave que liga o ativo ao produto. Sem ele, o ativo não é enviado.
- Papéis da imagem: imagem base, miniatura e imagem pequena, para a loja escolher a certa em cada local.
- Posição: a ordem na galeria, definida no DAM e não à mão na loja.
- Etiqueta: o texto associado à imagem, preparado por idioma quando a loja tem várias vistas.
- Estado de aprovação: só os ativos aprovados seguem.
Como se confirma que a loja ficou igual ao DAM?
Confirma-se com um relatório de reconciliação, que compara por SKU o número de imagens aprovadas no OTMM com o número de imagens na galeria do Magento. As diferenças são a lista de trabalho: produtos sem imagem, produtos com imagens a mais e produtos cuja imagem principal não coincide.
Recomendamos correr o relatório depois de cada carga e uma vez por semana em modo de rotina. Num catálogo grande, é a única forma de apanhar desvios que ninguém reparou porque nenhum cliente reclamou.
Que riscos tem esta integração e como se evitam?
- Cargas que não terminam. Pedidos lentos em série podem durar dias; usa-se fila e lotes.
- Imagens duplicadas. Evita-se comparando a galeria com o OTMM antes de enviar.
- Ficheiros demasiado pesados. Como a imagem viaja em base64 dentro do pedido, convém exportar do DAM uma versão otimizada para a web.
- Papéis em falta. Sem papéis definidos, a loja pode não mostrar a imagem no local certo.
- Edições manuais. Alterações feitas à mão no administrador podem ser perdidas na sincronização seguinte; a galeria só deve mudar através do DAM.
Lista de verificação antes de arrancar o projeto
- Todos os ativos aprovados do OTMM têm SKU?
- O limite de tamanho do ficheiro foi testado no ambiente real?
- A carga corre em lotes, com fila e repetição?
- A comparação com a galeria acontece antes de cada envio?
- Os papéis e as posições estão definidos no DAM?
- Existe um relatório de reconciliação por SKU?
- A regra de quem edita a galeria está escrita?
- Há um ambiente de teste com um conjunto representativo de produtos?
Como trabalhamos na Avafa
Começamos por um inventário do OTMM e do catálogo, para dimensionar o volume e identificar produtos sem imagem. Depois desenhamos a carga em lotes, testamo-la num ambiente separado e só então a ligamos à loja. O âmbito completo está na página de integração de DAM com ecommerce, e a visibilidade da loja nos motores de pesquisa na nossa agência de SEO para Magento.
Guias relacionados do mesmo cluster
- Integrar o Odoo com o Magento
- Integrar o A3ERP com o Magento
- Integrar o Sage 200 com o Magento e quando usar middleware
- Integrar o Microsoft Dynamics 365 com o Magento
- Integrar o OpenText DAM com o Adobe Commerce
Perguntas frequentes
Quanto tempo demora o envio de uma imagem pela API do Magento?
A Adobe refere que o pedido pode demorar cerca de 30 segundos, consoante o alojamento. Por isso as cargas grandes correm em lotes e não numa única passagem.
Como se envia uma imagem de produto?
Com um pedido POST ao endpoint de media do produto, indicando o SKU, com a imagem em base64, o tipo MIME e o nome do ficheiro. A resposta devolve o identificador da imagem.
Existe um limite de tamanho para a imagem?
A página da Adobe consultada não indica um limite. Convém testá-lo no ambiente do projeto e exportar do DAM uma versão otimizada.
O OpenText DAM tem conector nativo para o Magento?
Na documentação consultada não encontrámos um conector nativo. A ligação faz-se por desenvolvimento ou por uma camada de integração, e convém confirmá-lo com o fornecedor antes de orçamentar.
Posso usar a integração da Adobe com o AEM Assets no Magento?
A integração que a Adobe documenta refere implementações do Adobe Commerce e exige o AEM Assets. Para o Magento Open Source, convém confirmar a compatibilidade com a Adobe antes de a considerar.
Quanto tempo demora um projeto destes?
Depende do número de produtos, da qualidade dos metadados e do ambiente de teste. Por isso começamos sempre por um inventário, antes de indicar prazos.