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

Парсер собрал 40 000 товаров с маркетплейса, но импорт в 1С-Битрикс закончился ошибками? Стандартный модуль импорта не умеет разбирать иерархию категорий, тянуть изображения по URL и маппить динамические атрибуты. Мы сталкивались с этим десятки раз — и выработали надёжный алгоритм интеграции. Разрабатываем адаптер, который превращает сырые данные в корректную структуру Битрикса. Берём интеграцию под ключ: от маппинга до настройки расписания обновлений. За 5 лет мы реализовали 50+ подобных интеграций для крупных каталогов.

Типичная ситуация: штатный импорт CSV Битрикса не поддерживает очереди элементов, что приводит к падению производительности. Из-за этого импорт 40 000 товаров занимает 2 часа с 30% ошибок. Адаптер для импорта данных решает эти проблемы за один прогон — время сокращается до 20 минут, ошибки — менее 1%.

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

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

• 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-импорт не поддерживает динамические колонки.

Как адаптер решает проблему нормализации категорий?

Адаптер разбирает строку категории, рекурсивно создаёт разделы через CIBlockSection::Add(). Маппинг путь → ID раздела кешируется в b_iblock_section, чтобы не пересоздавать уже существующие. Для 40 000 товаров с глубиной категорий до 5 уровней эта операция занимает около 10 минут — в 6 раз быстрее поштучного создания.

Почему пакетная запись критична?

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

Сравнение подходов: нативный импорт vs адаптер

Как настроить адаптер за 3 шага?

1. Создать маппинг полей. Указываем, какое поле парсера соответствует названию, цене, категории и свойствам. Если парсер добавляет новые атрибуты, адаптер автоматически расширяет инфоблок.
2. Проверить категории. Запускаем пробную нормализацию: адаптер создаёт дерево разделов из строки пути. Результат можно откатить, если категории не совпадают.
3. Запустить тестовый импорт. Импортируем 100-200 товаров, проверяем корректность данных и отсутствие дублей. После этого запускаем полный прогон.

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

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

Что входит в интеграцию?

Дополнительно предоставляем пакет документации, доступ к репозиторию и поддержку в течение месяца после запуска. Ручной импорт 40 000 товаров обходится в 30 000 ₽ за один прогон, адаптер сокращает эту сумму до 5 000 ₽. Экономия на администрировании составляет до 50 000 ₽ в месяц.

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

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

Типовые сроки

Оценка времени под каждый проект индивидуальна, но ориентируйтесь на диапазон: от 1 до 3 рабочих дней для стандартной интеграции. Мы гарантируем безошибочный импорт и предоставляем тестовый прогон на ваших данных.

Получите консультацию — оценим проект за один день и предложим дорожную карту. Закажите интеграцию парсера с Битриксом без головной боли.