eCommerce Integration Framework
eCommerce Integration Framework
Overview / CQ / Adobe Experience Manager 5.6.1 / AEM eCommerce /
eCommerce, together with Product Information Management (PIM), handles the activities of a website
focused on selling products via an online store:
• Creation, lifetime, and obsolescence of a product
• Price management
• Transaction management
• Management of entire catalogs
• Live and centralized storage records
• Web interfaces
AEM eCommerce helps marketers deliver branded, personalized shopping experiences across web, mobile,
and social touchpoints. The AEM authoring environment allows you to customize pages and components
based on target visitor context and merchandising strategies; for example:
• Product pages
• Shopping cart components
• Checkout components
The implementation allows real-time access to product information. This can be used to enforce:
• Product information integrity
• Pricing
• Stock-keeping inventory
• Variations in state of a shopping cart
FEATURES
AEM eCommerce provides:
1.
A number of out-of-the-box AEM components:
• Product display
• Shopping cart
• Check-out
• Recently viewed products
• Vouchers
• and others
NOTE
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 1
Created on 2015-03-02
eCommerce Integration Framework
The integration framework provided by AEM also allows you to build additional AEM
components for commerce capabilities independent of your specific eCommerce
engine.
2.
Search - using either the AEM search, the search of the eCommerce system, a third party search (such
as Search&Promote) or a combination thereof.
3.
Uses the AEM ability to present your content in format needed by your visitors, be that full browser
window or mobile device.
4.
The ability to develop your own integration implementation based on the AEM eCommerce framework.
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 2
Created on 2015-03-02
eCommerce Integration Framework
The two implementations currently available are both built on the same basis - on top of the general
API (the framework). Implementing a new integration only involves implementing the feature(s) that
your integration needs. Front end components can be used by any new implementation as they use
interfaces (so are independent from the implementation).
5.
The possibility to develop experience-driven commerce based on shopper data. This allows you to
realize many scenarios:
• One example might be providing reductions in shipping costs when the total order exceeds a
specific amount.
• Another might allow you to provide seasonal offers that use profile data (e.g. location). These can
then be highlighted, again depending on other factors when necessary.
In the example below one teaser is shown as the contents of the cart are less than $75:
This can be changed when the contents of the cart exceed $75:
6.
And other features including:
• Shopping cart contents retained across sessions
• Full order history
• Express catalog update
Architecture and Concepts
INTEGRATION FRAMEWORK AND API
he integration framework provides the API, a range of components to illustrate functionality and several
extensions to provide examples of connection methods:
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 3
Created on 2015-03-02
eCommerce Integration Framework
NOTE
The framework provides the basis requirements for your own project.
A certain amount of development work is always needed to adapt the framework to your
specifications.
NOTE
The eCommerce integration framework is an AEM Add-On.
Your Sales representative will be able to give full details, according to the appropriate engine.
IMPLEMENTATIONS
Currently there are two flavors of eCommerce implementations with AEM:
• AEM eCommerce implemented with an eCommerce engine The eCommerce integration framework
has been built to allow you to easily integrate eCommerce systems with AEM. This allows you to connect
with a purpose built eCommerce system to control product data, shopping carts, checkout and order
fulfillment, while AEM controls the data display and marketing campaigns.
Several reference sites have already been implemented:
• hybris
• Elastic Path
• Intershop
NOTE
Some others are currently under development, for example Infield Design is developing
a Magento extension to AEM.
•
AEM eCommerce implemented within AEM using native development based on JCR
A standalone, AEM native eCommerce implementation of the API. This can be used to control
product data, shopping carts and checkout in conjunction with the existing data display and marketing
campaigns. In this case the product database is stored in the repository native to AEM (Adobe's
implementation of JCR).
NOTE
The AEM native/JCR implementation is currently intended for demonstration purposes only.
COMMERCE COMPONENTS
•
•
•
•
•
•
•
•
•
•
CCV
Call to Action
Cart Total
Dropdown Facet
Last-Viewed Call To Action
Navigation Products
Order History
Pagination
Perfect Partner Call To Action
Product
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 4
Created on 2015-03-02
eCommerce Integration Framework
•
•
•
•
•
•
•
•
•
Product (Mobile)
Product (Non-variant)
Product Lists
Product Table
Recently Viewed Products
Search
Shopping Cart
Submit Order
Vouchers
STANDARD ECOMMERCE TERMINOLOGY
This following terms are often used in eCommerce:
• Editorial content: content that is managed by websites users.
• PIM content: content that is managed by e-merchandizers.
• Product: group of content (PIM and editorial) related to a generic product.
• SKU: or stock-keeping unit, specifies the variant of a product that can directly be related to the stock,
and a price. A SKU is always tightly related to its product, a product can have one or more SKUs.
• Attribute: an attribute is a sku property (color, size, etc).
• Catalog: the vendor’s hierarchical set of products he offers.
• Category: a catalog item, that behaves like a PIM tag.
API DOCUMENTATION
The eCommerce API is provided by the packages:
com.adobe.cq.commerce.*
See the API documentation for further information.
ADDITIONAL POINTS TO NOTE
1.
2.
For all implementations the following points can be kept in mind:
• As product, stock-keeping units and categories can be numerous, try to use the least number of
nodes possible to model the content.
The more nodes you have, the more flexible your content is (e.g. parsys). However, everything is
a trade-off and do you need individual flexibility (by default) when manipulating (for example) 30K
products?
• Avoid duplication as much as you can (see localization), or when you do, think about how many
nodes your duplication will lead to.
• Try to tag your content as much as you can in order to prepare the query optimization.
For example:
/content/products/france/fr/shoe/reebok/pump/46 SKU
should have one tag per content level (i.e. country, language, category, brand, product). Searching
for
//element(*,my:Sku)[@country=’france’ and @language=’fr’
and
@category=’shoe’ and @brand=’reebok’ and @product=’pump’]
will be drastically quicker than searching for
/jcr:root/content/france/fr/shoe/reebok/pump/element(*,my:Sku)
• In your technical stack, plan very factorized content access model and services. This is a general
best practice, but is even more crucial her, as you can, in optimization phases, add application
caches for data that is read very often (and that you do not want to fill the bundle cache with).
For example, attributes management is very frequently a good candidate for caching as it concerns
data that is updated through products import.
If the following two categories can be differentiated, then this allows you to make clear URLs with
a meaningful structure (trees of cq:Page nodes) and therefore, very close to classical AEM content
management):
• Structural categories
The category tree defining what is a product; for example:
/products/mens/shoes/sneakers
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 5
Created on 2015-03-02
eCommerce Integration Framework
•
3.
Marketing categories
All other categories a product can belong to; for example:
/special-offers/christmas/shoes)
Performance testing must be taken into consideration on AEM eCommerce implementations:
• Author environment:
Background (e.g. import) activity can occur at the same time as normal user activity (e.g. page
editing) and even if front-end performance is (in general) given a higher priority, bad performance
seen by online authors can lead to frustration capable of blocking a go-live decision.
• Publication environment:
Replication is a critical process to ensure that the content is published quickly and reliably. This can
be impacted by how the author groups the content to be published.
• Front-end:
The mixture of front-end and cache invalidations can potentially lead to performance surprises.
Testing helps avoid these.
Please note that this performance testing requires knowledge and analysis of your target:
• Content volumes
• Assets
• Localized, I18ned products and SKUs
• User activity:
• Bulk edition
• Bulk publication
• Intense search requests
• Background processes
•
Imports
• Synchronization updates (e.g. pricing)
• Maintenance requirements (backup, Tar PM optimization, datastore garbage collection, etc)
Scaling eCommerce
Importing a large number of products (usually more than 100,000) from an eCommerce system (PIM) can
slow down the authoring instance if the products have associated assets (eg product images). This is due to
the fact that the post-processing of these assets is CPU and memory intensive.
There are various strategies you can choose to work around this:
• Offload asset post processing to a dedicated instance
• Only import product data
• Import Throttling and Batch Saves
OFFLOAD ASSET POST PROCESSING TO A DEDICATED INSTANCE
This scenario involves setting up two author instances:
1. Master author instance that imports product data from PIM, on which post-processing for the asset paths
is disabled.
2. Dedicated DAM author instance that imports and post-processes product assets from the PIM, and
replicates these back to the master author instance for use.
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 6
Created on 2015-03-02
eCommerce Integration Framework
ONLY IMPORT PRODUCT DATA
For cases when products do not contain assets (images) to be imported, you can import the product data
without being affected by asset post-processing.
IMPORT THROTTLING AND BATCH SAVES
Import throttling and batch saves are two general scaling mechanisms that can help when importing large
volumes of data.
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 7
Created on 2015-03-02