Looking for info on storing commerce products and their attributes in the JCR

[Art_Bird]

Using AEM 6.5 but we are not using Magento.

We are products we are importing into AEM. They can have over 40-50 attributes and each attribute has 4-8 of its own attributes. Attributes are basically technical specs describing dimensions, weights, speeds, and things you would see describing an engine. What is the best way to handle these attributes?

I've seen another project were each of these types of attributes were stored as part of the product. This ended up with a bunch of attributes stored with a special prefix to the key name and the value stored as a string. However, it didn't have as many attributes and they were very basic.

I've looked over the We.Retail products and there is only an example of products with variants and minimal attributes like description. I see nothing like what I need to do. Also, everything I find is related to Magento and we aren't using it on this project.

Would it be better to have each attribute stored in its own node? Any chance that would cause issue down the line if Magento is brought in?

I'm still new to working with AEM commerce features and I can't find any good docs on the scenario I'm dealing with.

[sprince1504]

.

[Prince_Shivhare · Accepted solution]

@Art_Bird 

Can you please help me with below points -

1. When you say "importing into AEM", is this a API call? or first you will storing it into somewhere in aem and then showing it to frontend.

2. If API, then what is your backend system. In my case, we are using Magento and graphql by which we are taking only specific attributes which are required for product (few products).

3. If later you have a plan to explore on Magento, and if there are multiple products which needs to showcase on AEM then you can go ahead with CIF Commerce integration.

4. If you want to store it first into the AEM as a node, and then show the data to AEM pages. then you will have to add these products somewhere in assets and store the attributes as a property. once it is done, you can fetch this data to AEM pages (not suggesting).

[Art_Bird]

1 & 2. We're pulling it from an API and storing it in /var/commerce/products/... The API is going away so we have to pull and store in AE

3. No plans for Magento but the number of products will be growing in size over the next few years.

4. This is how we are planning on doing it. We have put them in /var/commerce/products/ but are storing each attribute in their own node.

My issue with storing attributes as properties on the product node is that it would be a 40+ properties with string arrays of key value pairs. I'd think this would make it even harder to get to the attributes for filtering and searching for products.

[Prince_Shivhare]

In this case, you can still use it to store in assets as a property but to filter this data you will have create custom console or page with some dynamic dropdowns, where you can filter these data easily.

[mhaack]

The solution for this should be CIF (Commerce Integration Framework) it works with Magento and 3rd Party Commerce solutions. For non Magento you need some mapping, depending on your commerce solution there might be already a partner integration for CIF or you have to build that.

Regarding the product import and the patterns use for We.Retail. This is outdated approach and not recommended any more.