Інтеграція парсера з модулем імпорту 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().