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
© Copyright 2024