Парсинг XML-фідів постачальників для 1С-Бітрікс

Ручний імпорт XML-фіда від постачальника в 1С-Бітрікс перетворюється на пекло, коли каталог налічує десятки тисяч товарів. Помилки мапінгу, дублі, втрачені залишки — знайомо? Ми — команда сертифікованих бітрікс-розробників з 5+ років досвіду та більш ніж 50 успішних інтеграцій — автоматизуємо цей процес під ключ. Налаштуємо парсинг будь-якого XML, мапінг в інфоблоки та синхронізацію за розкладом з гарантією та підтримкою. Наприклад, при 50 000 товарах ручний імпорт займає 2-3 дні, а автоматизований парсинг — 15 хвилин.

Що таке XML-фід постачальника і чому він кращий за Excel?

XML-фід — це структурований файл з актуальними даними по товарах: цінами, залишками, описами, характеристиками. На відміну від Excel-прайсу, XML передбачуваний: у нього є схема, і його можна парсити надійно з мінімальними помилками. Але «передбачуваний» не означає «стандартний» — кожен постачальник винаходить свій XML-формат.

Вибір парсера для великого XML-фіда

Для файлів до 50 МБ достатньо SimpleXML. Він завантажує весь документ у пам'ять, що дає максимальну швидкість. Для фідів із сотнями тисяч товарів (наприклад, 500 000 позицій) SimpleXML «з'їсть» більше 1 ГБ RAM — XMLReader працює потоково і споживає в 10 разів менше пам'яті. Приклад використання XMLReader:

$reader = new XMLReader();
$reader->open($filePath);
while ($reader->read()) {
    if ($reader->nodeType === XMLReader::ELEMENT && $reader->name === 'offer') {
        $node = new SimpleXMLElement($reader->readOuterXml());
        // обробка одного товару
    }
}

Правильний вибір парсера знижує навантаження на сервер в 5-10 разів і економить до 70% часу на обробку. XMLReader — стандартний вибір для каталогів від 100 000 позицій.

Як мапити атрибути фіда у властивості інфоблока?

Багато постачальників зберігають характеристики як список <param> елементів з атрибутом name. Витягуємо в масив:

$params = [];
foreach ($offer->param as $param) {
    $name = (string)$param['name'];
    $value = (string)$param;
    $params[$name] = $value;
}

Потім через CIBlockElement::SetPropertyValueCode зберігаємо в інфоблок. Для властивостей-списків попередньо створюємо елемент списку, якщо його немає.

Процес роботи над інтеграцією

1. Аналітика — розбираємо структуру XML, виявляємо особливості, узгоджуємо мапінг.
2. Проектування — обираємо парсер, архітектуру зберігання (інфоблоки / HL-блоки).
3. Розробка — пишемо парсер, налаштовуємо мапінг, обробку помилок.
4. Тестування — завантажуємо тестовий фід, перевіряємо коректність даних, продуктивність.
5. Розгортання — налаштовуємо cron, логування, сповіщення про помилки.

Деталі реалізації: конфігурований мапінг та обробка помилок

Постачальники часто змінюють структуру XML без попередження. Ми розробляємо парсер з конфігурованим мапінгом у YAML-файлі — для адаптації достатньо змінити налаштування, а не код. Логування всіх помилок та сповіщення в Telegram або email гарантують, що проблема не залишиться непоміченою.

Що входить у результат

• Аналіз XML-фіда та консультація
• Розробка парсера з урахуванням усіх особливостей
• Налаштування мапінгу в інфоблоки Бітрікс
• Організація синхронізації за розкладом
• Тестування та виправлення помилок
• Документація та інструкція для адміністратора
• Гарантійна підтримка після запуску

Терміни та вартість оцінюємо індивідуально після аналізу фіда. Отримайте консультацію — надішлемо типовий план робіт та оцінимо трудомісткість.

Як уникнути типових помилок при парсингу?

Часта проблема — постачальник змінює атрибути без попередження. Рішення: конфігурований мапінг через YAML-файл або окремий клас, щоб адаптуватися без перезапуску. Інша помилка — не враховувати кодування: XML в UTF-8, а сайт в CP1251. Перетворюємо рядки відразу при читанні.

Чому інкрементальна синхронізація вигідніша?

Повне перезавантаження простіше, але при 50 000+ позиціях займає години. Інкрементальна синхронізація оновлює тільки змінені рядки за хешем або полем modified. Рекомендуємо інкрементальний підхід для каталогів, що оновлюються частіше ніж раз на добу: він знижує навантаження на сервер та час вікна синхронізації.

Кейс з практики: розбирали фід постачальника з 150 000 товарів і 30 параметрами в кожному. Використовували XMLReader, мапінг через XPath. Час завантаження — 15 хвилин замість 3 годин при повному перезавантаженні. Згідно з документацією 1С-Бітрікс, «для великих обсягів даних рекомендується використовувати потоковий парсер XMLReader».

Налаштовуємо cron:

0 */3 * * * /usr/bin/php /home/bitrix/www/local/cron/supplier_xml_import.php

Ціни та залишки — кожні 2-4 години, описи — раз на добу. Після кожного запуску — детальний лог з кількістю оновлень та помилок, при збої — сповіщення адміністратору.

Хочете забути про ручне завантаження прайсів? Зв'яжіться з нами — розберемо ваш XML і запропонуємо оптимальне рішення за 1 день. Отримайте консультацію: ми оцінимо складність і запропонуємо рішення під ваш бюджет.

З чого почати розробку парсера для 1С-Бітрікс?

XMLReader, а не SimpleXML — вибір інструмента визначає долю проекту. SimpleXML завантажує весь XML у пам’ять, і при файлі постачальника на 800 МБ PHP впаде з fatal error на ліміті 512 МБ. XMLReader обробляє потоково, node за node, споживаючи 20–30 МБ — в 30 разів ефективніше. З цієї деталі стартує будь-яка розробка парсерів під Бітрікс. Ми робимо такі системи вже понад 10 років, реалізували 50+ проектів, і жоден не обходиться без правильного вибору парсера.

Проблеми, які вирішує парсинг

• Первинне наповнення каталогу — 15 000 карток з описами, характеристиками, фото. Вручну це три місяці контент-менеджера; парсер — тиждень з налагодженням. Економія часу — до 90%.
• Моніторинг цін конкурентів — збір даних з Ozon, Wildberries, сайтів конкурентів. Конкурент знизив ціну на ходову позицію — дізнаєтеся через дві години, а не через два тижні. Окупається за 2–3 місяці.
• Агрегація постачальників — п’ять прайсів у різних форматах (CSV з CP1251, XML у CommerceML, Excel з об’єднаними комірками) перетворюються на єдиний каталог із загальною системою властивостей інфоблоку.
• Збагачення карток — підтягуємо характеристики, інструкції, 3D-моделі з сайтів виробників. Без цього картка товару — пустушка для SEO.
• Оновлення асортименту — товари, які зникли з фіду постачальника, деактивуються через CIBlockElement::Update($ID, ['ACTIVE' => 'N']). Нові — створюються. Каталог синхронізовано.

Інструменти для розробки парсерів

Статичні сайти — PHP (Goutte, Symfony DomCrawler) або Python (Scrapy, lxml). Швидкість: 50–100 сторінок/сек. Вистачає для каталогів без JS-рендерингу.

SPA та динамічні сайти — Puppeteer або Playwright. Нескінченний скрол, AJAX-фільтри, lazy-load картинок — headless-браузер все це обробить. Швидкість падає до 1–10 сторінок/сек, але альтернативи немає: дані існують лише після виконання JavaScript.

Файли постачальників:

• Excel (XLS, XLSX) — PhpSpreadsheet. Обережно з об’єднаними комірками та формулами — вони ламають автоматичний мапінг.
• CSV — fgetcsv() з правильною кодуванням. Постачальники люблять CP1251, BOM у UTF-8 та крапку з комою замість коми. Все це потрібно детектувати та обробляти.
• XML/YML — XMLReader для великих файлів, SimpleXML для фідів до 50 МБ.
• CommerceML — стандартний формат обміну з 1С. Розбираємо import.xml та offers.xml, мапимо на структуру інфоблоків.

API — REST-ендпоінти постачальників, API маркетплейсів (Ozon Seller API, Wildberries API). Працюємо в рамках rate limits, обробляємо пагінацію.

Як влаштований пайплайн автонаповнення?

Чотири етапи. Кожен може зламатися по-своєму.

1. Збір. Парсер обходить джерела по cron-розкладу. Сирі дані пишемо в проміжну таблицю — не одразу в b_iblock_element. Логуємо все: скільки сторінок обійшли, скільки елементів розпарсили, де отримали 403 або timeout. Без логів налагодження парсера — ворожіння на кавовій гущі.

2. Нормалізація. Тут основна робота:

   • Очищення HTML-тегів, зайвих пробілів, Unicode-сміття
   • Одиниці виміру: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
   • Мапінг категорій постачальника → розділи інфоблоку Бітрікс. В одного постачальника «Ноутбуки», в іншого «Ноутбуки та планшети», у третього «Laptops» — все в одну секцію
   • Дедуплікація за артикулом, EAN/GTIN. Один товар від трьох постачальників не повинен з’явитися тричі

3. Завантаження в Бітрікс. Через CIBlockElement::Add() для нових елементів, CIBlockElement::Update() для існуючих. Зображення: завантажуємо, ресайзимо через CFile::ResizeImageGet(), конвертуємо в WebP. Властивості — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генеруємо з транслітерації назви.

4. Оновлення. Ключовий момент — не затерти ручні правки контент-менеджера. Оновлюємо лише ціну, залишки, активність. Опис та фото, доопрацьовані вручну, позначаємо прапорцем UF_MANUAL_EDIT у властивостях елемента і пропускаємо при імпорті. Товари, що зникли з фіду — деактивуємо, але не видаляємо.

Моніторинг цін конкурентів: необхідність та реалізація

Окрема підсистема зі своєю специфікою:

Результат — дашборд: ваш товар vs конкуренти, історія цін, тренди. Менеджер бачить, де можна підняти ціну без втрати позиції, а де потрібно реагувати.

Модуль імпорту CSV/XML: налаштування під ваш формат

Для файлів від постачальників — кастомний модуль з адмінкою:

• Налаштовуваний мапінг: «колонка B у файлі → властивість BRAND інфоблоку»
• Автодетект кодування (CP1251, UTF-8, UTF-16) через mb_detect_encoding() з перевіркою
• Завантаження зображень за URL з чергою агентів Bitrix — щоб не забити канал
• Інкрементальне оновлення за хешем рядка: змінився рядок — оновлюємо, ні — пропускаємо
• Cron-розклад, звіт: створено 145, оновлено 892, помилок 3 (з деталями)

Великі файли: CSV обробляємо батчами по 1000 рядків через fgetcsv(), XML потоково через XMLReader, фонове виконання через чергу агентів Бітрікс — ніяких PHP-таймаутів.

Правова сторона — що важливо врахувати

• robots.txt — поважаємо. Crawl-delay — дотримуємося.
• Частота запитів — 1–2 в секунду, не більше. Не потрібно DDoS-ити чужий сайт.
• Контент виробників — використовуємо. Унікальні авторські тексти — не копіюємо.
• Персональні дані — не збираємо.

Що входить в розробку парсера під ключ?

Скільки часу займає розробка парсера?

Процес і терміни:

1. Прототип — парсер для 1–2 джерел за 2–3 дні. Оцінюємо якість даних, підводні камені (захист Cloudflare, капча, динамічне підвантаження).
2. Розробка — повний пайплайн: парсер → нормалізація → імпорт в Бітрікс → адмінка для управління.
3. Тестування — проганяємо на повному обсязі каталогу, перевіряємо edge-кейси (порожні поля, кривий HTML, биті картинки).
4. Запуск — налаштовуємо cron, моніторинг помилок через Telegram-бот.
5. Підтримка — конкурент переробив верстку? Оновлюємо CSS-селектори в парсері.

Отримайте консультацію: розкажіть про своє джерело даних — ми підберемо оптимальний підхід. Зв’яжіться для оцінки вашого проекту — запропонуємо рішення під ваш бюджет. Гарантуємо стабільну роботу парсерів і повну підтримку.