Polaris is a Swiss brand of household appliances and tableware that sells products through marketplaces and their web-store.

Initially, the interaction between the customer and all marketplaces was manual. Different product data was used at different marketplaces, and it took a long time to fill out product cards, using information from all different sources. Our task was to set up a centralized system for the product data management and integrate it with the customer's ERP and marketplaces.

It was suggested to use Pimcore as a product data management system: it could help automate manual tasks performed by managers, and ensure the centralized data verification and automatic integration with marketplaces.

To create a new data storage model, the project team decided to analyze the existing structure of storing data about different product groups in the customer's ERP, and compare this data with the requirements of marketplaces and company departments involved in the interaction process. The data exchange between the systems was organized via the ESB service bus.

During the preparation of analytics, we identified the requirements of the client's company departments, analyzed the business, and studied the existing structure of product data storage, differences in the composition of attributes for different product groups and technical documentation of the marketplaces connected.

Having analysed the collected data, we designed a data model and configured the basic classes in Pimcore.

During the preparation of analytics, we identified the requirements of the client's company departments, analyzed the business, and studied the existing structure of product data storage, differences in the composition of attributes for different product groups and technical documentation of the marketplaces connected.

We compared the requirements for each attribute and designed a product card in Pimcore in a way that allowed the customer's content manager fill in information with no regard to varying requirements of the marketplaces connected.

All mapping is configured at the level of Pimcore directories — in case of changes in the marketplace's requirements, a user with administrator's rights will be able to make necessary edits to the system or configure the automated update by implementing additional microservices in the ESB contour, without wasting time and money on the development.

We suggested using the WSO2 ESB, the RabbitMQ message broker and the ELK logging system as an enterprise service bus. In the future, these tools will allow the client to configure and expand their interactions without writing a code with the help of a graphical interface of the software involved.

On the one side, there is a set of micro services that learn about the product card creation or changes made in Pimcore, extract the data intended for marketplaces from there, add price information from ERP to messages and send it to RabbitMQ, where a separate queue for each marketplace is created. The use of queues helps avoid overloads in case of mass transfer of product information and prevents data losses in the event of temporary recipient server malfunctions.

On the other side, the micro services for data transmission to marketplaces are implemented, which eventually monitor the data processing status and send unique marketplace IDs back to Pimcore. Logs about the operation of microservices are sent to ELK, and are visualized in the form of diagrams there.

Some of the project work plans include scaling by product classes and adding the order exchange functionality. The project also has the potential to expand through expanded integrations with other marketplaces.