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

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

• Первичное наполнение каталога — 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-селекторы в парсере.

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