Pimcore in a company with a large technical catalog
Pimcore is a data management platform where PIM sits next to MDM and DAM. A product there is a data object, and its structure is set by a class definition designed by the implementation team. That is why Pimcore is common among manufacturers and distributors whose product page carries hundreds of parameters and whose every product group has a different set of properties.
For a shop integration this has one important consequence: there is no “standard Pimcore product”. Two installations can describe the same bearing with entirely different classes and fields. An integration with Endora Commerce therefore starts with a review of your data model, not with flipping a switch.
What moves from Pimcore to the shop
Data flows in one direction: Pimcore stays the source of truth about the product and the shop catalog mirrors it.
- Content and parameters: descriptions, technical parameters, variants and categories.
- Product media: images and documents, such as data sheets, attach to the product in the shop.
- Everything at once: one sync updates the full product dataset, rather than content and media separately.
How Pimcore concepts translate into go-live preparation
| In Pimcore | What to settle before go-live |
|---|---|
| Product class and its fields | Which fields become the name, description and attributes in the shop |
| Variants with inheritance | A variant inherits values from its parent object: which fields are shared and which tell variants apart |
| Classification Store | Category-specific attributes added without changing the class: which groups of properties the buyer should see |
| Localized fields | Which languages go to the shop and what to do when a translation is missing |
| Assets | Which images form the gallery and which files are downloadable attachments |
What to prepare on the Pimcore side
Pimcore exposes data to external systems through Datahub, a set of configurable GraphQL endpoints. Whatever the details of your rollout, a few things described in the Datahub documentation are worth sorting out early:
- A separate configuration for the shop with its own API key, generated in the configuration’s security settings.
- Schema: for data object classes, only the fields selected in the configuration are visible. A field added to the class later is not available through Datahub until it is added to the schema.
- Workspaces: with no workspace assigned, no directory is accessible. For fetching data alone, read permission on the folders holding products, categories and assets is enough.
- A Pimcore test environment with a representative sample of the catalog, so the mapping can be checked before production.
The other direction is covered by the Endora Commerce partner API: a key with the catalog:write scope can write products by SKU. That route is useful when Pimcore should be the one pushing changes.
Things worth asking about early
- Fallback language. GraphQL queries in Pimcore can return the fallback-language value when a translation is missing, unless the query switches that off. You need to decide whether the shop should then show text in another language or skip the field.
- SKU quality. Writes through the partner API identify a product by its SKU, so the numbers have to be unique and stable.
- Local edits in the shop. The shared PIM connector layer in the platform defines one consistent way of protecting fields, that is, excluding a locally refined value from being overwritten on import. It covers the name, description, attributes (also per language and sales channel), SEO metadata, gallery positions, attachments and category assignment. Ask which of these fields you want to edit in the shop.
One active PIM per installation
The platform lets you install several PIM connectors, but only one can be active. On a fresh install none is switched on: the operator picks one in the admin panel, and an attempt to enable a second is refused with the name of the connector already running. Changing PIM does not delete data, and products imported earlier stay in the catalog.
When Pimcore, and when another PIM
Pimcore is the natural choice if you already work in it, or if you need your own data model and asset management in one tool. If you are only starting to put product data in order and want a lighter start, see UnoPim. A ready-made model of families and attributes comes with Akeneo, and Ergonode is a PIM developed in Poland.
Want to see how your class model would translate into a shop catalog? Get in touch and show us a sample product page.
