Concepten

Het integratiekader biedt de mechanismen en componenten voor:

• verbinding met een eCommerce-motor
• gegevens in AEM
• die gegevens weergeven en de reacties van de winkels verzamelen
• transactiedetails retourneren
• zoeken naar gegevens van beide systemen

Dit betekent dat:

• Winkelaars kunnen zich registreren en winkelen zonder te wachten.
• De kopers zullen de prijswijzigingen onmiddellijk zien.
• De producten kunnen worden toegevoegd zoals vereist.

Om de werking te optimaliseren, richten zowel AEM als de eCommerce-motor zich op hun eigen expertisegebied. De informatie wordt in realtime tussen beide overgedragen; bijvoorbeeld:

• AEM kan:

  • Verzoek:

    • Productinformatie van de eCommerce-engine.

  • Geef:

    • Weergaven van gebruikers voor productinformatie, winkelwagentje en kassa.
    • Winkelwagentje en afrekeninformatie naar de eCommerce-engine.
    • SEO (Search Engine Optimization, optimalisatie van zoekmachines).
    • communautaire functionaliteit.
    • Niet-gestructureerde marketinginteracties.

• eCommerce-engine kan:

  • Geef:

    • Productinformatie uit de database.
    • Beheer van productvarianten.
    • Bestelbeheer.
    • ERP (Enterprise Resource Planning).
    • Zoek in de productinformatie.

  • Proces:

    • Het winkelwagentje.
    • De kassa.
    • Volgorde.

Een aantal uit-van-de-doos AEM componenten worden verstrekt om de integratielaag te gebruiken. Deze omvatten momenteel:

• Productinformatie
• Winkelwagentje
• Uitchecken
• Mijn account

Er zijn ook verschillende zoekopties beschikbaar.

Architectuur

Het integratieframework biedt de API, een reeks componenten om functionaliteit te illustreren en verschillende extensies om voorbeelden van verbindingsmethoden te geven:

Het framework biedt u toegang tot functies zoals:

Implementaties

AEM eCommerce wordt geïmplementeerd met een eCommerce-motor:

• Het integratieframework voor eCommerce is ontworpen om u in staat te stellen een eCommerce-motor met AEM te integreren. De speciaal gebouwde eCommerce-engine bestuurt productgegevens, winkelwagentjes, kassa's en bestelling, terwijl AEM de campagnes voor het weergeven en op de markt brengen van gegevens beheert.

Handelsleveranciers

Wanneer het invoeren van gegevens van een handelingsmotor in uw AEM eCommerce plaats, wordt een handelsleverancier gebruikt om de importeurs van gegevens te voorzien. Eén handelsprovider kan meerdere importeurs ondersteunen.

Een handelsleverancier is AEM code die aan of wordt aangepast:

• interface aan een achterste verkoopmotor
• een handelssysteem implementeren bovenop de gegevensopslagruimte van het GCO

Er zijn momenteel twee voorbeeld-aanbieders van handel beschikbaar voor AEM:

• één voor geometrixx-hybris
• een andere voor geometrixx-generic (JCR)

Hoewel gewoonlijk zal een project hun eigen, aangepaste, handelsleverancier specifiek voor hun PIM en schema van productgegevens moeten ontwikkelen.

De ProductServicesManager onderhoudt (via OSGi) een lijst met implementaties van de interfaces ProductImporter en CatalogBluprintImporter. Deze worden vermeld in Importer/Commerce Provider dropdown gebied van de tovenaar van de Importeur (gebruikend het commerceProvider bezit als naam).

Wanneer een specifieke importeur/handelsleverancier beschikbaar is in de vervolgkeuzelijst, moeten eventuele aanvullende gegevens worden gedefinieerd (afhankelijk van het type importeur) in:

• /apps/commerce/gui/content/catalogs/importblueprintswizard/importers
• /apps/commerce/gui/content/products/importproductswizard/importers

De map onder de desbetreffende map importers moet overeenkomen met de naam van de importer. bijvoorbeeld:

• .../importproductswizard/importers/geometrixx/.content.xml

De indeling van het bronimportbestand wordt gedefinieerd door de importer. Of de importer kan een verbinding tot stand brengen (bijvoorbeeld WebDAV of http) met de commerce engine.

Rollen

Het geïntegreerde systeem voorziet voor de volgende rollen om de gegevens te handhaven:

• PIM-gebruiker (Product Information Management) die het volgende onderhoudt:

  • Productinformatie.
  • Taxonomie, categorisering, goedkeuring.
  • Werkt met beheer van digitale middelen.
  • Prijsstelling - vaak komt dit uit een ERP-systeem en wordt dit niet expliciet in het handelssysteem gehandhaafd.

• Auteur/marketingmanager die het volgende onderhoudt:

  • Inhoud voor alle kanalen op de markt brengen.
  • Promoties.
  • Vouchers.
  • Campagnes.

• Surfer/shopper die:

  • Bekijk uw productinformatie.
  • Hiermee plaatst u artikelen in het winkelwagentje.
  • Controleert hun bestellingen.
  • Voldoen van bestelling verwacht.

Hoewel de daadwerkelijke plaats van uw implementatie kan afhangen; bijvoorbeeld generiek of met een eCommerce-engine:

Producten

Productgegevens versus marketinggegevens

Structuur- en marketingcategorieën

Als de volgende twee categorieën kunnen worden onderscheiden, kunt u zo duidelijke URL's met een zinvolle structuur (bomen van cq:Page knopen) maken en daarom, zeer dicht aan het beheer van de klassieke AEM inhoud):

• *Structurele *categorieën

  De categoriestructuur die wat is een product bepaalt; bijvoorbeeld:

  /products/mens/shoes/sneakers

• ** Marketingcategorieën

  Alle andere categorieën a product kunnen tot behoren; bijvoorbeeld:

  /special-offers/christmas/shoes)

Productgegevens

Als u uw product wilt portretteren en beheren, wilt u een reeks gegevens over het product bewaren.

Productgegevens kunnen zijn:

• rechtstreeks in AEM (algemeen) worden onderhouden.

• in de eCommerce-engine worden onderhouden en in AEM beschikbaar worden gesteld.

  Afhankelijk van het gegevenstype is het gesynchroniseerd zonodig, of direct betreden; bijvoorbeeld, worden de hoogst vluchtige en kritieke gegevens zoals productprijzen teruggewonnen van de e-commerce motor op elke paginaverzoek om ervoor te zorgen dat zij altijd bijgewerkt zijn.

In beide gevallen, wanneer de productgegevens zijn ingegaan/in AEM ingevoerd kan het van de console van Producten worden gezien. Hier wordt op de kaart en de lijstweergaven van een product informatie weergegeven zoals:

• de afbeelding
• de SKU-code
• wanneer laatst gewijzigd

Productvarianten

Voor geschikte producten kan ook informatie over varianten worden bewaard. Voor kledingstukken worden de verschillende beschikbare kleuren bijvoorbeeld als varianten bewaard:

Productkenmerken

De afzonderlijke kenmerken van elk product kunnen afhankelijk zijn van de eCommerce-engine die wordt gebruikt en van uw AEM implementatie. Deze zijn (waar van toepassing) beschikbaar bij het bekijken van productpagina's en/of het uitgeven van productinformatie en kunnen omvatten:

• Afbeelding

  Een afbeelding van het product.

• Titel

  De productnaam.

• Beschrijving

  Een tekstuele beschrijving van het product.

• Tags

  Tags die worden gebruikt om verwante producten te groeperen.

• Standaardelementcategorie

  Een standaardcategorie voor elementen.

• ERP-gegevens

  ERP-informatie (Enterprise Resource Planning).

  • SKU

    Informatie over de bewaareenheid (SKU).

  • Kleur

  • Grootte

  • Prijs

    De eenheidsprijs van het product.

• Samenvatting

  Een samenvatting van de productkenmerken.

• Functies

  Meer informatie over de productfuncties.

Productelementen

Voor afzonderlijke producten kan een selectie van activa worden aangehouden. Dit zijn meestal afbeeldingen en video's.

Catalogi

In een catalogus worden productgegevens gegroepeerd voor zowel beheer als representatie voor de klant. Een catalogus is vaak gestructureerd op basis van onder andere taal, geografisch gebied, merk, seizoen, hobby, sport.

Catalogusstructuur

Catalogi in meerdere talen

AEM ondersteunt productinhoud in meerdere talen. Wanneer gegevens worden aangevraagd, haalt het integratieframework de taal op uit de huidige structuur (bijvoorbeeld en_US voor pagina's onder /content/geometrixx-outdoors/en_US).

Voor een meertalige opslag, kunt u uw catalogus voor elke taalboom individueel invoeren (of het kopiëren door middel van MSM).

Catalogi voor meerdere merken

Net als bij talen kunnen grote multinationale ondernemingen meerdere merken in aanmerking nemen.

Catalogi op tags

Met labels kunt u ook producten groeperen in een catalogus. Deze kunnen worden gebruikt voor meer dynamische catalogi, zoals seizoensaanbiedingen.

Catalogusinstelling (eerste import)

Afhankelijk van uw implementatie kunt u de vereiste productgegevens voor uw basiscatalogus importeren in AEM van:

• een CSV-bestand (voor de algemene implementatie)
• de eCommerce-motor

Catalogusonderhoud (gegevenssynchronisatie)

Verdere wijzigingen van de productgegevens zijn onvermijdelijk:

• voor de generische implementatie kunnen deze worden beheerd met de producteditor
• wanneer het gebruiken van een eCommerce motor moeten de veranderingen worden gesynchroniseerd

Gegevenssynchronisatie met een eCommerce-engine (aan de gang)

Na de eerste import zijn wijzigingen in de productgegevens onvermijdelijk.

Bij gebruik van een eCommerce-motor worden de productgegevens daar bewaard en moeten ze in AEM beschikbaar zijn. Deze productgegevens moeten worden gesynchroniseerd wanneer updates worden uitgevoerd.

Dit kan afhankelijk zijn van het type gegevens:

• Een periodieke synchronisatie wordt gebruikt samen met een gegevensvoer van veranderingen.

  Daarnaast kunt u specifieke updates selecteren voor een express-update.

• De hoogst volatiele gegevens, zoals prijsinformatie, worden teruggewonnen van de handelingsmotor voor elk paginaverzoek, om ervoor te zorgen dat het altijd bijgewerkt is.

Catalogi - Prestaties en schalen

Het importeren van een grote catalogus met een groot aantal producten (meestal meer dan 100.000) uit een eCommerce-engine (PIM) kan het systeem beïnvloeden vanwege het grote aantal knooppunten. Het kan ook de ontwerpinstantie vertragen als de producten bijbehorende elementen (zoals productafbeeldingen) hebben. Dit komt door het feit dat de naverwerking van deze middelen CPU- en geheugenintensief is.

U kunt kiezen uit verschillende strategieën om deze problemen op te lossen:

• Bucketing - om rekening te houden met het grote aantal knooppunten
• Middelen na verwerking naar een specifieke instantie verplaatsen
• Alleen productgegevens importeren
• Throttling importeren en opslaan in batch
• Prestatietesten
• Prestaties - Diversen

Emmertje

Als een JCR-knooppunt veel directe onderliggende knooppunten heeft (bijvoorbeeld 1000 en meer), zijn emmers (fantoommappen) vereist om ervoor te zorgen dat de prestaties niet worden beïnvloed. Deze worden gegenereerd volgens een algoritme bij het importeren.

Deze emmers hebben de vorm van fantoommappen die aan uw catalogusstructuur worden geïntroduceerd, maar kunnen worden gevormd zodat zij niet duidelijk in openbare URLs zijn.

Middelen na verwerking naar een specifieke instantie verplaatsen

In dit scenario worden twee auteur-instanties ingesteld:

1. Master instantie van auteur

   Hiermee importeert u productgegevens van PIM, waarop naverwerking voor de assetpaden is uitgeschakeld.

2. Speciale DAM-auteurinstantie

   Importeert en nabewerkt productactiva van PIM, en herhaalt deze dan terug naar de master auteurinstantie voor gebruik.

Alleen productgegevens importeren

Als producten geen te importeren elementen (afbeeldingen) bevatten, kunt u de productgegevens importeren zonder dat dit wordt beïnvloed door de naverwerking van het element.

Prestatietesten

Bij AEM eCommerce-implementaties moet rekening worden gehouden met prestatietests:

• Auteursomgeving:

  Achtergrondactiviteiten (bijvoorbeeld import) kunnen tegelijkertijd met normale gebruikersactiviteiten plaatsvinden (bijvoorbeeld paginabewerking) en zelfs als front-end prestaties (in het algemeen) een hogere prioriteit krijgen, kunnen slechte prestaties van online auteurs leiden tot frustratie die een go-live beslissing kan blokkeren.

• Publicatieomgeving:

  Replicatie is een belangrijk proces om ervoor te zorgen dat de inhoud snel en betrouwbaar wordt gepubliceerd. Dit kan worden beïnvloed door de manier waarop de auteur de te publiceren inhoud groepeert.

• Voorkant:

  De combinatie van front-end en cache-invalidaties kan mogelijk leiden tot prestatieverrassingen. Door te testen voorkomt u deze problemen.

Houd er rekening mee dat voor deze prestatietests kennis en analyse van uw doel vereist is:

• Inhoudsvolumes

  • Assets
  • Gelokaliseerde, I18-producten en SKU's

• Gebruikersactiviteit:

  • Bulkuitgave
  • Bulkpublicatie
  • Intensieve zoekverzoeken

• Achtergrondprocessen

  • Invoer
  • Synchronisatie-updates (bijvoorbeeld prijzen)

• Onderhoudsvereisten (back-up, optimalisatie van Tar PM, opschonen van datastore, enz.)

Prestaties - Diversen

Voor alle implementaties kan rekening worden gehouden met de volgende punten:

• Aangezien het product, de bewaareenheden en de categorieën talrijk kunnen zijn, probeer om het minste aantal knopen te gebruiken mogelijk om de inhoud te modelleren.

  Hoe meer knooppunten u hebt, des te flexibeler uw inhoud is (bijvoorbeeld parsys). Maar alles is een compromis en hebt u (standaard) individuele flexibiliteit nodig bij het manipuleren (bijvoorbeeld) van 30K-producten?

• Vermijd dubbel zoveel als u kunt (zie lokalisatie), of wanneer u doet, denk over hoeveel knopen uw duplicatie tot zal leiden.

• Probeer de inhoud zo veel mogelijk van tags te voorzien om de query-optimalisatie voor te bereiden.

  Bijvoorbeeld:

  /content/products/france/fr/shoe/reebok/pump/46 SKU

  moet één tag per inhoudsniveau hebben (d.w.z. land, taal, categorie, merk, product). Zoeken naar

  //element(*,my:Sku)[@country=’france’ and @language=’fr’

  and

  @category=’shoe’ and @brand=’reebok’ and @product=’pump’]

  wordt veel sneller dan zoeken naar

  /jcr:root/content/france/fr/shoe/reebok/pump/element(*,my:Sku)

• In uw technische stapel, plan zeer gefactoriseerde inhoudstoegangsmodel en de diensten. Dit is een algemene beste praktijk, maar is nog belangrijker, aangezien u, in optimalisatiefasen, toepassingsgeheime voorgeheugens voor gegevens kunt toevoegen die zeer vaak worden gelezen (en dat u niet de bundelgeheime voorgeheugen met wilt vullen).

  Bijvoorbeeld, is het attributenbeheer zeer vaak een goede kandidaat voor caching aangezien het gegevens betreft die door de invoer van producten worden bijgewerkt.

• Overweeg het gebruik van proxypagina's.

Sectiepagina's catalogus

De secties van de Catalogus verstrekken u, bijvoorbeeld:

• een inleiding (afbeelding en/of tekst) op de categorie; dit kan ook worden gebruikt voor banners en teasers om speciale aanbiedingen te promoten
• links naar de afzonderlijke producten van die categorie
• links naar de andere categorieën

Productpagina's

Productpagina's bevatten uitgebreide informatie over afzonderlijke producten. Dynamische updates vanaf worden ook weerspiegeld; bijvoorbeeld prijswijzigingen die zijn geregistreerd op de eCommerce-engine.

Productpagina's zijn AEM pagina's die gebruikmaken van de component Product; bijvoorbeeld binnen de sjabloon Commerce Product:

De component Product biedt:

• Algemene productinformatie; inclusief tekst en afbeeldingen.
• Prijsstelling; Dit wordt gewoonlijk teruggewonnen van de eCommerce motor telkens als de pagina wordt getoond/verfrist.
• Informatie over productvarianten; bijvoorbeeld kleur en grootte.

Met deze informatie kan de verkoper het volgende selecteren wanneer hij een item aan zijn mandje toevoegt:

• Kleur- en formaatvarianten
• Aantal

Landingspagina's product

Dit zijn AEM pagina's die hoofdzakelijk statische informatie verstrekken; bijvoorbeeld een inleiding en een overzicht met koppelingen naar de onderliggende productpagina's.

Productcomponent

De Product component kan aan om het even welke pagina met een ouderpagina worden toegevoegd die de vereiste meta-gegevens (d.w.z. de wegen aan cartPage en cartObject) levert. In de demonstratielocatie, Geometrixx Outdoors, wordt dit geleverd door UserInfo.jsp.

De Product component kan ook worden aangepast volgens uw individuele vereisten.

Proxypagina's

Proxypagina's worden gebruikt om de structuur van de opslagplaats te vereenvoudigen en de opslagcapaciteit voor grote catalogi te optimaliseren.

Bij het maken van een catalogus worden tien knooppunten per product gebruikt, omdat dit afzonderlijke componenten bevat voor elk product dat u binnen AEM kunt bijwerken en aanpassen. Dit grote aantal knooppunten kan een probleem worden als uw catalogus honderden of zelfs duizenden producten bevat. Om problemen te voorkomen kunt u uw catalogus maken met proxypagina's.

Proxypagina's gebruiken een structuur met twee knooppunten ( cq:Page en jcr:content) die geen van de werkelijke productinhoud bevat. De inhoud wordt op verzoek gegenereerd door te verwijzen naar de productgegevens en de sjabloonpagina.

Er is echter een compromis. U kunt de productinformatie niet aanpassen binnen AEM, wordt een standaardsjabloon (gedefinieerd voor uw site) gebruikt.

Promoties en vouchers

Vouchers

Vouchers zijn een beproefde methode om kortingen aan te bieden om klanten aan te trekken voor het maken van een aankoop en/of het belonen van de loyaliteit van de klant.

• Levering aan vouchers:

  • Een vouchercode (die door de verkoper in de winkelwagen moet worden getypt).
  • Een voucherlabel (dat moet worden weergegeven nadat de gebruiker het in de winkelwagen heeft ingevoerd).
  • Een promotiepad (dat de actie definieert die de voucher toepast).

• De motoren van de buitenlandse handel kunnen bonnen ook leveren.

In AEM:

• Een voucher is een op pagina gebaseerde component die wordt gemaakt/bewerkt met de websiteconsole.

• De Voucher-component biedt:

  • Een renderer voor voucherbeheer; hieruit blijkt welke vouchers zich momenteel in de kar bevinden .
  • De bewerkingsdialoogvensters (formulier) voor het beheren (toevoegen/verwijderen) van de vouchers.
  • De handelingen die vereist zijn voor het toevoegen/verwijderen van vouchers aan/uit de kar.

• Vouchers hebben geen eigen datum/tijd, maar gebruiken die van hun bovenliggende campagnes.

Aanbiedingen

Met promoties kunt u samen met vouchers scenario's realiseren zoals:

• Een bedrijf verstrekt douaneprijzen voor werknemers, die een handgemaakte lijst van gebruikers is.
• Langlopende klanten ontvangen kortingen op alle orders.
• Een verkoopprijs die wordt aangeboden over een welomschreven periode.
• Een klant ontvangt een voucher wanneer de vorige bestelling een bepaald bedrag overschrijdt.
• Een klant die product-X koopt, krijgt een korting op product-Y (paarproducten).

Promoties worden gewoonlijk niet onderhouden door productinformatiemanagers, maar door marketingmanagers:

• Een bevordering is een op pagina-gebaseerde component die met de console van Websites wordt gecreeerd/uitgegeven. "

• Aanbod voor promoties:

  • Een prioriteit
  • Een pad voor promotiemandschappen

• U kunt promoties verbinden met een campagne om de aan/uit-datum of -tijden te definiëren.

• U kunt promoties aan een ervaring verbinden om hun segmenten te bepalen.

• Promoties die geen verband houden met een ervaring, worden niet op zichzelf afgegaan, maar kunnen nog steeds door een Voucher worden geactiveerd.

• De component Promotie bevat:

  • renderers en dialoogvensters voor bevorderingsbeheer
  • subcomponenten voor het teruggeven en het uitgeven configuratieparameters specifiek voor de bevorderingsmanagers

In AEM zijn de bevorderingen ook geïntegreerd in Campagne Management:

• a campagne geeft de aan/uit-tijden aan
• 🔗 ** de ervaring binnen de campagne wordt gebruikt om activa (theaterpagina's, promoties, enz.) te groeperen volgens het publiekssegment dat zij aan beantwoorden

Een promotieactie kan worden uitgevoerd in een ervaring of rechtstreeks in de campagne:

• Als een bevordering in een ervaring wordt gehouden, dan kan het automatisch op een publiekssegment worden toegepast.

  In de geometrixx-outdoorvoorbeeldsite is de promotie bijvoorbeeld:

  /content/campaigns/geometrixx-outdoors/big-spender/ordervalueover100/free-shipping

  bevindt zich in een ervaring en wordt dus automatisch geactiveerd wanneer het segment ( ordervalueover100) wordt opgelost.

• Als een bevordering niet binnen een ervaring verschijnt (slechts in de campagne), dan kan het niet automatisch op een publiek worden toegepast. Het kan echter nog steeds worden geactiveerd als de gebruiker een voucher in zijn winkelwagen invoert en die voucher verwijst naar de promotie.

  Bijvoorbeeld:

  /content/campaigns/geometrixx-outdoors/article/10-bucks-off

  buiten een ervaring valt en dus nooit automatisch wordt geactiveerd (dat wil zeggen: op basis van segmentatie). Er wordt echter naar verwezen door de vouchers die te vinden zijn in verschillende ervaringen in de artikelcampagne. Als deze vouchercodes in de winkelwagentje worden ingevoerd, wordt de promotieactie geactiveerd.

Personalisatie

Klantenregistratie en -accounts

Wanneer een winkelier zich registreert, moeten de rekeningdetails tussen AEM en de eCommerce-motor worden gesynchroniseerd. Gevoelige gegevens worden onafhankelijk opgeslagen, maar profielen worden gedeeld:

Het precieze mechanisme kan van het scenario afhangen:

1. De gebruikersaccounts bestaan in beide systemen:

   1. Geen actie vereist.

2. De gebruikersaccount bestaat alleen in AEM:

   1. De gebruiker wordt in de eCommerce-engine gemaakt met dezelfde account-id en een willekeurig wachtwoord dat in AEM wordt opgeslagen.
   2. Het willekeurige wachtwoord is noodzakelijk, aangezien AEM probeert om in de eCommerce motor op de eerste vraag (bijvoorbeeld, wanneer een productpagina wordt gevraagd en de eCommerce motor wordt van verwijzingen voorzien voor de prijs) te registreren. Omdat dit na AEM login gebeurt, is het wachtwoord niet beschikbaar.

3. De gebruikersaccount bestaat alleen in de eCommerce-engine:

   1. Het account wordt gemaakt in AEM met dezelfde account-id en hetzelfde wachtwoord.

Wanneer u een eCommerce-engine gebruikt, slaat AEM alleen de account-id en het wachtwoord op (optioneel een gebruikersgroep). Alle andere informatie wordt opgeslagen in de eCommerce-engine.

Aanmelden bij klant

Vaak is aanmelding vereist voor de winkelwagentje. Hiervoor is registratie (Account maken) vereist, zodat een klantspecifieke account kan worden gemaakt.

Aanmelden bij klant

Na aanmelding kan de winkel zich aanmelden bij zijn account, zodat de acties van de winkel kunnen worden bijgehouden en de bestellingen kunnen worden uitgevoerd.

Single Sign-On

Single-sign-on (SSO) wordt verstrekt, zodat de auteurs in zowel AEM als het systeem van de eCommerce zonder het moeten login tweemaal bekend zijn.

myAccount

Transactiegegevens van de eCommerce-engine worden gecombineerd met persoonlijke informatie over de winkelier. AEM gebruikt sommige van deze gegevens als profielgegevens. De actie van een formulier in AEM schrijft informatie terug naar de eCommerce-engine.

Er is een pagina waarmee u uw accountgegevens eenvoudig kunt beheren. U kunt het tot toegang hebben door Mijn Rekening bij de bovenkant van een geometrixx pagina te klikken, of door aan /content/geometrixx-outdoors/en/user/account.html te navigeren.

Adresboek

Uw site moet een selectie adressen opslaan. inclusief levering, facturering en alternatieve adressen. Dit kan worden uitgevoerd gebruikend vormen die op uw standaardadresformaat worden gebaseerd of u kunt de component van het Boek van het Adres gebruiken die door AEM wordt verstrekt.

Met deze component Adresboek kunt u:

• adressen in het boek bewerken
• selecteer een adres in het boek voor het verzendadres
• selecteer een adres uit het boek voor het factureringsadres

U kunt kiezen welk adres u als gebrek wilt.

De component van het adresboek is bereikbaar van Mijn Account pagina door Adresboek te klikken of door aan /content/geometrixx-outdoors/en/user/account/address-book.html te navigeren.

U kunt Nieuw adres toevoegen klikken… om een nieuw adres in uw adresboek toe te voegen. Er wordt een formulier geopend dat u kunt invullen en vervolgens op Adres toevoegen klikken.

Het adresboek wordt gebruikt wanneer u uw winkelwagentje uitcheckt:

Adressen blijven onder user_home/profile/addresses bestaan.
Voor Alison Parker, bijvoorbeeld, zou het onder /home/users/geometrixx/aparker@geometrixx.info/profile/adressen zijn

U kunt kiezen welk adres u als gebrek wilt, wordt deze informatie voortgeduurd in het profiel van de verkoopster eerder dan met het adres. De profieleigenschap address.default wordt ingesteld met het pad van het geselecteerde adres voor waarde.

Klantspecifieke prijzen

De eCommerce-engine gebruikt de context (in feite de verkoopinformatie) om de prijs te bepalen die hij in zijn bezit heeft en geeft vervolgens de juiste informatie terug aan AEM.

Winkelwagentje en bestellingen

Wanneer de winkel wordt geopend, bladert de winkelier door de productpagina's en selecteert hij items om deze in zijn winkelwagentje te plaatsen. Wanneer ze doorgaan met het uitchecken, kan een bestelling worden geplaatst.

Anonieme kopers

Een anonieme klant kan:

• Producten weergeven
• Producten aan hun winkelwagentje toevoegen
• Uitchecken uitvoeren om de bestelling te plaatsen

Geregistreerde kopers

Een geregistreerde klant kan:

• Aanmelden bij hun account
• Producten weergeven
• Producten aan hun winkelwagentje toevoegen
• Uitchecken uitvoeren om de bestelling te plaatsen
• Eerdere bestellingen weergeven en volgen

Overzicht van winkelwagentje inhoud

Het winkelwagentje biedt:

• een overzicht van geselecteerde objecten

• koppelingen naar de productpagina's voor de geselecteerde items

• de mogelijkheid om:

  • het aantal/de hoeveelheid afzonderlijke items bijwerken
  • afzonderlijke items verwijderen

Het winkelwagentje wordt opgeslagen op basis van de gebruikte motor:

• AEM generiek slaat de kar op in een koekje.
• Bepaalde eCommerce-motoren kunnen de winkelwagen tijdens een sessie opslaan.

In beide gevallen blijven de items in het winkelwagentje (en kunnen ze worden hersteld) staan bij aanmelding/afmelding (maar alleen op dezelfde computer/browser). Bijvoorbeeld:

• bladeren als anonymous en producten toevoegen aan de kar

• aanmelden als Allison Parker - haar winkelwagentje is leeg

• producten toevoegen aan haar winkelwagentje

• afmelden - de kart zal de producten voor anonymous tonen

• opnieuw aanmelden als Allison Parker - haar producten zijn hersteld

Vóór het afrekenen worden prijswijzigingen weerspiegeld (in beide systemen) naarmate ze zich voordoen.

Ordergegevens

Afhankelijk van de implementatiegegevens van een bestelling in de eCommerce-engine of in de AEM, wordt deze informatie door AEM weergegeven.

Er worden diverse gegevens opgeslagen, waaronder:

• Order-id

  Het referentienummer van de bestelling.

• Geplaatst

  De datum waarop de bestelling is geplaatst.

• Status

  de status van de order; bijvoorbeeld Verzonden.

• Valuta

  De valuta van de order.

• Inhoud-items

  Een lijst met geordende items.

• Subtotaal

  De totale kosten van de bestelde objecten.

• Belasting

  Het bedrag van de verschuldigde belastingen op de order.

• Verzending

  Verzendkosten.

• Totaal

  de totale waarde van de order; bestelde objecten, belastingen en overslag.

• Factuuradres

  Het adres waarnaar de factuur moet worden verzonden.

• Betaaltoken

  De betalingsmethode.

• Betalingsstatus

  De status van de betaling.

• Verzendadres

  Het adres waarnaar de goederen moeten worden verzonden.

• Verzendmethode

  de wijze van verzending; bijvoorbeeld land, zee of lucht.

• Trackingnummer

  Elk trackingnummer dat door de verzendende onderneming wordt gebruikt.

• Koppeling bijhouden

  De koppeling die wordt gebruikt voor het bijhouden van de bestelling tijdens het verzenden.

Wanneer de orde binnen AEM de console van de Orde wordt gehouden toont het volgende voor elke orde:

• het aantal artikelen in het winkelwagentje
• de totale waarde van de order
• op het moment dat de order werd geplaatst
• de status

Volgorde bijhouden

Nadat kopers een bestelling hebben geplaatst, keren ze vaak terug naar:

• De status van hun bestelling controleren
• Producten uit de bestelling verwijderen
• Producten aan de bestelling toevoegen

Na ontvangst van de levering van de bestelling willen kopers wellicht ook de geschiedenis van bestellingen over een bepaalde periode bekijken.

De afhandeling en het bijhouden van bestellingen wordt meestal beheerd door de eCommerce-engine. De informatie kan worden getoond door AEM te gebruiken de component van de Geschiedenis van de Orde, die alle relevante details, met inbegrip van de toegepaste bonnen en promoties toont. Bijvoorbeeld:

Afhandeling

Afhandeling wordt geïmplementeerd met standaard AEM formulieren. Hierdoor kan de marketingmanager de ervaring met marketinginhoud aanpassen.

De eCommerce beheert vervolgens het afrekenproces met invoer uit de AEM formulieren.

Betalingsbeveiliging

Betalingsgegevens, waaronder creditcardgegevens, worden vaak beheerd door de eCommerce-engine. AEM geeft deze transactiegegevens door aan de motor (vanwaar deze vervolgens wordt doorgestuurd naar een betalingsverwerkingsdienst).

De complicatie van de betaalkaartindustrie (PCI) kan worden bereikt.

Bevestiging van bestelling

De volgorde wordt op het scherm bevestigd en kan worden bijgehouden met order tracking.

Zoeken

Aangezien AEM standaardpagina's voor producten gebruikt, kunt u de standaardzoekcomponent gebruiken om een zoekpagina te maken.

Als u een grondiger implementatie nodig hebt, kunt u:

• Breid de standaardonderzoekscomponent met de functionaliteit uit u wenst.
• Voer de onderzoeksmethode in uw CommerceService uit en gebruik dan de eCommerce onderzoekscomponent op uw onderzoekspagina.

Wanneer u een eCommerce-engine gebruikt, kan de zoekfunctie-API voor eCommerce volledig worden geïmplementeerd in de eCommerce-oplossing, zodat u de zoekcomponent voor eCommerce kunt gebruiken die buiten het vak is opgegeven. Met de beperkte zoekopdracht kunt u zoeken in JCR en/of de engine: