Разработка системы автонаполнения каталога 1С-Битрикс

Когда каталог товаров растёт, ручное обновление перестаёт работать

Десятки изменений от поставщиков ежедневно, устаревшие данные в каталоге, потеря продаж из-за неактуальных цен — стандартная ситуация для растущего 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) Управляет последовательностью запусков, приоритетами, обработкой ошибок и откатом при сбое.

Почему важна таблица приоритетов?

Ключевая задача — определить, какое поле из какого источника имеет приоритет. Нужна явная таблица приоритетов:

Реализация: каждое поле имеет метаданные источника (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-логика без ручного вмешательства.