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

Мы разрабатываем административные интерфейсы для парсеров, которые превращают чёрный ящик cron-скрипта в управляемую систему. Без админки парсер понятен только автору: ошибки — в syslog, запуск — по расписанию, остановить или изменить источник может только разработчик с доступом к серверу. Полноценный интерфейс управления парсером — это инвестиция в управляемость: менеджер сам запускает парсинг, смотрит логи, правит селекторы. Наша команда имеет многолетний опыт разработки модулей для 1С-Битрикс, гарантируя стабильную работу даже при высоких нагрузках. Например, один из клиентов ранее тратил 20 часов в месяц на ручную закачку данных — после внедрения интерфейса менеджеры запускают парсинг за 2 минуты. Оценим ваш проект бесплатно — напишите нам.

Как устроен административный интерфейс управления парсером?

Почему стоит выбрать полноценный модуль вместо админ-страниц?

В 1С-Битрикс есть два пути создания админ-интерфейса:

1. Кастомный модуль (/local/modules/yourcompany.parser/) — полноценная структура с install/, admin/, lib/, регистрацией в системе модулей, пунктами меню в левой панели. Правильный путь для долгоживущих проектов.
2. Административные страницы (/local/admin/parser_*.php) — быстрее в реализации, но хуже масштабируется. Подходит для MVP.

Для интерфейса управления парсером рекомендую полноценный модуль. Причина — парсер обычно обрастает сущностями: источники, правила маппинга, расписания, логи. Всё это удобно группировать в рамках одного модуля с ORM-сущностями. Стандартный подход к разработке модулей в 1С-Битрикс описан в официальной документации.

Структура модуля

/local/modules/yourcompany.parser/
├── install/
│   ├── db/          — SQL миграции
│   └── index.php    — установка/удаление
├── admin/
│   ├── parser_source_list.php
│   ├── parser_source_edit.php
│   ├── parser_task_list.php
│   ├── parser_log_list.php
│   └── menu.php
├── lib/
│   ├── Source.php         — ORM-таблица источников
│   ├── Task.php           — ORM-таблица задач парсинга
│   ├── TaskLog.php        — ORM-таблица логов
│   ├── MappingRule.php    — правила маппинга полей
│   └── Engine/
│       ├── AbstractParser.php
│       ├── HttpClient.php
│       └── DomExtractor.php
└── lang/

Регистрация модуля стандартная — include.php в корне, Module::register() при установке, пункты меню через admin/menu.php с использованием $aMenuLinks[].

Экран 1: Управление источниками

Главный экран. Список источников парсинга в стандартном CAdminList с колонками:

Форма редактирования источника (CAdminForm / CAdminTabControl) содержит вкладки:

• Основное — имя, URL, статус, привязка к инфоблоку каталога (IBLOCK_ID).
• Правила парсинга — CSS-селекторы или XPath для полей: название, цена, артикул, описание, изображения. Каждое правило — строка с полями field_code, selector, type (text/html/attr/regex), transform (trim/number/replace).
• Расписание — cron-выражение или выбор из пресетов (каждый час, каждые 6 часов, ежедневно). Хранится в таблице источника, агент считывает и запускает.
• HTTP-настройки — User-Agent, таймаут, прокси, задержка между запросами, лимит страниц.

Экран 2: Задачи парсинга

Каждый запуск парсера создаёт запись в таблице parser_task:

CREATE TABLE parser_task (
    id SERIAL PRIMARY KEY,
    source_id INT REFERENCES parser_source(id),
    status VARCHAR(20) DEFAULT 'pending',  -- pending, running, completed, failed
    started_at TIMESTAMP,
    finished_at TIMESTAMP,
    total_items INT DEFAULT 0,
    created_items INT DEFAULT 0,
    updated_items INT DEFAULT 0,
    skipped_items INT DEFAULT 0,
    error_items INT DEFAULT 0,
    error_message TEXT
);

В списке задач — фильтр по источнику и статусу, цветовая индикация (зелёный — completed, красный — failed, жёлтый — running). Кнопки действий: Запустить заново, Остановить (устанавливает флаг status=cancelling, парсер проверяет флаг перед каждой итерацией).

Экран 3: Журнал ошибок

Построен поверх ORM-таблицы parser_task_log. Колонки: время, источник, уровень (info/warning/error), URL элемента, сообщение, контекст (JSON). Фильтрация по уровню и источнику обязательна — без неё лог нечитаем.

Для каждой записи ERROR уровня добавляем ссылку Открыть элемент — прямой URL на страницу товара в админке инфоблока (/bitrix/admin/iblock_element_edit.php?IBLOCK_ID=X&ID=Y).

Экран 4: Правила маппинга

Отдельная страница для визуального редактирования маппинга полей источника → свойства инфоблока. Таблица:

Маппинг хранится в JSON-поле источника или в отдельной таблице parser_mapping. Второй вариант удобнее для версионирования — можно откатить к предыдущему набору правил.

Почему стоит добавить тестовый парсинг?

Критически важная функция. Кнопка в форме редактирования источника запускает парсинг одного элемента по указанному URL и показывает результат прямо в интерфейсе: какие поля извлечены, какие значения получены, какие ошибки. Это позволяет менеджеру проверить селекторы без запуска полного цикла. Экономия времени на отладку — до 70%.

Реализация — AJAX-обработчик, принимающий source_id и test_url, вызывающий парсер в режиме dry_run=true (без записи в инфоблок) и возвращающий JSON с результатами.

Безопасность и права

Доступ к интерфейсу парсера — через проверку $APPLICATION->GetGroupRight('yourcompany.parser'). Назначайте права через стандартный механизм модулей: Настройки → Пользователи → Группы → Доступ к модулям. Минимум две роли: просмотр (логи, статусы) и управление (создание/редактирование источников, запуск).

Что входит в работу

• Разработка модуля с ORM-сущностями и миграциями
• Реализация всех экранов (источники, задачи, логи, маппинг)
• Тестовый парсинг в интерфейсе
• Настройка прав доступа
• Документация по эксплуатации
• Обучение менеджеров (1–2 часа)
• Поддержка в течение месяца после сдачи

Сроки по масштабу

Многолетний опыт разработки на 1С-Битрикс — более 30 проектов по интеграции парсеров. Стоимость разработки рассчитывается индивидуально после анализа ТЗ. Получите консультацию по вашему проекту — мы ответим в течение дня.

Разработка парсеров для 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-селекторы в парсере.

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