Case Study: Pimcore X Rollout at Leading Notebook and Consumer Electronics Retailer

In order to replace the old data management solution from NBB with Pimcore and to ensure the availability of the product data, including the product properties and images in all systems, the new system first had to be enriched with the inventory data from the previous PIM and DAM systems and fitted into the new data structure.

Parallel to the Pimcore backend, it should be possible to create products and images in Pimcore through other internal systems. For this purpose, a custom API was developed that maps all previous use cases and extends them with Pimcore-specific features. It was important for the project to maintain the back reference to the old PIM system in order to enable a time-independent changeover of further internal systems and thus reduce the time pressure for them or make further planning more flexible.

Ultimately, all changes to product data in Pimcore should be made available directly to all other systems by sending the data to an Apache Kafka queue. The implementation was carried out in close cooperation with the customer's internal development team. The biggest challenge during the implementation was a large amount of data for some OptionProviders and the ability to filter and edit products in bulk, which until then could not be mapped with relations.

Later, Pimcore X made it possible to replace the too-large OptionProviders with relations, which gave the project the final touch. Another challenge was the import of the DAM data, as the runtime would have taken several days in the beginning. Through configuration and a few adjustments, the runtime for importing the images was reduced to one day. NBB's product range includes not only standard products but also other product types such as bundles or insurances. With Pimcore's custom layouts, only the data fields that are needed are displayed for a given product type.

Sometimes the inheritance of Pimcore caused some compatibility problems, which could be adapted to the customer's needs with clever configuration and a separate solution for ObjectBricks. Due to the large amount of data generated by numerous choices and variants of products, among other things, it was necessary to ensure that the performance of the system did not suffer. For this purpose, direct SQL queries are cached so that the SQL does not have to be executed again for each request. In addition, caching all option providers reduces the need to reload all data.