Business Central: eventi e trigger in AL, guida ai tempi di esecuzione per sviluppatori

By Mirko Peters · 2026-08-22

Padroneggia lo sviluppo AL per Business Central capendo quando usare i trigger o i subscriber di eventi per la logica di business personalizzata, le convalide e i controlli in fase di registrazione.

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

Comprendere la differenza tra trigger ed eventi nello sviluppo AL di Microsoft Dynamics 365 Business Central è essenziale per scrivere estensioni pulite e facili da manutenere. Scegliere il meccanismo di esecuzione corretto garantisce che le regole di convalida vengano eseguite esattamente nel momento giusto, prevenendo l'inserimento di dati errati e garantendo aggiornamenti cloud senza problemi, senza duplicare il codice dell'applicazione base.

Punti chiave

• I trigger sono incorporati direttamente in specifici oggetti AL e vengono eseguiti immediatamente quando si verifica un evento dell'oggetto o una modifica dei dati.
• Gli event subscriber consentono alla tua estensione di ascoltare notifiche a livello di sistema senza modificare il codice dell'applicazione base né copiare processi nativi complessi.
• Scegliere tra eventi "on before" e "on after" determina se il tuo codice personalizzato può impedire una transazione o limitarsi a reagire a un'azione già completata.
• Un timing corretto fa sì che le regole di convalida intercettino gli errori in anticipo, evitando colli di bottiglia nelle prestazioni durante operazioni onerose come la registrazione degli ordini di vendita.

L'architettura della logica personalizzata in Business Central

Quando estendi Dynamics 365 Business Central usando l'Application Language (AL) di Microsoft, scrivere il codice è solo metà della sfida. La vera difficoltà sta nel decidere dove e quando quel codice deve essere eseguito. Che tu stia aggiungendo un semplice campo del livello premio a una scheda cliente o applicando un complesso controllo di conformità prima della generazione di una fattura, la longevità e la stabilità della tua estensione dipendono da come ti agganci al sistema.

I modelli di sviluppo più datati spingevano spesso a riscrivere direttamente il codice nativo dell'applicazione. Se volevi che un controllo venisse eseguito prima della registrazione di un documento, inserivi la tua logica direttamente nella routine di registrazione principale. Sebbene funzionasse per un certo periodo, ogni importante aggiornamento di Microsoft si trasformava in un doloroso progetto di riconciliazione. Lo sviluppo moderno delle estensioni di Business Central si basa invece su un modello modulare basato su app. Anziché riscrivere le routine standard, gli sviluppatori usano i punti di connessione integrati, in particolare trigger ed eventi, per inserire in modo sicuro la logica personalizzata accanto al codice standard dell'applicazione.

Demistificare i trigger di AL

Un trigger è una posizione predefinita e designata all'interno di un oggetto AL in cui puoi scrivere codice che viene eseguito automaticamente quando si verifica una specifica azione. Ogni oggetto standard e personalizzato, incluse tabelle, estensioni di tabella, pagine, estensioni di pagina, report e codeunit, contiene questi punti nativi.

Consideriamo uno scenario pratico: la tua organizzazione ha introdotto un campo personalizzato ID premio nella scheda cliente. Quando un utente seleziona un livello di premio dall'elenco a discesa, devi che il sistema verifichi immediatamente se l'account cliente è bloccato o se attributi secondari richiedono un aggiornamento. Utilizzando il trigger OnValidate su quel campo specifico, il codice si attiva nell'istante esatto in cui l'utente effettua una modifica.

Quando usare i trigger

I trigger sono utili quando la logica di business appartiene esclusivamente a un singolo oggetto e al suo contesto immediato. Per esempio:

• Verificare che un campo data personalizzato rientri in un trimestre di business accettabile.
• Eseguire la logica di inizializzazione quando si apre una pagina scheda per un nuovo inserimento.
• Cancellare i valori dei campi dipendenti quando si deseleziona un'opzione principale.

Poiché i trigger sono circoscritti strettamente agli oggetti che li ospitano, il codice localizzato resta facile da trovare, leggere e manutenere nel tempo.

Sfruttare gli eventi e le sottoscrizioni di Business Central

Mentre i trigger gestiscono le azioni localizzate, i processi più ampi composti da più passaggi, come la registrazione degli ordini di vendita, la spedizione del magazzino o la generazione di movimenti contabili, richiedono un approccio più sofisticato. Non puoi semplicemente inserire il tuo codice di convalida nel mezzo di una vasta routine di registrazione senza compromettere il modello di estensione.

Qui entrano in gioco gli eventi e i subscriber di eventi. Immagina un evento come una notifica ufficiale trasmessa dall'applicazione standard di Business Central. Il sistema segnala i passaggi più importanti, come 'un record sta per essere inserito' oppure 'un documento di vendita sta per essere registrato.' La tua estensione può ascoltare questi avvisi tramite una procedura subscriber di evento.

Quando Business Central genera quell'evento con nome, la procedura sottoscritta si attiva, esegue la tua regola personalizzata e, a seconda dei casi, dà il via libera oppure interrompe il processo con un messaggio di errore descrittivo. Soprattutto, la tua estensione non deve mai copiare, incollare o riscrivere il motore di registrazione sottostante.

La questione del tempismo: OnBefore vs. OnAfter

Quando crei subscriber di eventi in AL, le convenzioni di denominazione rivelano il momento dell'esecuzione. Capire questo timing è fondamentale per l'affidabilità del sistema:

• Eventi OnBefore: vengono eseguiti subito prima che un'azione standard termini o venga confermata. Sono il punto ideale per la logica di blocco e i controlli di convalida. Se in un ordine di vendita manca un documento di conformità obbligatorio, un evento di registrazione OnBefore può rilevare l'omissione, interrompere la transazione e mostrare un messaggio di avviso utile.
• Eventi OnAfter: vengono eseguiti immediatamente dopo che un processo standard si è completato con successo. Usa i subscriber OnAfter quando devi reagire a un'azione conclusa, per esempio creando automaticamente un'attività di follow-up, aggiornando una tabella di log esterna o avvisando un account manager una volta che l'ordine è stato registrato completamente.

Una regola che viene eseguita troppo tardi non può impedire una transazione errata, mentre una regola eseguita troppo presto potrebbe non disporre dei dati necessari calcolati durante la routine standard. Associare la logica alla firma di evento corretta elimina questi rischi.

Conclusione

Padroneggiare l'equilibrio tra trigger degli oggetti e subscriber di eventi cambia il modo in cui affronti le estensioni di Business Central. Usando i trigger localizzati per le convalide dei campi e i subscriber di eventi per i processi a livello di sistema, fai in modo che le tue personalizzazioni restino resilienti agli aggiornamenti cloud, mantenendo al tempo stesso l'ambiente veloce e sicuro.

Per approfondire i principi di progettazione delle applicazioni moderne e ascoltare analisi approfondite di architettura da parte di esperti, ascolta l'episodio completo del podcast M365 FM. Sintonizzati per scoprire come gli architetti cloud e gli sviluppatori ottimizzano l'ecosistema Microsoft per il successo aziendale nel mondo reale!

Domande frequenti

Qual è la differenza principale tra un trigger e un subscriber di eventi in AL?

Un trigger è un punto di esecuzione del codice predefinito, inserito direttamente all'interno di uno specifico oggetto AL (come un campo di tabella o una pagina), mentre un subscriber di eventi è una procedura separata nell'estensione che resta in ascolto delle notifiche pubblicate dall'applicazione base o da altri oggetti, senza modificare il codice originale.

Un subscriber di eventi può impedire la registrazione di un ordine di vendita?

Sì: se usi un subscriber di evento 'on before' collegato al processo di registrazione, il tuo codice personalizzato può valutare le condizioni di business, generare un messaggio di errore e interrompere la transazione prima che la routine di registrazione finalizzi le scritture.

Quando dovrei usare un trigger di convalida su un campo di tabella invece di un subscriber di eventi?

Dovresti usare un trigger di convalida su un campo di tabella quando la regola di business è strettamente legata alla variazione del valore di quel campo specifico, per esempio verificare che esista un Reward ID personalizzato oppure assicurarsi che un campo di stato correlato si aggiorni immediatamente all'inserimento dell'utente.

Perché il timing di esecuzione è critico quando si scrivono subscriber di eventi in AL?

Il momento di esecuzione determina se il codice viene eseguito prima o dopo il completamento di un processo fondamentale. Se la regola viene eseguita troppo presto, i dati necessari potrebbero non essere ancora stati popolati; se viene eseguita troppo tardi, si perde la possibilità di bloccare le transazioni non valide.