Overview
The Akeneo Connector does two things :
- Keep the SDM-PIM connected project up to date with its related PIM configuration
- Push products to the PIM once a job is completed.
Configuration Fetch
Configuration: It is the global structure of the PIM (Families, attribute groups… as listed below)
The configuration fetching process between SDM and PIM works by overriding the Project configuration in SDM (except for certain specific steps outlined below).
- Changing a project configuration manually if it is linked to a connector is useless as manual changes will be overridden during the next sync.
- The PIM sync overrides the project config only, not the step configs
- The configuration is synchronized using a cron task.
Categories and Hierarchies Fetch
During the sync:
- Attribute groups in PIM are converted to display groups in SDM.
- Families and categories are modeled as hierarchies.
- Attributes are converted according to their type.
By default, all synced categories are embedded into a single hierarchy called categories
.
Note: For customers who need separate steps for each category tree, the split_categories
option can be activated. This creates one hierarchy per category tree in PIM.
Activating the split_categories
option also changes the default project setup, adding a categorization step for each tree and a mapping step to combine different categories into the categories
attribute during the push.
Attributes Fetch
SDM and PIM use different sets of attributes. In general:
-
Scopable attributes: SDM creates one version per channel targeted, naming them as
${attribute_name}-${channel_name}
. - Localizable attributes: One version is created for each activated locale.
-
Scopable and localizable attributes: All combinations of channels and locales are created and named
${attribute_name}-${channel_name}-${locale}
.
Unsupported attribute types
For clarity’s sake, here are the PIM attribute types not currently supported in SDM :
pim_catalog_date
pim_catalog_file
More info➡️ PIM Attribute Handling and Limitations
It is now possible to manually synchronize with the Akeneo connector directly from the SDM interface! This means that when changes are made in the PIM, SDM users no longer need to wait until the next day's automatic sync or ask their SDM contact to fetch the PIM.
Product push
Once the final step of a job is completed, the connector attempts to push the products to the PIM using the public API.
⚠️ SDM uses the mass update and creates an endpoint for the push, meaning that if there is any conflict, the connector will override existing data in the PIM.
Empty values are not pushed. This means that empty fields in SDM will not overwrite existing data in the PIM when pushing updates to an existing product.
Push Identifier
The identifier used for the push depends on the use_uuid_push
option. If it is disabled (default behavior) then we will push to the /api/rest/v1/products
PIM endpoint and will use the pim_catalog_identifier
as identifier.
If instead the option is activated we will push to the /api/rest/v1/products-uuid
PIM endpoint. By default we will do this by generating an UUID4 on our end. But this means that we won't handle product updates as we don't accept a UUID attribute so there is no way to match a product coming into SDM to a product in the PIM. This is the point of the use_uuid_memory
option.
If activated, we will also need to provide a uuid_memory_reference_base
and uuid_memory_keys
. This argument allows SDM to store the generated UUID in a Reference Base using the uuid_memory_keys
as unique columns. That way if a product is to be pushed and we match all the values of uuid_memory_keys
with a row present in the uuid_memory_reference_base
, we will used the store UUID instead of creating a new one and therefore update the product.
Push Identifier Example
The method used to identify products during the push process depends on the configuration options. There are two main approaches:
1. Standard Identifier Push (Default)
-
Option:
use_uuid_push
is disabled -
Endpoint:
/api/rest/v1/products
-
Identifier: Uses
pim_catalog_identifier
2. UUID Push
-
Option:
use_uuid_push
is enabled -
Endpoint:
/api/rest/v1/products-uuid
- Identifier: Uses UUID
When using UUID push with the UUID memory option, the process enables product updates:
-
Options:
-
use_uuid_push
is enabled -
use_uuid_memory
is enabled - Requires
uuid_memory_reference_base
anduuid_memory_keys
-
-
Process:
- Checks the Reference Base for existing UUIDs
- Uses
uuid_memory_keys
as unique columns to match products - If a match is found, uses the stored UUID for updates
- If no match is found, generates a new UUID for the product and stores it in the Reference Base
3. UUID Push with Memory Process
- The system checks the Reference Base (UUID Memory) for an existing UUID based on the
uuid_memory_keys
. - If a match is found, it uses the stored UUID for the product update.
- If no match is found, it generates a new UUID and stores it in the Reference Base for future reference.
- Finally, it pushes the product to the PIM using the appropriate UUID.
Push Assets
Assets are pushed to their asset families according to mapping.
Push Variants
When using variants, the push process (as well as the config sync) is different and described in details in the Variant documentation page.
Interface
Re-sync PIM configuration
From Configuration tab > Connector, it is now possible to launch a fetch of the latest version of the PIM structure from the SDM interface, overriding the next Cron task.