Concepts concepts

Le framework d’intégration fournit les mécanismes et les composants pour les éléments suivants :

Cela signifie que :

Pour optimiser le fonctionnement, AEM et le moteur eCommerce se concentrent chacun sur leur propre champ d’expertise. Les informations sont transmises en temps réel entre les deux, par exemple :

Plusieurs composants AEM prêts à l’emploi sont proposés pour utiliser la couche d’intégration. Actuellement, il s’agit des éléments suivants :

Diverses options de recherche sont également disponibles.

Architecture architecture

Le framework d’intégration fournit l’API, une gamme de composants pour illustrer la fonctionnalité et plusieurs extensions pour fournir des exemples de modes de connexion :

Le framework vous donne accès à certaines fonctionnalités, comme :

Mises en œuvre implementations

AEM eCommerce est implémenté avec un moteur d’e-commerce :

Fournisseurs de commerce commerce-providers

Lors de l’importation des données d’un moteur de commerce dans votre site AEM eCommerce, un fournisseur de commerce est utilisé pour fournir des données aux importateurs. Un fournisseur de commerce peut prendre en charge plusieurs importateurs.

Un fournisseur de commerce est un code AEM personnalisé pour :

Deux exemples de fournisseurs de commerce sont actuellement disponibles pour AEM :

Cependant, généralement, un projet doit développer son propre fournisseur de commerce personnalisé, spécifique à son PIM et à son schéma de données de produit.

ProductServicesManager conserve (par le biais d’OSGi) une liste des mises en œuvre des interfaces ProductImporter et CatalogBlueprintImporter.Celles-ci sont répertoriées dans le champ de liste déroulante Importateur/Fournisseur de commerce de l’assistant d’importation (à l’aide de la propriété commerceProvider comme nom).

Lorsqu’un importateur/fournisseur de commerce spécifique est répertorié dans la liste déroulante, toutes les données complémentaires dont il a besoin doivent être définies (en fonction du type de l’importateur) dans :

Le dossier situé sous le dossier importers approprié doit correspondre au nom de l’importateur, par exemple :

Le format du fichier d’importation source est défini par l’importateur. L’importateur peut également établir une connexion (WebDAV ou HTTP, par exemple) avec le moteur de commerce.

Rôles roles

Le système intégré gère les rôles suivants pour traiter les données :

Bien que l’emplacement réel puisse dépendre de votre implémentation, par exemple, générique ou avec un moteur e-commerce :

Produits products

Données des produits ou données marketing product-data-versus-marketing-data

Catégories structurelles ou catégories marketing structural-versus-marketing-categories

Si les deux catégories ci-dessous peuvent être différenciées, vous pouvez créer des adresses URL claires avec une structure significative (arborescences de nœuds cq:Page) et, par conséquent, très proche de la gestion de contenu AEM classique :

Données du produit product-data

Pour représenter et gérer votre produit, vous souhaiterez conserver diverses informations à son sujet.

Les données des produits peuvent être :

Dans un cas comme dans l’autre, lorsque les données des produits ont été saisies/importées dans AEM, elles sont visibles dans la console Produits. Ici, les vues Carte et Liste d’un produit affichent des informations telles que :

Variantes de produit product-variants

Pour certains produits, il peut exister des informations sur les variantes. Pour des vêtements par exemple, les différentes couleurs disponibles sont affichées sous forme de variantes :

Attributs de produit product-attributes

Les différents attributs de produit peuvent dépendre du moteur eCommerce utilisé et de votre mise en œuvre AEM. Ils sont disponibles (le cas échéant) lors de l’affichage de pages de produits et/ou de la modification d’informations sur les produits et peuvent inclure :

Ressources du produit product-assets

Plusieurs ressources peuvent être disponibles pour différents produits. En général, il s’agit d’images et de vidéos.

Catalogues catalogs

Un catalogue regroupe des données sur les produits afin de faciliter la gestion et la présentation à l’acheteur. Souvent, un catalogue est structuré selon des attributs tels que la langue, la zone géographique, la marque, la saison, le loisir, le sport, etc.

Structure de catalogue catalog-structure

Catalogues en plusieurs langues catalogs-in-multiple-languages

AEM prend en charge le contenu du produit en plusieurs langues. Lorsque vous demandez des données, le framework d’intégration extrait la langue de l’arborescence actuelle (par exemple, en_US pour les pages sous /content/geometrixx-outdoors/en_US).

Pour un magasin multilingue, vous pouvez importer votre catalogue pour chaque arborescence de langues individuellement (ou le copier avec MSM).

Catalogues pour plusieurs marques catalogs-for-multiple-brands

Comme pour les langues, les grandes entreprises multinationales doivent couvrir plusieurs marques.

Catalogues par balises catalogs-by-tags

Vous pouvez également utiliser des balises pour regrouper des produits dans un catalogue. Ceci permet de générer des catalogues plus dynamiques, par exemple pour les offres saisonnières.

Configuration du catalogue (import initial) catalog-setup-initial-import

Selon votre implémentation, vous pouvez importer les données des produits requises pour votre catalogue de base dans AEM à partir :

Maintenance du catalogue (synchronisation des données) catalog-maintenance-data-synchronization

D’autres modifications des données des produits sont inévitables :

Synchronisation des données avec un moteur e-commerce (en cours) data-synchronization-with-an-ecommerce-engine-ongoing

Après l’import initial, les modifications apportées aux données de vos produits sont inévitables.

Lorsque vous utilisez un moteur e-commerce, les données des produits y sont conservées et doivent être disponibles dans AEM. Ces données sur les produits doivent être synchronisées en cas de mises à jour.

Cela peut dépendre du type de données :

Catalogues - Performance et mise à l’échelle catalogs-performance-and-scaling

L’import d’un catalogue volumineux contenant de nombreux produits (plus de 100 000) à partir d’un moteur e-commerce (PIM) peut avoir un impact sur le système en raison du grand nombre de nœuds. Il peut également ralentir l’instance de création si des ressources (images des produits, par exemple) sont associées aux produits. En effet, le post-traitement de ces ressources nécessite beaucoup de puissance de calcul et de mémoire.

Pour contourner ces problèmes, vous pouvez appliquer l’une des stratégies suivantes :

Compartimentation bucketing

Si un nœud JCR comporte de nombreux nœuds enfants directs (1 000 et plus, par exemple), des compartiments (ou dossiers fantômes) sont nécessaires pour s’assurer que les performances ne sont pas affectées. Ils sont générés selon un algorithme lors de l’import.

Ces compartiments prennent la forme de dossiers fantômes introduits dans la structure de votre catalogue, mais peuvent être configurés de sorte qu’ils ne soient pas visibles dans les URL publiques.

Décharger le post-traitement des ressources sur une instance dédiée offload-asset-post-processing-to-a-dedicated-instance

Ce scénario implique la configuration de deux instances de création :

Importer uniquement des données des produits only-import-product-data

Dans le cas où les produits ne contiennent pas de ressources (images) à importer, vous pouvez importer les données de produit sans que le post-traitement des ressources n’ait de conséquences.

Test de performance performance-testing

Les tests de performance doivent être pris en compte dans les implémentations d’AEM e-commerce :

Notez que ce test de performance nécessite des connaissances et une analyse de votre cible :

Performances – Divers performance-miscellaneous

Pour toutes les mises en œuvre, vous pouvez tenir compte des points suivants :

Pages de section du catalogue catalog-section-pages

Les sections du catalogue vous fournissent, par exemple :

Pages de produits product-pages

Les pages de produits fournissent des informations exhaustives sur des produits spécifiques. Les mises à jour dynamiques sont également répercutées ; par exemple, les modifications de prix enregistrées dans le moteur e-commerce.

Les pages de produits sont des pages AEM qui utilisent le composant Produit, par exemple, dans le modèle Produit Commerce  :

Le composant Produit fournit les éléments suivants :

Ces informations permettent à l’acheteur de sélectionner les éléments ci-dessous lorsqu’il ajoute un article dans son panier :

Pages de destination de produits product-landing-pages

Il s’agit de pages AEM qui fournissent principalement des informations statiques ; par exemple, une introduction et une vue d’ensemble avec des liens vers les pages de produits sous-jacentes.

Composant Produit product-component

Le composant Produit peut être ajouté à une page avec une page parente, qui contient les métadonnées nécessaires (à savoir, chemins d’accès à cartPage et à cartObject). Sur le site de démonstration Geometrixx Outdoors, il est fourni par UserInfo.jsp.

Le composant Produit peut également être personnalisé en fonction de vos besoins.

Pages de proxy proxy-pages

Les pages proxy sont utilisées pour simplifier la structure du référentiel et optimiser le stockage pour les catalogues volumineux.

La création d’un catalogue utilise dix nœuds par produit, car elle fournit des composants individuels pour chaque produit, que vous pouvez mettre à jour et personnaliser dans AEM. Ce grand nombre de nœuds peut devenir problématique si votre catalogue contient des centaines, voire des milliers de produits. Pour éviter tout problème, vous pouvez créer votre catalogue à l’aide de pages proxy.

Les pages de proxy reposent sur une structure à deux nœuds (jcr:content et cq:Page), qui ne contient pas de contenu réel de produits. Le contenu est généré lors de la demande, en se référant aux données des produits et au modèle de page.

Ceci présente cependant un inconvénient : Vous ne pourrez pas personnaliser les informations sur vos produits dans AEM. Un modèle standard (défini pour votre site) sera utilisé.

Promotions et bons promotions-and-vouchers

Bons vouchers

Les bons sont une méthode éprouvée d’offre de remise pour inciter les acheteurs et acheteuses à faire un achat et/ou récompenser leur fidélité.

Dans AEM :

Promotions promotions

Les promotions, ainsi que les bons, vous permettent de réaliser des scénarios tels que :

Les promotions ne sont pas gérées par les responsables des informations sur les produits, mais par les responsables marketing :

Dans AEM, les promotions sont également intégrées à Campaign Management :

Une promotion peut être contenue dans une expérience ou directement dans la campagne :

Personnalisation personalization

Enregistrement et compte des clientes et clients customer-registration-and-accounts

Lorsqu’un nouvel acheteur ou une nouvelle acheteuse s’enregistre, les détails du compte doivent être synchronisés entre AEM et le moteur e-commerce. Les données sensibles sont conservées indépendamment, mais les profils sont partagés :

Le mécanisme exact peut dépendre du scénario :

Lorsque vous utilisez un moteur eCommerce, AEM stocke uniquement l’ID de compte et le mot de passe (éventuellement, un groupe d’utilisateurs). Toutes les autres informations sont stockées dans le moteur eCommerce.

Inscription des clientes et clients customer-sign-up

Pour que l’acheteur ait accès au panier, il doit généralement s’inscrire. Cela implique un enregistrement (Créer un compte) afin de pouvoir créer un compte spécifique au client.

Connexion du client ou de la cliente customer-sign-in

Après leur inscription, le nouvel acheteur ou la nouvelle acheteuse peut se connecter à son compte, afin que ses actions puissent faire l’objet d’un suivi et que ses commandes soient exécutées.

Authentification unique single-sign-on

L’authentification unique (SSO) est fournie, de sorte que les auteurs et autrices soient connus dans AEM et dans le système e-commerce sans avoir à se connecter deux fois.

myAccount myaccount

Les données des transactions du moteur eCommerce sont combinées aux informations personnelles sur l’acheteur. AEM utilise certaines de ces données sous forme de données de profil. L’action d’un formulaire dans AEM réécrit les informations dans le moteur e-commerce.

Une page permet de gérer facilement les informations de compte. Pour y accéder, cliquez sur Mon compte dans la partie supérieure d’une page Geometrixx ou accédez à /content/geometrixx-outdoors/en/user/account.html.

Carnet d’adresses address-book

Votre site doit stocker diverses adresses, dont les adresses de livraison et de facturation, ou encore les adresses secondaires. Vous pouvez pour cela utiliser des formulaires basés sur votre format d’adresse par défaut ou utiliser le composant Carnet d’adresses fourni par AEM.

Ce composant Carnet d’adresses permet de :

Vous pouvez choisir l’adresse par défaut.

Pour accéder au composant Carnet d’adresses, sélectionnez la page Mon compte en cliquant sur Carnet d’adresses ou en accédant à /content/geometrixx-outdoors/en/user/account/address-book.html.

Cliquez sur Ajouter une nouvelle adresse… pour ajouter une adresse à votre carnet d’adresses. Vous ouvrez ainsi un formulaire à remplir. Cliquez ensuite sur Ajouter une adresse.

Le carnet d’adresses est utilisé lorsque vous passez en caisse avec votre panier :

Les adresses sont conservées ci-dessous user_home/profile/addresses.
Par exemple, Alison Parker serait enregistrée sous /home/users/geometrixx/aparker@geometrixx.info/profile/addresses.

Vous pouvez définir l’adresse à sélectionner par défaut. Ces informations sont conservées dans le profil de l’acheteur plutôt qu’avec l’adresse. La propriété de profil address.default est définie avec le chemin d’accès de l’adresse sélectionnée pour la valeur.

Tarifs spécifiques au client ou à la cliente customer-specific-pricing

Le moteur e-commerce utilise le contexte (essentiellement les informations sur les nouveaux acheteurs ou les nouvelles acheteuses) pour déterminer le prix, puis fournit les informations à AEM.

Panier et commandes shopping-cart-and-orders

Lorsque le nouvel acheteur ou la nouvelle acheteuse effectue des achats, il ou elle parcourt les pages de produits et sélectionne des articles à placer dans son panier. Au passage en caisse, la commande peut être passée.

Acheteurs anonymes anonymous-shoppers

Un client anonyme peut :

Nouveaux acheteurs et nouvelles acheteuses enregistrés registered-shoppers

Un client enregistré peut :

Vue d’ensemble du contenu du panier shopping-cart-content-overview

Le panier fournit :

Le panier est enregistré en fonction du moteur utilisé :

Dans un cas comme dans l’autre, les articles restent dans le panier (et peuvent être restaurés) au-delà de la connexion/déconnexion (mais uniquement sur le même ordinateur/dans le même navigateur). Par exemple :

Avant le passage en caisse, les changements de prix sont répercutés (dans les deux systèmes) au fur et à mesure.

Informations sur la commande order-information

En fonction de votre mise en œuvre, les informations relatives à une commande sont conservées dans le moteur e-commerce ou AEM. Ces informations sont générées par AEM.

Diverses informations sont stockées, notamment les éléments suivants :

Lorsque la commande est conservée dans AEM, la console Commande affiche les informations ci-dessous pour chaque commande :

Suivi des commandes order-tracking

Après avoir passé une commande, les acheteurs et acheteuses reviennent souvent :

Après réception de la commande, les acheteurs et acheteuses peuvent également souhaiter consulter l’historique des commandes passées sur une période donnée.

L’exécution et le suivi des commandes sont gérés par le moteur e-commerce. Ces informations peuvent être affichées par AEM à l’aide du composant Historique des commandes, qui affiche tous les détails pertinents, dont les bons et les promotions appliqués. Par exemple :

Passage en caisse checkout

Le passage en caisse est mis en œuvre avec des formulaires AEM standard. Cela permet au ou à la responsable marketing de personnaliser l’expérience avec le contenu marketing.

L’e-commerce gère ensuite le processus de passage en caisse avec les entrées des formulaires AEM.

Sécurité des paiements payment-security

Les informations de paiement, dont les informations de carte de crédit, sont généralement gérées par le moteur eCommerce. AEM transfère ces informations sur les transactions au moteur (d’où elles sont ensuite transférées à un service de traitement des paiements).

La conformité aux normes de sécurité des données de l’industrie des cartes de paiement peut être obtenue.

Confirmation de commande confirmation-of-order

La commande est confirmée à l’écran et peut être suivie grâce au suivi des commandes.

Rechercher search-features

Dans la mesure où AEM utilise des pages standard pour les produits, vous pouvez utiliser le composant de recherche standard afin de créer une page de recherche.

Si vous avez besoin d’une implémentation plus approfondie, vous pouvez :

Lorsque vous utilisez un moteur eCommerce, l’API de recherche eCommerce peut être totalement mise en œuvre dans la solution du moteur eCommerce afin que vous puissiez utiliser le composant de recherche eCommerce fourni. La recherche à facette permet d’effectuer une recherche dans JCR et/ou dans le moteur :