Integrar o OpenText DAM com o Adobe Commerce é garantir que as imagens e os materiais aprovados no DAM chegam à galeria de cada produto, com o texto alternativo certo e sem duplicar trabalho. A Adobe documenta uma integração própria para o AEM Assets; com o OpenText Media Management (OTMM), o caminho tem de ser construído, e convém escolhê-lo bem.
Para empresas com catálogos grandes e várias lojas, esta decisão afeta os custos de manutenção durante anos. Na Avafa tratamos o tema na nossa área de integração de DAM com ecommerce, e este guia compara as opções que costumam estar em cima da mesa.
O artigo explica o que a Adobe documenta para ativos, compara as opções numa matriz de decisão, descreve o processo que seguimos e lista os riscos e as verificações. As indicações de plataforma seguem a documentação da Adobe.
O que documenta a Adobe para gerir ativos no Adobe Commerce?
A Adobe documenta uma integração com o AEM Assets que liga os ativos digitais aos produtos e categorias do Adobe Commerce com base no SKU ou noutros atributos-chave. Segundo a documentação, as imagens e os materiais de marketing atualizam-se automaticamente quando o AEM Assets muda, e a limpeza de ativos também é automatizada.
A mesma documentação indica que o texto alternativo pode ser definido por vista de loja e sincroniza com o campo Label das imagens do Commerce. Com a versão 1.4.6 ou posterior da extensão, os papéis de imagem personalizados do AEM Assets são mantidos na sincronização, além dos quatro papéis standard.
Quanto a versões, a integração aplica-se ao Adobe Commerce on Cloud a partir da versão 2.4.5, ao Adobe Commerce as a Cloud Service e ao Adobe Commerce Optimizer, e exige o AEM Assets as a Cloud Service com licenças ativas. Quem usa o OTMM como DAM principal não tira partido desta integração tal como está documentada.
Que opções existem para ligar o OpenText DAM ao Adobe Commerce?
Na documentação consultada não encontrámos uma integração da Adobe para o OpenText, pelo que há quatro caminhos práticos. A matriz seguinte compara-os; os níveis de esforço e de manutenção são uma avaliação nossa, indicativa.
| Opção | Esforço | Manutenção | Quando faz sentido |
|---|---|---|---|
| Migrar o DAM para AEM Assets | Alto | Baixa depois | O DAM vai ser substituído |
| Camada de integração própria | Médio | Média | O OTMM continua como fonte |
| API REST direta do Commerce | Baixo a médio | Alta | Catálogo pequeno ou piloto |
| Carga manual assistida | Baixo | Muito alta | Só como solução temporária |
A migração para o AEM Assets é a única opção que usa a integração documentada pela Adobe, mas obriga a mudar de DAM. Para quem quer manter o OTMM, a camada de integração costuma ser o equilíbrio certo entre custo e controlo.
Em qualquer das opções, o SKU é a chave que liga o ativo ao produto. Se o OTMM não guarda o SKU em todos os ativos, esse trabalho de limpeza vem antes de qualquer código, e é muitas vezes o passo que mais tempo ocupa no projeto.
Como funciona a ligação pela API do Adobe Commerce?
O Adobe Commerce aceita imagens de produto pela API REST, no endpoint de media do produto, identificado pelo SKU. Segundo o tutorial da Adobe, o pedido leva o tipo de media, a etiqueta, a posição, o estado desativado, os papéis da imagem e o conteúdo, com a imagem em base64, o tipo MIME e o nome do ficheiro. A resposta devolve o identificador da nova imagem.
A Adobe avisa que o pedido pode demorar cerca de 30 segundos, consoante o alojamento. Com milhares de produtos, isto pesa: o processo deve correr em lotes, com fila e repetição, e não numa única passagem.
Quem pode editar a galeria do produto?
Quando há duas fontes de imagens, o DAM e a galeria do Commerce, é preciso decidir quem manda. Se alguém altera uma imagem diretamente no administrador da loja, a sincronização seguinte pode substituí-la ou deixá-la desfasada do OTMM.
A regra mais simples é que a galeria só se altera através do DAM. A equipa da loja pode pedir alterações, mas não as faz à mão, e o registo da integração mostra sempre de onde veio cada imagem.
Qual o processo que seguimos?
- Inventariar o OTMM e o catálogo, e medir quantos produtos não têm imagem ou têm imagem desatualizada.
- Escolher a opção da matriz e confirmar a versão e o tipo de implementação do Adobe Commerce.
- Definir o mapeamento: SKU, papéis de imagem, posição e texto alternativo por vista de loja.
- Construir a camada de integração e testá-la com um conjunto pequeno e representativo.
- Executar uma primeira carga controlada e comparar o resultado com o OTMM.
- Ativar a sincronização contínua, com registo de erros e alertas.
Que riscos tem esta integração e como se evitam?
- Papéis de imagem mal atribuídos. Se imagem base, miniatura e imagem pequena não forem definidas, a loja escolhe mal; o mapeamento deve indicá-las.
- Pedidos lentos. Com um tempo de resposta de cerca de 30 segundos, uma carga sem lotes pode não terminar; usa-se uma fila.
- Imagens em base64. O ficheiro inteiro viaja no pedido, por isso convém exportar do DAM uma versão otimizada.
- Texto alternativo sem idioma. Com várias vistas de loja, o texto alternativo deve existir por idioma.
- Dependência de uma extensão. Se a opção escolhida depende de uma extensão, as versões compatíveis têm de ser acompanhadas.
- Edições manuais na galeria. Alterações feitas à mão no administrador podem ser perdidas na sincronização seguinte.
Nenhum destes riscos é raro. Todos aparecem em projetos de catálogo grande, e todos se resolvem com regras escritas no início, antes de a primeira imagem ser enviada.
Lista de verificação antes de arrancar o projeto
- Está decidido se o DAM se mantém ou se migra para AEM Assets?
- Sabemos a versão e o tipo de implementação do Adobe Commerce?
- Todos os ativos do OTMM têm SKU?
- Os papéis de imagem estão mapeados?
- O texto alternativo existe por vista de loja?
- A carga corre em lotes, com repetição dos pedidos falhados?
- A regra de quem edita a galeria está escrita?
- Há um ambiente de teste com um conjunto representativo de produtos?
Se a resposta a alguma destas perguntas for não, o projeto ainda não está pronto para arrancar. Convém resolver essa lacuna primeiro, porque corrigi-la depois custa mais.
Como trabalhamos na Avafa
Começamos por um inventário do DAM e do catálogo e só depois propomos uma das opções da matriz, com os custos e os riscos de cada uma. Testamos num ambiente separado antes de tocar na 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 e Adobe Commerce.
Guias relacionados do mesmo cluster
- Integrar o OpenText DAM com Magento em catálogos complexos
- Integrar o Odoo com o Adobe Commerce
- Integrar o A3ERP com o Adobe Commerce
- Integrar o Sage 200 com o Adobe Commerce
- Integrar o Microsoft Dynamics 365 com o Adobe Commerce
Perguntas frequentes
O OpenText DAM tem integração oficial com o Adobe Commerce?
Na documentação consultada, a Adobe descreve a integração com o AEM Assets e não com o OpenText. Para o OTMM, a ligação faz-se por desenvolvimento ou por uma camada de integração, e convém confirmá-lo com os fornecedores.
É obrigatório usar o AEM Assets?
Não. É a opção que a Adobe documenta, mas pode manter-se o OTMM e ligá-lo pela API REST do Adobe Commerce através de uma camada de integração.
Que versão do Adobe Commerce é necessária?
Para a integração com o AEM Assets, a Adobe indica a versão 2.4.5 ou posterior no Adobe Commerce on Cloud. Para as opções por API, confirma-se a versão em cada projeto.
Quanto demora o envio de uma imagem pela API?
A Adobe refere que o pedido pode demorar cerca de 30 segundos, consoante o alojamento. Por isso as cargas grandes correm em lotes.
Quanto tempo demora um projeto destes?
Depende da opção escolhida, do número de produtos e das vistas de loja. Por isso começamos sempre por um inventário, antes de indicar prazos.