Client
A retail chain offering a wide range of household goods at low fixed prices. As of March 31, 2023, more than 5,800 stores operated under the Fix Price brand in CIS and neighboring countries, each carrying about 2,000 items across roughly 20 product categories. According to the company's 2022 report, revenue for the previous year exceeded RUB 277 billion.
One of Fix Price's development priorities is increasing online sales.
Problem: incomplete data and errors in product descriptions
Several systems operate in the client's IT landscape, including the e-commerce storefront, accounting system, warehouse management system, and ERP. All product data for items sold through the Fix Price chain must be loaded into the accounting system.
To create a product card in the ERP system, managers used to collect data from suppliers via messengers, by phone, or by email.
There was also a semi-automated option: a request through the supplier portal. After the supplier created a new product card, all other systems had to be notified.
These data collection methods did not guarantee high data quality. The process involved:
If the content manager lacked information for a product card, they had to send a request to the supplier through DKM, and as is well known, every new link in the communication chain slows the overall process.
At the same time, Fix Price's assortment includes about 2,000 items across 20 product categories. Each content manager is responsible for hundreds of products. With manual data entry, this increases the risk of errors and omissions.
- the supplier representative, who stores and collects product data according to internal standards;
- the manager in the category management department (DKM), focused on the data needed to add a product to the assortment matrix as quickly as possible;
- the content manager in the marketing department (DM), who needs information to fill out a product card on the e-commerce storefront: product name, specifications, package contents, product description, and so on.
Solution: suppliers and Fix Price departments work with product data electronically in a single system, and the service bus distributes it across Fix Price systems
To automate data collection while ensuring completeness and high quality, KT.Team implemented a supplier portal (hereinafter, the portal) based on Pimcore in Fix Price's IT landscape and integrated the Mule ESB service bus.
Pimcore is a product management system and a repository of master product cards. It stores accurate and complete information about all products sold across the Fix Price chain.
In the supplier portal, all three parties work with the same product card.
The supplier fills in the product card data directly in the portal, after which the card is automatically sent to the DKM manager.
The DKM manager retrieves, edits, or enriches the product data needed to support warehouse logistics processes, as well as the information required for the product to appear on offline store shelves. After DKM staff check the quality of the data, the product card moves on to web storefront data preparation, which is handled by the marketing department managers.
The DM manager validates the attributes for the e-commerce storefront for completeness and fills in fields with the description, product photos, and so on.
If any fields fail Fix Price department validation, the supplier receives a notification and can add or correct the information directly in the supplier portal, without lengthy email threads or calls.
The supplier portal is needed to request data directly from the supplier, distributor, or manufacturer. Suppliers, in turn, can submit a new product or a new variant of an existing product through the portal for review, such as a new chip flavor, a new T-shirt color, or a new plate design.
Interaction between the supplier portal and the accounting systems is built on data transfer through the Mule ESB system. The message flow inside the bus mirrors the client's business process logic.
Simplified Architecture Diagram
A product card completed in the supplier portal goes into Fix Price's PIM and from there to all other systems.
Data is transferred sequentially to three systems: e-commerce, the internal search system, and the accounting system. The structure of the client's business process does not allow a card to be sent to system No. 2 unless the publishing rules for system No. 1 are met.
Review a similar project with an architect
Result 1: only properly completed product cards are guaranteed to enter Fix Price systems
Each new product card must be validated against the publication criteria for the web storefront. The system defines strict rules for each product type regarding the list of mandatory fields and the required data formats. If any field is left empty, the card is sent back for revision. If validation succeeds, the ESB passes the card to other systems on Pimcore's initiation.
For example, when adding a new pasta product card, the supplier sees tooltip-style prompts showing which fields are required, such as type (penne, pipe rigate, spaghetti, etc.) and pack weight. Until this information is filled in, the product card will not move to the next review stage.
Result 2: information about new products is transferred to the client's IT systems in a controlled way
The bus acts as an intermediary between the supplier portal and other Fix Price IT systems, replacing direct system-to-system integrations. When a configured trigger fires, or on a set schedule, Pimcore initiates sending new product cards that have passed all validation stages to the ESB. After that, the product cards are delivered to the target consuming systems.
Monitoring and logging systems integrated into the ESB layer record which information was transferred and which was not, what errors occurred during transfer, and at what point. This makes it possible to accurately track the completeness and timeliness of data exchange between systems.
At the same time, the connector defines a specific mapping between source systems and consuming systems, so information is neither lost nor distorted.
Result 3: integrations do not need to be completely reworked when the product card structure changes
Sometimes the structure of a product card in the PIM system or on the e-commerce storefront can change. For example, a product's dimensions, which were previously stored in three fields, may need to be described in one field instead, or vice versa.
In that case, the standard integration would have required refactoring and code changes, which would have taken hours of development. With a service bus, the connectors do not need major changes: Mule ESB makes it possible to adjust field mapping within a couple of hours. The changes can then be rolled out to all related connectors, and from that point on information for both new and existing cards can be transferred according to the new rules.
Result 4: the supplier and content manager save time thanks to the bulk upload mechanism
Previously, category management department employees could not bulk upload products from suppliers. A supplier could send a manager an Excel file for manual transfer into Fix Price's internal systems. This process was unreliable because it increased the risk of human error: duplicate products could appear, along with inaccuracies and distortions when data was copied manually between files.
With ESB, the bulk upload process for product data is automated. The supplier downloads an Excel template with a predefined set of fields for each category, fills it in, and uploads it to the portal. DKM managers review and either approve or reject products from the selection; they can work with a specific card or with several cards at once from the selection.
