One of the core elements of any eCommerce implementation is the management of product data. When integrating with AEM you have the choice of either importing the product data into the JCR or having it exist solely in the eCommerce system. There are pros and cons to both approaches. Importing the data into AEM allows you to make use of the AEM Commerce components, use the AEM Commerce API, and do some fun things like product page generation, and data-driven tag creation. Having the product data in the JCR also allows AEM to access the information without having to make a call to the commerce platform every time. The con of having this data in AEM is that it may present challenges in keeping the data in sync. While things like product name, description, and image may not change often some more dynamic properties such as stock level, pricing, and active status may demand a more real time approach. This challenge can possibly be offset through the use of incremental imports and node listeners but ultimately the decision will come down to your specific implementation and the needed frequency for updates.
I have encountered two ways to import product data into the JCR. The first method of importing products is accomplished by uploading good ol’ fashioned CSV files with your product data in AEM Tools at http://localhost:4502/miscadmin. Navigate to /etc/commerce/products, click “New File..”, then browse and select the CSV.
This is the generic importer interface as evidenced by the “Geometrixx” option for commerce provider. If you do not want to use the provided Geometrixx importer you will need to install custom code for your particular commerce provider and select it from the drop down. You then browse to the location of the CSV within the JCR that you uploaded previously and click “Import Products”.
The second method I’ve used is very similar to the first. For hybris, rather than uploading CSV files, by installing the hybris commerce bundle, you gain access to a similar importer customized for hybris:
This importer pulls product data directly from hybris without the need of an additional export step. In order for this to work, you will need to install and configure the connection within OSGi and, within the importer, enter the name of the catalog you wish to import from hybris.
I’m sure there are more methods/importers out there for the eCommerce platforms I haven’t worked with yet but I’d assume they function very similarly to the ones I’ve mentioned.
For both importers (at least in Classic UI mode) you will enter a store name. This store name will dictate where in the JCR the product data will be stored following the pattern /etc/commerce/products/storename. How this product data looks after import can be seen within Geometrixx or in a much more tasty example in the screenshot below.
The products are organized under nodes of the type sling:Folder. Under the sling:Folder we have the base product. The base product will have the following properties:
- jcr:primaryType – nt:unstructured
- sling:resourceType – commerce/components/product
- cq:commerceType – product
In addition there should be an identifier that should be unique to that product. Other product data you will often finder on these base product nodes are jcr:title, jcr:description, and price. Also note the image node under the base product. This node has a sling:resourceType of commerce/components/product/image and a fileReference with the path to the product image. This is not required and, depending on your import configuration and needs, you may have the image path exist as a property on the product node.
The children of the base product are referred to as variants. These represent the different options a customer will have when viewing information for or ordering the product. A base product may have several variants or it may have none at all. In the screenshot above we have the property cq:productVariantAxes with a value of flavor. Typically I’ve seen this value be color or size and allows us to have variation specific data in the JCR.
The product variant, like the base product, will have the properties:
- jcr:primaryType – nt:unstructured
- sling:resourceType – commerce/components/product
The variants differ in that the cq:commerceType will have a value of variant and will also have a value for a property that corresponds to the cq:productVariantAxes value on the base product. In the case above, this property is flavor but will most likely be color or size in most implementations. Like a given product can have multiple available colors and each color can have multiple available sizes a base product can have multiple variants with each of those variants having variants as well. In these cases the cq:productVariantAxes would have an additional value as shown below.
Additional information can be found here:
The site is looking piece ostentatious and it gets the guests eyes. Outline is really basic and a decent easy to use interface. Shopify experts
ReplyDeleteThis blog website is pretty cool! How was it made ! Ecommerce in Liguria
ReplyDelete