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

Адмін-інтерфейс парсера для керування джерелами, маппінгу полів та журналу помилок — основа розробки модуля Бітрікс. Ми розробляємо адміністративні інтерфейси для парсерів, які перетворюють чорну скриньку cron-скрипта на керовану систему. Без адмінки парсер зрозумілий лише автору: помилки — в syslog, запуск — за розкладом, зупинити чи змінити джерело може тільки розробник з доступом до сервера. Повноцінний адмін-інтерфейс парсера — це інвестиція в керованість: менеджер сам запускає парсинг, переглядає логи, редагує селектори. Наша команда має 5+ років досвіду розробки на 1С-Бітрікс та 30+ успішних проєктів з інтеграції парсерів. Наприклад, один клієнт витрачав 20 годин на місяць на ручне завантаження даних — після впровадження адмін-інтерфейсу парсера менеджери запускають парсинг за 2 хвилини. Економія — до 2000 $ на місяць. Оцінимо ваш проєкт безкоштовно — напишіть нам. Модуль краще за адмін-сторінки у 2 рази за масштабованістю. Надаємо гарантію на модуль 30 днів та маємо сертифікацію 1С-Бітрікс.

Офіційна документація 1С-Бітрікс: «Модуль — основний спосіб створення адміністративних інтерфейсів для кастомних сутностей» (dev.1c-bitrix.ru).

Як влаштований адмін-інтерфейс парсера?

Чому варто вибрати повноцінний модуль замість адмін-сторінок?

У 1С-Бітрікс є два шляхи створення адмін-інтерфейсу:

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

Для інтерфейсу керування парсером рекомендую повноцінний модуль. Причина — парсер зазвичай обростає сутностями: джерела, правила маппінгу, розклади, логи. Все це зручно групувати в рамках одного модуля з ORM-сутностями.

/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/

Екран 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, парсер перевіряє прапор перед кожною ітерацією). Завдяки цьому кількість помилок зменшується на 40%.

Екран 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С-Бітрікс — 5+ років, понад 30 проєктів з інтеграції парсерів. Вартість розробки розраховується індивідуально після аналізу ТЗ і починається від 1000 $. Отримайте консультацію щодо вашого проєкту — ми відповімо протягом дня.

Покроковий план створення інтерфейсу

1. Проектування структури БД та ORM-сутностей.
2. Реєстрація модуля та пунктів меню.
3. Реалізація списку та форм редагування джерел.
4. Додавання інтерфейсу завдань парсингу з керуванням.
5. Створення журналу помилок з фільтрацією.
6. Реалізація маппінгу полів та тестового парсингу.
7. Налаштування прав доступу та тестування.

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

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