Розробка системи оповіщень для адміністраторів 1С-Бітрікс

Розробка системи сповіщень для адміністраторів 1С-Бітрікс

Адміністратор Бітрікс-сайту повинен дізнаватися про критичні подій швидко: нове замовлення, помилка оплати, заповнена форма зворотного зв'язку, падіння агента, перевищення дискової квоти. Стандартні поштові события Бітрікса покривають частину цих сценаріїв, але для повнофункціональної системи сповіщень їх недостатньо.

Стандартні поштові события Бітрікса

Ядро Бітрікса використовує механізм поштових событій: код события → шаблон листа → отримувачі. Усі события реєструються в таблиці b_event, шаблони — в b_event_message, а історія відправлених листів (при включеному логуванні) — в b_event_log.

Для e-commerce критичні события вже існують: SALE_ORDER_NEW (нове замовлення), SALE_ORDER_PAID (оплата отримана), SALE_ORDER_CANCEL (скасування). Отримувачів налаштуйте в шаблоні события через /bitrix/admin/sale_delivery_handler.php або через модуль main → «Поштові события».

Проблема стандартного механізму: листи відправляються синхронно в момент события, що гальмує відповідь сервера при повільному SMTP. Рішення — чергу відправки через таблицю b_email_service або зовнішній SMTP з швидким з'єднанням.

Спеціальні сповіщення через события модулів

Для нестандартних сценаріїв вішаєтеся на события модулів в init.php. Перелік корисних точок:

Нова заявка з форми — OnAfterAddResult модуля form:

AddEventHandler("form", "OnAfterAddResult", function($formId, $resultId, $arResult) {
    if ($formId == CALLBACK_FORM_ID) {
        notifyAdmin('Нова заявка #' . $resultId, formatFormData($arResult));
    }
});

Помилка в агентах — агенти в b_agent виконуються без явного логування. Оборвюйте код агента в try-catch та при винятку відправляйте сповіщення:

function MyModuleAgent() {
    try {
        // код агента
    } catch (\Throwable $e) {
        notifyAdmin('Помилка агента', $e->getMessage() . "\n" . $e->getTraceAsString());
    }
    return __FUNCTION__ . '();';
}

Перевищення лімітів диска — у Бітриксі є агент CIBlockAgent::CheckDiskQuota(). Його можна переопредилити або доповнити своїм агентом, що перевіряє розмір директорій та відправляє сповіщення при перевищенні порога.

Помилки оплати —況Event OnSalePaymentUpdate з перевіркою смены статусу на помилковий:

AddEventHandler("sale", "OnSalePaymentUpdate", function($id, &$arFields) {
    if ($arFields['IS_RETURN'] === 'Y' || strpos($arFields['PS_STATUS_MESSAGE'], 'error') !== false) {
        notifyAdmin('Помилка оплати замовлення', print_r($arFields, true));
    }
});

Багатоканальна доставка сповіщень

Email — базовий канал, але не завжди достатньо швидкий. Для критичних сповіщень додавайте:

Telegram-бот. Створюєте бота через BotFather, отримуєте BOT_TOKEN та CHAT_ID адміністраторського чату. Відправка через \Bitrix\Main\Web\HttpClient:

function notifyTelegram(string $message): void {
    $botToken = COption::GetOptionString('local', 'telegram_bot_token');
    $chatId = COption::GetOptionString('local', 'telegram_admin_chat_id');

    $httpClient = new \Bitrix\Main\Web\HttpClient();
    $httpClient->post(
        "https://api.telegram.org/bot{$botToken}/sendMessage",
        ['chat_id' => $chatId, 'text' => $message, 'parse_mode' => 'HTML']
    );
}

Зберігайте токени в b_option через COption, не в коді — при ротації токена не потрібно шукати по файлам.

SMS через API. Для дійсно критичних событій (недоступність платіжного шлюзу, спроби взлому) — SMS через SMSC.ru або SMS.ru. Ті ж HttpClient + API-ключ.

Push-сповіщення в браузер. Для сповіщень, коли адміністратор в адміністративній панелі — через системний Bitrix Push Server (push.1c-bitrix.ru) або через Web Push API з VAPID-ключами (див. окрему реалізацію).

Центр сповіщень в адміністративній панелі

Крім зовнішніх каналів, корисний внутрішній «журнал сповіщень» прямо в /bitrix/admin/. Реалізується як інфоблок або спеціальна таблиця b_local_notifications з полями TYPE, MESSAGE, IS_READ, DATE_CREATE.

В адміністративному меню додавайте посилання на список сповіщень через /bitrix/admin/menu_ext.php. Непрочитані сповіщення показуються лічильником у боковому меню через спеціальний адміністративний віджет.

Фільтрація та пріоритети

Не всі события однаково важливі. Встановіть пріоритети:

• Критично → негайно → Telegram + SMS: падіння сайту, помилка оплати, взломна активність
• Важливо → протягом години → Email: нове замовлення, нова заявка, закінчення строку ліцензії
• Інформаційно → дайджест раз в день → Email: статистика замовлень, нові реєстрації, активність форм

Дайджест реалізується через агент: збирає события за добу з лога, формує лист та відправляє о 9:00 наступного дня. Це знижує інформаційний шум для менеджерів.

Моніторинг технічного стану

Окрема категорія сповіщень — технічний стан сайту:

• Доступність сайту — зовнішній моніторинг (UptimeRobot, Zabbix) важливіше внутрішнього, тому що при падінні сервера внутрішні агенти не відпрацюють
• Помилки PHP — налаштуйте запис у файл + агент, що читає файл помилок та відправляє нові критичні записи адміністратору
• Розмір черги задач — таблиця b_agent: якщо записів з NEXT_EXEC у минулому накопичується більше норми, щось не працює

Таблиця b_event_log при включеному логуванні швидко зростає. Налаштуйте регулярну очистку через агент або крон: видаляйте записи старше 30 днів, зберігаючи тільки критичні события.