Événements et déclencheurs dans AL pour Business Central : guide de timing pour développeurs

By Mirko Peters · 2026-08-22

Maîtrisez le développement AL pour Business Central en comprenant quand utiliser les déclencheurs ou les abonnés à un événement pour la logique métier personnalisée, la validation et les contrôles de comptabilisation.

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

Comprendre la distinction entre déclencheurs et événements dans le développement AL pour Microsoft Dynamics 365 Business Central est essentiel pour écrire des extensions propres et faciles à maintenir. Choisir le bon mécanisme d’exécution garantit que vos règles de validation s’exécutent au moment exact voulu, évitent la saisie de données erronées et préservent le bon déroulement des mises à jour cloud, sans dupliquer le code de l’application standard.

Points clés

• Les déclencheurs sont intégrés directement dans des objets AL spécifiques afin d’exécuter du code dès qu’un événement de l’objet ou une modification de données se produit.
• Les abonnés à un événement permettent à votre extension de réagir aux notifications à l’échelle du système sans modifier le code de l’application standard ni recopier de vastes processus natifs.
• Le choix entre les événements « on before » et « on after » détermine si votre code personnalisé peut empêcher une transaction ou simplement réagir à une action déjà terminée.
• Un timing approprié permet aux règles de validation de détecter les erreurs au plus tôt, tout en évitant les goulots d’étranglement de performance lors d’opérations lourdes, comme la comptabilisation des commandes client.

L’architecture de la logique personnalisée dans Business Central

Lorsque vous étendez Dynamics 365 Business Central à l’aide du Application Language (AL) de Microsoft, écrire le code ne représente que la moitié du travail. Le véritable défi consiste à décider où et quand ce code doit s’exécuter. Qu’il s’agisse d’ajouter un simple champ de niveau de récompense à une fiche client ou d’imposer un contrôle de conformité complexe avant la génération d’une facture, la pérennité et la stabilité de votre extension dépendent de la manière dont vous vous connectez au système.

Les anciens modèles de développement encourageaient souvent à réécrire directement le code natif de l’application. Si vous souhaitiez qu’un contrôle s’exécute avant la comptabilisation d’un document, vous injectiez votre logique directement dans la routine de comptabilisation standard. Si cette approche fonctionnait temporairement, chaque mise à jour majeure de Microsoft se transformait en un projet de réconciliation pénible. Le développement moderne d’extensions Business Central repose sur un modèle modulaire, basé sur des applications. Plutôt que de réécrire les routines standard, les développeurs utilisent des points de connexion intégrés, à savoir les déclencheurs et les événements, pour intégrer la logique personnalisée en toute sécurité aux côtés du code standard de l’application.

Démystifier les déclencheurs AL

Un déclencheur est un emplacement prédéfini et désigné, au sein d’un objet AL, où vous pouvez écrire du code qui s’exécute automatiquement lorsqu’une action précise se produit. Chaque objet standard ou personnalisé, y compris les tables, les extensions de table, les pages, les extensions de page, les rapports et les codeunits, contient ces points natifs.

Prenons un scénario concret : votre organisation a ajouté un champ Reward ID personnalisé à la fiche client. Lorsqu’un utilisateur sélectionne un niveau de récompense dans la liste déroulante, vous avez besoin que le système vérifie immédiatement si le compte client est bloqué ou si des attributs secondaires doivent être mis à jour. En utilisant le déclencheur OnValidate sur ce champ précis, votre code s’exécute dès la seconde où l’utilisateur effectue une modification.

Quand utiliser les déclencheurs

Les déclencheurs sont préférables lorsque votre logique métier relève exclusivement d’un seul objet et de son contexte immédiat. Par exemple :

• Valider qu’un champ de date personnalisé se situe dans un trimestre d’activité acceptable.
• Exécuter une logique d’initialisation lorsqu’une page de fiche s’ouvre pour une nouvelle entrée.
• Effacer les valeurs des champs dépendants lorsqu’une option principale est désélectionnée.

Comme les déclencheurs sont étroitement liés à leur objet hôte, ils facilitent la recherche, la lecture et la maintenance du code localisé au fil du temps.

Tirer parti des événements et des abonnements Business Central

Si les déclencheurs gèrent les actions localisées, les processus plus larges en plusieurs étapes, comme la comptabilisation de commandes client, l’expédition de stock ou la génération de journaux financiers, exigent une approche plus élaborée. Vous ne pouvez pas simplement insérer votre code de validation au milieu d’une routine de comptabilisation complexe sans compromettre le modèle d’extension.

C’est là que les événements et les abonnés aux événements deviennent indispensables. Considérez un événement comme une notification officielle diffusée par l’application standard Business Central. Le système annonce les étapes majeures, comme « un enregistrement est sur le point d’être inséré » ou « un document de vente est sur le point d’être comptabilisé. » Votre extension peut être à l’écoute de ces notifications grâce à une procédure d’abonné à un événement.

Lorsque Business Central déclenche cet événement nommé, votre procédure abonnée s’active, exécute votre règle personnalisée, puis autorise la poursuite du processus ou l’interrompt avec un message d’erreur explicite. Point essentiel : votre extension n’a jamais besoin de copier, coller ou réécrire le moteur de comptabilisation sous-jacent.

La question du moment : OnBefore ou OnAfter

Lors de la création d’abonnés à des événements en AL, les conventions de nommage révèlent le moment d’exécution. Comprendre ce moment est essentiel pour la fiabilité du système :

• Événements OnBefore : ils s’exécutent juste avant qu’une action standard ne se termine ou ne soit validée. C’est l’emplacement idéal pour la logique de blocage et les contrôles de validation. Si un document de conformité obligatoire manque sur une commande client, un événement OnBefore de comptabilisation peut détecter l’omission, annuler la transaction et afficher un message d’avertissement utile.
• Événements OnAfter : ils s’exécutent immédiatement après la réussite d’un processus standard. Utilisez les abonnés OnAfter lorsque vous devez réagir à une action terminée, par exemple pour créer automatiquement une tâche de suivi, mettre à jour une table de journalisation externe ou informer un responsable de compte dès qu’une commande est entièrement comptabilisée.

Une règle exécutée trop tard ne peut pas empêcher une transaction erronée, tandis qu’une règle exécutée trop tôt risque de ne pas disposer des données calculées pendant la routine standard. Faire correspondre votre logique à la signature d’événement appropriée permet d’éviter ces écueils.

Conclusion

Maîtriser l’équilibre entre les déclencheurs d’objets et les abonnés aux événements transforme votre approche des extensions Business Central. En utilisant des déclencheurs localisés pour les validations de champs et des abonnés aux événements pour les processus à l’échelle du système, vous faites en sorte que vos personnalisations restent résilientes face aux mises à jour cloud, tout en gardant votre environnement rapide et sécurisé.

Pour approfondir les principes de conception d’applications modernes et entendre des analyses d’architecture menées par des experts, écoutez l’épisode complet du M365 FM Podcast. Découvrez comment les architectes cloud et les développeurs optimisent l’écosystème Microsoft pour des résultats métier concrets !

Questions fréquentes

Quelle est la principale différence entre un déclencheur et un abonné à un événement en AL ?

Un déclencheur est un point d’exécution de code prédéfini, placé directement dans un objet AL précis (comme un champ de table ou une page), alors qu’un abonné à un événement est une procédure distincte de votre extension qui écoute les notifications publiées par l’application de base ou par d’autres objets, sans modifier le code d’origine.

Un abonné à un événement peut-il empêcher la comptabilisation d’une commande client ?

Oui. Si vous utilisez un abonné à un événement « OnBefore » lié au processus de comptabilisation, votre code personnalisé peut évaluer des conditions métier, afficher un message d’erreur et interrompre la transaction avant que la routine de comptabilisation ne finalise les écritures.

Quand dois-je utiliser un déclencheur de validation de champ de table plutôt qu’un abonné à un événement ?

Utilisez un déclencheur de validation de champ de table lorsque votre règle métier est strictement liée à la modification de la valeur de ce champ précis, par exemple pour vérifier qu’un Reward ID personnalisé existe ou pour s’assurer qu’un champ de statut associé se met à jour immédiatement après la saisie de l’utilisateur.

Pourquoi le moment d’exécution est-il critique lors de l’écriture d’abonnés à des événements en AL ?

Le moment d’exécution détermine si votre code s’exécute avant ou après la fin d’un processus central. S’il s’exécute trop tôt, les données nécessaires ne sont peut-être pas encore renseignées ; s’il s’exécute trop tard, vous perdez la possibilité de bloquer les transactions non valides.