Конфигурируемый мэппинг полей парсинга для 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+ лет, и ни один проект не обходится без правильного выбора парсера.

Какие проблемы решает парсинг?

• Первичное наполнение каталога — 15 000 карточек с описаниями, характеристиками, фото. Вручную это три месяца контент-менеджера; парсер — неделя с отладкой.
• Мониторинг цен конкурентов — сбор данных с Ozon, Wildberries, сайтов конкурентов. Конкурент снизил цену на ходовую позицию — узнаёте через два часа, а не через две недели.
• Агрегация поставщиков — пять прайсов в разных форматах (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 с очередью — чтобы не забить канал
• Инкрементальное обновление по хешу строки: изменилась строка — обновляем, нет — пропускаем
• 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-селекторы в парсере.

Свяжитесь для оценки вашего проекта — мы предложим оптимальное решение под ваш бюджет. Гарантируем стабильную работу парсеров и полную поддержку в течение всего срока использования.