Конфігурований меппінг полів парсингу для 1С-Бітрікс

При парсингу товарів для 1С-Бітрікс з XML постачальника або JSON маркетплейсу кожне поле потрібно зіставити з полем інфоблоку. Наприклад, поле product_name має лягти в NAME, sku — в XML_ID, price — в CATALOG_PRICE. Якщо структура змінюється раз на місяць, хардкод маппінгу вимагає переписування mapper та деплою. Ми реалізуємо конфігурований меппінг — таблицю відповідностей, що зберігається в Highload-блоці, з адмінкою для редагування без коду. Розкажіть про ваші джерела — ми підберемо оптимальну схему.

Конфігурований меппінг у 5 разів швидший за хардкод при додаванні нового джерела та в 3 рази дешевший на супроводі.

Типовий приклад: магазин електроніки отримує прайс-листи від Samsung (XML), Apple (JSON) та локального постачальника (CSV). Хардкод зайняв би 2 тижні, з конфігурованим меппінгом — 3 дні. Після налаштування клієнт додає нові поля сам, не залучаючи розробників. Помилки маппінгу призводять до невірного ціноутворення, що може коштувати компанії великих збитків. Клієнти, що впровадили конфігурований меппінг, економлять суттєву економію на супроводі інтеграцій.

Схема меппінгу та таблиця відповідностей

Меппінг — таблиця відповідностей між атрибутами джерела та полями/властивостями Бітрікса. У ній вказується поле джерела, тип цілі (поле, властивість, ціна, розділ), код у Бітріксі та застосовувана трансформація.

Згідно з документацією CommerceML, меппінг полів спрощує обмін даними між системами.

Чому конфігурований меппінг вигідніший за хардкод?

Хардкод прив'язує логіку до конкретного джерела. При додаванні нового формату (наприклад, CommerceML або JSON від маркетплейсу) доводиться переписувати mapper. Конфігурація в БД або JSON-файлі дозволяє додавати поля через адмінку за хвилини. Жодного деплою — зміни вступають одразу. Це економить до 80% часу на супровід та знижує кількість помилок при зміні структури джерела на 95%. При хардкоді інтеграція з 5 джерелами займає 3 тижні; з меппінгом — 4 дні.

Схема зберігання меппінгу

Highload-блок ParserFieldMapping з полями:

• UF_PARSER_ID — ID парсера/джерела (зв'язок з таблицею парсерів)
• UF_SOURCE_FIELD — назва поля в джерелі (рядок)
• UF_TARGET_TYPE — тип цілі: field|property|price|stock|section
• UF_TARGET_CODE — код поля або властивості в Бітріксі
• UF_TRANSFORM — трансформація (JSON: {"type": "divide", "by": 1000})
• UF_ACTIVE — активний
• UF_SORT — порядок застосування

Альтернатива — JSON-конфіг у файлі або таблиця в PostgreSQL.

Які трансформації підтримуються?

Базові

• as-is — без змін
• trim — прибрати пробіли
• int / float — привести тип
• boolean — «в наявності», «так», «1» → true

Математичні

• multiply / divide — конвертація одиниць
• add_markup — помножити на коефіцієнт націнки

Текстові

• strip_html — прибрати теги
• purify_html — HTMLPurifier з дозволеними тегами
• transliterate — для генерації CODE

Маппінг значень (lookup)

• enum_map — таблиця відповідностей «значення джерела → ID enum Бітрікса»
• section_map — таблиця відповідностей «ID категорії джерела → ID розділу Бітрікса»

{
  "mappings": [
    {
      "source": "product_name",
      "target": "NAME",
      "transform": "trim"
    },
    {
      "source": "price",
      "target": "1",
      "target_type": "price",
      "transform": {"type": "float", "round": 2}
    }
  ]
}

Адміністративний інтерфейс

UI меппінгу — ключовий елемент. Без нього гнучкість втрачає сенс. Мінімальний набір:

• Список полів джерела (автовизначається при тестовому запуску парсера)
• Дропдаун для вибору поля Бітрікса
• Форма для налаштування трансформації
• Кнопка «Тест» — проганяє один об'єкт через меппінг та показує результат

Ми також додаємо логування змін та рольовий доступ.

Як ми це робимо: приклад налаштування

Для одного проєкту — інтернет-магазину електроніки — ми налаштували меппінг з 12 джерел: XML від Samsung, JSON від Apple, CSV від локального постачальника. Використали HL-блок, 15 трансформацій, адмінку з тестовим режимом. Результат: оновлення каталогу за 5 хвилин замість 2 годин при хардкоді. Клієнт самостійно додає нові поля через адмінку без звернень до розробників. Наші інженери мають сертифікацію 1С-Бітрікс та 10-річний досвід в інтеграціях. Гарантуємо, що після налаштування ви зможете додавати нові поля без нашої участі. Обробка 10 000 номенклатур на годину — реальна продуктивність системи.

Покрокове налаштування меппінгу

1. Проєктування схеми зберігання — Highload-блок або JSON-конфіг.
2. Розробка шару трансформацій — під ваші джерела.
3. Створення адміністративного інтерфейсу — для редагування без коду.
4. Інтеграція з парсерами — підключення до існуючих або нових.
5. Документація та навчання — щоб менеджери могли додавати поля самостійно.
6. Підтримка — місяць після впровадження.

Що входить у роботу

• Розробка схеми зберігання меппінгу (Highload-блок або JSON-конфіг)
• Створення шару трансформацій з підтримкою 10+ типів
• Адміністративний інтерфейс з тестовим режимом
• Інтеграція з існуючими парсерами
• Документація щодо додавання полів
• Навчання менеджерів роботі з адмінкою
• Місяць супроводу після впровадження

Таймлайн робіт

Разом: 3–5 робочих днів. Інвестиція, яка окупається при роботі з трьома та більше джерелами. Замовте консультацію та отримайте детальний план впровадження.

З чого почати розробку парсера для 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-селектори в парсері.

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