Integrar o Adobe Experience Manager (AEM) com o Salesforce Commerce Cloud (SFCC) significa usar o AEM para gerir conteúdo e ativos digitais e o SFCC para catálogo, preços, cesto e checkout. Não existe um botão único que ligue as duas plataformas: a Adobe e a Salesforce documentam peças e caminhos diferentes, e a escolha da arquitetura define o custo do projeto.
Para uma marca ou retalhista com catálogo grande, a decisão importa porque o conteúdo de produto vive em dois sítios. Se o AEM e o SFCC não se alinharem pelo SKU, aparecem imagens desatualizadas, páginas de campanha sem preço e equipas a corrigir à mão. É um tema típico de integração de DAM com e-commerce, onde o ativo certo tem de chegar ao produto certo.
Este guia resume o que a documentação oficial da Adobe e da Salesforce diz a 31-10-2026, compara três arquiteturas possíveis, lista os riscos mais frequentes e termina com uma checklist de trabalho em oito passos.
O que dizem as fontes oficiais sobre AEM e SFCC?
A documentação do AEM as a Cloud Service indica que o AEM pode integrar com Adobe Commerce, Salesforce Commerce, SAP Commerce Cloud ou outra solução. A Adobe recomenda o Edge Delivery Services como base para novas lojas e descreve o storefront baseado nos CIF Core Components como estando em modo de manutenção, a não usar em projetos novos.
Para quem já tem uma loja própria, por exemplo em React, a Adobe descreve o AEM como fornecedor de conteúdo e de ativos, com Content Fragments e edição contextual através do Universal Editor. O add-on CIF serve para trazer dados de produto para o AEM, de modo a que os autores os pesquisem e os usem nas páginas.
Do lado da Salesforce, o Composable Storefront é uma alternativa ao SFRA e assenta no PWA Kit, uma framework React de código aberto, e no Managed Runtime. A loja comunica com a instância através da Salesforce Commerce API (SCAPI), que se divide em APIs de comprador (Shopper) e de administração (Admin). Num storefront SFRA, a comunicação com a instância é direta.
A documentação antiga do AEM 6.x refere ainda um conector de código aberto para o Salesforce Commerce Cloud, compatível com o AEM 6.4. Quem herdou uma integração desse tipo deve tratá-la como legado e planear a migração, em vez de a replicar.
Que arquitetura escolher?
A escolha depende de quem controla a loja e de onde se quer editar conteúdo. A tabela resume as três opções mais comuns.
| Arquitetura | O AEM faz | O SFCC faz | Esforço |
|---|---|---|---|
| Loja SFRA com ativos do AEM | Ativos e campanhas | Loja e checkout | Médio |
| Composable Storefront com AEM | Conteúdo e ativos | Dados via SCAPI | Alto |
| Edge Delivery com comércio externo | Páginas e conteúdo | Dados de comércio | Alto |
Na primeira opção, o AEM alimenta imagens e páginas de campanha e o SFCC continua a renderizar a loja. É a mais simples, mas a edição de conteúdo fica dividida entre as duas ferramentas. Na segunda, a loja é headless: o PWA Kit apresenta a interface, a SCAPI traz os dados comerciais e o AEM fornece conteúdo. Exige equipa de front-end e um contrato claro entre as APIs.
A terceira opção segue a direção que a Adobe recomenda para novos projetos. A própria documentação indica que o Adobe Commerce Optimizer permite integrar uma solução de comércio existente e que as integrações com o Salesforce Commerce estão disponíveis através de um representante da Adobe. Convém confirmar com a Adobe o estado dessa integração antes de a incluir no orçamento.
Onde falham as integrações entre AEM e SFCC?
Quase todas as falhas vêm de identificadores e de responsabilidades mal definidas, não de tecnologia. Estes são os pontos a verificar primeiro:
- Chave de ligação: o SKU, ou outro identificador, tem de ser igual nos dois sistemas. Se o AEM usa o código do fabricante e o SFCC o código interno, nenhum automatismo funciona.
- Duas fontes de verdade: se o preço ou a descrição podem ser editados nos dois lados, um deles vai sobrepor o outro.
- Variantes: a cor ou o tamanho tratados como produto no SFCC e como ativo no AEM obrigam a uma regra de correspondência explícita.
- Mercados e idiomas: a estrutura de sites do SFCC e a árvore de conteúdo do AEM têm de refletir os mesmos mercados.
- Desempenho: pedidos a APIs em tempo real, em cada visita, tornam a loja lenta; é preciso definir o que fica em cache.
- Legado: conectores e componentes descontinuados não devem ser a base de um projeto novo.
Quando o catálogo vem de um ERP ou de um PIM, há uma terceira camada. Nesse caso convém decidir primeiro quem publica o dado de produto e só depois ligar o AEM. Pode ver um exemplo com PIM no guia sobre Bluestone PIM com Salesforce Commerce Cloud.
Checklist Avafa para integrar o AEM com o SFCC
Esta é a sequência que seguimos antes de qualquer desenvolvimento. Cada passo termina com um resultado escrito.
- Definir o objetivo: ativos de produto, páginas de campanha, loja completa ou as três coisas.
- Inventariar os sistemas que já existem: ERP, PIM, DAM e a versão do AEM em uso.
- Escolher o identificador comum e confirmar que existe em todos os produtos.
- Decidir quem é a fonte de verdade para cada campo: nome, descrição, preço, imagem e stock.
- Escolher a arquitetura da tabela anterior e validar com a Adobe e a Salesforce o que está suportado.
- Desenhar a estrutura de mercados, idiomas e sites nos dois lados.
- Testar com um conjunto pequeno de produtos, incluindo variantes e produtos sem imagem.
- Definir alertas e um responsável para as falhas de sincronização depois do arranque.
O ponto mais negligenciado é o sétimo. Um piloto com cinquenta produtos revela problemas de correspondência que um teste com cinco produtos escondia.
Convém também separar o que é conteúdo editorial do que é dado de produto. O primeiro pertence ao AEM e muda com a campanha; o segundo pertence ao catálogo e muda com o fornecedor. Quando as equipas misturam os dois, cada alteração de preço ou de descrição passa por duas aprovações e o site acaba por mostrar versões diferentes da mesma ficha.
Como trabalhamos na Avafa
Na Avafa tratamos a integração como um problema de dados antes de ser um problema de ferramentas. Começamos por mapear de onde vem cada campo, quem o edita e onde é publicado. Só depois discutimos conectores, APIs e prazos.
Se o seu projeto envolve ativos, PIM e catálogo, conheça o nosso serviço de integração de DAM com e-commerce e a agência de SEO para Salesforce Commerce Cloud, que cobre a parte de visibilidade orgânica da loja.
Guias relacionados
- Integrar AEM Assets com Adobe Commerce
- Integrar o AEM com BigCommerce
- Integrar o AEM com SAP Commerce Cloud
- Integrar SAP S/4HANA com Salesforce Commerce Cloud
- Integrar Microsoft Dynamics 365 com Salesforce Commerce Cloud
Perguntas frequentes
O AEM tem um conector oficial para o Salesforce Commerce Cloud?
A documentação do AEM 6.x referia um conector de código aberto compatível com o AEM 6.4. Na documentação do AEM as a Cloud Service, a Adobe indica que a integração com o Salesforce Commerce passa pelo Commerce Optimizer, através de um representante da Adobe. Confirme sempre a versão que vai usar.
Posso usar o AEM só para ativos e deixar o SFCC com a loja?
Sim. É a arquitetura mais simples: o AEM guarda e entrega imagens e conteúdo de campanha, e o SFCC mantém catálogo, cesto e checkout. O custo está em manter o SKU alinhado e em decidir quem edita o quê.
O que é o Composable Storefront do Salesforce?
É a alternativa ao SFRA, composta pelo PWA Kit, uma framework React de código aberto, e pelo Managed Runtime, que aloja a aplicação. A loja usa a SCAPI para obter produtos, cesto e restantes dados.
Devo começar por um projeto novo em CIF?
Não. A Adobe descreve o storefront com CIF Core Components como estando em modo de manutenção e recomenda o Edge Delivery Services para novos projetos.
Quanto tempo demora uma integração destas?
Depende da arquitetura, do número de mercados e da qualidade dos dados de produto. Sem diagnóstico prévio, qualquer prazo é um palpite, e por isso começamos pela checklist acima.