Estensioni AL fatte bene: le regole per non bloccare gli aggiornamenti

Business Central online si aggiorna con regolarità: due aggiornamenti principali all’anno e aggiornamenti minori nel mezzo. È uno dei vantaggi del cloud, ma solo se le personalizzazioni reggono il passo. Un’estensione scritta male può far fallire un aggiornamento, costringere a rimandarlo o, peggio, rompere un processo il giorno dopo.

Per chi guida un’azienda la domanda è semplice: le personalizzazioni che pago oggi mi bloccheranno domani? Per chi sviluppa la risposta sta in poche regole, applicate sempre. Eccole.

Perché le estensioni sono diverse dal vecchio codice

Nelle versioni storiche di Dynamics NAV le personalizzazioni si facevano modificando direttamente il codice standard. Ogni aggiornamento diventava un lavoro di confronto e fusione, riga per riga. Con le estensioni AL il codice personalizzato vive in un pacchetto separato e si aggancia all’applicazione Microsoft senza toccarla. Questo rende gli aggiornamenti possibili, ma non automaticamente indolori: dipende da come l’estensione è costruita.

Regola 1: estendere, non sostituire

Eventi e sottoscrittori

Il meccanismo principale sono gli eventi. Microsoft pubblica nell’applicazione dei punti di aggancio, gli eventi di integrazione e di business, e il runtime genera eventi trigger sulle operazioni di tabelle e pagine. La tua estensione si iscrive con un sottoscrittore e aggiunge il proprio comportamento senza modificare il codice originale.

Un esempio minimo: un controllo sul nome del cliente, agganciato all’evento di convalida del campo.

codeunit 50100 "Customer Checks"
{
    var
        NameTooShortErr: Label 'The customer name must be at least 3 characters long.';

    [EventSubscriber(ObjectType::Table, Database::Customer, 'OnAfterValidateEvent', 'Name', false, false)]
    local procedure CheckNameOnAfterValidate(var Rec: Record Customer; var xRec: Record Customer; CurrFieldNo: Integer)
    begin
        if StrLen(Rec.Name) < 3 then
            Error(NameTooShortErr);
    end;
}

Estensioni di tabelle e pagine

Per aggiungere campi, azioni o sezioni si usano le estensioni di tabella e di pagina. Il campo nuovo vive nella tua estensione, l’oggetto standard resta intatto.

Quando l’evento non c’è

Capita che il punto di aggancio che ti serve non esista. La tentazione è copiare una codeunit standard intera e modificarla: è la strada più rapida oggi e la più costosa domani, perché la copia non riceve le correzioni di Microsoft. Meglio cercare un evento alternativo, ripensare il flusso, oppure chiedere a Microsoft un nuovo evento tramite i canali previsti per l’estendibilità.

Regola 2: non appoggiarsi a ciò che sta per sparire

Microsoft non elimina oggetti, campi o procedure da un giorno all’altro. Prima li marca come obsoleti con la proprietà ObsoleteState, accompagnata da ObsoleteReason, che spiega cosa usare al suo posto, e da ObsoleteTag, che indica la versione in cui è stato deprecato. Per procedure e variabili si usa l’attributo Obsolete.

con lo stato Pending il compilatore segnala un avviso: l’elemento esiste ancora, ma ha i giorni contati;
con lo stato Removed l’elemento non è più utilizzabile e il codice che lo usa non compila.

La regola pratica è trattare ogni avviso di obsolescenza come un lavoro da pianificare subito, non come rumore. Microsoft pubblica una timeline di deprecazione: consultarla prima di ogni aggiornamento principale evita le sorprese. Lo stesso meccanismo vale per la tua estensione: se elimini un campo, marcalo prima come obsoleto e sposta i dati con il codice di upgrade.

Regola 3: gestire installazione e aggiornamento dei dati

Quando una nuova versione cambia la struttura dei dati, per esempio un campo che ne sostituisce un altro, servono le codeunit di upgrade, cioè codeunit con la proprietà Subtype impostata su Upgrade. Mettono a disposizione trigger dedicati, come OnCheckPreconditionsPerCompany, OnUpgradePerCompany e OnValidateUpgradePerCompany, con le varianti per database.

Per la prima installazione esistono le codeunit di installazione, con Subtype Install e trigger come OnInstallAppPerCompany. Per evitare che il codice di upgrade giri più di una volta Microsoft consiglia gli upgrade tag del modulo Upgrade Tags della System Application, più robusti del semplice confronto tra versioni quando le versioni sono tante. La guida ufficiale su come scrivere il codice di upgrade delle estensioni mostra lo schema completo.

Regola 4: versioni e dipendenze chiare

Il file app.json descrive l’estensione: version per la versione del pacchetto, application e platform per la versione minima dell’applicazione e della piattaforma su cui si basa, runtime per la versione del linguaggio, dependencies per le altre app da cui dipende.

incrementa sempre la versione a ogni rilascio: un aggiornamento è proprio l’installazione di una versione più alta;
non alzare application o runtime senza motivo, perché restringi le versioni su cui l’estensione può girare;
tieni le dipendenze al minimo indispensabile e documentate.

Regola 5: lasciare lavorare gli analizzatori

L’estensione AL di Visual Studio Code include quattro analizzatori di codice: CodeCop per le linee guida di scrittura, PerTenantExtensionCop per le estensioni installate su un singolo tenant, AppSourceCop per le app destinate al marketplace e UICop per le personalizzazioni dell’interfaccia web. Per un’estensione su misura i primi due sono il minimo.

Gli avvisi non vanno ignorati per abitudine. Se una regola non ha senso per il tuo progetto, disattivala in modo esplicito in un ruleset, con una motivazione, così chi arriva dopo sa che è una scelta e non una dimenticanza.

Regola 6: provare prima, in un ambiente di anteprima

Prima di ogni aggiornamento principale Microsoft rende disponibili le versioni di anteprima. Puoi creare una sandbox nuova sulla versione di anteprima, oppure aggiornare all’anteprima una sandbox esistente, magari copia della produzione, con le tue estensioni installate. Così verifichi sia che l’aggiornamento vada a buon fine sia che i processi funzionino. Gli ambienti di anteprima vengono eliminati qualche tempo dopo il rilascio, quindi vanno trattati come ambienti di prova. I dettagli sono nella pagina Microsoft sugli ambienti di anteprima.

Accanto ai test manuali, anche pochi test automatici sui processi critici fanno la differenza.

Regola 7: telemetria, sorgenti e pipeline

Telemetria: Business Central può inviare dati di telemetria ad Azure Application Insights, e un’estensione può avere una propria connection string nell’app.json. Errori, prestazioni ed esiti degli aggiornamenti diventano visibili prima che li segnalino gli utenti.
Controllo del codice sorgente: ogni estensione in un repository Git, con una storia leggibile delle modifiche. Il codice che esiste solo sul PC di uno sviluppatore è un rischio per l’azienda.
Pipeline di build: AL-Go for GitHub è il progetto Microsoft che fornisce modelli e azioni per compilazione, test e rilascio delle app AL. Anche una pipeline semplice garantisce che ogni versione sia compilata con gli analizzatori attivi e i test eseguiti.
Documentazione: cosa fa l’estensione, quali eventi usa, quali dati aggiunge. Bastano poche pagine, purché aggiornate.

Cosa chiedere a chi sviluppa per te

Se non sei tecnico, puoi comunque fare le domande giuste: le personalizzazioni sono tutte estensioni? Dove sta il codice sorgente? Vengono testate in anteprima prima degli aggiornamenti? Chi controlla gli avvisi di obsolescenza? Risposte chiare sono un buon segno.

Parliamone

Se vuoi far verificare le estensioni installate sul tuo Business Central, o impostare un modo di sviluppare che regga gli aggiornamenti, scrivici.