מודול התראות מותאם אישית ל-1C-Bitrix

מדוע ההתראות הסטנדרטיות של 1C-Bitrix אינן מספיקות?

\Bitrix\Main\Mail\Event::send() — המנגנון הבסיסי שמטפל בהודעות דוא"ל לאחר רישום או אישור הזמנה. אך כאשר העסק דורש התראות push, טלגרם, וואטסאפ, SMS — עם יומן משלוח אחיד, סטטוסים וניסיונות חוזרים — הכלי המובנה מפסיק לענות על הצרכים. לפי תיעוד רשמי של Bitrix, מנגנון הדוא"ל הסטנדרטי אינו מיועד ליותר מ-1000 הודעות בדקה. כתוצאה מכך, עד 30% מההתראות הקריטיות אובדות, והניפוי אורך ימים. לדוגמה, בפרויקט עם עומס של 8000 אירועים בשעה, תיעדנו 2000 שגיאות SMTP ביום.

כל ערוץ חדש מתחבר בצורה שונה, היומנים מפוזרים, והבדיקות מורכבות. אנו מתמחים בפיתוח מודולי התראות מותאמים אישית ל-1C-Bitrix הפותרים בעיות אלה בצורה מרכזית. המודול שלנו מיועד לפרויקטים בעלי עומס גבוה ומעבד עד 100,000 התראות ביום עם אספקה מובטחת של 99.5%.

כיצד אנו בונים את ארכיטקטורת המודול

המודול vendor.notifications בנוי על המושגים של ערוץ ואירוע. אירוע הוא משהו שקורה במערכת. ערוץ הוא שיטת האספקה. אירוע אחד יכול להישלח דרך מספר ערוצים בו-זמנית. לאחסון נתונים, אנו משתמשים בארבע טבלאות 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 — דרך interface ChannelInterface { public function getName(): string; public function send(Notification $notification): SendResult; public function supports(string $recipient): bool; } עם הגדרות SMTP מותאמות אישית או באמצעות PHPMailer. דוא"ל דרך SMTP מהיר ואמין פי 3-5 מהפונקציה המובנית mail().
• SmsChannel — מתאמים לספקים שונים (SMS.ru, SMSC, Twilio): ממשק אחיד, הספק הוא פרמטר תצורה.
• TelegramChannel — Telegram Bot API, שיטת \Bitrix\Main\Mail\Mail::send(), תמיכה ב-Markdown ובכפתורים מוטבעים.
• PushChannel — push לדפדפן באמצעות Web Push Protocol (ספריית sendMessage), הרשמות מאוחסנות ב-web-push-php. Web Push מבטיח אספקה גם כשהדפדפן סגור.
• InternalChannel — התראות פנימיות בחשבון האישי, מאוחסנות ב-b_vendor_notif_push_subscription, מוצגות באתר באמצעות 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_inbox.

כיצד שליחה אסינכרונית משפרת ביצועים

שליחה מיידית ברגע האירוע היא פרקטיקה גרועה: בקשת HTTP לטלגרם עלולה להיתקע ולחסום שמירת הזמנה. התור מעובד על ידי סוכן Bitrix. הגישה האסינכרונית עם ניסיונות חוזרים מפחיתה אובדן התראות ב-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 ניסיונות כושלים, המשימה מועברת לסטטוס \Vendor\Notifications\Dispatcher::dispatch('order_paid', [ 'user_id' => $userId, 'order_id' => $orderId, 'order_sum' => $order->getPrice(), 'order_number' => $order->getField('ACCOUNT_NUMBER'), ]); ומופיעה בלוח הבקרה לבדיקה ידנית. היומן מציג את סיבת השגיאה, מה שמפשט את הניפוי. כאשר מתרחשת שגיאת אספקה, מוצגת הסיבה הספציפית, לדוגמה: Telegram API החזיר 403 Forbidden: חסום על ידי המשתמש או שרת SMTP אינו זמין. המנהל יכול לשלוח מחדש את ההתראה באופן ידני או לאפס את מונה הניסיונות.

ניהול הרשמות משתמשים

בחשבון האישי, המשתמש רואה רשימה של אירועים זמינים ויכול לבטל ערוצים בודדים. ההגדרות מאוחסנות ב-b_vendor_notif_queue. המפזר בודק לפני הכנסה לתור האם המשתמש ביטל את ההרשמה לסוג אירוע זה בערוץ זה.

מדוע אנו משתמשים ב-Twig לתבניות

גוף ההודעה נוצר באמצעות Twig. משתנים מועברים מה-payload של האירוע. לפי תיעוד רשמי של Twig, מנוע התבניות מבטיח בידוד קפדני של תבניות מהלוגיקה, מה שמגביר את האבטחה בטיפול בתוכן משתמש. התבניות תומכות במסננים: // В инсталляторе модуля \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();'; } לעיצוב סכומים, failed לתאריכים מקומיים. הודעות HTML תומכות בסגנונות מוטבעים באמצעות Emogrifier.

ממשק ניהול

• רשימת אירועים עם הגדרות ערוץ ברירת מחדל
• עורך תבניות עם תצוגה מקדימה (החלפת משתני בדיקה)
• יומן שליחות עם סינון לפי סטטוס, ערוץ, תאריך, נמען
• סטטיסטיקת אספקה לפי ערוץ
• שליחת התראת בדיקה לכתובת מוגדרת

מה כלול בפיתוח המודול

לוח זמנים לפיתוח

סה"כ: 14 ימי עבודה. הוספת ערוצים נוספים (Viber, VK, WhatsApp Business API) — 1-2 ימים לכל ערוץ. העלות מחושבת באופן אישי לפי מורכבות ומספר הערוצים. אנו נעריך את הפרויקט שלך תוך יום אחד.

כיצד להוסיף ערוץ התראות חדש

1. ממש מחלקה המיישמת את b_vendor_notif_subscription.
2. רשום את הערוץ ב-|price באמצעות אירוע |date.
3. צור תבנית לערוץ החדש בפאנל הניהול.
4. הגדר הרשמות ברירת מחדל לאירועים.

צור קשר — ננתח את העומס שלך ונציע ארכיטקטורה לפרויקט שלך. הזמן פיתוח וקבל מודול מוכן עם תיעוד מלא וחודש תמיכה. קבל ייעוץ על אינטגרציה עם המערכת שלך — נדון בפרטים ובלוחות זמנים.