פיתוח ועידון מטפלי אירועים של 1С-Bitrix

חנות מקוונת על Bitrix עם קטלוג של 10,000 מוצרים. לקוח מבצע הזמנה, ואתה צריך לבדוק מלאי ב-1C, להזמין את הפריט, לשלוח נתונים ל-CRM ולעדכן את המחסן — כל זה תוך 0.5 שניות. ללא מטפלי אירועים (Event Handlers) מתוכננים היטב, כל אחד מהשלבים האלה מאט את האתר, שובר את השרשרת, או לעיתים גורם לקריסת העמוד. אנו מתכננים ארכיטקטורה מונעת אירועים כך שכל הפעולות הנוספות רצות באופן אסינכרוני — מבלי לאבד מהירות או לגרום לכשלים. במהלך השנים, יישמנו מעל 50 פרויקטים שבהם מודל האירועים היה הבסיס. החיסכון הממוצע בתקציב ללקוח היה 30% על ידי ביטול בקשות סינכרוניות מיותרות. מטפל כתוב נכון אינו מאט את האתר, אינו יוצר קריאות מחזוריות, ואינו שובר לוגיקה סמוכה. בואו נפרק את הנקודות המרכזיות.

האנטומיה של אירוע ב-Bitrix

הליבה מייצרת אירועים בנקודות מפתח באמצעות המחלקה EventManager. כל אירוע מקושר למודול ויש לו שם. מטפל נרשם באמצעות קריאה:

use Bitrix\Main\EventManager; EventManager::getInstance()->addEventHandler( 'sale', 'OnSaleOrderBeforeSaved', [\MyProject\Sale\OrderHandler::class, 'onBeforeSave'], 100 ); 

הרישום מתרחש ב-use Bitrix\Main\EventManager; EventManager::getInstance()->addEventHandler( 'sale', 'OnSaleOrderBeforeSaved', [\MyProject\Sale\OrderHandler::class, 'onBeforeSave'], 100 ); — קובץ זה נכלל בכל בקשה (hit). עבור לוגיקה ניידת, מטפלים נרשמים במתודת /local/php_interface/init.php של מודול מותאם אישית. אירועי לפני (installEvents()) מאפשרים לשנות נתונים לפני השמירה או לבטל את הפעולה על ידי החזרת OnBefore* עם שגיאה. אירועי אחרי (EventResult) מיועדים לתגובה לפעולה שכבר הושלמה.

אירועים מרכזיים לפי מודול

רשימה מלאה בתיעוד הרשמי.

איך לארגן נכון עשרות מטפלים?

בפרויקט אמיתי, ייתכנו 20–50 מטפלים. ללא מבנה, OnBeforeProlog הופך לבלאגן בלתי ניתן לניהול. אנו משתמשים בסכימה זו:

/local/php_interface/ ├── init.php → только подключение файлов регистрации ├── handlers/ │ ├── SaleHandlers.php → регистрация событий модуля sale │ ├── IblockHandlers.php → регистрация событий модуля iblock │ └── MainHandlers.php → регистрация событий модуля main └── classes/ ├── OrderEventHandler.php → логика обработчиков заказов ├── CatalogEventHandler.php └── UserEventHandler.php 

init.php מכיל רק /local/php_interface/ ├── init.php → только подключение файлов регистрации ├── handlers/ │ ├── SaleHandlers.php → регистрация событий модуля sale │ ├── IblockHandlers.php → регистрация событий модуля iblock │ └── MainHandlers.php → регистрация событий модуля main └── classes/ ├── OrderEventHandler.php → логика обработчиков заказов ├── CatalogEventHandler.php └── UserEventHandler.php . קבצי רישום מכילים רק קריאות init.php. מחלקות מטפלים כוללות מתודות סטטיות עם אחריות יחידה.

למה לא להשתמש בפעולות כבדות באירועי לפני?

require_once נקרא מספר פעמים במהלך תהליך התשלום — כל חישוב מחדש מפעיל את האירוע. בקשת HTTP ל-API חיצוני בתוכו מאטה את העמוד פי 5–10. פעולות כבדות מועברות לאירועי אחרי או לסוכנים (Agents). השוואה: מטפל דרך סוכן מבצע 40% מהר יותר מבקשה סינכרונית.

איך לתכנן מטפל לאינטגרציה עם 1C?

הנה דוגמה שלב אחר שלב לאירוע addEventHandler.

1. קבע את רגע הטריגר — אחרי ייבוא קטלוג מ-1C.
2. רשום את המטפל עם sort 200, כך שהוא רץ אחרי הסטנדרטיים.
3. בתוך המטפל, בדוק את סוג הייבוא (מלא או חלקי) ועדכן את המלאי דרך REST API של 1C.
4. בצע את הבקשה באופן אסינכרוני באמצעות סוכן רקע כדי לא לחסום את הבקשה.
5. תעד את התוצאה עם OnSaleOrderBeforeSaved לניתוח מאוחר יותר.

גישה זו מבטיחה שהאתר לא מאט ושהנתונים ב-1C וב-Bitrix נשארים מסונכרנים.

שגיאות קריטיות והפתרונות שלהן

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

class CatalogEventHandler { private static bool $inProgress = false; public static function onAfterElementUpdate(array $arFields): void { if (self::$inProgress) { return; } self::$inProgress = true; try { // логика обновления } finally { self::$inProgress = false; } } } 

חוסר טיפול בחריגות. חריגה לא מטופלת יכולה לקרוס את העמוד. לכל הפחות — Debug::writeToFile() עם רישום לוג באמצעות OnAfterIBlockElementUpdate.

סדר ביצוע. מספר מטפלים על אותו אירוע מתבצעים בסדר עולה של class CatalogEventHandler { private static bool $inProgress = false; public static function onAfterElementUpdate(array $arFields): void { if (self::$inProgress) { return; } self::$inProgress = true; try { // логика обновления } finally { self::$inProgress = false; } } } . אם המטפל שלך תלוי באחר — הגדר במפורש try/catch; ברירת המחדל היא 100.

איך לבדוק מטפלי אירועים?

השתמש במודול Debug::writeToFile() לפרופילינג. הרץ תרחיש בדיקה (ביצוע הזמנה, הוספת אלמנט) ומדוד את זמן הביצוע. השבת את כל המטפלים, ואז הפעל אחד אחד. השווה זמנים. אם התרחיש לוקח 0.5 שניות ללא מטפלים ו-3 שניות איתם, מצא את הצוואר בקבוק. אנו גם משתמשים בבדיקות יחידה PHPUnit ללוגיקת מטפלים מבודדת. הניסיון שלנו מראה שגישה זו מפחיתה תקלות בחצי.

רשימת בדיקה: טעויות נפוצות בפיתוח מטפלים

• שכח לטפל בחריגות — העמוד קורס עם שגיאת 500.
• לא לקח בחשבון שאירוע לפני יכול להיקרא מספר פעמים — נתונים נפגמים.
• רישום מטפל ב-init.php ללא בדיקת מודול — שגיאה כאשר המודול מושבת.
• שימוש ב-sort להעברת נתונים בין מטפלים — אובדן קונטקסט.
• לא בודק קיום שדה ב-sort — גישה למפתח שאינו קיים.

מה כולל העבודה

• ביקורת על מטפלים קיימים וזיהוי צווארי בקבוק.
• עיצוב ארכיטקטורה: הפרדה לפי מודולים ואחריות.
• רישום וקידוד מטפלים עם הגנה מפני קריאות מחזוריות.
• אינטגרציה עם שירותים חיצוניים (CDEK, 1C, שערי תשלום) באירועי אחרי.
• תיעוד לכל מטפל.
• בדיקות ופרופילינג באמצעות מודול perfmon.
• אחריות על הקוד ותמיכה למשך חודש.

לוחות זמנים משוערים

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

הגישה שבה אנו משתמשים מבוססת על תכנות מונחה אירועים. זה מאפשר הרחבה גמישה של פונקציונליות ללא שינויי ליבה. מטפלי אירועים הם כלי מפתח להרחבת פרויקטים של Bitrix.

מקור: תיעוד רשמי של 1С-Bitrix.