La structure d’intégration fournit les mécanismes et les composants des opérations suivantes :
Cela signifie que :
La structure de commerce électronique peut être utilisée avec :
le framework d’intégration du e-commerce est un module complémentaire d’AEM.
Le représentant commercial peut vous donner plus de détails, en fonction du moteur approprié.
Le framework fournit les exigences de base de votre propre projet.
Un certain travail de développement reste nécessaire pour adapter le framework à vos spécifications.
L’installation standard d’AEM inclut une mise en œuvre générique d’eCommerce (JCR) AEM.
Pour le moment, elle est utilisée à des fins de démonstration ou comme base d’une mise en œuvre personnalisée selon vos besoins.
Pour optimiser le fonctionnement, AEM et le moteur eCommerce se concentrent chacun sur leur propre champ d’expertise. Les informations sont transférées entre les deux en temps réel. Par exemple :
AEM peut :
Requête :
Fournissez les détails suivants :
Le moteur eCommerce peut :
fournir les détails suivants :
Processus :
Les détails exacts dépendent du moteur eCommerce et de la mise en œuvre du projet.
Un certain nombre de composants AEM prêts à l’emploi sont proposés pour utiliser la couche d’intégration. Pour le moment, par exemple :
Différentes options de recherche sont également disponibles.
La structure d’intégration fournit l’API, une série de composants illustrant les fonctionnalités et différentes extensions pour fournir des exemples de méthodes de connexion.
Le framework vous donne accès à certaines fonctionnalités, comme :
AEM eCommerce est mis en œuvre avec un moteur eCommerce :
L’installation standard d’AEM inclut une mise en œuvre générique d’eCommerce (JCR) AEM.
Pour le moment, elle est utilisée à des fins de démonstration ou comme base d’une mise en œuvre personnalisée selon vos besoins.
AEM eCommerce mis en œuvre dans AEM à l’aide du développement générique reposant sur JCR est :
Un exemple d’instance AEM eCommerce native autonome illustrant l’utilisation de l’API, qui peut être utilisée pour contrôler des données des produits, les paniers et le passage en caisse conjointement à l’affichage des données existantes et aux campagnes marketing. Dans ce cas, la base de données de produits est stockée dans le référentiel natif à AEM (mise en œuvre JCR d’Adobe).
L’installation standard d’AEM contient les éléments de base de la mise en œuvre générique eCommerce.
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 différents importateurs.
Un fournisseur de commerce est du code AEM personnalisé pour les opérations suivantes :
Deux exemples de fournisseurs de commerce sont disponibles actuellement pour AEM :
Généralement, un projet doit développer son propre fournisseur de commerce personnalisé spécifique à sa gestion d’informations sur les produits et à son schéma de données sur les produits.
Les importateurs geometrixx utilisent des fichiers CSV. Les commentaires précédant la mise en œuvre décrivent le schéma accepté (avec les propriétés personnalisées autorisées).
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 :
/apps/commerce/gui/content/catalogs/importblueprintswizard/importers
/apps/commerce/gui/content/products/importproductswizard/importers
Le dossier situé sous le dossier importers
approprié doit correspondre au nom de l’importateur, par exemple :
.../importproductswizard/importers/geometrixx/.content.xml
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) au moteur de commerce.
Le système intégré gère les rôles ci-dessous pour conserver les données :
Utilisateur de la gestion d’informations sur les produits, qui gère les éléments suivants :
Créateur/responsable marketing, qui gère les données suivantes :
Utilisateur du site/acheteur, qui gère les éléments suivants :
L’emplacement réel peut dépendre de votre mise en œuvre, par exemple, générique ou avec un moteur eCommerce :
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 :
Catégories structurelles
Arborescence de catégories définissant ce qu’est un produit ; par exemple :
/products/mens/shoes/sneakers
Catégories Marketing
Toutes les autres catégories auxquelles un produit peut appartenir, par exemple :
/special-offers/christmas/shoes
)
Pour décrire et gérer votre produit, vous souhaitez conserver une série d’informations les concernant.
Les données peuvent être :
créées directement dans AEM (générique) ;
gérées dans le moteur eCommerce et mises à disposition dans AEM.
Selon le type de données, elles sont synchronisées si nécessaire ou directement accessibles. Par exemple, les données très variables et essentielles, comme les prix des produits, sont extraites du moteur eCommerce pour chaque demande de page afin qu’elles soient toujours à jour.
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. Dans l’exemple ci-dessous, les vues sous forme de carte et de liste fournissent des informations du type suivant :
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 :
Les différents attributs de produit peuvent dépendre du moteur eCommerce utilisé et de votre mise en œuvre AEM. Ils sont disponibles (lorsque cela est approprié) lors de l’affichage des pages et/ou de la modification des informations sur les produits et peuvent inclure les informations suivantes :
Image
Image du produit.
Titre
Nom du produit.
Description
Description textuelle du produit.
Balises
Balises utilisées pour regrouper des produits associés.
Catégorie de ressources par défaut
Catégorie par défaut des ressources.
Données ERP
Informations sur la planification des ressources de l’entreprise.
SKU
Informations sur les unités de gestion des stocks (SKU).
Couleur
Taille
Prix
Prix du produit à l’unité.
Résumé
Récapitulatif des caractéristiques du produit.
Fonctions
Informations plus exhaustives des caractéristiques du produit.
Plusieurs ressources peuvent être disponibles pour différents produits. En général, il s’agit d’images et de vidéos.
Un catalogue regroupe des données sur les produits afin de faciliter la gestion et la présentation à l’acheteur. Généralement, un catalogue est structuré selon des attributs comme la langue, la région géographique, la marque, la saison, le centre d’intérêt, le sport, etc.
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 une boutique multilingue, vous pouvez importer un catalogue individuellement pour chaque arborescence de langue (ou le copier avec MSM).
Comme pour les langues, les grandes entreprises multinationales peuvent avoir à couvrir plusieurs marques.
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.
En fonction de votre mise en œuvre, vous pouvez importer les données sur les produits nécessaires pour votre catalogue de base dans AEM à partir de l’un des éléments suivants :
D’autres modifications apportées aux données du produit sont inévitables :
Après l’importation initiale, les modifications apportées aux données de vos produits sont inévitables.
Lorsque vous utilisez un moteur eCommerce, 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 dépend du type de données :
Une synchronisation périodique est utilisée avec un flux de données des modifications.
De plus, vous pouvez sélectionner des mises à jour spécifiques pour une mise à jour express.
Des données très variables, comme des informations sur les prix, sont extraites du moteur de commerce pour chaque demande de page afin de veiller à ce qu’elles soient toujours à jour.
L’importation d’un catalogue volumineux contenant de nombreux produits (plus de 100 000 en général) à partir d’un moteur eCommerce (gestion d’informations sur les produits) peut avoir un impact sur le système en raison du grand nombre de nœuds. Elle peut également ralentir l’instance de création si des ressources (images des produits, par exemple) sont associées aux produits. Cela s’explique par l’utilisation intensive du processeur et de la mémoire lors du post-traitement de ces ressources.
Pour contourner ces problèmes, vous pouvez appliquer l’une des stratégies suivantes :
Si un nœud JCR comporte de nombreux nœuds enfants directs (1 000 et plus, par exemple), des compartiments (dossiers fantômes) sont nécessaires pour s’assurer que les performances ne sont pas affectées. Ils sont créés selon un algorithme lors de l’importation.
Ces compartiments prennent la forme de dossiers fantômes introduits dans la structure du catalogue, mais peuvent être configurés afin d’être invisibles dans les adresses URL publiques.
Ce scénario consiste à configurer deux instances de création :
Instance de création principale
Importe des données de produit à partir de la gestion d’informations sur les produits, pour laquelle le post-traitement des chemins d’accès aux ressources est désactivé.
Instance de création de gestion des ressources numériques dédiée
Importe et post-traite des ressources de produit à partir de la gestion d’informations sur les produits, puis réplique ces ressources sur l’instance de création principale pour les utiliser.
En l’absence de ressources (images) à importer pour des produits, vous pouvez importer les données des produits sans être affecté par le post-traitement des ressources.
Le test de performances doit être pris en compte dans les mises en œuvre d’AEM eCommerce :
Environnement de création :
L’activité en arrière-plan (une importation, par exemple) peut avoir lieu en même temps que l’activité habituelle de l’utilisateur (modification des pages, par exemple). Même si les performances frontales (en général) bénéficient d’une priorité supérieure, des performances médiocres constatées par les créateurs en ligne peuvent conduire à une frustration susceptible de bloquer une décision de lancement.
Environnement de publication :
La réplication est un processus critique, qui permet de s’assurer que le contenu est publié rapidement et facilement, et qui peut être influencé par la façon dont le créateur regroupe le contenu à publier.
Frontal :
L’ensemble des invalidations frontales et du cache peut nuire aux performances. Des tests permettent de les éviter.
Ces tests des performances impliquent de connaître et d’analyser la cible :
Volumes de contenu
Activité de l’utilisateur
Processus en arrière-plan
Exigences de maintenance (sauvegarde, optimisation TAR PM, nettoyage de l’entrepôt de données, etc.)
Pour toutes les mises en œuvre, tenez compte des points suivants :
Comme les produits, il peut y avoir de nombreuses unités de gestion des stocks et catégories. Utilisez le plus petit nombre de nœuds possible afin de modéliser le contenu.
Plus il y a de nœuds, plus le contenu est flexible (système de paragraphes, par exemple). Cependant, certains compromis sont inévitables. Avez-vous besoin d’une flexibilité individuelle (par défaut) lorsque vous manipulez, par exemple, 30 000 produits ?
Évitez autant que possible la duplication (voir localisation) ou, en cas de duplication, pensez au nombre de nœuds découlant de la duplication.
Essayez autant que possible de définir des balises pour le contenu afin de préparer l’optimisation des requêtes.
Par exemple :
/content/products/france/fr/shoe/reebok/pump/46 SKU
Doit comporter une balise par niveau de contenu (c’est-à-dire pays, langue, catégorie, marque, produit). Recherche de
//element(*,my:Sku)[@country=’france’ and @language=’fr’
et
@category=’shoe’ and @brand=’reebok’ and @product=’pump’]
sera considérablement plus rapide que la recherche de
/jcr:root/content/france/fr/shoe/reebok/pump/element(*,my:Sku)
Dans votre pile technique, planifiez un modèle et des services d’accès au contenu très adaptés. Cette pratique recommandée générale s’impose encore plus dans le cas présent, car vous pouvez, lors des phases d’optimisation, ajouter des caches d’application pour les données lues très souvent (avec lesquelles vous ne souhaitez pas remplir le cache des lots).
Par exemple, il est habituellement recommandé de mettre en cache la gestion des attributs, car cela concerne les données mises à jour lors de l’importation des produits.
Envisagez d’utiliser des pages de proxy.
Les sections du catalogue fournissent, par exemple, les éléments suivants :
Les pages de produits fournissent des informations exhaustives sur des produits spécifiques. Les mises à jour dynamiques sont également prises en compte, par exemple les changements de prix enregistrés dans le moteur eCommerce.
Les pages de produits sont des pages AEM qui utilisent le composant Produit, par exemple dans le modèle Produit du 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 :
Ces pages AEM fournissent principalement des informations statiques, par exemple une présentation et un aperçu contenant des liens vers les pages de produit sous-jacentes.
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é selon vos exigences.
Des pages de proxy sont utilisées pour simplifier la structure du référentiel et optimiser le stockage des 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, créez le catalogue en utilisant des pages de 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 les produits dans AEM, car un modèle standard (défini pour votre site) est utilisé.
Vous ne rencontrerez aucun problème si vous importez un catalogue volumineux sans pages de proxy.
Vous pouvez passer d’une méthode à l’autre à tout moment. Vous pouvez également convertir une sous-section de votre catalogue.
Les bons constituent une méthode éprouvée pour proposer des remises afin d’inciter les acheteurs à acheter et/ou de récompenser la fidélité des clients.
Les bons se composent des éléments suivants :
Les moteurs de commerce externes peuvent également fournir des bons.
Dans AEM :
Un bon est un composant basé sur une page, créé/modifié avec la console Sites Web.
Le composant Bon fournit :
Les bons ne comportent pas leurs propres dates/périodes de validité ; ils utilisent celles de leurs campagnes parentes.
AEM utilise le terme bon, synonyme de coupon.
Tout comme les bons, les promotions permettent d’exécuter des scénarios, comme ceux qui suivent :
Généralement, les promotions ne sont pas gérées par les responsables des informations sur les produits, mais par les directeurs marketing :
Une promotion est un composant basé sur une page, créé/modifié avec la console Sites Web. ``
Diffusion de promotions :
Vous pouvez associer des promotions à une campagne pour définir leur date/heure d’activation/de désactivation.
Vous pouvez associer des promotions à une expérience pour définir leurs segments.
Les promotions qui ne sont pas liées à une expérience ne se déclenchent pas seules, mais peuvent être déclenchées par un bon.
Le composant Promotion contient les éléments suivants :
Dans AEM, les promotions sont également intégrées à la gestion des campagnes :
Une promotion peut être contenue dans une expérience ou directement dans la campagne :
Si une promotion est contenue dans une expérience, elle peut être appliquée automatiquement à un segment ciblé.
Par exemple, dans l’exemple de site geometrixx-outdoors, la promotion :
/content/campaigns/geometrixx-outdoors/big-spender/ordervalueover100/free-shipping
se déclenche automatiquement chaque fois que le segment (ordervalueover100
) est résolu.
Si une promotion ne s’affiche pas dans une expérience (seulement dans la campagne), elle ne peut pas être appliquée automatiquement à une audience. Cependant, elle peut se déclencher si l’acheteur saisit un bon dans son panier et que ce bon est associé à la promotion.
Par exemple, la promotion :
/content/campaigns/geometrixx-outdoors/article/10-bucks-off
se trouve en dehors d’une expérience et ne se déclenche donc jamais automatiquement (par exemple : en fonction de la segmentation). Elle est, cependant, référencée par les bons qui se trouvent dans différentes expériences dans la campagne concernant l’article. La saisie de ces codes de bon dans le panier déclenche la promotion.
Les promotions Hybris et les bons Hybris couvrent tout ce qui influence le panier et est lié au prix. Le contenu marketing spécifique à une promotion (bannières, etc.) ne fait pas partie de la promotion Hybris.
Lorsqu’un acheteur s’enregistre, les détails du compte doivent être synchronisés entre AEM et le moteur eCommerce. 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 :
Le compte utilisateur existe sur les deux systèmes :
Le compte utilisateur existe seulement dans AEM :
Le compte utilisateur existe uniquement dans le moteur eCommerce :
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.
Lorsque vous utilisez un moteur eCommerce, vous devez vous assurer que les comptes créés pour les utilisateurs qui se connectent à une instance AEM sont répliqués (par le biais de workflows, par exemple) sur les autres instances AEM qui communiquent avec ce moteur.
Autrement, ces autres instances AEM essaient également de créer des comptes pour les mêmes utilisateurs dans le moteur. Ces actions échouent avec une exception DuplicateUidException
générée par le moteur.
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.
Un panier et un passage en caisse anonymes sont également pris en charge.
Après s’être inscrit, l’acheteur peut se connecter à son compte afin que ses actions puissent faire l’objet d’un suivi et que ses commandes soient exécutées.
La connexion unique (SSO) est proposée afin que les créateurs soient identifiés dans AEM et sur le système de commerce électronique sans avoir à s’identifier deux fois.
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 eCommerce.
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
.
Votre site doit stocker diverses adresses, dont les adresses de livraison, de facturation et secondaires. Cette possibilité peut être mise en œuvre à l’aide de formulaires en fonction du format d’adresse par défaut ou vous pouvez utiliser le composant Carnet d’adresses fourni par AEM.
Ce composant Carnet d’adresses permet ce qui suit :
Vous pouvez choisir l’adresse à définir 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 nouvelle adresse à votre carnet d’adresses. Un formulaire à remplir s’affiche. Cliquez ensuite sur Ajouter une adresse.
Vous pouvez saisir plusieurs adresses dans votre carnet d’adresses.
Le carnet d’adresses est utilisé lors du passage en caisse de 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.
Le moteur eCommerce utilise le contexte (essentiellement les informations de l’acheteur) afin de déterminer le prix qu’il contient, puis renvoie les informations correctes dans AEM.
Lorsque l’acheteur effectue des achats, il parcourt les pages de produits et sélectionne des articles qu’il place dans son panier. Lorsqu’il passe en caisse, il peut passer une commande.
Un client anonyme peut :
Selon la configuration de vos informations d’adresse d’instance, l’enregistrement des clients peut être nécessaire avant le passage en caisse.
Un client enregistré peut :
Le panier fournit :
une présentation des articles sélectionnés ;
des liens vers des pages de produits pour les articles sélectionnés ;
la possibilité de :
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 :
Parcourez un site en tant qu’utilisateur anonymous
et ajoutez des articles au panier.
Connectez-vous en tant qu’Allison Parker
(son panier est vide).
Ajoutez des produits à son panier.
Déconnectez-vous. Le panier affiche les produits de l’utilisateur anonymous
.
Reconnectez-vous en tant qu’Allison Parker
. Ses produits sont restaurés.
Un panier anonyme peut être restauré uniquement sur le même ordinateur/dans le même navigateur.
Il n’est pas recommandé de tester la restauration du contenu du panier avec le compte admin
, car cela peut créer un conflit avec le compte admin
du moteur eCommerce (Hybris, par exemple).
Hybris peut être configuré de manière à supprimer les paniers en attente après une certaine période.
Avant le passage en caisse, les modifications des prix sont répercutées (sur les deux systèmes) dès qu’elles ont lieu.
En fonction de vos informations de mise en œuvre sur une commande contenue dans le moteur eCommerce ou dans AEM, ces informations sont rendues par AEM.
Différentes informations sont stockées, notamment :
ID de commande
Numéro de référence de la commande.
Passée
Date à laquelle la commande a été passée.
Statut
Statut de la commande, par exemple, Expédiée.
Devise
Devise dans laquelle la commande est libellée.
Éléments de contenu
Liste des éléments triés.
Sous-total
Coût total des articles commandés.
Taxes
Montant des taxes dues sur la commande.
Expédition
Frais d’expédition.
Total
Valeur totale de la commande : articles commandés, taxes et frais d’expédition.
Adresse de facturation
Adresse à laquelle la facture doit être envoyée.
Jeton de paiement
Mode de paiement.
Statut du paiement
Statut du paiement.
Adresse d’expédition
Adresse à laquelle les produits doivent être expédiés.
Mode d’expédition
Mode d’expédition, par exemple, par voie terrestre, maritime ou aérienne.
Numéro de suivi
Tout numéro de suivi utilisé par le transporteur.
Lien de suivi
Lien utilisé pour suivre la commande en cours d’expédition.
Les champs utilisés dans l’assistant de création de commande dépendent de la génération de modèles automatique optimisée pour les écrans tactiles définie pour le lieu. Dans l’exemple générique, elle se trouve sous :
/etc/scaffolding/geometrixx-outdoors/order/jcr:content/cq:dialog
Lorsque la commande est conservée dans AEM, la console Commande affiche les informations ci-dessous pour chaque commande :
Après avoir passé une commande, les acheteurs reviennent souvent sur le site pour :
Après réception de la commande, ils peuvent également consulter l’historique des commandes passées pendant une période donnée.
L’exécution et le suivi des commandes sont généralement gérés par le moteur eCommerce. 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 :
Le passage en caisse est mis en œuvre avec des formulaires AEM standard. Cela permet au responsable marketing de personnaliser l’expérience avec du contenu marketing.
Le moteur eCommerce gère ensuite le processus de passage en caisse avec les informations saisies dans les formulaires AEM.
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.
La commande est confirmée à l’écran et peut être suivie grâce au suivi des commandes.
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 mise en œuvre approfondie, vous pouvez :
CommerceService
, puis utiliser le composant de recherche eCommerce sur votre page de recherche.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 :