A estrutura de integração fornece os mecanismos e os componentes para:
Isso significa que:
A estrutura de comércio eletrônico pode ser usada com:
A variável Estrutura de integração de comércio eletrônico O é um complemento do AEM.
Seu representante de vendas pode fornecer todos os detalhes, de acordo com o mecanismo apropriado.
A estrutura fornece os requisitos básicos para o seu próprio projeto.
Uma certa quantidade de trabalho de desenvolvimento é sempre necessária para adaptar a estrutura às suas especificações.
A instalação padrão do AEM inclui a implementação de comércio eletrônico genérico AEM (JCR).
Ele é destinado a fins de demonstração ou como base para uma implementação personalizada de acordo com seus requisitos.
Para otimizar a operação, tanto o AEM quanto o mecanismo de comércio eletrônico se concentram em sua própria área de especialização. As informações são transferidas entre os dois em tempo real; por exemplo:
O AEM pode:
Solicitação:
Fornecer:
O mecanismo de comércio eletrônico pode:
Fornecer:
Processo:
Os detalhes exatos dependem do mecanismo de comércio eletrônico e da implementação do projeto.
Vários componentes AEM prontos para uso são fornecidos para usar a camada de integração. Atualmente, eles incluem:
Várias opções de pesquisa também estão disponíveis.
A estrutura de integração fornece a API, uma variedade de componentes para ilustrar a funcionalidade e várias extensões para fornecer exemplos de métodos de conexão:
A estrutura oferece acesso a funcionalidades como:
O eCommerce AEM é implementado com um mecanismo de eCommerce:
A instalação padrão do AEM inclui a implementação de comércio eletrônico genérico AEM (JCR).
Ele é destinado a fins de demonstração ou como base para uma implementação personalizada de acordo com seus requisitos.
O eCommerce AEM implementado no AEM usando desenvolvimento genérico com base em JCR é:
Um exemplo de comércio eletrônico independente e nativo de AEM para ilustrar o uso da API. Isso pode ser usado para controlar dados do produto, carrinhos de compras e check-out com a exibição de dados existente e campanhas de marketing. Nesse caso, o banco de dados do produto é armazenado no repositório nativo do AEM (Adobe implementation of JCR).
A instalação padrão do AEM contém as noções básicas do implementação de comércio eletrônico genérico.
Ao importar dados de um mecanismo de comércio para o site de comércio eletrônico AEM, um provedor de comércio é usado para fornecer dados aos importadores. Um único provedor de comércio pode oferecer suporte a vários importadores.
Um provedor de comércio é um código AEM personalizado para:
Dois exemplos de provedores de comércio estão disponíveis atualmente para o AEM:
Embora geralmente um projeto precise desenvolver seu próprio provedor de comércio personalizado específico para seu PIM e esquema de dados do produto.
Geometrixx Os importadores usam arquivos CSV; há uma descrição do schema aceito (com propriedades personalizadas permitidas) nos comentários acima de sua implementação.
A variável ProductServicesManager mantém (até OSGiuma lista das implementações do ProductImporter e CatalogBlueprintImporter interfaces. Elas estão listadas no Importador/Provedor de comércio campo suspenso do assistente de importador (usando o commerceProvider
como um nome).
Quando um importador/provedor de comércio específico estiver disponível na lista suspensa, todos os dados complementares necessários deverão ser definidos (dependendo do tipo de importador) no:
/apps/commerce/gui/content/catalogs/importblueprintswizard/importers
/apps/commerce/gui/content/products/importproductswizard/importers
A pasta na pasta apropriada importers
a pasta deve corresponder ao nome do importador; por exemplo:
.../importproductswizard/importers/geometrixx/.content.xml
O formato do arquivo de importação de origem é definido pelo importador. Ou o importador pode estabelecer uma conexão (por exemplo, WebDAV ou http) com o mecanismo de comércio.
O sistema integrado atende às seguintes funções para manter os dados:
Usuário do Gerenciamento de informações do produto (PIM) que mantém:
Autor/Gerente de marketing que mantém:
Surfista/consumidor que:
Embora a localização real possa depender da sua implementação; por exemplo, genérico ou com um mecanismo de comércio eletrônico:
Se as duas categorias a seguir puderem ser diferenciadas, isso permitirá definir URLs claros com uma estrutura significativa (árvores de cq:Page
nós) e, portanto, muito próximo da gestão clássica de conteúdo do AEM):
*Categorias * estruturais
A árvore de categorias definindo o que é um produto; por exemplo:
/products/mens/shoes/sneakers
Marketing categorias
Todas as outras categorias que um o produto pode pertencer a; por exemplo:
/special-offers/christmas/shoes
)
Para representar e gerenciar seu produto, você desejará manter uma variedade de informações sobre ele.
Os dados do produto podem ser:
mantida diretamente no AEM (genérico).
mantido no mecanismo de comércio eletrônico e disponibilizado no AEM.
Dependendo do tipo de dados, é sincronizado conforme necessário, ou acessados diretamente; por exemplo, dados altamente voláteis e críticos, como preços de produtos, são recuperados do mecanismo de comércio eletrônico em cada solicitação de página para garantir que estejam sempre atualizados.
Em ambos os casos, quando os dados do produto forem inseridos/importados no AEM, eles poderão ser vistos no Produtos console. Aqui, as exibições de cartão e lista de um produto mostram informações como:
Para produtos apropriados, informações sobre variantes também podem ser mantidas. Por exemplo, para artigos de vestuário, as diferentes cores disponíveis são mantidas como variantes:
Os atributos individuais mantidos sobre cada produto podem depender do mecanismo de eCommerce sendo usado e da implementação de AEM. Eles estão disponíveis (conforme apropriado) ao visualizar páginas de produtos e/ou editar informações sobre produtos e podem incluir:
Imagem
Uma imagem do produto.
Título
O nome do produto.
Descrição
Uma descrição textual do produto.
Tags
Tags usadas para agrupar produtos relacionados.
Categoria do ativo padrão
Uma categoria padrão para ativos.
Dados de ERP
Informações de ERP (Enterprise Resource Planning, planejamento de recursos corporativos).
SKU
Informações da unidade de manutenção de estoque (SKU).
Cor
Tamanho
Preço
O preço unitário do produto.
Resumo
Um resumo dos recursos do produto.
Recursos
Detalhes mais completos dos recursos do produto.
Uma seleção de ativos pode ser mantida para produtos individuais. Geralmente, eles incluem imagens e vídeos.
Um catálogo agrupa os dados do produto para facilitar o gerenciamento e a representação ao comprador. Muitas vezes, um catálogo é estruturado de acordo com atributos como idioma, área geográfica, marca, estação, hobby, esporte, entre muitos outros.
O AEM oferece suporte ao conteúdo do produto em vários idiomas. Ao solicitar dados, a estrutura de integração recupera o idioma da árvore atual (por exemplo, en_US
para páginas em /content/geometrixx-outdoors/en_US
).
Para um armazenamento em vários idiomas, você pode importar o catálogo para cada árvore de idioma individualmente (ou copiá-lo com MSM).
Assim como com os idiomas, grandes empresas multinacionais devem atender a várias marcas.
As tags também podem ser usadas para agrupar produtos em um catálogo. Eles podem ser usados para catálogos mais dinâmicos, como ofertas sazonais.
Dependendo da sua implementação, você pode importar os dados do produto necessários para o catálogo base no AEM de:
São inevitáveis novas alterações nos dados do produto:
Após a importação inicial, as alterações nos dados do produto são inevitáveis.
Ao usar um mecanismo de comércio eletrônico, os dados do produto são mantidos lá e devem estar disponíveis no AEM. Esses dados do produto devem ser sincronizados quando as atualizações forem feitas.
Isso pode depender do tipo de dados:
A a sincronização periódica é usada junto com um feed de dados de alterações.
Além disso, é possível selecionar atualizações específicas para uma atualização expressa.
Dados altamente voláteis, como informações de preço, são recuperados do mecanismo de comércio para cada solicitação de página, para garantir que estejam sempre atualizados.
A importação de um grande catálogo com um alto número de produtos (mais de 100.000) de um mecanismo de comércio eletrônico (PIM) pode afetar o sistema devido ao grande número de nós. Ela também pode retardar a instância de criação se os produtos tiverem ativos associados (por exemplo, imagens de produtos). Isso ocorre porque o pós-processamento desses ativos consome muita CPU e memória.
Há várias estratégias que você pode escolher para contornar esses problemas:
Se um nó JCR tiver muitos nós secundários diretos (por exemplo, 1000 ou mais), os buckets (pastas fantasmas) serão necessários para garantir que o desempenho não seja afetado. Eles são gerados de acordo com um algoritmo ao importar.
Esses buckets tomam a forma de pastas fantasmas que são introduzidas na estrutura do catálogo, mas podem ser configurados para que não fiquem aparentes em URLs públicos.
Esse cenário envolve a configuração de duas instâncias de autor:
Instância do autor principal
Importa dados de produto do PIM, no qual o pós-processamento dos caminhos de ativos está desativado.
Instância de autor DAM dedicada
Importa e pós-processa ativos de produtos do PIM e os replica de volta na instância do autor principal para uso.
Para os casos em que os produtos não contêm ativos (imagens) a serem importados, é possível importar os dados do produto sem ser afetado pelo pós-processamento de ativos.
O teste de desempenho deve ser considerado em implementações de comércio eletrônico AEM:
Ambiente do autor:
A atividade em segundo plano (por exemplo, importação) pode ocorrer ao mesmo tempo que a atividade normal do usuário (por exemplo, edição de página) e mesmo que o desempenho de front-end receba (em geral) uma prioridade mais alta, o desempenho inadequado visto por autores online pode levar à frustração capaz de bloquear uma decisão de publicação.
Ambiente de publicação:
A replicação é um processo essencial para garantir que o conteúdo seja publicado de forma rápida e confiável. Isso pode ser afetado pela forma como o autor agrupa o conteúdo a ser publicado.
Front-end:
A combinação de invalidações de front-end e cache pode levar a surpresas no desempenho. Testes ajudam a evitá-los.
Observe que este teste de desempenho requer conhecimento e análise do público-alvo:
Volumes de conteúdo
Atividade do usuário:
Processos de segundo plano
Requisitos de manutenção (backup, otimização de PM do Tar, coleta de lixo do armazenamento de dados etc.)
Para todas as implementações, os seguintes pontos podem ser considerados:
Como os produtos, as unidades de manutenção de estoque e as categorias podem ser numerosas, tente usar o menor número possível de nós para modelar o conteúdo.
Quanto mais nós você tiver, mais flexível será seu conteúdo (por exemplo, parsys). No entanto, tudo é uma escolha e você precisa de flexibilidade individual (por padrão) ao manipular (por exemplo) produtos de 30 mil?
Evite a duplicação o máximo possível (consulte a localização) ou, quando fizer isso, pense em quantos nós a duplicação leva.
Tente marcar seu conteúdo o máximo possível para preparar a otimização da consulta.
Por exemplo:
/content/products/france/fr/shoe/reebok/pump/46 SKU
deve ter uma tag por nível de conteúdo (ou seja, país, idioma, categoria, marca, produto). Pesquisando
//element(*,my:Sku)[@country='france' and @language='fr'
e
@category='shoe' and @brand='reebok' and @product='pump']
será drasticamente mais rápido do que pesquisar por
/jcr:root/content/france/fr/shoe/reebok/pump/element(*,my:Sku)
Em seu conjunto técnico, planeje o modelo e os serviços de acesso ao conteúdo fatorados. Esta é uma prática recomendada geral, mas é ainda mais importante aqui, pois você pode, em fases de otimização, adicionar caches de aplicativo para dados que são lidos com frequência (e que você não deseja preencher o cache do pacote com).
Por exemplo, o gerenciamento de atributos frequentemente é um bom candidato para armazenamento em cache, pois trata de dados atualizados por meio da importação de produtos.
Considere o uso de páginas de proxy.
As seções de Catálogo fornecem, por exemplo:
As páginas de produtos fornecem informações abrangentes sobre produtos individuais. Atualizações dinâmicas do também são refletidas; por exemplo, alterações de preço registradas no mecanismo de comércio eletrônico.
As páginas de produto são páginas AEM que usam Produto componente; por exemplo, dentro do Produto do Commerce modelo:
O componente do produto fornece:
Essas informações permitem que o comprador selecione o seguinte ao adicionar um item à sua cesta:
Essas são páginas AEM que fornecem informações principalmente estáticas; por exemplo, uma introdução e uma visão geral com links para as páginas de produto subjacentes.
A variável Produto pode ser adicionado a qualquer página com uma página principal que forneça os metadados necessários (ou seja, os caminhos para cartPage
e cartObject
). No site de demonstração, Geometrixx Outdoors, isso é fornecido pela UserInfo.jsp
.
A variável Produto componente também pode ser personalizado de acordo com suas necessidades individuais.
As páginas proxy são usadas para simplificar a estrutura do repositório e otimizar o armazenamento para catálogos grandes.
A criação de um catálogo usa dez nós por produto, pois fornece componentes individuais para cada produto que você pode atualizar e personalizar no AEM. Esse grande número de nós pode se tornar um problema se o catálogo contiver centenas ou até mesmo milhares de produtos. Para evitar problemas, você pode criar seu catálogo usando páginas de proxy.
As páginas proxy usam uma estrutura de dois nós ( cq:Page
e jcr:content
) que não contém nenhum conteúdo real do produto. O conteúdo é gerado, no momento da solicitação, referenciando os dados do produto e a página do modelo.
No entanto, há uma compensação. Você não será capaz de personalizar as informações do seu produto dentro do AEM, um modelo padrão (definido para o seu site) será usado.
Você não terá problemas se importar um catálogo grande sem páginas de proxy.
É possível converter de uma metodologia para outra a qualquer momento. Também é possível converter uma subseção do catálogo.
Os vouchers são um método experimentado e testado de oferecer descontos para atrair os compradores a fazer uma compra e/ou recompensar a fidelidade do cliente.
Fornecimento de vouchers:
Mecanismos de comércio externo também podem fornecer vouchers.
No AEM:
Um voucher é um componente baseado em páginas que é criado / editado com o console Sites.
A variável Voucher O componente fornece:
Os vouchers não têm suas próprias datas/horas de ativação e desativação, mas usam os das campanhas principais.
AEM usa o termo Voucher, é sinônimo do termo Cupom.
As promoções, juntamente com vouchers, permitem que você realize cenários como:
As promoções não são mantidas por gerentes de informações do produto, mas por gerentes de marketing:
Uma promoção é um componente baseado em páginas, criado/editado com o console Sites. "
Fornecimento de promoções:
É possível conectar promoções a uma campanha para definir suas datas/horas de ativação/desativação.
É possível conectar promoções a uma experiência para definir seus segmentos.
As promoções não conectadas a uma experiência não serão acionadas por conta própria, mas ainda poderão ser acionadas por um Voucher.
O componente de Promoção contém:
No AEM, as promoções também estão integradas no Campaign Management:
Uma promoção pode ser realizada em uma experiência ou diretamente na campanha:
Se uma promoção for realizada em uma experiência, ela poderá ser aplicada automaticamente a um segmento de público-alvo.
Por exemplo, no site de amostra geometrixx-outdoors, a promoção:
/content/campaigns/geometrixx-outdoors/big-spender/ordervalueover100/free-shipping
está em uma experiência e, portanto, é acionado automaticamente sempre que o segmento ( ordervalueover100
) resolve.
Se uma promoção não aparecer em uma experiência (somente na campanha), ela não poderá ser aplicada automaticamente a um público-alvo. No entanto, ainda poderá ser acionado se o comprador inserir um voucher no carrinho e esse voucher fizer referência à promoção.
Por exemplo, a promoção:
/content/campaigns/geometrixx-outdoors/article/10-bucks-off
O está fora de uma experiência e, portanto, nunca é acionado automaticamente (ou seja: com base na segmentação). No entanto, é referenciado pelos vouchers que podem ser encontrados em várias das experiências dentro da campanha de artigos. Inserir esses códigos de voucher no carrinho resulta no acionamento da promoção.
promoções hybris e vouchers hybris abranja tudo o que influencia o carrinho de compras e está relacionado a preços. Conteúdo de marketing específico para promoções (como banners etc.) não faz parte da promoção hybris.
Quando um comprador se registra, os detalhes da conta devem ser sincronizados entre o AEM e o mecanismo de eCommerce. Os dados confidenciais são mantidos independentemente, mas os perfis são compartilhados:
O mecanismo exato pode depender do cenário:
As contas de usuário existem em ambos os sistemas:
A conta de usuário existe apenas no AEM:
A conta de usuário existe apenas no mecanismo de comércio eletrônico:
Ao usar um mecanismo de comércio eletrônico, o AEM armazena somente a ID da conta e a senha (opcionalmente, um grupo de usuários). Todas as outras informações são armazenadas no mecanismo de comércio eletrônico.
Ao usar um mecanismo de comércio eletrônico, você deve garantir que as contas criadas para usuários que fazem logon em uma instância do AEM sejam replicadas (por exemplo, por meio de workflows) para qualquer outra instância do AEM que se comunique com esse mecanismo.
Caso contrário, essas outras instâncias do AEM também tentarão criar contas para os mesmos usuários no mecanismo. Essas ações falham com uma DuplicateUidException
vem do motor.
Muitas vezes, a inscrição é necessária para que o comprador tenha acesso ao carrinho de compras. Isso requer registro (Criar conta) para que uma conta específica do cliente possa ser criada.
Um carrinho de compras anônimo e um check-out também são compatíveis.
Após a inscrição, o comprador pode fazer logon com sua conta para que suas ações possam ser rastreadas e seus pedidos atendidos.
O Logon único (SSO) é fornecido, para que os autores sejam conhecidos no AEM e no sistema de comércio eletrônico sem precisar fazer logon duas vezes.
Os dados de transação do mecanismo de comércio eletrônico são combinados com informações pessoais sobre o comprador. O AEM usa alguns desses dados como dados de perfil. A ação de um formulário no AEM grava as informações de volta no mecanismo de comércio eletrônico.
Há uma página que permite gerenciar facilmente as informações da sua conta. Você pode acessá-lo clicando em Minha conta na parte superior de uma página do Geometrixx ou navegando até /content/geometrixx-outdoors/en/user/account.html
.
Seu site precisa armazenar uma seleção de endereços, incluindo entrega, cobrança e endereços alternativos. Isso pode ser implementado usando formulários com base no formato de endereço padrão ou você pode usar o componente Catálogo de endereços fornecido pelo AEM.
Esse componente do Catálogo de Endereços permite:
Você pode escolher qual endereço deseja como padrão.
O componente do catálogo de endereços pode ser acessado de Minha conta clicando em Catálogo de Endereços ou navegando até /content/geometrixx-outdoors/en/user/account/address-book.html
.
Você pode clicar em Adicionar novo endereço… para adicionar um endereço no seu catálogo de endereços. Ele abre um formulário que pode ser preenchido e, em seguida, clique em Adicionar endereço.
Você pode inserir vários endereços no seu Catálogo de Endereços.
O Catálogo de endereços é usado ao "finalizar a compra" do carrinho:
Os endereços são mantidos abaixo user_home/profile/addresses
.
Por exemplo, para Alison Parker, seria em /home/users/geometrixx/aparker@geometrixx.info/profile/addresses
Você pode escolher qual endereço deseja como padrão, essas informações são mantidas no perfil do comprador em vez do endereço. A propriedade do perfil address.default
é definido com o caminho do endereço selecionado para o valor.
O mecanismo de comércio eletrônico usa o contexto (essencialmente as informações do comprador) para determinar o preço que está retendo e, em seguida, fornece as informações corretas ao AEM.
Ao fazer compras, o comprador navega pelas páginas do produto e seleciona itens para colocá-los em seu carrinho de compras. Quando eles prosseguirem com o check-out, um pedido poderá ser feito.
Um cliente anônimo pode:
Dependendo da configuração das informações de endereço da instância ou do registro do cliente, pode ser necessário antes da finalização da compra.
Um cliente registrado pode:
O carrinho de compras fornece:
uma visão geral dos itens selecionados
links para as páginas de produto dos itens selecionados
a capacidade de:
O carrinho de compras é salvo de acordo com o mecanismo que está sendo usado:
Em ambos os casos, os itens ficam no carrinho (e podem ser restaurados) durante o logon/logout (mas somente na mesma máquina/navegador). Por exemplo:
procurar como anonymous
e adicionar produtos ao carrinho
fazer logon como Allison Parker
- O carrinho de Allison está vazio
adicionar produtos ao carrinho de Allison
sair - o carrinho mostra os produtos para anonymous
entrar novamente como Allison Parker
- Os produtos da Allison são restaurados.
Um carrinho anônimo só pode ser restaurado na mesma máquina/navegador.
Não é recomendável testar a restauração do conteúdo do carrinho com o admin
conta, pois isso pode entrar em conflito com a admin
conta do mecanismo de comércio eletrônico (por exemplo, hybris).
o hybris pode ser configurado para remover carrinhos pendentes após um período definido.
Antes do check-out, as alterações de preço são refletidas (em ambos os sistemas) à medida que ocorrem.
Dependendo de suas informações de implementação sobre um pedido que é mantido no mecanismo de eCommerce ou no AEM, essas informações são renderizadas pelo AEM.
Várias informações são armazenadas, que podem incluir:
ID do pedido
O número de referência do pedido.
Instalado
A data em que o pedido foi feito.
Status
O status do pedido; por exemplo, Enviado.
Moeda
A moeda do pedido.
Itens de conteúdo
Uma lista de itens ordenados.
Subtotal
O custo total dos itens solicitados.
Imposto
O valor de quaisquer impostos devidos sobre o pedido.
Envio
Custos de envio.
Total
O valor total do pedido; itens solicitados, impostos e remessa.
Endereço de cobrança
O endereço para o qual a fatura deve ser enviada.
Token de pagamento
O método de pagamento.
Status do pagamento
O status do pagamento.
Endereço de envio
O endereço para o qual as mercadorias devem ser enviadas.
Método de envio
O método de envio; por exemplo, terra, mar ou ar.
Número de rastreamento
Qualquer número de rastreamento usado pela empresa de remessa.
Link de rastreamento
O link usado para rastrear o pedido enquanto é enviado.
Os campos usados no assistente de criação de pedidos dependem de um andaime otimizado para toque definido para o local. No exemplo genérico, ele pode ser encontrado em:
/etc/scaffolding/geometrixx-outdoors/order/jcr:content/cq:dialog
Quando o pedido é mantido no AEM, o console Pedido mostra o seguinte para cada pedido:
Depois de fazer um pedido, os compradores geralmente retornam para:
Depois de receber a entrega do pedido, os compradores também podem querer visualizar o histórico de pedidos feitos durante um período de tempo.
O atendimento e o rastreamento de pedidos são gerenciados pelo mecanismo de comércio eletrônico. As informações podem ser exibidas pelo AEM usando o componente Histórico de pedidos, que mostra todos os detalhes relevantes, incluindo os vouchers e as promoções aplicadas. Por exemplo:
A finalização é implementada com formulários AEM padrão. Isso permite que o gerente de marketing personalize a experiência com conteúdo de marketing.
Em seguida, o eCommerce gerencia o processo de finalização com a entrada dos formulários AEM.
Os detalhes do pagamento, incluindo informações de cartão de crédito, geralmente são gerenciados pelo mecanismo de comércio eletrônico. O AEM encaminha essas informações transacionais para o mecanismo (de onde elas são encaminhadas para um serviço de processamento de pagamentos).
Conformidade com o PCI (Payment Card Industry, setor de cartões de pagamento) pode ser alcançada.
O pedido é confirmado na tela e pode ser rastreado com o rastreamento de pedidos.
Como o AEM usa páginas padrão para produtos, você pode usar o componente de pesquisa padrão para criar uma página de pesquisa.
Se você precisar de uma implementação mais completa, é possível:
CommerceService
e, em seguida, use o componente de pesquisa de comércio eletrônico na página de pesquisa.Ao usar um mecanismo de comércio eletrônico, a API de pesquisa de comércio eletrônico pode ser totalmente implementada na solução de mecanismo de comércio eletrônico, para que você possa usar o componente de pesquisa de comércio eletrônico fornecido pronto para uso. A pesquisa facetada permite pesquisar JCR e/ou o mecanismo: