Complexities of a landscape on a global scale with the CIF connector

[geertsmichael]

I first want to explain the background of our issue to get some information on how to approach this problem. We tried looking into the code of the CIF Connector to get our customization realized, but we prefer not to modify this connector.

Our brand is globally represented and Magento will contain our products, the same product from a customer’s point of view, is not the same product in Magento. The example product is a product with a power outlet, which is different between US, UK and EU. This means 3 products will be available in Magento, with 3 different SKUs. From an AEM perspective, this is the same product. If our top navigation is linking to that product on the English Master Level, it needs to link in every locale to that product, but the SKU is different. So after rolling out this product, the SKU behind this link is not correct if rolled out to the UK site, as it will still refer to the SKU entered on the English Language Master, which is not the correct one for UK.

We see the need to enter a SKU in 3 different spots in AEM: • When defining a product card or product banner, to show product information • When linking to a Product Page • When having a Product Page that is different from the general template (sub-page of product-page)

All these use-cases will have invalid SKUs after rolling out in AEM due to a different SKU per locale. We want to prevent our authors to change all SKUs after rolling out.

We are aware of the possible selectionIds in the CIF Product Picker: id, sku, slug, path, combinedSku.

We will introduce a new custom attribute “global_product_id” in Magento, which will be set to the same for the 3 products in EU, UK and US, which are despite their power outlet, the same product.

We tried a few things already:

1. We tried to add “global_product_id” as new selectionId: This requires us customizing the models in the CIF connector as these doesn’t use the graphQL models and queries from our code base. So the CIF connector cannot handle custom attributes.
2. We tried to create a new GraphqlDataService in our code base to map to the “global_product_id” to the “sku” and to use our own graphQL models and queries: we had to export GraphqlDataService as it was not exported as OSGI service and we had to copy a service and customize.

Both solutions are not acceptable as we need to customize too much and it would prevent smooth upgrades to new versions of the CIF connector. I want to hear from you what the plans are with the selectionIds of the CIF Product Picker and how you would solve our problem? Could this be made extensibe from the CIF connectors point of view so we could select our own selectionID?

We are also looking into: • Use slug as selectionId, and in Magento return the “global_product_id” as the url_key field, so we fake that we use the slug/url_key, but actually magento returns a different value as url_key (the value of the global_product_id) • We just use the url_key field in AEM to fill in the global_product_id, but I don’t know the implications of this? What other features we might need to abandon because we do this? • Rewrite SKUs on rollout by calling Magento during the rollout to get the counterpart SKU for that locale. • Other suggestions?

So I am looking forward to hear your take on this topic as it becomes very crucial in our plans to start authoring. We plan for go-live the beginning of July and authoring still needs to start.

Thanks in advance.

[cjelger]

This might not be possible in your current catalog configuration, but if the product is basically the same but only has a different power outlet, then the easiest solution would be to create a configurable product in Magento with 3 variants, that is one variant for each power outlet. It's like having a t-shirt with different sizes, but in this case it's just a different power outlet "variation". This would work, and you could still have different SKUs for each variant. Would this an option for you?