Installing alongside an existing SFCC catalog

Summary

Overview

It is feasible to manage products in Akeneo and legacy products within Salesforce Commerce Cloud (SFCC) simultaneously. This article describes how the Akeneo connector behaves when its data is mixed with products and categories that are not managed by the PIM, and what to watch out for if you plan to migrate them over time.

The connector will never remove or alter existing SFCC products unless they are added to the PIM. It does not migrate existing products to the PIM, and it does not mark them as not originating from the PIM. Migration is performed by the merchant from the PIM dashboard, either manually or through an import, and is outside the scope of the connector.

It is feasible to manage products in both Akeneo and legacy products within Salesforce Commerce Cloud (SFCC) simultaneously.

This section outlines the features of the Akeneo connector and its integration with an existing catalog.

 

Choosing your catalog strategy

Keeping a separate master catalog

If there are products in your catalog that have not been migrated and there is no intention to migrate them, the optimal approach is to use a separate master catalog. The platform supports the coexistence of multiple master catalogs, and they can be used on the same site. You declare the one the connector works with in the SFCC Master Catalog ID parameter.

 

Migrating into the existing catalog

If you want to migrate your products over time while preserving their product IDs, it is preferable to use the same catalog as the existing products. As long as the cartridge is configured to use SKUs instead of UUIDs, and the Akeneo product code matches the ID of the old product in SFCC, the products will be managed by the Akeneo PIM. See the Product ID Type On SFCC parameter in Filtering and mapping products.

Product IDs in SFCC are globally unique across all catalogs of an instance. So if you use separate master catalogs and then decide to migrate, you must remove the products from the unmigrated catalogs before importing the migrated ones.

 

Categories in a mixed storefront catalog

Unlike master catalogs, of which SFCC supports several, the SFCC platform permits only one storefront catalog. Consequently, that catalog will necessarily contain a mixture of migrated and unmigrated categories.

Managing the catalog in the PIM is possible but not required: you can fully manage the storefront catalog in SFCC, in which case you also have to manage the catalog assignments in SFCC manually.

The connector is designed to allow migrated and unmigrated categories to coexist within the same storefront catalog. The following caveats apply:

  • If the SFCC Categories Sync preference is disabled, products managed by the PIM will be unassigned from SFCC categories
  • Catalog-level refinements are saved and re-added to the storefront catalog, whereas category-level refinements are not
  • Category custom attributes are not configurable in the PIM, and the connector will only set the showInMenu custom attribute
  • The Online Categories Sync preference sets both the online flag and the showInMenu custom attribute of the category

You can suppress the import of categories from the PIM while still using the PIM for category assignments by disabling the ExportCategories flag of the Export-storefront-catalog job step. See Synchronization: load and transfer data.

 

Settings that behave differently in a mixed catalog

Most connector parameters behave the same way whether or not your SFCC instance holds unmanaged data. The two below deserve particular attention. For every other parameter, refer to the configuration articles in this documentation.

Connector parameter SFCC information
SFCC Master Catalog ID (akeneoProductsCatalogID) — General tab The ID of the master catalog used by the connector. Assign a dedicated master catalog ID to separate manually configured products from those managed by the PIM.
Akeneo Image View Types — Images & Assets tab Controls the image view types of the Akeneo master catalog. Make sure the existing view type configuration of your unmigrated products is preserved.

 

SFCC Master Catalog ID

SFCC supports multiple master catalogs, so you can assign a distinct master catalog ID to the connector and keep manually configured products separate from those managed by the PIM.

A key limitation of the platform to consider is that IDs for an SFCC object type must be globally unique across the entire instance. Consequently, only one product can have the ID "Product1" across all catalogs. If a product with this ID already exists in one catalog, any attempt to import it into another catalog will be disregarded. This becomes particularly relevant if you want to migrate manually configured products to the PIM gradually while using separate catalogs.

 

Image view types and downloaded media

Images are one area where mixing migrated and unmigrated products can cause trouble.

The connector overrides the view type definitions of the master catalog it imports into. An incomplete or incorrect configuration of the Akeneo Image View Types preference can therefore result in data loss for unmigrated products.

The Remove Downloaded Assets On Full Mode and Remove Downloaded Media On Full Mode options of the Images & Assets tab will result in image loss for unmigrated products.

To avoid these pitfalls, it is preferable to use a separate master product catalog. See Filtering and mapping PIM images and assets for the full description of these options.

 

Master variation products, bundles and sets

Existing unmigrated master variation products are not affected by product imports from the PIM. When migrating master variation products to the PIM, if preserving the product IDs matters, make sure the code of the master and of its variations matches the ones in SFCC, and that the cartridge is configured to use SKUs instead of UUIDs.

Existing unmigrated product bundles and product sets are not affected either. Migrating bundles and sets follows the same rules as migrating simple products. For the configuration of bundles and sets themselves, see Filtering and mapping PIM product associations.