К нам часто обращаются за рефакторингом и доработкой проектов с внешними интеграциями — чаще всего с 1С. Со штатными механизмами обычно проблем немного.
Но стоит появиться нестандартному flow — и всё начинает ломаться. И здесь важно не искать виноватого в 1С, а разобраться, где заканчиваются возможности стандартного обмена и начинается архитектура конкретного e-commerce-проекта.
Например, когда изменения происходят не сотнями, а десятками тысяч раз в день — как в одном из наших проектов.
Это была продуктовая сеть: 10 магазинов, примерно по 5000 товаров в каждом. В сумме остатки менялись около 50 000 раз в день. Штатный обмен уже не справлялся с такой нагрузкой.
Мы собрали самописную шину данных на базе SQL. 1С через интерфейс записывала изменения небольшими пакетами: товар, склад, остаток. Дальше очередь разбирал отдельный обработчик.
Почему это сработало? Мы убрали ненужные данные и посредников, не переписывая весь обмен — только изменили участок, который ограничивал производительность.
Этот кейс хорошо показывает простой принцип: не стоит пытаться передавать через один механизм вообще всё:
— быстрые данные (остатки и цены) должны идти одним способом, например через API или ORM.
— обычные операции (заказы и изменения товаров) — другим.
— тяжёлые и редкие данные (файлы и изображения) — третьим.
Кейс: как мы перестали терять заказы между сайтом и 1С
Другой проект — магазин с 3–5 тысячами заказов в день через Битрикс. Проблема была неприятнее: часть заказов не доходила до 1С.
Пакеты периодически терялись между системами — хаотично и без понятной закономерности.
Мы подняли резервный канал обмена через Datareon — по сути, очередь сообщений. Сайт начал дублировать информацию о заказе туда. 1С обрабатывала очередь и при необходимости могла повторно запросить данные.
Со временем резервный канал стал основным: через него перевели обмен товарами, остатками, ценами и заказами. Штатный обмен при этом оставили как резервный.
И здесь важен не сам факт наличия 1С, а понимание, какие данные, с какой скоростью и по какому сценарию должны проходить между системами, и что произойдёт, если основной канал не сработает?
Именно это помогает избежать ситуации, когда сайт показывает клиенту товар, которого уже нет, или заказ есть у клиента и на сайте, но почему-то отсутствует в 1С.
А у вашего обмена есть план Б?