Интеграция парсера с модулем импорта 1С-Битрикс

Интеграция парсера с модулем импорта 1С-Битрикс

Стандартный парсер отдаёт данные в CSV или JSON, а модуль импорта 1С-Битрикс (bitrix.catalog) ожидает конкретную структуру: поля товара, привязку к разделам, изображения, свойства. Без адаптера между ними данные либо не импортируются, либо импортируются с ошибками — дублируются записи, теряются свойства, ломается дерево категорий.

Как работает модуль импорта в Битриксе

Нативный импорт каталога использует модуль catalog и компонент bitrix:catalog.import.csv. Таблицы, с которыми работает импорт:

• b_iblock_element — элементы инфоблока (товары)
• b_iblock_element_prop_s* / b_iblock_element_prop_m* — значения свойств
• b_catalog_price — цены
• b_catalog_product — параметры товара (вес, размеры, тип)

Стандартный CSV-импорт через CIBlockElement::Add() и CIBlockElement::Update() — рабочий, но не масштабируется при объёмах от 10 000 товаров: каждый вызов делает отдельный запрос к БД.

Где ломается наивная интеграция

Кейс. Парсер собирает 40 000 товаров с маркетплейса, пишет в CSV с колонками name, price, category_path, images[], attrs{}. Запускается стандартный импорт — через 2 часа завершается с 30% ошибок:

• Категории создаются как плоский список вместо дерева, потому что парсер пишет путь строкой «Электроника / Смартфоны / Apple», а импортёр не разбирает иерархию.
• Изображения не подтягиваются — парсер передаёт URL, импортёр ожидает локальный путь или base64.
• Свойства (атрибуты) игнорируются — CSV-импорт не поддерживает динамические колонки.

Архитектура правильной интеграции

Парсер → Адаптер (PHP/Python) → Промежуточный формат → Битрикс API

Адаптер выполняет три задачи:

1. Нормализация категорий. Разбирает путь категории, рекурсивно создаёт разделы через CIBlockSection::Add(), кеширует маппинг путь → ID раздела в b_iblock_section.

2. Загрузка изображений. Скачивает файлы по URL во временную директорию, передаёт пути в CFile::MakeFileArray(), после успешного импорта очищает временные файлы.

3. Маппинг свойств. Динамические атрибуты из attrs{} матчатся со свойствами инфоблока через CIBlockProperty::GetList(). Отсутствующие свойства создаются автоматически с типом S (строка) или N (число).

Пакетная запись для больших объёмов

Вместо поштучного CIBlockElement::Add() используем событийную модель и очереди:

// Отключаем поиск и события на время импорта
CIBlock::DisableOptimization();
$GLOBALS['BX_DONT_WRITE_INDEX'] = true;

// Пакет по 500 элементов через транзакцию
$DB->StartTransaction();
foreach ($batch as $item) {
    $el = new CIBlockElement();
    $el->Add($fields, false, false, false);
}
$DB->Commit();

После импорта вручную перестраиваем поисковый индекс: CSearch::ReIndexAll() или bitrix:search.reindex через агент.

Синхронизация при обновлениях

Повторный запуск парсера не должен создавать дубли. Стратегия: внешний ID товара (артикул или URL источника) хранится в свойстве инфоблока EXTERNAL_ID или в b_iblock_element.XML_ID. Перед созданием проверяем наличие через CIBlockElement::GetList(['=XML_ID' => $externalId]) — обновляем существующий или создаём новый.

Расписание и мониторинг

Повторяющийся парсинг запускается через агенты Битрикса (b_agent таблица) или системный cron. Агент вызывает метод адаптера, который логирует результат в пользовательский инфоблок или таблицу — дата запуска, количество обработанных/ошибочных записей. При ошибке более 5% — отправляет уведомление администратору через CEvent::Send().