Integrar o OpenText DAM com o Salesforce Commerce Cloud é fazer com que as imagens e os ficheiros aprovados no DAM cheguem ao catálogo da loja sem exportações manuais. O OpenText Media Management (OTMM) guarda as versões finais dos ativos; o Commerce Cloud mostra-as, associadas ao produto certo e ao tipo de vista certo. A ligação faz-se por API e exige regras claras de nomes, estados e variantes.
Para uma empresa com catálogo extenso, o ganho está na rotina: menos fotografias a chegar tarde à loja, menos produtos com imagem antiga e menos equipas a carregar o mesmo ficheiro duas vezes. Na Avafa tratamos esta ligação dentro da nossa área de integração de DAM com ecommerce, e este guia resume o que convém decidir antes de começar.
O artigo explica como o Commerce Cloud gere imagens, que dados passam do DAM para a loja, como se faz a ligação técnica, que riscos existem e que lista de verificação usamos antes de arrancar. As indicações sobre a plataforma seguem a documentação da Salesforce.
Como gere o Salesforce Commerce Cloud as imagens de produto?
O Commerce Cloud organiza as imagens por tipos de vista no catálogo, e cada produto guarda apenas o caminho relativo do ficheiro. Segundo a documentação da Salesforce, um catálogo novo traz quatro tipos: Large, para a página de produto; Medium, para os resultados de pesquisa; Small, para a pré-visualização ao passar o rato; e Swatch, uma miniatura usada para distinguir variações, por exemplo de cor.
A localização das imagens define-se nas definições de imagem do catálogo, como interna (um caminho base) ou externa (um URL base HTTP ou HTTPS). O catálogo guarda a localização e o produto guarda o caminho relativo. A Salesforce indica que o caminho da imagem pode ter até 1.800 carateres e o URL completo até 2.056.
As imagens atribuem-se ao produto base. As variações recebem a imagem certa por correspondência de atributos, como a cor. Na prática, o ficheiro vindo do DAM tem de trazer a informação que permite esta correspondência, ou a loja mostra a imagem errada.
Que dados do OpenText DAM devem chegar à loja?
Só devem seguir para a loja os ativos aprovados, com a informação mínima para o Commerce Cloud os associar ao produto. A tabela seguinte é a base que usamos para definir o mapeamento; cada empresa ajusta-a ao seu modelo de dados.
| Dado no DAM | Destino no Commerce Cloud | Regra |
|---|---|---|
| Ficheiro aprovado | Imagem do produto base | Só estado aprovado |
| Código do produto (SKU) | Associação ao produto | Chave única |
| Tipo de utilização | Tipo de vista | Large, Medium, Small, Swatch |
| Cor ou variante | Atributo da variação | Igual ao catálogo |
| Texto alternativo | Texto alternativo localizável | Um por idioma |
A Salesforce refere que o texto alternativo e os títulos das imagens são localizáveis. Compensa por isso guardá-los no DAM por idioma e enviá-los em separado do ficheiro, o que evita retrabalho quando a loja vende em vários mercados.
Como se faz a ligação técnica entre o OTMM e o Commerce Cloud?
A ligação faz-se com a API REST do OTMM de um lado e as APIs do Commerce Cloud do outro, quase sempre com uma camada intermédia que traduz os dados e regista erros. Do lado da Salesforce, a escolha da API merece atenção: segundo a documentação, a OCAPI está marcada como descontinuada desde abril de 2026, em modo de manutenção, e as novidades só entram na SCAPI.
Isto não obriga a abandonar tudo o que existe. A própria Salesforce admite que certas tarefas complexas ainda se tratam melhor pela OCAPI. Num projeto novo, partimos da SCAPI, incluindo as APIs de administração do catálogo, e confirmamos caso a caso se o recurso necessário já está coberto.
O processo que seguimos tem seis passos.
- Definir o OTMM como fonte única dos ficheiros aprovados e o catálogo como fonte dos produtos.
- Extrair, pela API REST do OTMM, o ficheiro aprovado e os metadados necessários.
- Publicar o ficheiro num local acessível à loja, interno ou externo, conforme as definições do catálogo.
- Atualizar o catálogo com o caminho relativo, o tipo de vista e o texto alternativo.
- Validar tudo num ambiente de teste com produtos simples, variações e produtos sem imagem.
- Registar cada erro com o identificador do ativo e do produto, para repetir só o que falhou.
Porque importa o Dynamic Imaging Service para o DAM?
O Dynamic Imaging Service (DIS) gera as imagens a pedido a partir de uma única fonte de alta resolução, aplicando formato, corte, escala e qualidade. Segundo a Salesforce, isto dispensa criar vários tamanhos à partida. Há limites: imagens com mais de 10 MB ou 3.000 x 3.000 píxeis são servidas sem transformação, e as transformações expiram ao fim de 29 segundos.
Para o DAM, a conclusão é simples: exportar uma versão de origem com boa qualidade, mas dentro destes limites, em vez de enviar o ficheiro original de estúdio. Assim a loja gera os tamanhos de que precisa e o DAM deixa de ter de produzir uma derivação por cada tipo de vista.
Que riscos tem esta integração e como se evitam?
- Nomes de ficheiro com carateres especiais. A Salesforce avisa que, por exemplo, trémas nos nomes causam falhas na importação e exportação do site. Normalizamos os nomes antes do envio.
- Imagens sem tipo de vista. Sem pelo menos um tipo de vista, a imagem não pode ser atribuída, por isso o mapeamento tem de o definir sempre.
- Variações mal associadas. Se o atributo de cor no DAM não coincidir com o do catálogo, a imagem não aparece na variação certa.
- Ficheiros não aprovados. Filtrar pelo estado no OTMM evita publicar versões provisórias.
- Matrizes grandes. A Salesforce indica que o JSON de imagens de uma matriz não pode exceder 10 MB, pelo que convém manter a estrutura consistente.
Lista de verificação antes de arrancar o projeto
- Existe um identificador de produto (SKU) em todos os ativos do DAM?
- Os quatro tipos de vista do catálogo estão definidos e mapeados?
- A localização das imagens, interna ou externa, está decidida?
- Os nomes de ficheiro seguem uma regra sem carateres especiais?
- Os textos alternativos existem por idioma?
- O estado de aprovação do OTMM controla o que sai?
- Há um ambiente de teste com produtos simples e variações?
- Alguém é responsável por tratar os erros de sincronização?
Como trabalhamos na Avafa
Começamos por auditar o catálogo e o DAM: que ativos existem, como se identificam e que produtos ficam sem imagem. Depois definimos o mapeamento, testamos em ambiente separado e só então ligamos a produção. O âmbito completo está na página de integração de DAM com ecommerce, e a vertente de visibilidade nos motores de pesquisa na nossa agência de SEO para Salesforce Commerce Cloud.
Guias relacionados do mesmo cluster
- Integrar o SAP S/4HANA com o Salesforce Commerce Cloud
- Integrar o SAP Business One com o Salesforce Commerce Cloud
- Integrar o Microsoft Dynamics 365 com o Salesforce Commerce Cloud
- Integrar o Brandfolder com o Salesforce Commerce Cloud
- Integrar o Odoo com o Salesforce Commerce
Perguntas frequentes
O OpenText DAM tem ligação nativa ao Commerce Cloud?
Na documentação consultada não encontrámos um conector nativo. A ligação faz-se normalmente por desenvolvimento ou por uma camada de integração que usa a API REST do OTMM e as APIs da Salesforce. Convém confirmá-lo com o fornecedor antes de orçamentar.
As imagens ficam guardadas no DAM ou na loja?
Depende da localização definida no catálogo. Se for externa, a loja usa o URL base e o produto guarda o caminho relativo; se for interna, os ficheiros ficam no Commerce Cloud.
Posso usar a OCAPI num projeto novo?
Pode, mas a Salesforce marca-a como descontinuada desde abril de 2026 e coloca as novidades na SCAPI. Não há data de fim anunciada, mas é prudente partir da SCAPI.
Preciso de criar vários tamanhos de cada imagem no DAM?
Não necessariamente. Com o Dynamic Imaging Service, a loja gera os tamanhos a partir de uma fonte única, dentro dos limites de 10 MB e de 3.000 x 3.000 píxeis.
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 uma auditoria do catálogo e do DAM, antes de indicar prazos.