Integrating the parser with the 1C-Bitrix import module

Parser Integration with the 1C-Bitrix Import Module

A standard parser outputs data as CSV or JSON, while the 1C-Bitrix import module (bitrix.catalog) expects a specific structure: product fields, section assignments, images, and properties. Without an adapter between them, data either fails to import or imports with errors — records are duplicated, properties are lost, and the category tree breaks.

How the Bitrix Import Module Works

The native catalog import uses the catalog module and the bitrix:catalog.import.csv component. Tables involved in the import:

• b_iblock_element — infoblock elements (products)
• b_iblock_element_prop_s* / b_iblock_element_prop_m* — property values
• b_catalog_price — prices
• b_catalog_product — product parameters (weight, dimensions, type)

The standard CSV import via CIBlockElement::Add() and CIBlockElement::Update() works but does not scale for volumes above 10,000 products: each call issues a separate database query.

Where Naive Integration Breaks

Scenario. A parser collects 40,000 products from a marketplace and writes them to a CSV with columns name, price, category_path, images[], attrs{}. The standard import is launched — after 2 hours it finishes with 30% errors:

• Categories are created as a flat list instead of a tree, because the parser writes the path as a string "Electronics / Smartphones / Apple" and the importer does not parse the hierarchy.
• Images are not loaded — the parser passes URLs, the importer expects a local path or base64.
• Properties (attributes) are ignored — the CSV importer does not support dynamic columns.

Correct Integration Architecture

Parser → Adapter (PHP/Python) → Intermediate format → Bitrix API

The adapter performs three tasks:

1. Category normalization. Parses the category path, recursively creates sections via CIBlockSection::Add(), and caches the mapping path → section ID in b_iblock_section.

2. Image loading. Downloads files by URL to a temporary directory, passes the paths to CFile::MakeFileArray(), and cleans up temporary files after a successful import.

3. Property mapping. Dynamic attributes from attrs{} are matched against infoblock properties via CIBlockProperty::GetList(). Missing properties are created automatically with type S (string) or N (number).

Batch Writing for Large Volumes

Instead of record-by-record CIBlockElement::Add(), use an event-driven model and queues:

// Disable search indexing and events during import
CIBlock::DisableOptimization();
$GLOBALS['BX_DONT_WRITE_INDEX'] = true;

// Batch of 500 elements in a transaction
$DB->StartTransaction();
foreach ($batch as $item) {
    $el = new CIBlockElement();
    $el->Add($fields, false, false, false);
}
$DB->Commit();

After the import, rebuild the search index manually: CSearch::ReIndexAll() or bitrix:search.reindex via an agent.

Synchronization on Updates

A repeated parser run must not create duplicates. Strategy: the product's external ID (SKU or source URL) is stored in the infoblock property EXTERNAL_ID or in b_iblock_element.XML_ID. Before creating, check for existence via CIBlockElement::GetList(['=XML_ID' => $externalId]) — update the existing record or create a new one.

Schedule and Monitoring

Recurring parsing is launched via Bitrix agents (b_agent table) or system cron. The agent calls the adapter method, which logs the result to a custom infoblock or table — run date, number of processed/failed records. If the error rate exceeds 5%, an admin notification is sent via CEvent::Send().