Business Central: події та тригери в AL — посібник з вибору моменту виконання для розробників

By Mirko Peters · 2026-08-22

Опануйте розробку в Business Central на AL: розберіться, коли для власної бізнес-логіки, перевірок і контролю проведення використовувати тригери, а коли — підписники подій.

Automatically translated with AI from the original post. Read the English original

Розуміння відмінності між тригерами та подіями в розробці AL для Microsoft Dynamics 365 Business Central є ключовим для написання чистих і зручних у супроводі розширень. Вибір правильного механізму виконання гарантує, що ваші правила перевірки спрацьовують саме в потрібний момент, запобігаючи введенню некоректних даних і забезпечуючи безперебійне оновлення в хмарі без дублювання коду основного застосунку.

Головне

• Тригери вбудовуються безпосередньо в конкретні об'єкти AL і виконують код одразу, коли відбувається подія об'єкта або зміна даних.
• Підписники подій дають змогу вашому розширенню «слухати» системні сповіщення без зміни коду основного застосунку та без копіювання масивних стандартних процесів.
• Вибір між подіями «on before» і «on after» визначає, чи може ваш власний код зупинити транзакцію, або він лише реагуватиме на вже завершену дію.
• Правильний момент виконання дає змогу виявляти помилки на ранньому етапі та водночас уникати проблем із продуктивністю під час ресурсомістких операцій, таких як проведення замовлень на продаж.

Архітектура власної логіки в Business Central

Коли ви розширюєте Dynamics 365 Business Central за допомогою мови Application Language (AL) від Microsoft, написання коду — це лише половина справи. Справжній виклик полягає в тому, щоб вирішити, де і коли цей код має виконуватися. Чи ви додаєте просте поле рівня винагороди до картки клієнта, чи впроваджуєте складну перевірку відповідності вимогам перед формуванням рахунку, довговічність і стабільність вашого розширення залежать від того, як ви підключаєтеся до системи.

Старіші моделі розробки часто заохочували переписувати стандартний код застосунку безпосередньо. Якщо потрібно було, щоб перевірка спрацьовувала перед проведенням документа, логіку вбудовували прямо в основну процедуру проведення. Хоча це тимчасово працювало, кожне великe оновлення Microsoft перетворювалося на болісний проєкт звіряння змін. Сучасна розробка розширень Business Central спирається на модульну, застосунково орієнтовану модель. Замість переписування стандартних процедур розробники використовують вбудовані точки підключення, а саме тригери та події, щоб безпечно вплітати власну логіку поряд зі стандартним кодом застосунку.

Розбираємо тригери AL

Тригер — це визначене, заздалегідь передбачене місце всередині об'єкта AL, де можна написати код, що автоматично виконується, коли відбувається конкретна дія. Кожен стандартний і власний об'єкт, зокрема таблиці, розширення таблиць, сторінки, розширення сторінок, звіти та кодунити, містить такі вбудовані точки.

Розглянемо практичний сценарій: у вашій організації до картки клієнта додано власне поле Reward ID. Коли користувач обирає рівень винагороди зі списку, системі потрібно одразу перевірити, чи не заблокований обліковий запис клієнта, або чи потрібно оновити додаткові атрибути. Використовуючи тригер OnValidate для цього конкретного поля, ваш код запускається в ту саму секунду, коли користувач вносить зміну.

Коли використовувати тригери

Тригери найкраще застосовувати тоді, коли бізнес-логіка стосується лише одного об'єкта та його безпосереднього контексту. Наприклад:

• Перевірка того, що користувацьке поле дати потрапляє в допустимий бізнес-квартал.
• Виконання логіки ініціалізації, коли картка відкривається для нового запису.
• Очищення залежних значень полів, коли знімається вибір основного параметра.

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

Використання подій і підписок Business Central

Тоді як тригери обробляють локальні дії, багатоетапні процеси, як-от проведення замовлень на продаж, відвантаження запасів або формування фінансових журналів, потребують складнішого підходу. Ви не можете просто вставити код валідації в середину великої процедури проведення, не порушивши модель розширень.

Тут незамінними стають події та обробники подій. Подію можна уявити як офіційне сповіщення, яке транслює стандартний застосунок Business Central. Система оголошує про ключові віхи, наприклад «запис ось-ось буде вставлено» або «документ продажу ось-ось буде проведено». Ваше розширення може відстежувати ці сповіщення за допомогою процедури-обробника події.

Коли Business Central викликає іменовану подію, ваша процедура-обробник прокидається, виконує ваше правило і або дає зелене світло, або зупиняє процес із зрозумілим повідомленням про помилку. Найважливіше, що вашому розширенню ніколи не потрібно копіювати, вставляти чи переписувати внутрішній механізм проведення.

Значення часу: OnBefore проти OnAfter

Під час створення обробників подій в AL іменування подій показує момент їх виконання. Розуміння цього часу критично важливе для надійності системи:

• Події OnBefore: Вони виконуються безпосередньо перед тим, як стандартна дія завершиться або зафіксується. Це ідеальне місце для логіки блокування та перевірок. Якщо в замовленні на продаж бракує обов'язкового документа відповідності, обробник події OnBefore під час проведення може помітити цю прогалину, перервати транзакцію та показати корисне попередження.
• Події OnAfter: Вони виконуються одразу після успішного завершення стандартного процесу. Використовуйте обробники OnAfter, коли потрібно відреагувати на завершену дію, наприклад автоматично створити наступне завдання, оновити зовнішню таблицю журналу або повідомити менеджера з роботи з клієнтами після повного проведення замовлення.

Правило, що виконується занадто пізно, не може запобігти хибній транзакції, а правило, що виконується занадто рано, може не мати даних, які стандартна процедура ще не обчислила. Прив'язка вашої логіки до правильного підпису події усуває ці пastки.

Висновок

Опанування балансу між тригерами об'єктів і обробниками подій змінює підхід до розробки розширень Business Central. Використовуючи локальні тригери для валідації полів і обробники подій для загársистемних процесів, ви забезпечуєте стійкість своїх доопрацювань до оновлень хмари та швидкість і безпеку середовища.

Щоб глибше зануритися в принципи сучасного проєктування застосунків і почути експертний розбір архітектури, послухайте повний епізод подкасту M365 FM. Долучайтеся, щоб дізнатися, як хмарні архітектори та розробники оптимізують екосистему Microsoft для реальних бізнес-результатів!

Поширені запитання

Яка головна відмінність між тригером і обробником подій в AL?

Тригер — це заздалегідь визначена точка виконання коду, вбудована безпосередньо в конкретний об'єкт AL (наприклад, поле таблиці або сторінку), тоді як обробник події — це окрема процедура у вашому розширенні, яка прослуховує опубліковані сповіщення базового застосунку або інших об'єктів, не змінюючи початковий код.

Чи може обробник події завадити проведенню замовлення на продаж?

Так. Якщо ви використовуєте обробник події «on before», прив'язаний до процесу проведення, ваш власний код може оцінити бізнес-умови, викликати повідомлення про помилку та зупинити транзакцію до того, як процедура проведення остаточно зафіксує записи.

Коли варто використовувати тригер валідації поля таблиці замість обробника події?

Тригер валідації поля таблиці варто використовувати, коли бізнес-правило строго пов'язане зі зміною значення саме цього поля, наприклад перевірка, чи існує користувацький Reward ID, або гарантія того, що пов'язане поле статусу оновлюється одразу після введення користувачем.

Чому час виконання критично важливий під час написання обробників подій AL?

Момент виконання визначає, чи запуститься ваш код до або після завершення ключового процесу. Якщо правило спрацьовує занадто рано, потрібні дані ще можуть не бути заповнені; якщо занадто пізно, ви втрачаєте можливість блокувати некоректні транзакції.