Когда каталог товаров растёт, ручное обновление перестаёт работать
Десятки изменений от поставщиков ежедневно, устаревшие данные в каталоге, потеря продаж из-за неактуальных цен — стандартная ситуация для растущего e-commerce бизнеса. Мы разрабатываем комплексные системы автонаполнения каталога на 1С-Битрикс под ключ — от проектирования архитектуры до стабильной, надёжной работы в production. На основе опыта более 20 успешных проектов (каталоги от 10 000 до 200 000 товаров) гарантируем отказоустойчивую архитектуру с безошибочной интеграцией 1С через CommerceML, REST API поставщиков, FTP-фидов, XML и Excel. Свяжитесь с нами сегодня для бесплатной консультации и оценки вашего проекта.
Архитектура системы
Правильная система автонаполнения состоит из нескольких слоёв:
Слой сбора данных (Collectors)
Каждый источник — отдельный коллектор с интерфейсом CollectorInterface::collect(). Коллекторы не знают о Битриксе — они только собирают и возвращают нормализованные структуры данных. Это позволяет тестировать и заменять источники независимо. Коллекторы парсят цены, остатки и описания из любого формата.
Слой трансформации (Transformers) Нормализация данных: единицы измерения, форматы дат, кодировки, маппинг полей. Трансформер принимает «сырой» объект коллектора и возвращает массив, готовый для записи в инфоблок.
Слой записи (Writers)
Инкапсулирует работу с API Битрикса: CIBlockElement::Add/Update, CCatalogProduct::Update, CFile::SaveFile. Writer знает о структуре инфоблока, но не о том, откуда пришли данные.
Слой оркестрации (Orchestrator) Управляет последовательностью запусков, приоритетами, обработкой ошибок и откатом при сбое.
Почему важна таблица приоритетов?
Ключевая задача — определить, какое поле из какого источника имеет приоритет. Нужна явная таблица приоритетов:
| Поле | Источник 1 (высший) | Источник 2 | Источник 3 |
|---|---|---|---|
| Цена | 1С (ERP) | Прайс поставщика | — |
| Остаток | 1С (склад) | Сайт поставщика | — |
| Описание | Ручной ввод | Сайт производителя | AI-генерация |
| Изображения | Ручная загрузка | Производитель | Поставщик |
Реализация: каждое поле имеет метаданные источника (SOURCE_* свойства). При обновлении данными низкого приоритета — проверяем, не заполнено ли поле источником высшего приоритета.
Как система справляется с нагрузкой?
Для каталога 50 000+ позиций синхронная обработка невозможна. Используем очереди:
Вариант 1: таблица-очередь в БД
CREATE TABLE parser_queue (
id SERIAL PRIMARY KEY,
task_type VARCHAR(50), -- 'price', 'stock', 'description', 'image'
element_id INT,
payload JSONB,
status VARCHAR(20) DEFAULT 'pending', -- pending/processing/done/error
attempts INT DEFAULT 0,
created_at TIMESTAMP DEFAULT NOW(),
processed_at TIMESTAMP
);
Воркеры берут задачи батчами по 100 записей, обрабатывают, обновляют статус.
Вариант 2: Redis Queues — для высокочастотных обновлений (цены, остатки). Быстрее БД, но нет персистентности без AOF.
Что происходит при сбое?
Система без мониторинга ломается незаметно. Обязательные метрики:
- Количество обработанных записей за последний цикл
- Количество ошибок и их типы
- Время последнего успешного запуска каждого коллектора
- Размер очереди (если растёт — воркеры не успевают)
Самовосстановление: задачи со статусом error и attempts < 3 автоматически возвращаются в pending через час — retry-логика без ручного вмешательства.
Кейс из нашей практики: оптовый магазин
Задача: 35 000 SKU, 4 поставщика с разными форматами данных (API, FTP-фид, парсинг сайта, email с Excel), обновление цен и остатков каждые 2 часа.
Архитектура:
- 4 коллектора (REST API, XML-фид с FTP, HTTP-парсер, Excel-reader)
- Единый трансформер с таблицей маппинга полей (конфигурируется в административной части)
- Writer через
D7 ORM(\Bitrix\Catalog\ProductTable) — документация - Таблица-очередь в PostgreSQL с 3 параллельными воркерами
- Prometheus-метрики + Grafana dashboard для мониторинга
Результат: система работает 14 месяцев, среднее время обработки полного цикла — 1 час 40 минут. Ручные вмешательства за этот период — 3 раза (два раза менял API поставщика, один раз упала структура сайта для парсера). Экономия на ручных операциях составила более 1 200 000 ₽ в год.
Что входит в работу
- Проектирование архитектуры автонаполнения с учётом ваших источников и каталога
- Разработка и настройка коллекторов, трансформеров и писателей
- Создание системы очередей и воркеров (Redis или БД)
- Интеграция мониторинга (Grafana + алерты)
- Административный интерфейс для просмотра очередей и логирования
- Документация по архитектуре и инструкция для операторов
- Обучение двух специалистов работе с системой
- Месяц сопровождения после внедрения
Таймлайн работ
| Этап | Срок |
|---|---|
| Проектирование архитектуры, таблица приоритетов | 1–2 дня |
| Разработка коллекторов (по 1–2 дня на источник) | 4–8 дней |
| Слой трансформации и нормализации | 2–3 дня |
| Writers, интеграция с Битриксом | 2–3 дня |
| Очереди, воркеры, система retry | 2–3 дня |
| Мониторинг, алерты, административный интерфейс | 2–3 дня |
| Тестирование на реальных данных | 3–5 дней |
Итого: 3–5 недель — это проект, а не задача. Сокращение ручных операций на 90% экономит до 1 000 000 ₽ в год на зарплате операторов.
Наши инженеры имеют сертификацию 1С-Битрикс, что гарантирует корректную интеграцию с ядром платформы. «Очереди — единственный путь для каталогов более 50 000 товаров» — эксперт Bitrix на форуме community.1c-bitrix.ru.
Свяжитесь с нами для оценки вашего проекта. Получите консультацию по архитектуре автонаполнения каталога. Закажите консультацию уже сегодня.