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

By Mirko Peters · 2026-08-22

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

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 на языке прикладного программирования Microsoft (AL) написание кода — лишь половина дела. Настоящая сложность заключается в том, чтобы определить, где и когда этот код должен выполняться. Добавляете ли вы простое поле уровня вознаграждения в карточку клиента или вводите сложную проверку соответствия требованиям перед формированием счёта, долговечность и стабильность расширения зависят от того, как вы подключаетесь к системе.

Старые модели разработки часто подталкивали разработчиков переписывать стандартный код приложения напрямую. Если нужно было выполнить проверку до проводки документа, логику внедряли прямо в основную процедуру проводки. Хотя так работало какое-то время, каждое крупное обновление Microsoft превращалось в болезненный проект по приведению кода в соответствие. Современная разработка расширений для Business Central опирается на модульную, основанную на приложениях модель. Вместо переписывания стандартных процедур разработчики используют встроенные точки подключения — прежде всего триггеры и события, — чтобы безопасно встраивать пользовательскую логику в стандартный код приложения.

Разбираем триггеры AL

Триггер — это заранее определённое место внутри объекта AL, куда можно поместить код, который автоматически выполняется при наступлении определённого действия. Каждый стандартный и пользовательский объект — включая таблицы, расширения таблиц, страницы, расширения страниц, отчёты и кодовые модули — содержит такие встроенные точки.

Рассмотрим практический сценарий: в вашей организации в карточку клиента добавлено пользовательское поле Reward ID. Когда пользователь выбирает уровень вознаграждения из выпадающего списка, системе нужно немедленно проверить, не заблокирован ли аккаунт клиента, и нужно ли обновить связанные атрибуты. Используя триггер OnValidate для этого поля, ваш код срабатывает в ту же секунду, когда пользователь вносит изменение.

Когда использовать триггеры

Триггеры лучше всего применять, когда ваша бизнес-логика относится исключительно к одному объекту и его непосредственному контексту. Например:

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

Поскольку триггеры жёстко привязаны к объектам, в которых они находятся, локальный код легко найти, прочитать и поддерживать на протяжении всего жизненного цикла.

Использование событий и подписок в Business Central

Пока триггеры обрабатывают локальные действия, более широкие многошаговые процессы, такие как проводка заказов на продажу, отгрузка запасов или формирование финансовых журналов, требуют более продуманного подхода. Нельзя просто вставить код проверки в середину громоздкой процедуры проводки и не нарушить модель расширений.

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

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

Значение времени выполнения: OnBefore и OnAfter

При создании подписчиков на события в AL их имена показывают, когда именно они выполняются. Понимание этого момента критически важно для надёжности системы:

• События OnBefore: выполняются непосредственно перед завершением или фиксацией стандартного действия. Это идеальное место для блокирующей логики и проверок. Если в заказе на продажу отсутствует обязательный документ, подтверждающий соответствие требованиям, обработчик события OnBefore при проводке может обнаружить пропуск, прервать транзакцию и вывести понятное предупреждение.
• События OnAfter: выполняются сразу после успешного завершения стандартного процесса. Используйте подписчики OnAfter, когда нужно отреагировать на уже выполненное действие, например автоматически создать последующую задачу, обновить таблицу внешнего журнала или уведомить менеджера по работе с клиентами после полной проводки заказа.

Правило, которое срабатывает слишком поздно, не может предотвратить ошибочную транзакцию, а правило, которое срабатывает слишком рано, может не получить данные, вычисляемые в ходе стандартной процедуры. Правильный выбор сигнатуры события позволяет избежать этих ошибок.

Заключение

Освоив баланс между триггерами объектов и обработчиками событий, вы по-новому подойдёте к разработке расширений Business Central. Используя локальные триггеры для проверки полей и обработчики событий для системных процессов, вы сделаете свои доработки устойчивыми к обновлениям из облака и при этом сохраните среду быстрой и безопасной.

Чтобы глубже разобраться в принципах современного проектирования приложений и послушать разбор архитектурных решений от экспертов, послушайте выпуск целиком в подкасте M365 FM. Подключайтесь, чтобы узнать, как облачные архитекторы и разработчики оптимизируют экосистему Microsoft для реальных бизнес-результатов!

Часто задаваемые вопросы

В чём основное различие между триггером и подписчиком на событие в AL?

Триггер — это заранее определённая точка выполнения кода, встроенная непосредственно в конкретный объект AL (например, поле таблицы или страницу), тогда как подписчик на событие — это отдельная процедура в вашем расширении, которая реагирует на публикуемые уведомления базового приложения или других объектов, не изменяя исходный код.

Может ли подписчик на событие помешать проводке заказа на продажу?

Да. Если использовать подписчик на событие «on before», привязанный к процессу проводки, ваш пользовательский код может проверить бизнес-условия, вывести сообщение об ошибке и прервать транзакцию до того, как процедура проводки завершит формирование записей.

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

Триггер проверки поля таблицы стоит использовать, когда бизнес-правило строго связано с изменением значения конкретного поля, например при проверке существования пользовательского Reward ID или при немедленном обновлении связанного поля статуса после ввода пользователем данных.

Почему время выполнения критично при написании подписчиков на события в AL?

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