Client
The company is a manufacturer and seller of environmentally friendly cosmetics and cleaning products that operates under the MLM scheme and sells goods at retail.
In total, the company's network has more than 200 retail outlets, each of which has its own 1C application.
The problem
In the previous version of the IT architecture, each 1C:Retail system was connected to the parent company's circuit by integrating the point-to-point format. As a result, the company faced the following problems.
- It was almost impossible to track whether all point-of-sale systems were receiving requests and updates in a timely manner. The architecture was opaque.
- Sometimes point-of-sale systems contained irrelevant information if the recipient system was offline at the time of sending data from the main IT circuit.
- The parent company's “1C:ERP Enterprise Management” was overloaded with requests from retail.
Challenge
Organize a transparent, controlled and asynchronous exchange of information between the company's main systems and 1C in retail outlets.
Hypothesis 1: separate connectors for each of 1C:Retail
KT.team's initial hypothesis was to create separate connectors to obtain information for each of the 1C:Retail systems.
Such an approach would make it possible to separate information flows and make them independent for each of the 1C:Retail systems. Monitoring and logging systems would make it much easier to record problems in data transmission.
The flip side of this approach was the huge number of connectors: more than 200 connectors had to be developed for each entity (product range, prices, balances, etc.). When adding a new retail outlet, it was also necessary to create new connectors for each entity.
The final solution: a common API connector for each entity for all retailers
To facilitate the architecture at the moment and facilitate the further growth of the client's network, the KT.team proposed a fundamentally different approach. There is only one connector for each entity that needs to be taken from 1C:ERP Enterprise Management. It collects the entire amount of information on a specific entity at a predetermined frequency or when a predetermined trigger is triggered: nomenclature, prices, balances, etc. The received data is then transferred to a shared storage facility. No matter how the customer's retail network grows, this connector will always be the same and will operate according to a predetermined algorithm.
For retail outlets, we have developed a single API that can be described as follows: “I give nomenclatures to any consumer who is ready to pick them up according to the described rules.”
All 1C:Retail outlets are connected to this API. Their connectors have conditions that specify what information they should collect. Each retail outlet can send a request using this API: “give me all items that match my unique identifier”. In response, it receives either information or an empty array (if, for example, nothing has been updated since the last interaction). If the vault is unavailable at the moment, retailers receive an error message.
We have developed a scheme for the operation of the component for “1C” for “1C: Retail” for each of the entities. When adding a new outlet, it will take a minimum of time to connect. It is enough to copy the previously developed components, change the 1C:Retail system identifier in the settings and add the corresponding setting to the corporate monitoring tool to regulate the availability and activity of the 1C:Retail outlet.
Benefits for the customer
- There is a single message contract for requesting data. There is no need to remember or store documentation for the standards of more than 200 disparate systems.
- On the ESB side, there is no need to host the ESB server and maintain the same standard connectors for each entity.
- You can add a new retail outlet quickly and without extra development costs.
- Each new “1C:Retail” is monitored on the data transfer graph. If one of 1C:Retail is unavailable, technical support receives an appropriate notification.
