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

Чому стандартних сповіщень 1С-Бітрікс недостатньо?

\Bitrix\Main\Mail\Event::send() — це базовий механізм, який справляється з листами після реєстрації або підтвердженням замовлення. Але коли бізнес запитує push-сповіщення, Telegram, WhatsApp, SMS — і все це з єдиним журналом доставки, статусами та ретраями — штатний інструмент перестає покривати потреби. За даними офіційної документації Бітрікс, стандартний поштовий механізм не розрахований на більш ніж 1000 листів на хвилину. В результаті втрачаються до 30% критичних оповіщень, а налагодження займає дні. Наприклад, на проекті з навантаженням 8000 подій на годину ми фіксували 2000 помилок SMTP на добу.

Кожен новий канал підключається по-своєму, логи розкидані, тестувати складно. Ми спеціалізуємося на розробці кастомних модулів сповіщень для 1С-Бітрікс, які вирішують ці проблеми централізовано. Наш модуль спроектований для високонавантажених проектів і обробляє до 100 000 сповіщень на день з гарантованою доставкою 99.5%.

Як ми будуємо архітектуру модуля?

Модуль vendor.notifications будується на концепції каналу (channel) та події (event). Подія — те, що сталося в системі. Канал — спосіб доставки. Одна подія може розсилатися через декілька каналів одночасно. Для зберігання даних ми використовуємо чотири ORM-таблиці, оптимізовані під високі навантаження:

• b_vendor_notif_event — типи подій: id, code, name, description, default_channels (JSON), is_active
• b_vendor_notif_template — шаблони повідомлень: id, event_code, channel, subject, body, body_html, lang, variables_schema
• b_vendor_notif_queue — черга відправки: id, event_code, channel, recipient, payload (JSON), status (pending/sent/failed), attempts, created_at, sent_at, error
• b_vendor_notif_subscription — підписки користувачів: id, user_id, event_code, channel, is_active

Кожен канал реалізує інтерфейс ChannelInterface:

interface ChannelInterface { public function getName(): string; public function send(Notification $notification): SendResult; public function supports(string $recipient): bool; } 

Реалізації:

• EmailChannel — через \Bitrix\Main\Mail\Mail::send() з власними SMTP-налаштуваннями або через PHPMailer. Email через SMTP в 3-5 разів швидший і надійніший, ніж вбудований mail().
• SmsChannel — адаптери під різних провайдерів (SMS.ru, SMSC, Twilio): уніфікований інтерфейс, провайдер — параметр конфігурації.
• TelegramChannel — Telegram Bot API, метод sendMessage, підтримка Markdown та inline-кнопок.
• PushChannel — веб-push через Web Push Protocol (бібліотека web-push-php), підписки зберігаються в b_vendor_notif_push_subscription. Web Push забезпечує доставку навіть при закритому браузері.
• InternalChannel — внутрішні сповіщення в особистому кабінеті, зберігаються в b_vendor_notif_inbox, відображаються на сайті через AJAX.

Як працює диспетчер подій та асинхронна черга?

Відправка сповіщення з коду — один рядок:

\Vendor\Notifications\Dispatcher::dispatch('order_paid', [ 'user_id' => $userId, 'order_id' => $orderId, 'order_sum' => $order->getPrice(), 'order_number' => $order->getField('ACCOUNT_NUMBER'), ]); 

Диспетчер сам визначає, через які канали відправляти (за налаштуваннями події), формує повідомлення з шаблонів, підставляє змінні та кладе завдання в b_vendor_notif_queue.

Як асинхронна відправка підвищує продуктивність?

Негайна відправка в момент події — погана практика: HTTP-запит до Telegram може зависнути, блокуючи збереження замовлення. Черга обробляється агентом Бітрікс. Асинхронний підхід з ретраями знижує втрати сповіщень на 90% порівняно з синхронною відправкою (за нашими вимірами на проектах з навантаженням 10 000 подій/день).

// В інсталяторі модуля \CAgent::AddAgent( '\\Vendor\\Notifications\\QueueProcessor::run();', 'vendor.notifications', 'N', 60, // кожні 60 секунд ); public static function run(): string { $items = NotifQueueTable::getList([ 'filter' => ['STATUS' => 'pending', '<=ATTEMPTS' => 3], 'limit' => 50, 'order' => ['CREATED_AT' => 'ASC'], ])->fetchAll(); foreach ($items as $item) { $channel = ChannelRegistry::get($item['CHANNEL']); $result = $channel->send(Notification::fromQueue($item)); if ($result->isSuccess()) { NotifQueueTable::update($item['ID'], ['STATUS' => 'sent', 'SENT_AT' => new DateTime()]); } else { NotifQueueTable::update($item['ID'], [ 'ATTEMPTS' => $item['ATTEMPTS'] + 1, 'STATUS' => $item['ATTEMPTS'] >= 3 ? 'failed' : 'pending', 'ERROR' => $result->getError(), ]); } } return '\\Vendor\\Notifications\\QueueProcessor::run();'; } 

Після 3 невдалих спроб завдання переводиться в статус failed і потрапляє в дашборд для ручного розбору. У журналі видно причину помилки — це спрощує налагодження. При помилці доставки відображається конкретна причина, наприклад: Telegram API повернув 403 Forbidden: blocked by user або SMTP-сервер не відповідає. Адміністратор може вручну перевідправити сповіщення або скинути лічильник спроб.

Управління підписками користувача

В особистому кабінеті користувач бачить список доступних подій і може вимкнути окремі канали. Налаштування зберігаються в b_vendor_notif_subscription. Диспетчер перед постановкою в чергу перевіряє, чи не відписався користувач від даного типу сповіщень на даному каналі.

Чому ми використовуємо Twig для шаблонів?

Тіло повідомлення формується через Twig. Змінні передаються з payload події. Згідно з офіційною документацією Twig, шаблонізатор забезпечує строгу ізоляцію шаблонів від логіки, що підвищує безпеку при роботі з користувацьким контентом. У шаблонах доступні фільтри: |price — форматування суми, |date — локалізована дата. HTML-листи підтримують inline-стилі через Emogrifier.

Адміністративний інтерфейс

• Список подій з налаштуванням каналів за замовчуванням
• Редактор шаблонів з попереднім переглядом (підстановка тестових змінних)
• Журнал відправки з фільтрацією за статусом, каналом, датою, отримувачем
• Статистика доставляємості за каналами
• Тестова відправка сповіщення на вказану адресу

Що входить у розробку модуля

Терміни розробки

Разом: 14 робочих днів. Підключення додаткових каналів (Viber, VK, WhatsApp Business API) — по 1–2 дні на канал. Вартість розраховується індивідуально залежно від складності та кількості каналів. Оцінимо ваш проект за 1 день.

Як додати новий канал сповіщень

1. Реалізувати клас, що імплементує ChannelInterface.
2. Зареєструвати канал в ChannelRegistry через подію OnBuildChannels.
3. Створити шаблон для нового каналу в адмінці.
4. Налаштувати підписки за замовчуванням для подій.

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