Розробка адмін-інтерфейсу для парсера 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. Налаштування прав доступу та тестування.