Кастомні ORM-обробники для 1С-Бітрікс: розробка та аудит

ORM-події в 1С-Бітрікс: кастомні обробники

Уявіть проєкт з каталогом на 50 000 товарів в інфоблоці. Кожне збереження елемента запускає старі події OnBeforeIBlockElementUpdate та OnAfterIBlockElementUpdate. Вони спрацьовують при будь-якій зміні через API, адмінка гальмує вдвічі. Вихід — ORM-події, прив'язані до конкретного DataManager. Вони спрацьовують тільки при викликах add(), update(), delete(). Такий підхід точково реагує на зміни та знижує навантаження на 40%. Ми розробляємо такі обробники під ключ: від простого аудиту до каскадних операцій з десятками сутностей. Працюємо з інфоблоками, HL-блоками, замовленнями, користувачами. Сертифіковані спеціалісти з семирічним стажем. Напишіть нам — оцінимо ваш проєкт і запропонуємо реалістичні терміни.

Кастомний обробник нагадує тригер у базі даних, але з можливістю гнучкої модифікації полів. ORM (object-relational mapping) у Бітрікс реалізовано через класи-нащадки DataManager. Кожна операція із записом породжує події до та після дії.

Як влаштовані події ORM?

У кожного DataManager-класу чотири точки життєвого циклу: додавання, оновлення, видалення. Для кожної — before і after. Подія формується за шаблоном {ClassName}::On{Action}. Наприклад, для Bitrix\Sale\Internals\OrderTable подія перед додаванням — Bitrix\Sale\Internals\OrderTable::OnBeforeAdd.

Реєстрація стандартна:

use Bitrix\Main\EventManager; EventManager::getInstance()->addEventHandler( 'sale', '\Bitrix\Sale\Internals\OrderTable::OnAfterAdd', [\MyProject\Handlers\OrderOrmHandler::class, 'onAfterAdd'] ); 

Покрокова реєстрація ORM-обробника

1. Створіть клас-обробник з публічними статичними методами.
2. У методі OnBeforeAdd або OnAfterAdd обробіть подію.
3. Для before-подій повертайте EventResult з модифікованими полями.
4. Для after-подій повернення не потрібне, але можна логувати.
5. Зареєструйте обробник через EventManager::addEventHandler.
6. Переконайтеся, що операція викликається через ORM (DataManager::add()), а не старий API.

При реєстрації важливо вказати точне повне ім'я класу з неймспейсом.

Об'єкт події та доступні дані

В обробник передається об'єкт \Bitrix\Main\Entity\Event. З нього витягуються параметри:

public static function onAfterAdd(\Bitrix\Main\Entity\Event $event): void { $result = $event->getParameter('result'); // об'єкт Result з ID $fields = $event->getParameter('fields'); // масив збережених полів $newId = $result->getId(); $userId = $fields['USER_ID'] ?? null; } 

Для Before-подій можна модифікувати поля через EventResult:

public static function onBeforeAdd(\Bitrix\Main\Entity\Event $event): \Bitrix\Main\Entity\EventResult { $result = new \Bitrix\Main\Entity\EventResult(); $result->modifyFields(['CREATED_BY' => \CUser::GetID()]); return $result; } 

Типові помилки при реєстрації ORM-подій

Найчастіша — неправильне ім'я класу або опечатка в операції. Друга — реєстрація на подію, яка не спрацює через використання старого API. Перевіряйте: якщо дані вставляються через CIBlockElement::Add, ORM-подія не викличеться. Завжди тестуйте обробник на реальних даних, імітуючи навантаження в 10 000 записів. Третя помилка — забувають повертати EventResult у before-подіях. Без цього операція виконається без змін.

Практичні сценарії

Аудит змін. Логуємо, хто і коли змінив запис у кастомній HL-таблиці. Замість коду — просто факт: записуємо в таблицю аудиту з ідентифікатором сутності, користувачем та серіалізованими змінами. Це допомагає відстежити, хто зіпсував дані.

Автоматичне заповнення полів. При додаванні запису автоматично проставляємо поля: дата створення, статус, хеш.

public static function onBeforeAdd(\Bitrix\Main\Entity\Event $event): \Bitrix\Main\Entity\EventResult { $result = new \Bitrix\Main\Entity\EventResult(); $result->modifyFields([ 'CREATED_AT' => new \Bitrix\Main\Type\DateTime(), 'STATUS' => 'DRAFT', 'HASH' => md5(uniqid('', true)), ]); return $result; } 

Каскадне видалення. Перед видаленням основного запису чистимо пов'язані дані. Наприклад, при видаленні замовлення видаляємо його позиції. ORM не робить це автоматично, обробник підтримує цілісність.

Чому ORM-події кращі за старі?

Важливий нюанс: якщо запис створюється через прямий SQL або старий API, ORM-події не спрацьовують. Вони працюють тільки при викликах DataManager::add(), update(), delete().

Чому ORM-події критичні для високонавантажених проєктів?

На сайтах з мільйонами записів кожне зайве спрацьовування збільшує час відгуку. ORM-події реагують тільки на потрібні зміни, знижуючи навантаження. Ми оптимізуємо кожен обробник: теговане кешування, мінімізація запитів до БД, індекси. На одному проєкті після міграції на ORM-події час збереження товару скоротився на 40%. Окупність — за 2 місяці скорочення часу завантаження.

Highload-блоки та ORM-події

Для HL-блоків клас DataManager генерується динамічно. Знайдіть клас:

$hlblock = \Bitrix\Highloadblock\HighloadBlockTable::getById($hlId)->fetch(); $entity = \Bitrix\Highloadblock\HighloadBlockTable::compileEntity($hlblock); $className = $entity->getDataClass(); 

Потім зареєструйте обробник на цей клас. Для кількох HL-блоків створіть універсальний маршрутизатор.

Що входить у розробку обробників?

• Аналіз поточної подійної моделі та схеми даних
• Проєктування структури обробників з урахуванням бізнес-логіки
• Реалізація на ORM D7 з навантажувальним тестуванням (10 000 подій за хвилину)
• Документація щодо кожного обробника: схема, параметри, приклади
• Гарантія 6 місяців на код та підтримка після здачі

Терміни

Приклади засновані на офіційній документації 1С-Бітрікс: ORM D7.

Замовте розробку під ключ

Ми реалізували понад 50 проєктів по 1С-Бітрікс. Використовуємо ORM D7, теговане кешування, подійну модель. Зв'яжіться з нами — отримайте консультацію та точну оцінку вашого проєкту. Пишіть прямо зараз.