Das Integrationsframework stellt Mechanismen und Komponenten für die folgenden Aufgaben bereit:
Das heißt:
Das eCommerce-Framework kann mit Folgendem verwendet werden:
Das eCommerce-Integrationsframework ist ein Add-on von AEM.
Umfassende Informationen hierzu, passend zur entsprechenden Engine, erhalten Sie von dem für Sie zuständigen Vertriebsmitarbeiter.
Das Framework stellt die grundlegenden Voraussetzungen für Ihr eigenes Projekt bereit.
Ein gewisses Maß an Entwicklungsarbeit ist immer erforderlich, um das Framework an Ihre Vorgaben anzupassen.
Die AEM-Standardinstallation umfasst die generische AEM-eCommerce-Implementierung (JCR).
Sie dient derzeit zur Veranschaulichung bzw. als Grundlage für eine benutzerdefinierte Implementierung nach Ihren jeweiligen Anforderungen.
Um den Betrieb zu optimieren, konzentrieren sich AEM und die eCommerce-Engine auf ihren jeweiligen Fachbereich. Daten werden in Echtzeit zwischen ihnen ausgetauscht, z. B.:
AEM kann:
Anfrage:
Geben Sie Folgendes an:
Die eCommerce-Engine kann:
Geben Sie Folgendes an:
verarbeiten:
Die genauen Details hängen von der eCommerce-Engine und der Projektimplementierung ab.
Zur Verwendung der Integrationsebene stehen eine Reihe vordefinierter AEM zur Verfügung. Aktuell gehören dazu folgende:
Verschiedene Suchoptionen sind ebenfalls verfügbar.
Das Integrationsframework stellt die API, mehrere Komponenten zur Veranschaulichung der Funktionalität und einige Erweiterungen für Beispiele für Anbindungsmethoden bereit:
Über das Framework erhalten Sie Zugriff auf Funktionen, z. B.:
AEM eCommerce wird mit einer eCommerce-Engine implementiert:
Die AEM-Standardinstallation umfasst die generische AEM-eCommerce-Implementierung (JCR).
Sie dient derzeit zur Veranschaulichung bzw. als Grundlage für eine benutzerdefinierte Implementierung nach Ihren jeweiligen Anforderungen.
AEM eCommerce, implementiert in AEM, mit generischer Entwicklung basierend auf JCR, ist:
Beim Importieren von Daten aus einer Commerce-Engine in Ihre AEM-eCommerce-Website erhalten die Importtools ihre Daten von einem Commerce-Anbieter. Ein Commerce-Anbieter kann mehrere Importtools unterstützen.
Ein Commerce-Anbieter ist ein angepasster AEM-Code, der entweder
Derzeit sind zwei Beispiel-Commerce-Anbieter für AEM verfügbar:
Dennoch müssen Sie für ein Projekt in der Regel einen eigenen, angepassten Commerce-Anbieter entsprechend dem PIM und Produktdatenschema entwickeln.
Die Geometrixx-Importtools nutzen CSV-Dateien. In den Kommentaren über ihre Implementierung finden Sie eine Beschreibung des akzeptierten Schemas (samt der zulässigen benutzerdefinierten Eigenschaften).
Der ProductServicesManager verwaltet (über OSGi) eine Liste der Implementierungen der ProductImporter- und CatalogBlueprintImporter-Schnittstelle. Diese werden im Dropdown-Feld Importer/Commerce-Anbieter des Importassistenten aufgeführt (unter Verwendung der commerceProvider
-Eigenschaft als Name).
Wenn ein bestimmtes Importtool/ein bestimmter Commerce-Anbieter im Dropdown-Feld verfügbar ist, müssen Sie alle weiteren benötigten Daten (je nach Art des Importtools) definieren, unter einem der folgenden Pfade:
/apps/commerce/gui/content/catalogs/importblueprintswizard/importers
/apps/commerce/gui/content/products/importproductswizard/importers
Der Ordner unter dem entsprechenden Ordner importers
muss mit dem Namen des Importeurs übereinstimmen. Beispiel:
.../importproductswizard/importers/geometrixx/.content.xml
Das Format der Quell-Importdatei wird vom Importtool definiert. Oder der Importeur kann eine Verbindung (z.B. WebDAV oder http) zur Commerce-Engine herstellen.
Das integrierte System unterstützt die folgenden Rollen, um die Daten zu verwalten:
Produktdatenverwaltung (PIM)-Benutzer, der Folgendes verwaltet:
Autor/Marketingmanager, der Folgendes verwaltet:
Surfer/Käufer, die:
Der tatsächliche Ort kann je nach Implementierung unterschiedlich ausfallen (z. B. allgemein oder mit einer eCommerce-Engine):
Durch die Unterscheidung der folgenden beiden Kategorien können Sie deutliche URLs mit bedeutungsvoller Struktur erstellen (Bäume von cq:Page
-Knoten und daher sehr ähnlich der klassischen Inhaltsverwaltung in AEM):
*Struktur *Kategorien
Die Kategorie, die Was ist ein Produkt definiert; Beispiel:
/products/mens/shoes/sneakers
** Marketingkategorien
Alle anderen Kategorien eines Produkts können zu gehören; Beispiel:
/special-offers/christmas/shoes
)
Um Ihr Produkt zu beschreiben und zu verwalten, speichern Sie viele Daten zu ihm.
Produktdaten können:
direkt in AEM verwaltet werden (allgemein)
in der eCommerce-Engine verwaltet und in AEM bereitgestellt werden
Je nach Datentyp ist er bei Bedarf synchronisiert oder wird direkt aufgerufen. Beispielsweise werden bei jeder Seitenanforderung hochgradig schwankende und wichtige Daten wie Produktpreise von der E-Commerce-Engine abgerufen, um sicherzustellen, dass sie immer auf dem neuesten Stand sind.
In jedem Fall können Sie die Produktdaten nach der Eingabe bzw. dem Import in AEM über die Produktekonsole einsehen. Hier finden Sie in der Karten- und der Listenansicht eines Produkts u. a. folgende Informationen:
Sie können auch Informationen zu Produktvarianten für die entsprechenden Produkte speichern. Beispielsweise werden bei Bekleidungsartikeln die unterschiedlichen angebotenen Farben als Varianten gespeichert:
Welche individuellen Attribute zu jedem Produkt gespeichert werden, hängt möglicherweise von der genutzten eCommerce-Engine und Ihrer AEM-Implementierung ab. Sie sind entsprechend verfügbar, wenn Sie die Produktseiten anzeigen und/oder Produktdaten bearbeiten. Folgende Attribute gibt es unter anderem:
Bild
Ein Bild des Produkts.
Titel
Der Produktname.
Beschreibung
Eine Textbeschreibung des Produkts.
Tags
Tags, die zum Gruppieren verwandter Produkte verwendet werden.
Standard-Asset-Kategorie
Eine Standard-Kategorie für Assets.
ERP-Daten
Informationen zur Unternehmensressourcenplanung (ERP).
SKU
Angaben zur Bestandsbuchhaltung (SKU).
Farbe
Größe
Preis
Der Stückpreis des Produkts.
Zusammenfassung
Eine Zusammenfassung der Produktfunktionen.
Funktionen
Genauere Details zu den Produktfunktionen.
Sie können eine Reihe an Assets für einzelne Produkte speichern. Dazu gehören in der Regel Bilder und Videos.
In einem Katalog werden Produktdaten zusammengestellt, um die Verwaltung zu vereinfachen und die Darstellung für die Käufer übersichtlich zu gestalten. Häufig wird ein Katalog nach Attributen wie Sprache, geografische Region, Marke, Saison, Hobby, Sport usw. strukturiert.
AEM unterstützt Produktinhalte in mehreren Sprachen. Beim Anfordern von Daten ruft das Integrationsframework die Sprache aus der aktuellen Struktur ab (z. B. en_US
für Seiten unter /content/geometrixx-outdoors/en_US
).
Bei einem mehrsprachigen Speicher können Sie Ihren Katalog für jeden Sprachbaum einzeln importieren (oder ihn mit MSM kopieren).
Ähnlich wie bei Sprachen müssen multinationale Unternehmen auch mehrere Marken unterstützen.
Sie können Tags auch nutzen, um Produkte in einem Katalog zusammenzustellen. Dieser Ansatz bietet sich für dynamischere Kataloge an.
Je nach Implementierung können Sie die Produktdaten für Ihren Basiskatalog in AEM aus folgenden Quellen importieren:
Weitere Änderungen der Produktdaten sind nötig für:
Nach dem anfänglichen Import sind Änderungen an den Produktdaten unvermeidbar.
Wenn Sie eine eCommerce-Engine verwenden, werden die Daten dort verwaltet und müssen in AEM verfügbar sein. Diese Produktdaten müssen nach Aktualisierungen synchronisiert werden.
Dies ist abhängig vom Datentyp:
Eine regelmäßige Synchronisierung wird zusammen mit einem Daten-Feed der Änderungen genutzt.
Zusätzlich können Sie bestimmte Aktualisierungen für ein Express-Update auswählen.
Höchst volatile und wichtige Daten wie Produktdaten werden beispielsweise bei jeder Seitenabfrage von der eCommerce-Engine abgerufen, damit sie jederzeit aktuell sind.
Das Importieren eines großen Katalogs mit einer großen Anzahl an Produkten (in der Regel mehr als 100.000) aus einer eCommerce-Engine (PIM) kann wegen der hohen Anzahl an Knoten das System beeinträchtigen. Auch die Autoreninstanz kann sich verlangsamen, wenn die Produkte mit Assets (wie Produktbildern) verknüpft sind. Das liegt daran, dass die Nachbearbeitung dieser Assets rechen- und speicherintensiv ist.
Es gibt verschiedene Möglichkeiten, diese Probleme zu umgehen:
Wenn ein JCR-Knoten über viele direkte untergeordnete Knoten (z. B. mind. 1.000) verfügt, werden Buckets (Phantomordner) benötigt, um sicherzustellen, dass die Leistung nicht beeinträchtigt wird. Sie werden beim Importvorgang entsprechend einem Algorithmus erzeugt.
Diese Buckets werden in Form von Phantomordnern in die Katalogstruktur eingeführt. Sie können sie aber so konfigurieren, dass sie in den öffentlichen URLs nicht sichtbar sind.
Dieses Szenario sieht vor, dass zwei Autoreninstanzen eingerichtet werden:
Übergeordnet Autoreninstanz
Importiert Produktdaten von PIM, bei denen die Nachbearbeitung für die Asset-Pfade deaktiviert ist.
Dedizierte DAM-Autoreninstanz
Importiert und verarbeitet Produkt-Assets aus dem PIM und repliziert diese dann zur Verwendung zurück zur Übergeordnet Authoring-Instanz.
Wenn Produkte keine Assets (Bilder) enthalten, die importiert werden müssen, können Sie die Produktdaten importieren, ohne von der Asset-Nachbearbeitung beeinträchtigt zu werden.
Leistungstests müssen bei AEM eCommerce-Implementierungen in Erwägung gezogen werden:
Autor-Umgebung:
Die Aktivität im Hintergrund (z. B. beim Import) kann gleichzeitig mit der normalen Aktivität des Benutzers (z. B. bei der Seitenbearbeitung) erfolgen. Selbst wenn die Front-End-Leistung (im Allgemeinen) eine höhere Priorität erhält, kann eine schlechte Leistung, die Online-Autoren erkennen, zu Frustration führen, die eine Go-Live-Entscheidung blockieren kann.
Umgebung der Veröffentlichung:
Die Replikation ist ein entscheidender Prozess, um sicherzustellen, dass die Inhalte schnell und zuverlässig veröffentlicht werden. Dies kann dadurch beeinflusst werden, wie der Autor die Inhalte gruppiert, die veröffentlicht werden sollen.
Front-End:
Die Mischung aus Front-End- und Cache-Ausfällen kann möglicherweise zu Leistungsüberraschungen führen. Durch Tests können diese Probleme verhindert werden.
Beachten Sie, dass für diesen Leistungstest Kenntnisse und Analysen des Ziels erforderlich sind:
Inhaltsvolumen
Benutzeraktivität:
Hintergrundprozesse
Wartungsanforderungen (Sicherung, Tar-PM-Optimierung, Datenspeicherbereinigung usw.)
Beachten Sie bei allen Implementierungen die folgenden Punkte:
Da die Anzahl an Produkten, SKUs und Kategorien sehr hoch ausfallen kann, versuchen Sie, so wenig Knoten wie möglich für die Modellierung der Inhalte zu verwenden.
Je mehr Knoten Sie nutzen, desto flexibler sind Ihre Inhalte (z. B. ParSys). Es ist aber immer Abwägungssache: Benötigen Sie (standardmäßig) individuelle Flexibilität, wenn Sie (beispielsweise) 30.000 Produkte bearbeiten?
Vermeiden Sie Duplikate, so gut es geht (siehe Lokalisierung), und berücksichtigen Sie, wenn sich Duplikate nicht umgehen lassen, zu wie vielen Knoten die Duplizierung führen wird.
Versuchen Sie, Ihre Inhalte so oft wie möglich mit Tags zu kennzeichnen, um die Abfrage zu optimieren.
Beispiel:
/content/products/france/fr/shoe/reebok/pump/46 SKU
sollte ein Tag pro Inhaltsebene haben (d.h. Land, Sprache, Kategorie, Marke, Produkt). Suchen nach
//element(*,my:Sku)[@country=’france’ and @language=’fr’
und
@category=’shoe’ and @brand=’reebok’ and @product=’pump’]
wird drastisch schneller als die Suche nach
/jcr:root/content/france/fr/shoe/reebok/pump/element(*,my:Sku)
Planen Sie für Ihren technischen Stack faktorisierte Inhaltszugriffsmodelle und Dienste. Dies ist allgemein eine bewährte Vorgehensweise, in diesem Fall aber sogar noch wichtiger, da Sie bei Optimierungsphasen Anwendungscaches für Daten hinzufügen können, die häufig gelesen werden (und mit denen Sie nicht den Bundle-Cache füllen möchten).
Beispielsweise ist die Attributverwaltung oft gut für das Caching geeignet, da sie Daten betrifft, die durch das Importieren von Produkten aktualisiert werden.
Ziehen Sie die Nutzung von Proxyseiten in Erwägung.
Auf Katalogsbereichsseiten finden Sie zum Beispiel:
Produktseiten bieten umfassende Informationen zu den einzelnen Produkten. Dynamische Aktualisierungen von externen Quellen werden auch widergespiegelt, z. B. Preisänderungen, die auf der eCommerce-Engine erfolgt sind.
Produktseiten sind AEM-Seiten, die die Produkt-Komponente nutzen, beispielsweise in der Vorlage Commerce-Produkt:
Die Produkt-Komponente bietet:
Anhand dieser Daten kann der Käufer folgende Optionen auswählen, wenn er einen Artikel zum Warenkorb hinzufügt:
Dabei handelt es sich um AEM-Seiten, die in erster Linie statische Informationen anzeigen, beispielsweise eine Einleitung und eine Übersicht mit Links zu den dazugehörigen Produktseiten.
Die Produkt-Komponente können Sie zu jeder Seite mit einer übergeordneten Seite hinzufügen, welche die benötigten Metadaten bereitstellt (d. h. die Pfade zu cartPage
und cartObject
). Bei der Demo-Website, Geometrixx Outdoors, ist dies UserInfo.jsp
.
Sie können die Produkt-Komponente auch an Ihre individuellen Anforderungen anpassen.
Mit Proxyseiten können Sie die Struktur des Repositorys vereinfachen und den Speicher für große Kataloge optimieren.
Beim Erstellen eines Katalogs werden zehn Knoten pro Produkt eingesetzt, um individuelle Komponenten für jedes Produkt bereitzustellen, die Sie in AEM aktualisieren und anpassen können. Diese große Anzahl an Knoten kann problematisch werden, wenn Ihr Katalog mehrere hundert oder gar tausend Produkte enthält. Um diese Schwierigkeiten zu vermeiden, können Sie bei der Erstellung Ihres Katalogs Proxyseiten verwenden.
Proxy-Seiten verwenden eine Zwei-Knoten-Struktur ( cq:Page
und jcr:content
), die keinen der eigentlichen Produktinhalte enthält. Der Inhalt wird zur Anforderungszeit durch Verweis auf die Produktdaten und die Vorlagenseite generiert.
Dabei gilt allerdings: Sie können die Produktdaten nicht in AEM anpassen. Eine Standardvorlage (für Ihre Website definiert) wird verwendet.
Es werden keine Probleme auftreten, wenn Sie einen großen Katalog ohne Proxyseiten importieren.
Die Konversion von einer Methode zur anderen ist jederzeit möglich. Sie können auch einen Teilbereich Ihres Katalogs umwandeln.
Gutscheine sind eine bewährte Methode für Preisnachlässe, um Käufer zu einem Kauf zu animieren und/oder die Treue von Kunden zu belohnen.
Gutscheine umfassen:
Externe Commerce-Engines können ebenfalls Gutscheine bereitstellen.
In AEM:
Ein Gutschein ist eine seitenbasierte Komponente, die mit der Websites-Konsole erstellt und bearbeitet wird.
Die Gutschein-Komponente bietet:
Gutscheine haben keine eigenen Datums-/Zeitangaben für Aktivierung und Deaktivierung, sondern nutzen die der übergeordneten Kampagnen.
AEM verwendet den Begriff Gutschein, der ein Synonym zu Coupon ist.
Mit Promotions können Sie, in Verbindung mit Gutscheinen, Szenarien wie folgende umsetzen:
Promotions werden in der Regel nicht von Produktinformationsmanagern, sondern von Marketingmanagern verwaltet:
Eine Promotion ist eine seitenbasierte Komponente, die mit der Websites-Konsole erstellt und bearbeitet wird. "
Promotions umfassen:
Sie können Promotions mit einer Kampagne verbinden, um ihre Datums-/Zeitangaben für Aktivierung und Deaktivierung zu definieren.
Sie können Promotions mit einem Erlebnis verbinden, um ihre Segmente zu definieren.
Promotions, die nicht mit einem Erlebnis verbunden sind, starten nicht von selbst, können aber durch einen Gutschein ausgelöst werden.
Die Promotion-Komponente umfasst:
In AEM sind die Promotions auch in das Kampagnen-Management integriert:
Eine Promotion kann entweder in einem Erlebnis oder direkt in der Kampagne erfasst werden:
Wenn eine Promotion in einem Erlebnis erfasst ist, kann sie automatisch auf ein Zielgruppensegment angewendet werden.
Beispiel: Auf der Website geometrixx-outdoors:
/content/campaigns/geometrixx-outdoors/big-spender/ordervalueover100/free-shipping
in einem Erlebnis enthalten ist, und wird daher automatisch ausgelöst, sobald das Segment ( ordervalueover100
) aufgelöst wird.
Wenn eine Promotion nicht in einem Erlebnis angezeigt wird (also nur in der Kampagne), kann sie nicht automatisch auf eine Zielgruppe angewendet werden. Es kann jedoch trotzdem ausgelöst werden, wenn der Käufer einen Gutschein in den Warenkorb legt und dieser Gutschein auf die Promotion verweist.
Beispielsweise die Promotion:
/content/campaigns/geometrixx-outdoors/article/10-bucks-off
außerhalb eines Erlebnisses liegt und daher nie automatisch ausgelöst wird (d. h.: basierend auf der Segmentierung). Sie wird jedoch von den Gutscheinen referenziert, die in mehreren Erlebnissen innerhalb der Kampagne des Artikels enthalten sind. Die Eingabe dieser Gutscheincodes in den Warenkorb führt zu einer Promotion-Auslösung.
hybris promotions und hybris vouchers decken alle Aspekte ab, die sich auf den Warenkorb auswirken und mit der Preisfestlegung in Verbindung stehen. Promotionspezifische Marketinginhalte (wie Banner) sind nicht Teil der hybris-Promotion.
Wenn sich ein Kunde registriert, müssen die Daten seines Kontos zwischen AEM und der eCommerce-Engine synchronisiert werden. Sensible Daten werden separat gespeichert, die Profile sind jedoch freigegeben:
Der genaue Mechanismus hängt vom Szenario ab:
Das Benutzerkonto ist auf beiden Systemen vorhanden:
Das Benutzerkonto ist nur in AEM vorhanden:
Das Benutzerkonto ist nur in der eCommerce-Engine vorhanden:
Bei Verwendung einer eCommerce-Engine speichert AEM nur die Konto-ID und das Kennwort (optional eine Benutzergruppe). Alle anderen Daten werden in der eCommerce-Engine gespeichert.
Bei Nutzung einer eCommerce-Engine müssen Sie sicherstellen, dass Konten, die für Benutzer erstellt wurden, die sich bei einer AEM-Instanz anmelden, auf anderen AEM-Instanzen repliziert werden, die mit dieser Engine kommunizieren (z. B. über Workflows).
Andernfalls versuchen diese anderen AEM-Instanzen ebenfalls, Konten für dieselben Benutzer in der Engine zu erstellen. Diese Aktionen schlagen fehl und die Engine gibt DuplicateUidException
aus.
Häufig muss sich ein Käufer anmelden, um Zugriff zum Warenkorb zu erhalten. Dafür ist eine Registrierung (Konto erstellen) nötig, damit ein kundenspezifisches Konto erstellt werden kann.
Auch ein anonymer Warenkorb und die anonyme Bezahlung werden unterstützt.
Nach der Registrierung kann sich der Kunde bei seinem Konto anmelden, damit seine Aktionen nachverfolgt und seine Bestellungen bearbeitet werden.
Single Sign-On wird bereitgestellt, damit Benutzer beim AEM- und beim eCommerce-System bekannt sind, ohne sich zweimal anmelden zu müssen.
Transaktionsdaten von der eCommerce-Engine werden mit personenbezogenen Daten zum Käufer kombiniert. AEM nutzt einige dieser Daten als Profildaten. Eine Formularaktion in AEM schreibt Daten zurück in die eCommerce-Engine.
Es gibt eine Seite, auf der Sie Ihre Kontodaten leicht verwalten können. Sie können darauf zugreifen, indem Sie auf Mein Konto oben auf einer geometrixx-Seite klicken oder indem Sie zu /content/geometrixx-outdoors/en/user/account.html
navigieren.
Ihre Website muss zahlreiche Adressen speichern, darunter Liefer-, Rechnungs- und Alternativanschriften. Dazu können Sie Formulare basierend auf dem Standardformat der Adressen nutzen oder die Adressbuch-Komponente von AEM.
Mit der Adressbuch-Komponente können Sie:
Sie können auswählen, welche Adresse Sie als Standard festlegen möchten.
Die Adressbuchkomponente kann über die Seite Mein Konto erreicht werden, indem Sie auf Adressbuch klicken oder zu /content/geometrixx-outdoors/en/user/account/address-book.html
navigieren.
Klicken Sie auf Neue Adresse hinzufügen…, um eine neue Adresse zum Adressbuch hinzuzufügen. Ein Formular wird geöffnet. Geben Sie die Adressdaten ein und klicken Sie dann auf Adresse hinzufügen.
Sie können mehrere Adressen zum Adressbuch hinzufügen.
Das Adressbuch kommt zum Einsatz, wenn Sie den Warenkorb bezahlen:
Adressen bleiben unter user_home/profile/addresses
erhalten.
Für Alison Parker wäre es beispielsweise unter /home/users/geometrixx/aparker@geometrixx.info/Profil/address
Sie können auswählen, welche Adresse Sie als Standard festlegen möchten. Diese Information wird im Käuferprofil gespeichert, nicht zusammen mit der Anschrift. Die Profil-Eigenschaft address.default
wird mit dem Pfad der ausgewählten Adresse für den Wert festgelegt.
Die eCommerce-Engine bestimmt mithilfe des Kontexts (also im Wesentlichen der Käuferdaten) den gespeicherten Preis und gibt die korrekten Daten an AEM zurück.
Beim Einkaufen durchsucht der Käufer die Produktseiten und legt die ausgewählten Artikel in den Warenkorb. Wenn er zur Kasse wechselt, kann er eine Bestellung aufgeben.
Ein anonymer Käufer kann:
Je nach Konfiguration Ihrer Instanz ist vor dem Bezahlen die Angabe von Adressdaten oder eine Kundenregistrierung erforderlich.
Ein registrierter Käufer kann:
Der Warenkorb umfasst:
einen Überblick über die ausgewählten Artikel
Links zu den Produktseiten für die ausgewählten Artikel
die Fähigkeit:
Der Warenkorb wird je nach verwendeter Engine gespeichert:
In jedem Fall bleiben die Artikel im Warenkorb (und können wiederhergestellt werden), wenn sich der Käufer ab- und wieder anmeldet (allerdings nur auf demselben Rechner/im selben Browser). Beispiel:
suchen Sie nach anonymous
und fügen Sie dem Warenkorb Produkte hinzu.
anmelden als Allison Parker
- ihr Warenkorb ist leer
Fügen Sie Produkte zu ihrem Warenkorb hinzu.
Abmelden - der Warenkorb zeigt die Produkte für anonymous
an
erneut als Allison Parker
anmelden - ihre Produkte werden wiederhergestellt
Ein anonymer Warenkorb kann nur auf demselben Rechner/im selben Browser wiederhergestellt werden.
Es wird nicht empfohlen, die Wiederherstellung des Einkaufswageninhalts mit dem admin
-Konto zu testen, da dies mit dem admin
-Konto der eCommerce-Engine (z. B. hybris) in Konflikt geraten kann.
Sie können hybris so konfigurieren, dass ausstehende Warenkörbe nach einem festgelegten Zeitraum gelöscht werden.
Vor dem Bezahlen werden etwaige Preisänderungen (in beiden Systemen) widergespiegelt.
Je nach Implementierung werden die Daten zu einer Bestellung entweder in der eCommerce-Engine oder in AEM gespeichert; diese Daten werden von AEM gerendert.
Es werden unterschiedliche Daten gespeichert, beispielsweise:
Auftrags-ID
Die Referenznummer für die Bestellung.
Platziert
Das Datum, an dem die Bestellung aufgegeben wurde.
Status
Der Status der Bestellung z. B. „versendet“
Währung
Die Währung der Bestellung.
Inhaltselemente
Eine Liste der bestellten Artikel.
Zwischensumme
Die Gesamtkosten der bestellten Artikel.
Steuer
Der Betrag der auf die Bestellung geschuldeten Steuern.
Versand
Versandkosten.
Insgesamt
Gesamtwert der Bestellung; bestellte Artikel, Steuern und Versandkosten.
Rechnungsadresse
Anschrift, an die die Rechnung zu senden ist.
Zahlungs-Token
Die Zahlungsmethode.
Zahlungsstatus
Status der Zahlung.
Lieferadresse
Die Anschrift, an die die Waren versandt werden sollen.
Versandart
Versandart; zum Beispiel Land, Meer oder Luft.
Nachverfolgungsnummer
Eine beliebige von der Firma verwendete Verfolgungsnummer.
Nachverfolgungslink
Der Link, der zur Nachverfolgung der Bestellung während des Versands verwendet wird.
Welche Felder im Assistenten „Auftrag erstellen“ verwendet werden, hängt davon ab, ob für den Ort eine Touch-optimierte Strukturvorlage definiert ist. Im generischen Beispiel ist dies zu finden unter:
/etc/scaffolding/geometrixx-outdoors/order/jcr:content/cq:dialog
Wenn eine Bestellung in AEM gespeichert wird, zeigt die Bestellungs-Konsole Folgendes für jede Bestellung an:
Nachdem sie eine Bestellung aufgegeben haben, kehren Käufer häufig zurück, um:
Nach dem Erhalt der Lieferung möchten Käufer möglicherweise die Bestellungen einsehen, die sie in einem bestimmten Zeitraum aufgegeben haben.
Die Erfüllung und die Nachverfolgung von Bestellungen werden in der Regel von der eCommerce-Engine verwaltet. Die Informationen können AEM mit der Bestellverlaufskomponente angezeigt werden, die alle relevanten Details einschließlich der Gutscheine und Promotions anzeigt. Beispiel:
Die Kasse wird mit standardmäßigen AEM-Formularen implementiert. Damit kann der Marketingmanager das Erlebnis mit Marketinginhalten anpassen.
Das eCommerce-System verwaltet dann den Bezahlvorgang mit Daten aus den AEM-Formularen.
Zahlungsdaten, einschließlich Kreditkartendaten, werden häufig von der eCommerce-Engine verwaltet. AEM leitet solche Transaktionsdaten an die Engine weiter (von wo aus sie dann zu einem Zahlungsdienstleister weitergeleitet werden).
Die Einhaltung des Payment Card Industry (PCI)-Standards ist gewährleistet.
Die Bestellung wird auf dem Bildschirm bestätigt und lässt sich mit der Bestellungsnachverfolgung nachverfolgen.
Da AEM Standardseiten für Produkte nutzt, können Sie mit der Standard-Such-Komponente eine Suchseite erstellen.
Wenn Sie eine tiefergreifende Implementierung benötigen, können Sie:
CommerceService
implementieren und dann die eCommerce-Such-Komponente auf der Suchseite nutzenBei Verwendung einer eCommerce-Engine kann die eCommerce-Suchschnittstelle vollständig in die eCommerce-Suchmaschinenlösung implementiert werden, sodass Sie die vordefinierte eCommerce-Suchkomponente verwenden können. Mit der Facettensuche können Sie JCR und/oder die Engine durchsuchen: