Client
Polaris is a Swiss brand of home appliances and cookware that sells through marketplaces and its own online store.
Challenge
At the start of the project, the client was working with all marketplaces manually. Product data for each marketplace differed, and managers had to spend a lot of time filling in product cards by gathering information from different sources. Our task was to set up a centralized system for product data management and integrate it with the client's ERP and marketplaces.
Solution
Pimcore was proposed as the product data management system: it will help automate managers' manual work, ensure centralized data validation, and provide automatic integration with marketplaces.
To create a new information storage model, we decided to analyze how data for different product groups is stored in the client's ERP, compare that data with the requirements of the marketplaces and the company's departments involved in interacting with them. It was decided to organize data exchange between systems through the ESB service bus.
We'll curate materials for your task
We'll reply within 30 minutes and send relevant cases, diagrams, or analyses tailored to your context.
Stage 1: Analysis
During the analysis phase, we identified the requirements of the client's departments, analyzed the business, studied the existing product data storage structure, the differences in attribute sets for different product groups, and the technical documentation of the connected marketplaces.
After comparing the data we received, we designed the information model and configured the base classes in Pimcore.
Stage 2: Pimcore integration
During the analysis phase, we identified the requirements of the client's departments, analyzed the business, studied the existing product data storage structure, the differences in attribute sets for different product groups, and the technical documentation of the connected marketplaces.
We matched the requirements for each attribute and designed the product card in Pimcore so that the client's content manager could enter information without having to think about the differing requirements of the connected marketplaces.
All mapping is configured at the Pimcore data dictionary level, so if marketplace requirements change, the client can update its system as the administrator or automate the changes by implementing additional microservices within the ESB layer without spending time or money on development.
Stage 3: WSO2 ESB integration
As the data service bus, we proposed using WSO2 ESB, the RabbitMQ message broker, and the ELK logging system. In the future, these tools will let the client configure and extend integrations without writing code, using the graphical interface of the software in use.
Implementation of the project architecture
On one side, we developed a set of microservices that detect when product cards are created or updated in Pimcore, retrieve the data intended for marketplaces, add pricing information from the ERP to the messages, and send them to RabbitMQ, where a separate queue is created for each marketplace. Using queues helps avoid overload during bulk product data transfers and prevents data loss if the recipient is temporarily unavailable.
On the other hand, microservices were implemented to send data to marketplaces, then monitor processing status and send the marketplaces' unique IDs back to Pimcore. Logs from the microservices are sent to ELK, where they are visualized as charts.
