Built a unified API for fast connection of 200+ 1C:Retail systems

Client

The company manufactures and sells eco-friendly cosmetics and cleaning products, operates under an MLM model, and sells directly to retail customers.

The company’s network includes more than 200 retail locations, each running its own 1C application.

The Problem

In the previous IT architecture, each 1C:Retail system was connected to the parent company environment through a point-to-point integration. As a result, the company faced the following issues.

• It was almost impossible to track whether all store systems were receiving requests and updates on time. The architecture was not transparent.
• Sometimes store systems contained outdated information if the receiving system was offline at the moment data was sent from the main IT environment.
• The parent company’s 1C:ERP Enterprise Management system was overloaded with requests from retail.

Challenge

To organize transparent, controlled, and asynchronous information exchange between the company’s core systems and 1C at retail locations.

Hypothesis 1: separate connectors for each 1C:Retail instance

KT.Team’s initial hypothesis was to create separate connectors for collecting information for each 1C:Retail system.

This approach would have separated information flows and made them independent for each 1C:Retail system. With monitoring and logging systems, it would have been much easier to identify data transfer issues.

The downside of this approach was the huge number of connectors: more than 200 connectors had to be developed for each entity (assortment, prices, stock, etc.). When adding a new retail location, new connectors also had to be created for each entity.

Final solution: a shared API connector for each entity across all retail locations

To simplify the architecture immediately and support the client’s future network growth, the KT.Team team proposed a fundamentally different approach. For each entity that needs to be retrieved from 1C:ERP Enterprise Management, there is only one connector. At a set interval or when a predefined trigger is activated, it retrieves the full data set for that specific entity: item master, prices, stock, and so on. The received data is then transferred to a shared repository. No matter how much the client’s retail network grows, this connector will always remain a single one and will operate according to the defined algorithm.

For retail locations, we developed a single API whose behavior can be described as: "I provide item master data to any consumer that is ready to receive it under the defined rules."

All store 1C:Retail systems connect to this API. Their connectors define the conditions for what information they should retrieve. Each retail location can send a request through this API: "Return all item master data matching my unique identifier." The response is either the data or an empty array (for example, if nothing has changed since the last interaction). If the repository is unavailable at that moment, the retail system receives an error message.

We designed the operating scheme of the 1C component for 1C:Retail for each entity. When adding a new store, connection takes minimal time. It is enough to copy the previously developed components, change the 1C:Retail system identifier in the settings, and add the corresponding configuration to the corporate monitoring tool to control the availability and activity of the 1C:Retail location.

Client Benefits

• There is a single message contract for data requests. There is no need to remember or store documentation for the standards of more than 200 separate systems.
• On the ESB side, there is no need to host it on an ESB server or maintain identical standard connectors for each entity.
• A new retail location can be added quickly and without unnecessary development costs.
• Each new 1C:Retail instance appears in monitoring on the data transfer chart. If any 1C:Retail instance becomes unavailable, technical support receives a corresponding alert.