Налаштування парсера за розкладом (cron) для 1С-Бітрікс

Ми часто бачимо: сайт на Бітріксі з ручним оновленням цін та залишків — помилки, затримки, втрачені продажі. Одного разу до нас звернувся клієнт з каталогом з 15 000 товарів: ціни оновлювались раз на тиждень вручну через Excel. За місяць збитки від прострочених акцій склали 8% обороту. Разовий парсинг проблему не вирішує — потрібен автоматичний запуск за розкладом. Налаштування парсера за розкладом (cron) для 1С-Бітрікс — це ключове завдання для автоматизації оновлення даних. Ми підбираємо механізм (агенти Бітрікса vs системний cron), реалізуємо блокування паралельних запусків, налаштовуємо логування та алерти. Результат — дані оновлюються самі, без участі людини.

Як системний cron вирішує проблему оновлення даних?

Агенти (b_agent) — вбудований механізм Бітрікса. Вони працюють тільки коли на сайт заходить відвідувач і спрацьовує CAgent::CheckAgents(). При низькій відвідуваності агенти запізнюються. Режим точного запуску через cron вирішує проблему, але вимагає налаштування системного завдання. Наш досвід показує: для парсерів з частотою оновлення раз на 30 хвилин системний cron надійніший.

Системний cron — прямий виклик PHP-CLI. Жодної залежності від веб-сервера:

*/30 * * * * /usr/bin/php -f /var/www/site/local/scripts/parser_run.php >> /var/log/parser.log 2>&1

Для важких парсерів (10 000+ позицій) системний cron кращий — немає лімітів PHP-FPM за часом виконання. Ми гарантуємо стабільність запуску в будь-який час, навіть якщо сайт не навантажений.

Чому ми рекомендуємо системний cron для важких парсерів?

У проєкті з 50 000 товарів і оновленням кожні 30 хвилин агенти не справлялись: при відвідуваності 200 осіб на день виконання зсувалось на 10-15 хвилин. Перехід на системний cron усунув затримки — оновлення стало точним до секунди. Вартість підтримки знизилась на 30% завдяки автоматизації.

Як захистити парсер від паралельних запусків?

Парсер виконується 25 хвилин, cron запускає наступний через 30 — два екземпляри не перетнуться. Але якщо скрипт завис на 35 хвилин? Потрібен захист. Використовуємо блокування через файл або Redis:

$lockFile = '/tmp/parser_' . md5($parserName) . '.lock';
if (file_exists($lockFile) && (time() - filemtime($lockFile)) < 3600) {
    exit('Already running');
}
touch($lockFile);
// ... робота парсера ...
unlink($lockFile);

Для розподілених систем (кілька серверів) — блокування через Redis: SET lock:parser NX EX 3600. Вартість помилки при паралельному запуску — дублікати даних і навантаження на сервер. Ми враховуємо це в кожному проєкті.

Агенти чи cron: що обрати? Порівняння

Покрокове налаштування cron для парсера

1. Визначте команду запуску — повний шлях до PHP та скрипту. Перевірте версію: which php.
2. Налаштуйте логування — перенаправте stdout та stderr у файл з датою.
3. Додайте завдання в crontab — crontab -e, вкажіть розклад і команду.
4. Реалізуйте блокування — lock-файл або Redis.
5. Протестуйте — виконайте команду вручну, перевірте логи.
6. Налаштуйте алерти — надсилання сповіщень при помилках.

Цей алгоритм ми застосовуємо в кожному проєкті — він скорочує час налагодження на 40%.

Налаштування агентів Бітрікса для парсингу

Якщо все ж використовуємо агенти — реєструємо через CAgent::AddAgent():

CAgent::AddAgent(
    'MyParserAgent::Run();',  // функція-агент
    'mymodule',               // модуль
    'N',                      // не точний
    3600,                     // інтервал у секундах
    '',                       // дата першого запуску
    'Y',                      // активний
    date('d.m.Y H:i:s', time() + 3600)  // наступний запуск
);

Агент повинен бути зареєстрований у include.php модуля або в init.php. Для продакшену рекомендуємо комбінувати з системним cron через документацію 1С-Бітрікс. Це дає максимальну гнучкість і точність.

Що дає структуроване логування?

Парсер без логів — чорна скринька. Мінімальна схема:

file_put_contents($logFile, date('[Y-m-d H:i:s] ') . $message . PHP_EOL, FILE_APPEND);

Для продакшену — структуровані логи з рівнями (info/warning/error) і ротацією через logrotate. Алерт при помилці: якщо в логу за останній запуск є рядки з ERROR — надсилаємо email через \Bitrix\Main\Mail\Event. Це скорочує час реакції на збої та знижує витрати на підтримку вдвічі. Згідно з рекомендаціями Bitrix, такий моніторинг обов'язковий для критичних оновлень.

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

• Аудит поточного парсера або написання нового
• Вибір та налаштування механізму запуску (cron/агенти)
• Реалізація блокування паралельних запусків
• Налаштування логування та алертів
• Тестування розкладу та сценаріїв помилок
• Документація по доступах та роботі парсера
• Гарантія стабільності протягом тижня після запуску

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

Разом: 6–12 годин. Вартість розраховується індивідуально — оцінимо ваш проєкт за один робочий день.

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

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

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