Modulo 1 — Business Central · E-learning (PC)

Modulo 1 — Orientarsi in Business Central senza rompere niente

Versione e-learning: Business Central 28, runtime AL 17.0 (alternativa BC 27, runtime 16.0). Prima si studia in slide, poi si fa l'esercizio in sandbox, poi il mini-test. Usa le frecce della tastiera per le slide. Tempo e progresso sono salvati nel browser.

Introduzione — Come si studia questo modulo

INTRODUZIONE · CONCETTO

Questo è un corso, non un documento da scorrere

Prima si studia, poi si fa, poi si verifica. In quest'ordine, sempre.

Ogni sezione è una lezione in slide: una idea per slide, avanti e indietro con i pulsanti o con le frecce della tastiera. Solo dopo aver visto tutte le slide si apre l'esercizio guidato in sandbox, e solo dopo l'esercizio arriva il mini-test.

INTRODUZIONE · SCHEMA

Il percorso in 10 lezioni

Sezione 0 → 1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9 → Consegna → 36 domande finali

Le tappe sono bloccate in ordine. Una tappa completata resta rivisitabile, ma non si può saltare avanti. Il tempo totale e il tempo per lezione restano sempre visibili in alto, e progresso e risultati sono salvati nel browser: chiudendo e riaprendo, riprendi da dove eri.

INTRODUZIONE · CONCETTO

Cosa ti serve, e cosa non ti serve

PC, VS Code con AL Language, una sandbox Business Central. Mai la produzione.

Versione del corso: Business Central 28, runtime AL 17.0; alternativa coerente BC 27, runtime 16.0. I file app.json e launch.json vanno generati con AL: Go! per la tua sandbox reale, mai copiati da tutorial vecchi. La regola d'oro di tutto il modulo: mai modificare la Base Application, solo extension, solo in sandbox, e verifica finale con un utente non-SUPER.

Sezione 0 — Come usare questo modulo da solo

LEZIONE 0 · CONCETTO

Questo modulo si fa, non si legge

Si studia facendo.

Sei un programmatore che parte da zero su Business Central. Ogni sezione va fatta in sandbox, non solo letta.

LEZIONE 0 · SCHEMA

L'ordine che non si salta

Studio → Esercizio → Test

Prima capisci il concetto, poi lo provi in sandbox, poi verifichi con il mini-test. Sempre in quest'ordine.

LEZIONE 0 · CONCETTO

Cosa ti serve prima di partire

PC, VS Code, sandbox.

Ti servono un PC, VS Code con l'estensione AL Language e una sandbox. Versione di riferimento: Business Central 28, runtime 17.0; se la tua sandbox è BC 27, il runtime è 16.0.

LEZIONE 0 · CONCETTO

Cosa non ti serve ancora

Niente contabilità, niente AL, niente BC.

Non devi sapere nulla di Business Central, di contabilità o di AL. Sai già programmare in un altro linguaggio: è il prerequisito vero.

LEZIONE 0 · ESEMPIO

Come è fatta ogni sezione

Spiegazione, esempio, esercizio, errore tipico.

La struttura non cambia mai. Così sai sempre dove sei: stai leggendo, stai provando, o stai verificando.

LEZIONE 0 · ERRORE TIPICO

Leggere tutto di fila

“Gli esercizi li faccio dopo.”

È l'errore tipico di questo modulo. Leggere senza fare non conta come studio: il “dopo” non arriva mai.

LEZIONE 0 · CONFRONTO

Raccontare contro dimostrare

Alla fine dimostri, non racconti.

Chi controlla non fa lezione e non spiega da capo. Controlla solo che la consegna esista e funzioni, in sandbox, mai in produzione.

LEZIONE 0 · RIEPILOGO

Quando puoi andare avanti

Solo se l'esercizio funziona.

Non passare alla sezione successiva se l'esercizio non funziona. Torna indietro, rileggi, riprova: è così che il modulo è pensato.

2 · Esercizio guidato in sandbox

Si apre dopo aver visto tutte le slide della lezione. Lavoro solo in sandbox, mai in produzione.

Esercizio guidato 0 — Cosa dovrai saper dimostrare

Obiettivo: scrivere, con parole tue, cosa dovrai saper dimostrare alla fine del modulo. Tieni come riferimento la “Consegna verificabile” del Modulo 1 e l'indice delle sezioni.

  1. Apri l'indice del modulo e leggi i titoli delle Sezioni da 0 a 9.
  2. Leggi la “Consegna verificabile”: sandbox identificata, mappa del codice, prima extension pubblicata, estensione “senza rompere niente”, permission set con prova non-SUPER, checklist “prima di pubblicare”.
  3. Scrivi in 5 righe cosa dovrai saper dimostrare alla fine del modulo.
  4. Rileggi le tue 5 righe: ogni riga deve indicare qualcosa da mostrare in sandbox, non un argomento letto.
  5. Se non sai rispondere, rileggi questa sezione e l'indice, poi riparti dal punto 1.
  • Le righe sono 5, scritte con parole tue.
  • Ogni riga indica una dimostrazione in sandbox, non un'opinione.
  • La consegna è in sandbox, mai in produzione.
  • Nota per dopo: quando arriverai a generare un progetto, app.json e launch.json vanno generati con AL: Go! per la tua sandbox reale, mai copiati da tutorial vecchi.

Campo testo (descritto, non funzionante in questo frammento): un'area di testo con etichetta “Le mie 5 righe — cosa dovrò saper dimostrare”, in cui lo studente scrive le 5 righe dell'esercizio. In questa versione del frammento il campo è solo descritto: non invia e non salva nulla.

3 · Mini-test

Leggi ogni domanda, scegli la risposta, poi premi “Mostra risposta” per leggere la spiegazione. Le risposte sono nel testo per il controllo locale: l'obiettivo è attraversare lezione, esercizio e test, non barare sul punteggio.

Mini-test 0

Domanda 1

In che ordine si studia ogni sezione di questo modulo?

  1. Test, poi studio, poi esercizio.
  2. Leggere tutte le sezioni, poi fare tutti gli esercizi alla fine.
  3. Studio, poi esercizio in sandbox, poi mini-test.
  4. Esercizio da soli, senza mai leggere la spiegazione.

Risposta corretta: C

Spiegazione: l'ordine è studio → esercizio → test. A inverte l'ordine; B è proprio l'errore tipico (rimandare gli esercizi); D salta la spiegazione, che serve a capire cosa si sta provando.

Domanda 2

Cosa ti serve per iniziare il percorso in sandbox cloud descritto qui?

  1. Un PC, VS Code con l'estensione AL Language e una sandbox.
  2. Un SDK .NET separato, obbligatorio prima di cominciare.
  3. Una conoscenza preliminare di contabilità e di AL.
  4. Una lezione live con un docente.

Risposta corretta: A

Spiegazione: bastano PC, VS Code con l'estensione AL e una sandbox. B è sbagliato: la documentazione Microsoft Learn “Get started with AL” non elenca un SDK .NET separato come prerequisito per questo percorso; C è sbagliato: il prerequisito è saper programmare in un altro linguaggio; D è sbagliato: il modulo è asincrono, da solo, senza lezioni live.

Domanda 3

Quando puoi passare alla sezione successiva?

  1. Quando hai letto la sezione una volta.
  2. Quando l'esercizio della sezione funziona in sandbox.
  3. Quando hai letto anche la sezione successiva.
  4. Quando il mini-test è stato solo letto, senza rispondere.

Risposta corretta: B

Spiegazione: si va avanti solo se l'esercizio funziona. A confonde lettura e studio; C anticipa il lavoro invece di chiuderlo; D non verifica nulla: il test va fatto, non solo letto.

Domanda 4

Cosa consegni alla fine del Modulo 1?

  1. Un riassunto scritto di tutte le sezioni.
  2. Un esercizio svolto in produzione.
  3. Una promessa di saper usare Business Central.
  4. Una consegna verificabile in sandbox: sandbox identificata, extension pubblicata e funzionante, prova con utente non-SUPER, checklist compilata.

Risposta corretta: D

Spiegazione: la consegna si dimostra in sandbox e deve funzionare. A è solo un racconto; B viola la regola base (solo in sandbox, mai in produzione); C è un'intenzione, non una prova.

Per completare servono: tutte le slide viste, tutte le spunte dell'esercizio, testo dell'esercizio compilato, spunta del mini-test.

Sezione 1 — Che cos'è Business Central, per un programmatore

LEZIONE 1 · CONCETTO

Non “un gestionale”. Un'applicazione a oggetti.

Un ERP che si estende, non si riscrive.

Business Central è un ERP: tutta la funzionalità è codificata in oggetti. Il passaggio da fare è da “è un gestionale” a “è un'applicazione a oggetti che si estende”.

LEZIONE 1 · SCHEMA

Gli oggetti e il loro pacchetto

  • Tabelle · Pagine
  • Codeunit · Report · Enum
  • File .al → pacchetto .app

Il linguaggio è AL, l'ambiente è VS Code con l'estensione AL Language. Il manifest del pacchetto .app dichiara nome, publisher, versione e dipendenze.

LEZIONE 1 · ESEMPIO

La Base Application è una libreria

Tu scrivi il plugin, non la libreria.

In cloud non possiedi il sorgente base da modificare. La tua extension si aggancia tramite punti di estensione dichiarati, senza modificare la libreria.

LEZIONE 1 · CONFRONTO

Da NAV a Business Central

Modifica diretta → extension + eventi.

In Dynamics NAV prevaleva la modifica diretta degli oggetti base in C/AL, con merge manuale a ogni upgrade. In Business Central il modello è AL, extension ed eventi.

LEZIONE 1 · CONCETTO

Role Center: la pagina iniziale del ruolo

Una panoramica, non una tabella.

Il Role Center è la pagina iniziale per un profilo utente. Non è collegato a una tabella sorgente: è assemblato con parti, ciascuna collegata a una tabella.

LEZIONE 1 · CONCETTO

Tell Me: prima cerca, poi concludi

Se non la trovi nel menu, cercala.

Tell Me è la ricerca integrata di Business Central per pagine, report, azioni e impostazioni. Se non trovi una pagina dal menu, cercala con Tell Me prima di concludere che non esista.

LEZIONE 1 · SCHEMA

Tre tipi di dati, tre ruoli diversi

  • Anagrafiche: dati stabili
  • Documenti: testata + righe
  • Registrazioni: storia, non si riscrive

Anagrafiche come cliente, fornitore, articolo. Documenti come ordini. Registrazioni: i movimenti registrati (ledger) dopo il posting.

LEZIONE 1 · ESEMPIO

Un documento, testata + righe

Sales Header + Sales Line.

La testata contiene i dati generali, le righe il dettaglio. Lo stesso vale per un ordine di acquisto: Purchase Header + Purchase Line.

LEZIONE 1 · ERRORE TIPICO

“Tanto è solo un campo in più”

Il campo in più è un'extension.

Un campo in più non giustifica toccare la base. È l'esempio classico di ciò che si fa con un'extension, come vedrai nella Sezione 4.

LEZIONE 1 · RIEPILOGO

Estendere senza rompere la base

Base intatta. Extension separata.

Chi arriva da NAV, o da ERP dove “si tocca il core”, deve prima disimparare quell'abitudine, poi imparare la sintassi. Tenant, ambiente e azienda non sono sinonimi: li distingui nella Sezione 3.

2 · Esercizio guidato in sandbox

Si apre dopo aver visto tutte le slide della lezione. Lavoro solo in sandbox, mai in produzione.

Esercizio guidato 1 — Modificare la base contro creare un'extension

Obiettivo: spiegare la differenza con parole tue e orientarti nella sandbox con Tell Me. Lavora solo in sandbox: può contenere dati demo (in genere l'azienda di esempio CRONUS) oppure una copia dei dati di produzione, ma resta una sandbox, non è produzione.

  1. Scrivi in 5 righe, con parole tue, la differenza tra “modifico la base” e “creo un'extension”.
  2. Apri la sandbox e usa Tell Me per trovare Customer List.
  3. Annota quale tabella è la sorgente di Customer List.
  4. Usa Tell Me per trovare Customer Card.
  5. Annota quale tabella è la sorgente di Customer Card e confrontala con quella di Customer List.
  6. Se non sai spiegare la differenza tra modificare la base e creare un'extension, non proseguire: rileggi le slide 3, 4, 9 e 10 di questa sezione.

Campo testo (descritto, non funzionante in questo frammento): un'area di testo con etichetta “Le mie 5 righe — modificare la base contro creare un'extension”, seguita da due campi descrittivi, “Tabella sorgente di Customer List” e “Tabella sorgente di Customer Card”, in cui lo studente scrive le risposte. In questa versione del frammento i campi sono solo descritti: non inviano e non salvano nulla.

3 · Mini-test

Leggi ogni domanda, scegli la risposta, poi premi “Mostra risposta” per leggere la spiegazione. Le risposte sono nel testo per il controllo locale: l'obiettivo è attraversare lezione, esercizio e test, non barare sul punteggio.

Mini-test 1

Domanda 1

In Business Central moderno, come si personalizza il comportamento standard senza “rompere” gli aggiornamenti?

  1. Modificando direttamente gli oggetti della Base Application.
  2. Creando un'extension separata che estende gli oggetti esistenti.
  3. Modificando il database con SQL.
  4. Copiando gli oggetti base con un nuovo ID sotto 50.000.

Risposta corretta: B

Spiegazione: si estende con un'extension separata, tramite punti di estensione dichiarati. A rompe il modello e gli upgrade; C aggira l'applicazione e non è il modello AL; D non è un'extension: è una copia della base con un altro ID.

Domanda 2

Cos'è il Role Center?

  1. Una tabella con i dati di tutti gli utenti.
  2. La pagina iniziale per un profilo utente, assemblata con parti collegate a tabelle.
  3. Un report di controllo per l'amministratore.
  4. La lista di tutte le extension installate.

Risposta corretta: B

Spiegazione: il Role Center mostra panoramica, navigazione e azioni del ruolo ed è assemblato con parti. A è sbagliato: non è una tabella; C confonde una pagina iniziale con un report; D è Extension Management, non il Role Center.

Domanda 3

Cosa succede con il posting di un documento?

  1. Il documento diventa un'anagrafica.
  2. Il documento viene cancellato e riscritto come pagina.
  3. Il documento si trasforma in movimenti registrati (ledger), che in genere non si modificano a mano.
  4. Il documento resta modificabile come prima, senza alcuna differenza.

Risposta corretta: C

Spiegazione: il posting trasforma un documento in storia contabile e di magazzino. A confonde documenti e anagrafiche; B inventa una riscrittura come pagina; D ignora proprio il punto: dopo il posting i movimenti registrati in genere non si modificano a mano, ed è per questo che un errore di codice su un documento è più grave di un errore di visualizzazione.

Domanda 4

Un programmatore AL che vuole certificarsi come sviluppatore deve puntare a quale certificazione?

  1. MB-800, perché è la certificazione da sviluppatore.
  2. MB-820 (Developer Associate); MB-800 è Functional Consultant.
  3. Prima MB-800 obbligatoriamente, poi MB-820, perché è un prerequisito formale.
  4. Nessuna: Microsoft non ha certificazioni per Business Central.

Risposta corretta: B

Spiegazione: MB-820 è la certificazione da sviluppatore; MB-800 è Functional Consultant e copre configurazione contabile e operatività, non codice AL. A inverte i ruoli; C inventa un prerequisito formale; D è falsa: le certificazioni esistono.

Per completare servono: tutte le slide viste, tutte le spunte dell'esercizio, testo dell'esercizio compilato, spunta del mini-test.

Sezione 2 — Cloud vs on-premises: cosa cambia per chi sviluppa

LEZIONE 2 · CONCETTO

La domanda giusta, prima di scrivere codice

Dove gira Business Central cambia il tuo lavoro, non il linguaggio.

In questo modulo: Business Central 28 / runtime 17.0 (alternativa: 27 / 16.0). Questo corso usa la sandbox cloud. Capire l'on-premises serve per riconoscerlo, non per partire da lì.

LEZIONE 2 · CONCETTO

Cloud / SaaS: il servizio lo gestisce Microsoft

Tu sviluppi. Microsoft gestisce server, web server e database su Azure.

Lo sviluppatore non installa server, web server o database. Lavora in VS Code su una sandbox online, con gli strumenti del servizio.

LEZIONE 2 · CONCETTO

On-premises: installa e gestisce l'organizzazione

Server, web server e database sono in casa del cliente o del partner.

La documentazione elenca: Business Central Server, Business Central Web Server e componenti database. Requisiti citati: Windows Server o Windows 11/10, .NET 8.0, IIS 10 per il Web Server, SQL Server o Azure SQL.

LEZIONE 2 · SCHEMA

On-premises: quattro topologie, un'idea sola

Più componenti separi, più macchine servono — e più gestione serve.
  • Dimostrativa: tutto su un solo computer, con dati demo
  • A un computer
  • A due computer: web server separato da server + database
  • A tre computer: web server, server e database separati

LEZIONE 2 · CONFRONTO

Cloud vs on-premises, in quattro righe

Chi ospita, chi aggiorna, chi tocca il database: tre risposte diverse.
Cloud / SaaSOn-premises
Chi ospitaMicrosoft su AzureL'organizzazione
Chi aggiornaMicrosoftCliente o partner
Accesso al databaseNoSì, se autorizzato
StrumentiVS Code e DesignerAnche SSMS e altri

LEZIONE 2 · CONCETTO

La differenza più importante

In cloud non esiste “apro il database e sistemo la riga”.

Neppure “apro il sorgente standard e cambio due righe”. Si passa sempre da oggetti AL, API ed eventi. Mai modificare la Base Application: solo extension, solo in sandbox.

LEZIONE 2 · CONFRONTO

Sandbox online vs sandbox container

Online: niente accesso al database. Container: accesso al database sì.

Il container è un approfondimento futuro, non il percorso principale: richiede tra l'altro Windows, Docker in modalità Windows containers (Business Central non gira su container Linux) e strumenti come BcContainerHelper. Debug e distribuzione restano in VS Code: in sandbox l'app si pubblica da VS Code, il container aggiunge solo strumenti extra come SSMS.

LEZIONE 2 · CONCETTO

Aggiornamenti in cloud: li gestisce Microsoft

Ciclo semestrale (“release wave”) + aggiornamenti minori mensili.

I minori portano nuove funzionalità della wave, aggiornamenti normativi e correzioni critiche. L'Admin Center permette di gestire gli aggiornamenti per ambiente. Non si può rimandare per sempre l'adeguamento del codice.

LEZIONE 2 · CONCETTO

Aggiornamenti on-premises: li decide il cliente

On-premises si può rimandare. Ma il debito si accumula.

Ogni salto è un progetto di upgrade — conversione del database, sincronizzazione, pubblicazione delle app in ordine di dipendenza — non un clic. Rimandare non cancella il lavoro: lo sposta in avanti, più grande.

LEZIONE 2 · ERRORE TIPICO

“Sistemo la riga nel database”

Portare abitudini on-premises e SQL in cloud fa perdere tempo.

In cloud quella strada non c'è. Se la cerchi, ti blocchi prima di cominciare. Torna alla strada corretta: oggetto AL, API o evento — e verifica con un utente non-SUPER.

LEZIONE 2 · RIEPILOGO

Sezione 2 in una frase

Cloud: sviluppi in sandbox, con AL, senza toccare database né standard.

On-premises cambia chi ospita, chi aggiorna e a cosa puoi accedere. Il container, con accesso al database, resta un approfondimento futuro.

2 · Esercizio guidato in sandbox

Si apre dopo aver visto tutte le slide della lezione. Lavoro solo in sandbox, mai in produzione.

Esercizio guidato — Sezione 2 -->

Esercizio guidato 2 — La tabella cloud vs on-premises

Obiettivo: spiegare con parole tue, non copiate da questa sezione, cosa cambia per chi sviluppa.

  1. Apri un documento vuoto e disegna una tabella a due colonne: cloud / SaaS e on-premises.
  2. Scrivi le quattro righe, una alla volta: chi ospita, chi aggiorna, accesso al database, strumenti.
  3. Per ogni riga, scrivi la risposta con parole tue, senza guardare la slide di confronto.
  4. Aggiungi una quinta riga: “Cosa NON posso fare in cloud?” — e rispondi in una frase.
  5. Rileggi la tabella e confrontala con la slide di confronto: correggi solo ciò che è di fatto sbagliato, non lo stile.
  • ☐ La tabella ha due colonne e almeno quattro righe: chi ospita, chi aggiorna, accesso al database, strumenti.
  • ☐ Per il cloud è chiaro: niente accesso diretto al database, niente modifica del sorgente standard.
  • ☐ Per l'on-premises è chiaro: chi ospita e chi aggiorna è l'organizzazione (cliente o partner).
  • ☐ Il testo è scritto con parole tue, non copiato da questa sezione.

Mini-test 2 — Quattro domande

1. In una sandbox cloud, chi gestisce server, web server e database?

  1. A. Lo sviluppatore, che li installa sul proprio PC
  2. B. Microsoft, su Azure
  3. C. Il cliente, con il proprio reparto IT
  4. D. Nessuno: la sandbox non ha database

Risposta corretta: B.

A è sbagliata: in cloud lo sviluppatore non installa server, web server o database. C descrive l'on-premises, non il cloud. D è sbagliata: la sandbox ha un database, ma lo sviluppatore non vi accede direttamente.

2. Qual è la differenza principale tra sandbox online e sandbox container?

  1. A. L'online ha accesso al database, il container no
  2. B. Il container ha accesso al database, l'online no
  3. C. Sono identiche in tutto
  4. D. L'online richiede Docker in modalità Windows containers

Risposta corretta: B.

A inverte i termini. C è sbagliata: accesso al database e strumenti differiscono. D è sbagliata: Docker in modalità Windows containers è un requisito del container, non della sandbox online.

3. In cloud, come si cambia un comportamento standard?

  1. A. Modificando la riga direttamente nel database
  2. B. Modificando il sorgente della Base Application
  3. C. Con oggetti AL, API ed eventi, in un'extension
  4. D. Con C/SIDE, lo strumento AL moderno

Risposta corretta: C.

A è l'errore tipico di questa sezione: in cloud quella strada non c'è. B è vietato: la Base Application non si modifica mai, solo extension. D è sbagliata: C/SIDE è tecnologia legacy dell'era NAV, non uno strumento AL moderno.

4. On-premises, che cos'è un salto di versione?

  1. A. Un clic che Microsoft applica in automatico
  2. B. Un progetto di upgrade: conversione database, sincronizzazione, pubblicazione delle app in ordine di dipendenza
  3. C. Un aggiornamento minore mensile, sempre uguale al cloud
  4. D. Un'operazione che non serve mai, perché on-premises non si aggiorna

Risposta corretta: B.

A descrive la gestione cloud, non on-premises. C confonde gli aggiornamenti minori cloud con l'upgrade on-premises. D è sbagliata: on-premises si può rimandare, ma il debito si accumula — prima o poi l'upgrade va fatto.

Per completare servono: tutte le slide viste, tutte le spunte dell'esercizio, testo dell'esercizio compilato, spunta del mini-test.

Sezione 3 — Tenant, ambiente, azienda — e sandbox vs produzione

LEZIONE 3 · CONCETTO

Tre parole, tre livelli. Mai confusi.

Tenant, ambiente e azienda non sono sinonimi.

Obiettivo di questa sezione: non confondere mai i tre livelli — e non sviluppare mai in produzione. Se sai dire dove sei, sai anche cosa ti è permesso fare.

LEZIONE 3 · SCHEMA

La gerarchia, in tre scatole

Un tenant contiene ambienti. Un ambiente contiene aziende.
TENANT
Identità dell'organizzazione in Microsoft Entra
↓ AMBIENTE
Istanza isolata, con proprio database
↓ AZIENDA
Entità legale o unità di business

Leggila dall'alto in basso: ogni livello sta dentro quello sopra, e ha regole proprie.

LEZIONE 3 · CONCETTO

Tenant: chi sei, come organizzazione

Il tenant è l'identità organizzativa in Microsoft Entra (ex Azure AD).

L'Admin Center amministra un tenant: ambienti di produzione e sandbox, notifiche, accessi, telemetria Application Insights. Un tenant, tanti ambienti.

LEZIONE 3 · CONCETTO

Ambiente: un'istanza isolata

Ogni ambiente ha proprio database e proprie configurazioni.

Ogni ambiente è legato a un paese e a una localizzazione specifica, che determina anche la regione Azure. Isolato vuol dire: ciò che fai qui non tocca gli altri ambienti.

LEZIONE 3 · CONCETTO

Azienda: chi fa i conti

Dentro un ambiente possono esistere più aziende.

Ogni azienda è un'entità legale o un'unità di business con requisiti contabili separati. Stesso ambiente, aziende diverse, conti separati.

LEZIONE 3 · ESEMPIO

Contoso, per fissare la gerarchia

Tenant Contoso → Ambiente “Produzione IT” → Contoso S.p.A. e Contoso Retail S.r.l.

In parallelo, un Ambiente “Sandbox IT” con la stessa struttura, ma dati di test. Stesso tenant, stesso schema di aziende — ambiente diverso, dati diversi.

LEZIONE 3 · CONFRONTO

Produzione vs sandbox, in quattro righe

Stesso prodotto, scopo opposto: lavoro reale contro banco di prova.
ProduzioneSandbox
ScopoAttività quotidiana realeSviluppo, test, formazione, demo
DatiDati aziendali realiDati demo o copia di produzione
Deploy da VS Code (DEV)NoSì
DebugEndpoint non aperto di defaultEndpoint aperto di default
CancellazioneOperazione criticaSi può eliminare e ricominciare

LEZIONE 3 · CONCETTO

Sandbox: il banco di prova

In sandbox “si può giocare, usarla come banco di prova per lo sviluppo, e cancellarla a piacimento”.

Si possono distribuire app direttamente da VS Code e collegare una sessione di debug. Le DEV extension esistono solo in sandbox: in produzione non ci sono.

LEZIONE 3 · CONCETTO

Dati demo o copia di produzione?

Demo per imparare. Copia di produzione per testare sul reale — restando in sandbox.

Le sandbox possono avere dati demo, una copia dei dati di produzione (da Admin Center) o pacchetti RapidStart. Una copia aggiornata è il terreno migliore per testare prima di andare in produzione.

LEZIONE 3 · CONCETTO

Upgrade o spostamento: le DEV vanno via, i dati restano

L'upgrade della sandbox rimuove le DEV extension. Non i dati.

Basta ripubblicare e reinstallare. Le app caricate con Upload Extension da Extension Management (scope globale) vengono invece riscaricate e reinstallate, quindi non scompaiono.

LEZIONE 3 · CONCETTO

Limiti della sandbox, da ricordare

Una sandbox con dati di produzione resta una sandbox.
  • I database sandbox non si possono esportare (dati fuori: Excel, RapidStart, o copia dell'ambiente in produzione)
  • Il tier non è quello di produzione: non è affidabile per benchmark
  • Le chiamate HTTP in uscita sono bloccate di default, da approvare per app
  • Le sandbox su versioni preview non vengono aggiornate al rilascio e vengono eliminate a fine periodo preview

LEZIONE 3 · ERRORE TIPICO

“Si chiama Produzione, quindi è produzione”

Il nome dell'ambiente non fa fede. Il tipo vero si verifica nell'Admin Center.

Altri errori della stessa famiglia: sviluppare in produzione, usare la sandbox per benchmark, dimenticare di ripubblicare le DEV dopo upgrade o spostamento, lasciare le HTTP bloccate e pensare che “l'integrazione non funzioni”.

LEZIONE 3 · RIEPILOGO

Il flusso corretto, sempre

Sandbox → test → PTE → produzione. Mai sviluppare direttamente in produzione.

Sviluppa in sandbox, testa in sandbox (possibilmente con copia aggiornata dei dati di produzione), impacchetta come PTE, installa o aggiorna in produzione da Extension Management o Admin Center. Mai modificare la Base Application: solo extension, verificate con un utente non-SUPER.

2 · Esercizio guidato in sandbox

Si apre dopo aver visto tutte le slide della lezione. Lavoro solo in sandbox, mai in produzione.

Esercizio guidato — Sezione 3 -->

Esercizio guidato 3 — Crea (o fatti assegnare) la tua sandbox

Obiettivo: avere una sandbox reale, identificata per nome, pronta per le sezioni successive. app.json e launch.json saranno generati da AL:Go! per questa sandbox reale, mai copiati da tutorial vecchi.

  1. Apri l'Admin Center e vai su Environments.
  2. Scegli New per creare un nuovo ambiente.
  3. Scrivi il nome dell'ambiente (annotalo esattamente: ti servirà più avanti).
  4. Imposta Environment Type = Sandbox — mai Production. Controlla due volte prima di andare avanti.
  5. Imposta Country e Version, poi premi Create.
  6. Attendi finché State = Active. Non cominciare a sviluppare prima: un ambiente non attivo non è pronto.
  7. Verifica nell'Admin Center che il tipo sia davvero Sandbox: il nome, da solo, non fa fede.
  8. Annota il nome esatto: dovrà coincidere con environmentName in launch.json (Sezione 5).
  • ☐ Environment Type = Sandbox (mai Production), verificato nell'Admin Center.
  • ☐ State = Active.
  • ☐ Nome esatto dell'ambiente annotato e pronto per environmentName in launch.json.
  • ☐ È chiaro che app.json / launch.json saranno generati da AL:Go! per questa sandbox, non copiati da tutorial vecchi.

Mini-test 3 — Quattro domande

1. Qual è l'ordine corretto della gerarchia?

  1. A. Azienda → ambiente → tenant
  2. B. Tenant → ambiente → azienda
  3. C. Ambiente → tenant → azienda
  4. D. Tenant → azienda → ambiente

Risposta corretta: B.

A inverte l'ordine. C mette l'ambiente sopra il tenant, ma è il tenant a contenere gli ambienti. D mette l'azienda sopra l'ambiente, ma le aziende stanno dentro un ambiente.

2. Dove si può distribuire un'app direttamente da VS Code come DEV extension?

  1. A. In produzione, perché è più veloce
  2. B. Solo in sandbox
  3. C. In produzione e in sandbox allo stesso modo
  4. D. Da nessuna parte: le DEV extension non esistono

Risposta corretta: B.

A è l'errore tipico di questa sezione: non si sviluppa mai in produzione. C è sbagliata: in produzione le DEV extension non esistono. D è sbagliata: esistono, ma solo in sandbox.

3. Dopo l'upgrade di una sandbox, che cosa succede?

  1. A. Le DEV extension restano e i dati vengono cancellati
  2. B. Le DEV extension vengono rimosse, i dati sono preservati: basta ripubblicare e reinstallare
  3. C. Non cambia nulla, né app né dati
  4. D. La sandbox diventa automaticamente produzione

Risposta corretta: B.

A inverte i termini: via le DEV, restano i dati. C è sbagliata: le DEV vanno ripubblicate. D è sbagliata: il tipo non cambia per upgrade, e il nome da solo non fa mai fede — il tipo si verifica nell'Admin Center.

4. Una sandbox con una copia dei dati di produzione…

  1. A. È produzione a tutti gli effetti: si può usare per benchmark e si può esportarne il database
  2. B. Resta una sandbox: niente export del database, niente tier di produzione, niente garanzie di produzione
  3. C. Diventa produzione se la si rinomina “Produzione”
  4. D. Ha le chiamate HTTP in uscita sempre aperte, come in produzione

Risposta corretta: B.

A è sbagliata su entrambi i punti: niente export del database sandbox e niente benchmark affidabile. C è sbagliata: il nome non fa fede, il tipo si verifica nell'Admin Center. D è sbagliata: in sandbox le HTTP sono bloccate di default e vanno approvate per app, altrimenti arriva l'errore di blocco del runtime.

Per completare servono: tutte le slide viste, tutte le spunte dell'esercizio, testo dell'esercizio compilato, spunta del mini-test.

Sezione 4 — Base Application vs extension: il cuore del modulo

LEZIONE 4 · CONCETTO

La Base Application è l'ERP standard

Finanza, vendite, acquisti, magazzino, produzione, servizi, progetti.

È ciò che l'utente vede aprendo Business Central “liscio”: logica gestionale implementata come oggetti AL — tabelle, pagine, codeunit, report, enum.

LEZIONE 4 · CONCETTO

La System Application è un altro strato

Piattaforma e framework, non logica gestionale.

Servizi di base, gestione errori, email, notifiche e simili. Non va confusa con la Base Application: sono due strati diversi, con ruoli diversi.

LEZIONE 4 · CONCETTO

Un'extension aggiunge, non riscrive

Nuovi oggetti + estensioni di oggetti esistenti.

Definizione Microsoft Learn: la funzionalità è definita come aggiunta a oggetti esistenti, per modificare il comportamento della soluzione senza riscriverla.

LEZIONE 4 · ESEMPIO

Un'azienda di cibo biologico

Campi “Organic” e “Local Produce” sugli articoli.

Esempio ufficiale: una table extension aggiunge i campi alla tabella articoli; una page extension li mostra nell'interfaccia. La tabella standard resta intatta.

LEZIONE 4 · SCHEMA

Base vs extension: cosa tocca chi

BASE APPLICATION → resta com'è, aggiornata da Microsoft.
EXTENSION → aggiunge campi, pagine, logica, sicurezza.
MAI → modificare un oggetto della base.

Si estendono tabelle, enum, pagine, report, flussi di codice e modello di sicurezza. Il codice AL vive in file .al; il pacchetto compilato è il file .app.

LEZIONE 4 · CONFRONTO

Tre tipi di extension, tre destini diversi

Global app · Per-tenant extension (PTE) · DEV extension

Global: produzione e sandbox, non controllata dal tenant. PTE: produzione e sandbox, controllata dal tenant. DEV: solo sandbox, controllo completo. Force sync: no per Global, consentito per PTE e DEV.

LEZIONE 4 · CONCETTO

Identità e dipendenze: il grafo che tiene tutto insieme

id + version identificano l'extension; le dipendenze ne ordinano installazione e upgrade.

Ordine: System → Base → Application → Microsoft e terze parti → personalizzazioni. Senza dipendenza dichiarata in app.json, il compilatore non risolve i riferimenti: servono i simboli.

LEZIONE 4 · CONCETTO

Gli eventi: estendere il codice senza toccarlo

Publisher lancia l'evento · Subscriber risponde.

Il codice standard pubblica un evento in un punto preciso; il tuo codice subscriber si aggancia a quel punto. La base non viene modificata, ma il comportamento cambia.

LEZIONE 4 · ERRORE TIPICO

IsHandled: usato con misura, o fa danni

Impostalo solo se hai davvero gestito il caso.

In alcuni eventi, IsHandled segnala che un subscriber ha già gestito il caso e la logica standard può essere saltata. Usato a sproposito, salta logica che serviva: misura, non automatismo.

LEZIONE 4 · SCHEMA

Publish ≠ Sync ≠ Install

PUBLISH → aggiunge l'extension al database applicativo.
SYNC → aggiorna lo schema del database del tenant.
INSTALL → rende attiva l'extension.

Tre passi distinti. Confonderli significa credere che una funzionalità sia attiva quando è solo pubblicata, o viceversa.

LEZIONE 4 · ERRORE TIPICO

Force sync: il rischio è perdere dati

Sincronizzare con forza può rimuovere dati legati allo schema.

In sandbox si può cancellare e ricominciare. In produzione no: ordini, fatture e magazzino sono reali. Per questo le DEV vivono solo in sandbox e le PTE non testate non vanno in produzione.

LEZIONE 4 · RIEPILOGO

La regola d'oro

Mai modificare la Base Application. Solo extension, solo in sandbox.

Posizione Microsoft, testuale: invece di personalizzare il codice della Base, è fortemente consigliato creare extension ogni volta che è possibile. Verifica finale con un utente non-SUPER.

2 · Esercizio guidato in sandbox

Si apre dopo aver visto tutte le slide della lezione. Lavoro solo in sandbox, mai in produzione.

Esercizio guidato 4 — “Canale di vendita preferito” su Customer

Non scrivere codice in questa sezione: descrivi oggetti e destino. Lavora in sandbox.

  1. Crea una table extension su Customer che aggiunge il campo “Canale di vendita preferito”. Annota: è un nuovo oggetto, la tabella Customer standard non viene toccata.
  2. Crea una page extension su Customer Card che mostra il campo. Annota: la pagina standard non viene modificata, viene estesa.
  3. Scenario A — fatto bene: descrivi la PTE versionata. All'upgrade, campo e dati restano; la PTE non viene disinstallata dalla produzione, salvo che impedisca l'upgrade.
  4. Scenario B — fatto male (on-premises): descrivi la modifica diretta alla Customer Card nella base personalizzata. A ogni aggiornamento serve un nuovo merge, risincronizzazione in ordine e ripubblicazione di tutto.
  5. Scenario C — “provo in produzione”: spiega perché pubblicare da VS Code verso la produzione non è il flusso previsto e perché lo stesso bug, in sandbox, si sarebbe visto cancellando e ricominciando.
  6. Verifica con un utente non-SUPER: il campo è visibile e compilabile come previsto, senza permessi amministrativi?

3 · Mini-test

Leggi ogni domanda, scegli la risposta, poi premi “Mostra risposta” per leggere la spiegazione. Le risposte sono nel testo per il controllo locale: l'obiettivo è attraversare lezione, esercizio e test, non barare sul punteggio.

Mini-test 4

  1. Perché non si modifica mai la Base Application?

    • A) Perché è vietato dal contratto di licenza in ogni caso
    • B) Perché a ogni aggiornamento le modifiche andrebbero rifatte con un merge, e in cloud non è il modello previsto
    • C) Perché la base non contiene codice modificabile
    • D) Perché le extension non possono aggiungere campi

    Risposta corretta: B. A è sbagliata: on-premises la procedura è documentata, ma fortemente sconsigliata. C è sbagliata: la base è codice AL, il punto è non toccarlo. D è sbagliata: aggiungere campi è proprio il lavoro delle table extension.

  2. Quale tipo di extension esiste solo in sandbox?

    • A) Global app
    • B) Per-tenant extension (PTE)
    • C) DEV extension
    • D) System Application

    Risposta corretta: C. A e B esistono anche in produzione. D è sbagliata: la System Application è uno strato di piattaforma, non un tipo di extension.

  3. Cosa fa lo step Sync?

    • A) Rende attiva l'extension
    • B) Aggiunge l'extension al database applicativo
    • C) Aggiorna lo schema del database del tenant con lo schema dell'extension
    • D) Compila il file .app

    Risposta corretta: C. A è Install, B è Publish, D è la compilazione che precede la pubblicazione: tre passi diversi, non sinonimi.

  4. Cosa succede se usi un oggetto della base senza dichiarare la dipendenza?

    • A) Il compilatore non risolve il riferimento: servono i simboli e la dipendenza dichiarata
    • B) Nulla, la dipendenza è automatica
    • C) L'extension viene installata ma il campo sparisce
    • D) La base viene modificata in automatico

    Risposta corretta: A. B è sbagliata: senza dipendenza dichiarata non c'è risoluzione. C e D descrivono comportamenti che non avvengono: il problema è in compilazione, prima dell'installazione.

Per completare servono: tutte le slide viste, tutte le spunte dell'esercizio, testo dell'esercizio compilato, spunta del mini-test.

Sezione 5 — Strumenti: VS Code, AL Language, app.json, launch.json, simboli, CodeCop

LEZIONE 5 · CONCETTO

VS Code + AL Language: l'ambiente di lavoro

VS Code è l'editor. AL Language lo fa “capire” AL.

L'estensione AL Language for Microsoft Dynamics 365 Business Central (Microsoft, ms-dynamics-smb.al) aggiunge supporto al linguaggio, IntelliSense, compilazione, pubblicazione e debug. Senza di essa, VS Code non capisce AL.

LEZIONE 5 · ESEMPIO

Il primo progetto nasce con AL: Go!

Ctrl+Shift+P → AL: Go! (oppure Alt+A, poi Alt+L).

Chiede cartella nuova o vuota, versione e piattaforma target (uguale alla sandbox) e endpoint di sviluppo. Genera tutta la struttura, inclusi app.json e launch.json: non crearli a mano da zero.

LEZIONE 5 · CONCETTO

app.json è il manifest dell'extension

Identità, versione, dipendenze, intervalli di ID.

È generato automaticamente all'avvio di un nuovo progetto AL, insieme a launch.json. Descrive l'extension e la versione minima degli oggetti della Base Application su cui è costruita.

LEZIONE 5 · ERRORE TIPICO

L'id è un GUID immutabile

Cambiarlo = i dati delle vecchie tabelle non vengono più usati.

L'id è generato automaticamente. Mai cambiarlo “per prova”: l'extension diventerebbe un'altra extension, e i dati resterebbero orfani della vecchia identità.

LEZIONE 5 · CONCETTO

Version: quattro parti, sempre in crescita

Formato 1.0.0.0 — ogni nuova pubblicazione ha una versione maggiore.

Name e publisher possono cambiare (rebranding, acquisizione), ma allora va incrementata version, e chi dipende deve riscaricare i simboli e ricompilare.

LEZIONE 5 · ERRORE TIPICO

Platform, application e runtime devono coincidere con la sandbox reale

BC 28 = runtime 17.0 · BC 27 = runtime 16.0

Si può pubblicare su un server con runtime uguale o superiore a quello dichiarato, non inferiore. Un app.json 21.0 / runtime 10.0 copiato da un vecchio tutorial è un errore, non un modello.

LEZIONE 5 · SCHEMA

ID ranges: la tua fascia è una sola

0–49.999 → Base Application, non usare.
50.000–99.999 → personalizzazioni e training, la tua fascia.
100.000–999.999 → localizzazioni Microsoft, non usare.

Per il Modulo 1, riserva un sotto-intervallo piccolo dentro 50.000–99.999 (esempio Learn: 50100–50149). Oggetti fuori intervallo o intervalli sovrapposti = errore di compilazione.

LEZIONE 5 · CONCETTO

Dipendenze: dichiarate, non implicite

Ogni dipendenza: id, name, publisher, version minima.

La versione in app.json è la versione minima: viene restituita l'ultima versione che la soddisfa. System e Base Application non si elencano più come dipendenze esplicite: sono catturate in application.

LEZIONE 5 · ERRORE TIPICO

launch.json: environmentName deve coincidere

Nome esatto della sandbox in Admin Center, non “Sandbox” generico.

Il file in .vscode/ descrive il server di lancio: environmentType Sandbox, startupObjectId 22 con startupObjectType Page (si apre Customer List). Se il nome non coincide, la pubblicazione punta all'ambiente sbagliato.

LEZIONE 5 · CONCETTO

Simboli: come VS Code “vede” la base

Ctrl+Shift+P → AL: Download Symbols → cartella .alpackages.

I simboli sono file .app di riferimento: descrivono schema e firme, non sono il sorgente eseguibile della base. Senza di essi, il codice che estende oggetti standard risulta sottolineato in rosso.

LEZIONE 5 · CONCETTO

CodeCop attivo: l'analisi che legge mentre scrivi

"al.enableCodeAnalysis": true — CodeCop + PerTenantExtensionCop + UICop.

È analisi statica a build time: segnala potenziali problemi con warning o errori mentre scrivi. Configurazione a livello workspace (.vscode/settings.json), non solo utente. Non sostituisce test funzionali né revisione logica.

LEZIONE 5 · ESEMPIO

Regola AA0001: uno spazio per lato

Sbagliato: result := 2+2; · Giusto: result := 2 + 2;

La regola richiede esattamente uno spazio per lato di un operatore binario. L'espressione errata risulta sottolineata; passando il cursore sopra si legge il warning; l'elenco completo è in View → Problems.

LEZIONE 5 · ESEMPIO

Pubblicare: Ctrl+F5, poi verifica

Ctrl+F5 = avvio senza debug · F5 = avvio con debug.

Entrambi, in AL, compilano e pubblicano. Nel Modulo 1 la strada primaria è Ctrl+F5 (Run Without Debugging). Verifica attesa: si apre il client web e compare la message box “Hello World”.

LEZIONE 5 · ERRORE TIPICO

Senza EXTEN. MGT. - ADMIN, la pubblicazione fallisce

Permission set assegnato con Company vuota, non circoscritto.

L'accesso a sviluppo e pubblicazione è controllato da EXTEN. MGT. - ADMIN. Se è circoscritto a una singola company, o manca, l'errore non è un problema di codice: è un problema di permessi.

LEZIONE 5 · ERRORE TIPICO

HTTP bloccato di default in sandbox

Le chiamate HttpClient non passano finché non le abiliti.

In sandbox serve l'impostazione “Allow HttpClient Requests”. Se una chiamata HTTP fallisce in sandbox, controlla prima questa impostazione, non il codice della chiamata.

LEZIONE 5 · RIEPILOGO

La catena che funziona

AL: Go! → simboli → CodeCop attivo → Ctrl+F5 → verifica.

Genera, non copiare. Simboli scaricati, environmentName esatto, permessi senza company, versione incrementata. Se “Hello World” non compare, non si passa oltre: si torna a simboli e launch.json.

2 · Esercizio guidato in sandbox

Si apre dopo aver visto tutte le slide della lezione. Lavoro solo in sandbox, mai in produzione.

Esercizio guidato 5 — La prima extension in sandbox cloud

Prerequisiti: tenant + sandbox cloud attiva, permessi EXTEN. MGT. - ADMIN senza company. Solo sandbox, mai produzione.

  1. Installa VS Code e l'estensione AL Language (View → Extensions, Ctrl+Shift+X, cerca “AL Language”, Install). Resta sulla release stabile, non sulla pre-release.
  2. Command Palette (Ctrl+Shift+P) → AL: Go! (oppure Alt+A, poi Alt+L). Scegli una cartella nuova o vuota, piattaforma target uguale alla versione della sandbox, endpoint “Microsoft cloud sandbox”.
  3. Verifica che VS Code abbia generato app.json, launch.json e il file di esempio. Mostra quello reale generato: non copiarlo da un tutorial.
  4. Command Palette → AL: Download Symbols. Se richieste, fornisci le credenziali organizzative. Controlla: cartella .alpackages presente, file di esempio non in rosso, “Customer List” non sottolineato in rosso.
  5. In app.json imposta name e publisher dell'esercizio (un publisher sensato, non da cambiare a cuor leggero). In .vscode/launch.json verifica: environmentType Sandbox, environmentName uguale al nome esatto della sandbox, startupObjectId 22, startupObjectType Page.
  6. Attiva CodeCop: in .vscode/settings.json imposta "al.enableCodeAnalysis": true e analyzer CodeCop + PerTenantExtensionCop + UICop. Non attivare AppSourceCop insieme a PerTenantExtensionCop.
  7. Pubblica con Ctrl+F5 (Run Without Debugging). Attendi compilazione e pubblicazione; dalla runtime 16.0 in poi puoi annullarla col pulsante Cancel nel dialogo in basso a destra.
  8. Verifica finale: si apre il client web e compare la message box “Hello World” all'apertura della pagina di avvio. Se non compare, torna ai controlli di simboli e launch.json: non passare oltre.

3 · Mini-test

Leggi ogni domanda, scegli la risposta, poi premi “Mostra risposta” per leggere la spiegazione. Le risposte sono nel testo per il controllo locale: l'obiettivo è attraversare lezione, esercizio e test, non barare sul punteggio.

Mini-test 5

  1. Perché non si copia un app.json da un vecchio tutorial?

    • A) Perché app.json non serve più
    • B) Perché può contenere dipendenze System/Base esplicite superate e valori datati, come 21.0 / runtime 10.0
    • C) Perché AL: Go! non genera più app.json
    • D) Perché l'id va sempre cambiato a mano

    Risposta corretta: B. A è sbagliata: app.json è il manifest, indispensabile. C è sbagliata: AL: Go! genera app.json e launch.json. D è sbagliata: l'id non va mai cambiato “per prova”.

  2. La pubblicazione fallisce e launch.json punta a una sandbox che si chiama diversamente. Qual è il controllo giusto?

    • A) Cambiare l'id in app.json
    • B) Verificare che environmentName coincida col nome esatto della sandbox in Admin Center
    • C) Disattivare CodeCop
    • D) Cancellare la cartella .alpackages a mano

    Risposta corretta: B. A è sbagliata: cambiare l'id orfana i dati. C è sbagliata: CodeCop non c'entra col puntamento all'ambiente. D è sbagliata: .alpackages è generata, non va modificata a mano; al massimo si rilancia AL: Download Symbols.

  3. Quale controllo affidabile conferma che i simboli sono a posto?

    • A) Contare che i file .app in .alpackages siano esattamente tre
    • B) Assenza di sottolineature rosse e di errori “symbol not found”
    • C) Che il file app.json sia stato copiato da un tutorial
    • D) Che VS Code non chieda credenziali

    Risposta corretta: B. A è sbagliata: il numero esatto di file dipende da versione e dipendenze, non è una regola fissa. C è sbagliata: copiare app.json è l'errore classico. D è sbagliata: le credenziali possono essere richieste legittimamente.

  4. Cosa significa un warning CodeCop AA0001 su “result := 2+2;”?

    • A) Che il calcolo è sbagliato
    • B) Che manca uno spazio per lato dell'operatore: corretto è “result := 2 + 2;”
    • C) Che il codice non verrà mai pubblicato
    • D) Che serve un permesso EXTEN. MGT. - ADMIN

    Risposta corretta: B. A è sbagliata: il valore è giusto, è lo stile a violare la regola. C è sbagliata: un warning non blocca di per sé la pubblicazione, va letto in Problems. D è sbagliata: i permessi riguardano la pubblicazione, non l'analisi statica.

Per completare servono: tutte le slide viste, tutte le spunte dell'esercizio, testo dell'esercizio compilato, spunta del mini-test.

Sezione 6 — Oggetti AL essenziali: come riconoscere a colpo d'occhio cosa si sta guardando

LEZIONE 6 · CONCETTO

La mappa in cinque oggetti

Tabella = dati. Pagina = vista. Codeunit = lavoro. Report = stampa. Evento = aggancio.

Se sai dire in una frase cosa fa l'oggetto che hai davanti, sai anche dove cercare un errore.

LEZIONE 6 · CONCETTO

Table: dove stanno i dati

Ogni transazione finisce in una tabella, da qualsiasi canale arrivi.

Una tabella AL non è solo struttura: è schema più comportamento minimo del dato — proprietà, campi, chiavi, trigger e procedure.

LEZIONE 6 · ESEMPIO

Table: un esempio concreto

Una tabella di indirizzi: campo, validazione, valore iniziale.

Campi come Address Text[50] e IsValidated Boolean con InitValue = false; un trigger OnValidate() che chiama la validazione quando il valore viene validato.

LEZIONE 6 · SCHEMA

Table: l'ordine conta

Proprietà → fields → keys → trigger e codice.

In VS Code lo snippet base è ttable. DataPerCompany = true significa: dati separati per azienda.

LEZIONE 6 · CONCETTO

Campi: TableRelation, da dove vengono i valori

TableRelation dice da quale tabella provengono i valori validi — e apre la lookup.

Esempio: un campo fornitore collegato a Vendor, con filtro sul saldo. Attenzione: una modifica via table extension è additiva e una prima relazione incondizionata prevale.

LEZIONE 6 · SCHEMA

FlowField: calcolato, non memorizzato

Il risultato non è nel database. È memorizzata la formula, non il valore.

FieldClass = FlowField con CalcFormula: Sum, Lookup, Count, Exist, Average, Min, Max.

LEZIONE 6 · ERRORE TIPICO

Trattare un FlowField come un campo normale

Se lo leggi senza calcolarlo, leggi un valore sbagliato.

Un FlowField va calcolato o aggiornato per essere letto correttamente. E ogni campo nuovo vuole la sua DataClassification: se manca, resta ToBeClassified.

LEZIONE 6 · CONCETTO

Page: cosa vede l'utente

Una pagina, una sola tabella sorgente.

Per mostrare dati di altre tabelle, la pagina usa parti (part) collegate a quelle tabelle. Mai due SourceTable nella stessa pagina.

LEZIONE 6 · CONFRONTO

Card, List, Document: non confonderle

Un record · una collezione · un documento con righe.
  • Card: un singolo record, con FastTab.
  • List: una collezione, con un solo repeater.
  • Document: come una Card, ma con le righe dentro.

LEZIONE 6 · ESEMPIO

Sales Order: testata e righe

La testata sta su Sales Header, le righe su Sales Line.

È una pagina Document: la testata in alto, le righe in una ListPart. La List collegata punta alla stessa tabella e rimanda alla Card con CardPageId.

LEZIONE 6 · SCHEMA

Page vs pageextension: estendi, non modificare

La base resta intatta. Il tuo codice vive accanto, nell'extension.

Una page extension aggiunge campi, azioni o parti a una pagina esistente. Eccezione da ricordare: una pagina API non si estende — per una nuova API si crea una nuova pagina API.

LEZIONE 6 · CONCETTO

Codeunit: chi fa il lavoro

Le pagine mostrano e raccolgono. Le codeunit eseguono.

Niente interfaccia propria. OnRun gira quando la codeunit viene eseguita direttamente; TableNo la collega a una tabella, il cui record è Rec.

LEZIONE 6 · CONCETTO

Codeunit: i SubType da distinguere

Normal · Test · Install · Upgrade: quattro lavori diversi.
  • Install: prima installazione, per azienda o per database.
  • Upgrade: migrazione dei dati quando la versione cambia.
  • Test: continua anche se un metodo fallisce.

Più codeunit Install? L'ordine di esecuzione non è garantito: devono funzionare da sole.

LEZIONE 6 · ERRORE TIPICO

Logica di business scritta nella pagina

Copiata in due pagine, va corretta in due pagine. E si rompe all'aggiornamento.

Regola: la pagina definisce layout e azioni; l'azione richiama una codeunit. Così la logica è riutilizzabile, testabile e meno fragile.

LEZIONE 6 · CONCETTO

Report: prima i dati, poi la stampa

Dataset → layout → request page. In quest'ordine.

Il dataset è fatto di data item (tabelle) e colonne. La request page chiede filtri e opzioni prima dell'esecuzione. Lo snippet base è treport.

LEZIONE 6 · CONCETTO

Enum: valori chiusi, non testo libero

Un enum è un elenco di valori ammessi, con un nome per ciascuno.

Esempio didattico: uno stato con valori come Aperto e Rilasciato. Se un valore non è nell'elenco, non è un valore valido: niente errori di battitura travestiti da dati.

LEZIONE 6 · CONCETTO

Eventi: perché esistono

Agganciarsi senza modificare l'originale: così l'aggiornamento costa meno.

La tua funzionalità resta separata dalla logica di business. Cambia l'originale con impatto minimo su di te, e viceversa.

LEZIONE 6 · SCHEMA

Eventi: publisher e subscriber

Il publisher dichiara. Il subscriber esegue. Nessuno conosce l'altro.
  • Il metodo publisher è solo la firma: da solo, non fa nulla.
  • L'evento va sollevato, altrimenti nessun subscriber risponde.
  • Più subscriber: uno alla volta, in nessun ordine garantito.
  • Senza subscriber, la riga che chiama il publisher viene ignorata.

LEZIONE 6 · SCHEMA

Table vs tableextension

Table definisce. Tableextension aggiunge — senza toccare la definizione.

Solo le tabelle con Extensible = true si possono estendere. Tabelle di sistema e virtuali no. Da BC 18, una table extension può contenere anche solo definizioni di chiavi.

LEZIONE 6 · SCHEMA

Chiavi: la prima è la primaria

La prima chiave definita è la chiave primaria. Le altre sono secondarie.

In una table extension, una chiave secondaria può usare campi dell'estensione oppure campi della tabella base — ma non mescolare campi base e campi dell'estensione nella stessa chiave.

LEZIONE 6 · CONFRONTO

Table vs tabledata: definizione contro permessi

table dice com'è fatto il dato. tabledata dice chi può leggerlo, inserirlo, modificarlo, cancellarlo.

Nei permission set i due piani sono separati: puoi avere il permesso sull'oggetto senza avere il permesso sui record — e allora l'utente vede l'errore, non i dati.

2 · Esercizio guidato in sandbox

Si apre dopo aver visto tutte le slide della lezione. Lavoro solo in sandbox, mai in produzione.

Esercizio guidato — Sezione 6 (solo in sandbox)
  1. Apri il progetto AL generato da AL: Go! e verifica in app.json che piattaforma, applicazione e runtime siano allineati alla tua sandbox (BC 28 / runtime 17.0, oppure BC 27 / runtime 16.0).
  2. Scarica i simboli e apri una tabella base: individua la sezione fields, la prima chiave e, se presente, un campo con TableRelation e uno con CalcFormula. Annota per ciascuno: dato memorizzato o calcolato?
  3. Apri Customer List, Customer Card e Sales Order e annota per ciascuna: PageType, SourceTable, presenza di repeater, group o part.
  4. Aggiungi un campo alla scheda cliente senza toccare la base: crea una table extension su Customer con un campo nuovo (con DataClassification impostata) e una page extension che lo mostra su Customer Card.
  5. Pubblica in sandbox e apri la scheda cliente: il campo nuovo deve apparire. Verifica che nessun oggetto base sia stato modificato: i tuoi file sono solo quelli dell'extension.
  6. Trova, dai simboli, quale codeunit richiama un'azione di una pagina base e scrivi in una frase cosa fa: se non sai dirlo, non hai ancora riconosciuto l'oggetto.

3 · Mini-test

Leggi ogni domanda, scegli la risposta, poi premi “Mostra risposta” per leggere la spiegazione. Le risposte sono nel testo per il controllo locale: l'obiettivo è attraversare lezione, esercizio e test, non barare sul punteggio.

Mini-test — Sezione 6

  1. 1. In una tabella AL, qual è la chiave primaria?

    1. La chiave con più campi.
    2. La prima chiave definita nella sezione keys.
    3. La chiave marcata Clustered = true.
    4. L'ultima chiave definita.

    Risposta corretta: B. La prima chiave definita è la primaria; le successive sono secondarie.

    Perché le altre sbagliano: A confonde dimensione e ruolo; C indica una proprietà di memorizzazione, non il ruolo di primaria; D inverte l'ordine.

  2. 2. Che cosa distingue un FlowField da un campo Normal?

    1. Il FlowField è memorizzato, il Normal è calcolato.
    2. Il FlowField è calcolato da una CalcFormula e non è memorizzato.
    3. Il FlowField può essere usato come chiave primaria.
    4. Nessuna differenza: sono sinonimi.

    Risposta corretta: B. Del FlowField è memorizzata la formula, non il risultato: va calcolato o aggiornato prima di leggerlo.

    Perché le altre sbagliano: A inverte i ruoli; C è falso proprio perché un valore calcolato non conta come campo dati vero (serve un campo chiave “fittizio” se la tabella ha solo FlowField); D ignora FieldClass.

  3. 3. Vuoi mostrare un campo nuovo su Customer Card senza modificare la Base Application. Cosa fai?

    1. Modifichi direttamente la pagina base.
    2. Crei una table extension con il campo e una page extension che lo mostra.
    3. Crei una nuova pagina API.
    4. Scrivi la logica nella pagina base e la copi nella Card.

    Risposta corretta: B. Estensione su estensione: la base resta intatta e l'aggiornamento resta gestibile.

    Perché le altre sbagliano: A viola la regola “mai modificare la base”; C serve per endpoint, non per schermate (e una pagina API non si estende); D mette logica dove non deve stare e la duplica.

  4. 4. Un publisher viene dichiarato ma mai sollevato, e due subscriber sono pronti. Cosa succede?

    1. I subscriber eseguono comunque, in ordine di dichiarazione.
    2. Non succede nulla: pubblicare da solo non fa eseguire alcun subscriber.
    3. Esegue solo il primo subscriber.
    4. Il publisher esegue il codice dei subscriber al suo posto.

    Risposta corretta: B. L'evento deve essere sollevato perché i subscriber rispondano; pubblicarlo lo rende solo disponibile.

    Perché le altre sbagliano: A e C presuppongono un ordine garantito, che non esiste; D confonde publisher (solo firma, nessun codice) con subscriber (la logica vera).

Per completare servono: tutte le slide viste, tutte le spunte dell'esercizio, testo dell'esercizio compilato, spunta del mini-test.

Sezione 7 — Sicurezza operativa: cosa rompe la produzione, versioni, dipendenze, deprecazione

LEZIONE 7 · CONCETTO

Rompere non è solo “dare errore”

Perdere dati, bloccare un upgrade, rallentare tutti: anche questo è rompere.

Un'extension è un pacchetto .app che vive accanto alla base, non dentro di essa. È questa separazione a rendere gli aggiornamenti gestibili.

LEZIONE 7 · SCHEMA

Schema: Synchronize, Recreate, ForceSync

Synchronize conserva i dati. Recreate li cancella. ForceSync forza — con cautela estrema.

La modalità è schemaUpdateMode in launch.json. In modalità sicura, le modifiche distruttive non passano: si progetta un percorso di upgrade, non si forza.

LEZIONE 7 · ERRORE TIPICO

Il Recreate ereditato dal launch.json di sviluppo

Pubblichi “solo una modifica” e le tabelle tornano vuote.

Disinstallare, da sola, non cancella i dati per impostazione predefinita — ma attivare esplicitamente Delete Extension Data sì, ed è irreversibile, anche per le app dipendenti.

LEZIONE 7 · CONCETTO

Identità dell'app: l'ID non si tocca

Cambi l'ID in app.json e i dati delle vecchie tabelle non vengono più usati.

name e publisher possono cambiare, ma solo con versione incrementata — e tutte le extension dipendenti devono riscaricare i simboli e ricompilare.

LEZIONE 7 · CONCETTO

Versioni: quattro numeri, un significato

X.Y.U.Z — e mai lo stesso numero per due build diverse nello stesso tenant.

La versione decide anche se un'installazione è un Install o un Upgrade. Allinea piattaforma, applicazione e runtime alla destinazione: BC 28 / runtime 17.0, oppure BC 27 / runtime 16.0.

LEZIONE 7 · SCHEMA

Dipendenze: la versione indicata è una minima

Viene restituita la versione più recente che soddisfa nome, publisher e minima dichiarata.

Troppo alta blocca i clienti su versioni vecchie; troppo bassa e usare API che ancora non esistevano produce errori a runtime. Dichiara la minima che contiene davvero ciò che usi.

LEZIONE 7 · ESEMPIO

Dipendenze: non sono transitive di default

Se A dipende da B e B dipende da C, A non vede i tipi di C.

Serve una dipendenza diretta in app.json — a meno che B non imposti "propagateDependencies": true, che vale per tutte le sue dipendenze dirette, senza esclusioni.

LEZIONE 7 · CONCETTO

Deprecazione: non cancellare, marca

Il codice obsoleto resta al suo posto, marcato. Cancellarlo rompe chi dipende da te.

Tre proprietà: ObsoleteState, ObsoleteReason (perché, e da cosa è sostituito), ObsoleteTag (versione in cui è stato marcato). Per metodi e variabili, l'attributo [Obsolete(...)].

LEZIONE 7 · SCHEMA

Deprecazione: almeno 12 mesi prima della rimozione

Un warning di obsolescenza è un debito con scadenza, non un errore immediato.

Tag '18.0': il codice è ancora presente in 19 e 20 e viene rimosso al più presto in 21. Microsoft non fissa una data precisa: almeno due versioni di margine.

LEZIONE 7 · CONCETTO

Permessi: il test che conta è da non-SUPER

“Sul mio utente funziona” non prova nulla, se il tuo utente è SUPER.

Il permission set dell'extension dichiara oggetti, tabledata (RIMD dove serve) ed Execute sulle codeunit. Poi si prova con un utente che ha solo quei permessi.

LEZIONE 7 · ERRORE TIPICO

La scorciatoia SUPER

Testare solo da SUPER nasconde esattamente gli errori che devi scoprire.

Altre due trappole: Access = Internal non è un confine di sicurezza, è progettazione di API; TestPermissions = Disabled fa girare i test come SUPER e maschera i problemi di permessi.

LEZIONE 7 · SCHEMA

Aggiornamenti: minor sposta, major avvisa

La breaking change non arriva mai di sorpresa in produzione: preavviso, tempo per correggere, versione pronta.

Minor mensile: l'app viene spostata, nessuna differenza attesa. Major: se la tua app si rompe durante l'upgrade del tenant, Microsoft esegue il rollback allo stato sano precedente.

LEZIONE 7 · CONCETTO

Lento è rotto, anche senza errori

Cicli senza filtri, FlowField costosi, transazioni lunghe: un incidente senza messaggio d'errore.

In SaaS non hai accesso diretto a SQL Server: la diagnosi passa da telemetria e profiler, non da query sul database. E in produzione non si debugga dal vivo.

LEZIONE 7 · RIEPILOGO

Prima di pubblicare: cinque controlli

ID immutabile · versione univoca · Synchronize · permessi provati da non-SUPER · warning letti.

CodeCop sempre attivo, warning soppressi solo se motivati uno a uno. In produzione si carica il .app da Extension Management o Admin Center, mai con F5 da VS Code.

2 · Esercizio guidato in sandbox

Si apre dopo aver visto tutte le slide della lezione. Lavoro solo in sandbox, mai in produzione.

Esercizio guidato — Sezione 7 (solo in sandbox, mai in produzione)
  1. Apri launch.json della tua extension di prova e leggi schemaUpdateMode: deve essere Synchronize. Se trovi Recreate, correggilo e annota perché in una sandbox usa-e-getta andava bene e altrove no.
  2. Apri app.json e verifica: id (GUID) originale e mai rigenerato, versione univoca e incrementata rispetto alla pubblicazione precedente, piattaforma, applicazione e runtime allineati alla sandbox.
  3. Controlla le dipendenze: ogni dipendenza verso un'altra extension dichiara id, publisher, nome e versione minima reale. Se usi un tipo di un'app da cui dipendi solo indirettamente, aggiungi la dipendenza diretta (o verifica propagateDependencies nell'app intermedia).
  4. Compila il progetto contro i simboli aggiornati di tutte le dipendenze, con CodeCop attivo. Leggi ogni warning di obsolescenza che riguarda API usate dalla tua extension e annotalo: cosa è obsoleto, da cosa è sostituito, da quando.
  5. Genera il permission set dal progetto e verifica che includa oggetti, tabledata e Execute sulle codeunit. Poi prova la funzionalità con un utente non-SUPER che ha solo quei permission set.
  6. Simula il rilascio senza toccare la produzione: prepara il .app, la versione precedente pronta per il rollback e una riga di motivazione per ogni warning soppresso, ogni dipendenza a minima “alta”, ogni eccezione alla regola.

3 · Mini-test

Leggi ogni domanda, scegli la risposta, poi premi “Mostra risposta” per leggere la spiegazione. Le risposte sono nel testo per il controllo locale: l'obiettivo è attraversare lezione, esercizio e test, non barare sul punteggio.

Mini-test — Sezione 7

  1. 1. Pubblichi in sviluppo con schemaUpdateMode: Recreate e lo lasci attivo. Cosa rischi quando la stessa configurazione finisce su dati veri?

    1. Nulla: Recreate conserva sempre i dati.
    2. La ricreazione di tabelle e table extension a ogni pubblicazione, con perdita dei dati di quelle tabelle.
    3. Solo un rallentamento, senza effetti sui dati.
    4. La cancellazione dell'intero tenant.

    Risposta corretta: B. Recreate ricrea le tabelle a ogni pubblicazione: i dati di quelle tabelle vanno persi.

    Perché le altre sbagliano: A descrive Synchronize, non Recreate; C sottovaluta un effetto distruttivo reale; D esagera oltre ciò che la documentazione dice (perdita limitata alle tabelle ricreate, non all'intero tenant).

  2. 2. In app.json dichiari una dipendenza alla versione 20.0. Quale versione verrà usata?

    1. Esattamente la 20.0, mai un'altra.
    2. La versione più recente che soddisfa nome, publisher e minima 20.0.
    3. Sempre l'ultima versione pubblicata, anche di un altro publisher.
    4. Solo la versione installata nel tuo ambiente di sviluppo.

    Risposta corretta: B. La versione indicata è una minima, non un'uguaglianza esatta.

    Perché le altre sbagliano: A confonde minima con esatta; C ignora che nome e publisher fanno parte del vincolo; D confonde simboli locali e risoluzione a runtime.

  3. 3. Un metodo che usi è marcato obsoleto con tag '18.0'. Quando può essere rimosso al più presto?

    1. Subito, alla versione 18.0.
    2. Alla versione 19.0.
    3. Alla versione 21.0, dopo almeno 12 mesi e almeno due versioni di margine.
    4. Mai: il codice obsoleto non viene mai rimosso.

    Risposta corretta: C. Il codice resta presente in 19 e 20 e viene rimosso al più presto in 21.

    Perché le altre sbagliano: A confonde marcatura e rimozione; B concede una sola versione di margine; D nega la rimozione, che invece arriva dopo il periodo minimo.

  4. 4. La tua extension “funziona in sandbox, esplode in produzione” per gli utenti normali. Qual è la causa più probabile, secondo questa sezione?

    1. Il codice è sbagliato, ma solo in produzione.
    2. Permessi mancanti: in sandbox eri SUPER e SUPER maschera gli errori di permesso.
    3. La versione di Business Central in produzione è sempre diversa.
    4. Gli eventi non scattano mai in produzione.

    Risposta corretta: B. Senza tabledata RIMD ed Execute dichiarati, gli utenti non-SUPER ottengono errori a runtime anche se “sul tuo utente funziona”.

    Perché le altre sbagliano: A non spiega la differenza tra ambienti; C non è una regola generale; D è falso in generale: gli eventi non scattano mentre un'extension è disinstallata, non “mai in produzione”.

Per completare servono: tutte le slide viste, tutte le spunte dell'esercizio, testo dell'esercizio compilato, spunta del mini-test.

Sezione 8 — Testing, debug e telemetria di base

LEZIONE 8 · CONCETTO

“Funziona da me” non basta

Un test prova la regola, non la tua postazione.

Se funziona solo sul tuo PC, con i tuoi dati e i tuoi permessi, non è provato. Il minimo del modulo: test, debug in sandbox, telemetria di base.

LEZIONE 8 · SCHEMA

Cos’è una test codeunit, e come gira

SubType = Test: OnRun → metodi → SUCCESS o FAILURE

Una codeunit con SubType = Test verifica la logica di business. Ogni metodo gira, per default, in una transazione separata; se uno fallisce, i successivi continuano comunque.

LEZIONE 8 · CONCETTO

Come si eseguono i test

Test Tool sempre. Test Explorer solo da BC 28.

Base comune: il Test Tool nel client. Da BC 28, in più, il Test Explorer in VS Code scopre ed esegue i test nel workspace. La test runner codeunit serve solo quando il flusso va orchestrato o automatizzato.

LEZIONE 8 · ESEMPIO

Il minimo sensato per un principiante

Percorso felice + percorso di errore, per ogni funzione nuova.
  • Valido → record creato con i valori attesi.
  • Invalido → errore atteso, non un crash generico.
  • Un test per ogni regola che, se sbagliata, crea dati contabili errati.
  • Handler appena il codice mostra un dialogo o una conferma.
  • Almeno un’esecuzione con permessi ristretti, non solo da SUPER.

Non “un test per ogni procedura”: un test per ogni regola che conta.

LEZIONE 8 · ERRORE TIPICO

Tre errori che invalidano il test

Test solo da SUPER = test che non prova niente.
  • TestPermissions = Disabled equivale a SUPER: l’utente reale potrebbe non poter usare la funzione.
  • Test senza handler su codice che mostra dialoghi: il test si blocca in attesa dell’utente.
  • Test in produzione, o appoggiati a dati demo che in un tenant pulito potrebbero mancare.

I test girano in sandbox, su dati di test isolati. Mai in produzione.

LEZIONE 8 · CONCETTO

Il debugger in sandbox: F5

F5 avvia il debug. F9 mette il breakpoint.

VS Code + estensione AL Language: F5 avvia, Ctrl+F5 avvia senza debug, Shift+F5 ferma. F10 passo sopra, F11 passo dentro, Shift+F11 passo fuori. Solo in sandbox, solo su extension: mai modificare la Base Application.

LEZIONE 8 · SCHEMA

Breakpoint: dove fermarsi, e perché

“Chi sta scrivendo in questa tabella?”
  • Breakpoint: l’esecuzione si ferma su un’istruzione, finché non la fai ripartire.
  • breakOnError = All (default): ferma anche sugli errori gestiti.
  • breakOnRecordWrite: ferma prima di Insert, Modify, Delete e simili.
  • Database statistics in VARIABLES: statement SQL, righe lette, lock, durata.

Se un’operazione è lenta, prima domanda: quante righe ha letto, e quanto è durato lo statement?

LEZIONE 8 · CONFRONTO

Debug classico F5 vs snapshot debugging

In sandbox fermi tutto. In produzione non puoi.
  • F5 in sandbox: sessione live, breakpoint che fermano l’esecuzione, ideale per imparare e riprodurre.
  • Snapshot debugging: registra lo stato e lo si esamina dopo, offline, in VS Code — senza fermare gli utenti.
  • Snapshot: serve il permission set D365 Snapshot Debug e simboli allineati tra tenant e server.
  • Mai debug live in produzione: una sessione che ferma gli utenti non è uno strumento, è un’interruzione.

Prima F5 in sandbox, poi snapshot. Mai il contrario.

LEZIONE 8 · CONCETTO

Snapshot debugging, in breve

Snappoint: registra, non ferma.

Gli snappoint sono breakpoint che non fermano l’esecuzione: registrano lo stato in quel punto. Le variabili si raccolgono solo su snappoint ed eccezioni AL. Il codice con snappoint deve essere già distribuito, altrimenti il debug non funziona.

LEZIONE 8 · CONCETTO

AL Profiler: solo un cenno

Dove va il tempo: codice AL o SQL?

Due modalità: Instrumentation registra ogni frame eseguito; Sampling cattura periodicamente lo stack attivo, con overhead generalmente minore. Serve a isolare pagine e processi lenti. Nel Modulo 1 va solo nominato, non imparato a fondo.

LEZIONE 8 · CONCETTO

Telemetria: cosa guardare, senza KQL

Attivala prima che il problema accada. Non è retroattiva.

Business Central emette telemetria in Azure Application Insights, per ambiente o per singola extension. Segnali utili: errori, long-running SQL, lock, errori di autorizzazione, lifecycle di extension e company, report, web service. La telemetria verbose, che mostra tutte le query di una sessione, va usata solo in una breve finestra di riproduzione: rallenta il sistema.

LEZIONE 8 · RIEPILOGO

Quando qualcosa non funziona, in ordine

Riproduci → leggi l’errore → debugger → profiler → snapshot/telemetria
  • 1. Riproducilo in sandbox, non in produzione.
  • 2. Leggi l’errore esatto: testo, pagina, utente, orario.
  • 3. Debugger in sandbox sul punto sospetto.
  • 4. Se è lentezza: profiler per “dove va il tempo”, telemetria per “succede anche ad altri? da quando?”.
  • 5. Se è in produzione e non riproducibile: snapshot debugging e telemetria.

Se non si riproduce in sandbox, manca un dato, un permesso o una dipendenza: anche questa è un’informazione.

2 · Esercizio guidato in sandbox

Si apre dopo aver visto tutte le slide della lezione. Lavoro solo in sandbox, mai in produzione.

Esercizio guidato — Sezione 8: breakpoint, SQL e un test minimo

Lavora solo in sandbox, solo su extension. app.json e launch.json vanno generati da AL:Go! per la tua sandbox reale, mai copiati da tutorial vecchi.

  1. Apri la tua extension in VS Code e scegli una regola di business semplice, ad esempio una validazione o un calcolo.
  2. Metti un breakpoint (F9) sull’istruzione sospetta e avvia con F5: verifica che il client sandbox si apra e che l’esecuzione si fermi sul breakpoint.
  3. Nel pannello VARIABLES annota le variabili visibili in quel punto e il nodo Database statistics: ultimo statement SQL, righe lette, lock.
  4. Attiva breakOnRecordWrite e modifica un record dalla funzione sotto test: annota su quale istruzione di scrittura l’esecuzione si ferma.
  5. Scrivi una test codeunit (SubType = Test) con due metodi: percorso felice (input valido → valori attesi) e percorso di errore (input invalido → errore atteso).
  6. Se il codice mostra un dialogo o una conferma, aggiungi un handler: senza handler il test si blocca in attesa dell’utente.
  7. Esegui i test dal Test Tool (o, da BC 28, dal Test Explorer in VS Code) e annota l’esito di ciascun metodo: SUCCESS o FAILURE.
  8. Riesegui almeno una volta con permessi ristretti (TestPermissions = Restrictive): il test che passa solo da SUPER non è superato.
  9. Rimuovi eventuali Message di debug dal codice: “debuggare con Message” lascia sporcizia in produzione.
  10. Compila la checklist qui sotto prima di considerare l’esercizio chiuso.

Checklist pre-pubblicazione — Sezione 8

3 · Mini-test

Leggi ogni domanda, scegli la risposta, poi premi “Mostra risposta” per leggere la spiegazione. Le risposte sono nel testo per il controllo locale: l'obiettivo è attraversare lezione, esercizio e test, non barare sul punteggio.

Mini-test — Sezione 8

1. In una test codeunit, se un metodo di test fallisce, che cosa succede ai metodi successivi?

  1. La codeunit si interrompe subito.
  2. I metodi successivi continuano comunque.
  3. Vengono saltati tutti i metodi con handler.
  4. Il test viene rieseguito automaticamente da SUPER.

Risposta corretta: B.

A è il comportamento di una codeunit normale, non di una test codeunit. C confonde gli handler (che simulano l’utente sui dialoghi) con l’esecuzione. D inventa un riesegui automatico che non esiste: l’esito globale diventa FAILURE e l’errore finisce nel log dei risultati.

2. Il tuo codice mostra una conferma all’utente e il test si blocca. Che cosa manca?

  1. Un breakpoint condizionale.
  2. Un handler che simuli la risposta dell’utente.
  3. Il Performance Toolkit.
  4. Un permesso D365 Snapshot Debug.

Risposta corretta: B.

A serve a fermarsi solo se una condizione è vera, non a rispondere a un dialogo. C è uno strumento separato per test di carico e performance, non per sbloccare un test funzionale. D serve per creare o scaricare snapshot in produzione, non per gestire dialoghi nei test.

3. Un problema si verifica in produzione ma non si riproduce in sandbox. Quale strumento è quello “sicuro” per la produzione?

  1. Una sessione di debug live che ferma gli utenti.
  2. Lo snapshot debugging, con permesso D365 Snapshot Debug e simboli allineati.
  3. Un Message lasciato nel codice.
  4. Un test eseguito direttamente in produzione.

Risposta corretta: B.

A è esplicitamente da evitare: ferma gli utenti. C è un errore tipico, non uno strumento di diagnosi in produzione. D non è un test ma un incidente: i test girano in sandbox e un test che scrive in tabelle reali di produzione danneggia dati veri.

4. Che cosa è vero sulla telemetria in Azure Application Insights?

  1. Va attivata prima che il problema accada: non è retroattiva.
  2. Registra ogni singola chiamata AL, sempre.
  3. La modalità verbose va tenuta sempre accesa.
  4. Sostituisce il debugger in sandbox.

Risposta corretta: A.

B è falso: non ogni chiamata AL viene loggata, altrimenti rallenterebbe il server. C è falso: la telemetria verbose rallenta il sistema e inietta molti dati, quindi va usata solo in una breve finestra di riproduzione. D confonde gli strumenti: la telemetria dice “succede anche ad altri? da quando?”, il debugger dice “che cosa fa il codice, riga per riga”.

Per completare servono: tutte le slide viste, tutte le spunte dell'esercizio, testo dell'esercizio compilato, spunta del mini-test.

Sezione 9 — Fonti, percorsi di studio e certificazioni: cosa studiare dopo il Modulo 1

LEZIONE 9 · CONCETTO

Il punto di partenza ufficiale

“Find development resources for building applications”

È la pagina-indice di Microsoft Learn per gli sviluppatori. Filtra così: prodotto = Business Central, ruolo = Developer, tipo = Learning path. Da lì, non da tutorial sparsi, scegli il percorso successivo.

LEZIONE 9 · CONCETTO

Primi due percorsi Learn

Prima estensione, poi fondamenta della personalizzazione.
  • 1. Get started with development: prima estensione completa, ambiente, eventi di base.
  • 2. Discover the foundation of customizing: tabelle, pagine, table extension e page extension, debug e deploy in sandbox.

Regola d’oro in entrambi: solo in sandbox, solo extension, mai modifiche al codice standard.

LEZIONE 9 · CONCETTO

Poi il linguaggio vero: AL

Learn the application foundation with AL

Per chi sa già programmare ma non conosce AL: variabili e tipi, istruzioni, procedure, codeunit, eventi e trigger, interfacce, manipolazione dati, multilanguage. È il percorso che trasforma “codice che compila” in “codice AL”.

LEZIONE 9 · CONCETTO

Dopo le basi AL: dati e standard

File, XMLport, query — e come si scrive “alla Business Central”.
  • Learn about the data management foundation: file, Temp Blob, streaming, XMLport, query.
  • Work with essential development standards: tipi di tabelle funzionali, modello di processo dei dati, master data, standard dei documenti.

Senza gli standard, il codice funziona ma non è manutenibile da un altro sviluppatore BC.

LEZIONE 9 · SCHEMA

Il percorso consigliato, in ordine

Prodotto → prima estensione → fondamenta → AL → dati → standard
  • 1. Orientarsi nel prodotto: navigazione, Role Center, aziende demo, documenti, posting.
  • 2. Get started with development.
  • 3. Discover the foundation of customizing.
  • 4. Application foundation with AL, modulo per modulo.
  • 5. Data management foundation, poi essential development standards.

Durante gli esercizi, tieni aperti i riferimenti permanenti: landing AL, Get started with AL, AL Language reference.

LEZIONE 9 · CONFRONTO

MB-820 vs MB-800: non sono intercambiabili

MB-820 è per lo sviluppatore. MB-800 per il consulente funzionale.
  • MB-820 Developer Associate: progettare, sviluppare, testare e mantenere soluzioni; AL, debug, deploy, test, telemetria, integrazioni, ALM e CI/CD.
  • MB-800 Functional Consultant Associate: configurare l’applicazione core, aziende, contabilità, vendite, acquisti, magazzino, cespiti.
  • In MB-800 non compaiono: scrivere codice AL, eventi, API, debug, deploy, test, CI/CD.

MB-800 non è un prerequisito di MB-820: nessuna pagina ufficiale lo indica come tale.

LEZIONE 9 · CONCETTO

Dentro MB-820: dov’è il cuore

Develop by using AL objects: 35–40% del peso.

Tabelle e pagine, enum, report, trigger, codeunit con eventi, interfacce, install e upgrade codeunit, permission set, query. Le altre aree — descrivere BC, installare e distribuire, AL, strumenti, integrazioni — pesano ciascuna il 10–20% circa. Usa la guida allo studio come mappa di ripasso, non come testo di studio.

LEZIONE 9 · ERRORE TIPICO

Cosa NON studiare subito

MB-800 come tappa obbligatoria: no.
  • MB-800 come obiettivo per uno sviluppatore: fuorviante, è configurazione, non programmazione.
  • Test AI e agente: documentati, ma fuori perimetro per un principiante.
  • Prezzi, durate e numero di domande d’esame da siti di provider: non verificati sulle pagine ufficiali, non citarli.

La cultura funzionale serve, ma come alfabetizzazione — non come certificazione-obiettivo.

LEZIONE 9 · CONCETTO

Come continuare con i Moduli 2–5

Dopo il Modulo 1: report, UI, integrazioni, Git e CI/CD.

In ordine, dopo le fondamenta: Build reports; Tailor roles e UI (Role Center, Assisted Setup, notifiche); Interface with Business Central (API, REST, Azure Functions); Git e CI/CD con AL-Go. Solo alla fine, la guida MB-820 come ripasso generale.

LEZIONE 9 · RIEPILOGO

Restare aggiornati, senza inseguire ogni novità

What’s New a ogni release wave. GA prima di usarlo.

Verifica sempre cosa è GA e cosa è solo preview prima di usarlo in un esercizio. Punteggio minimo d’esame verificato: 700. Le certificazioni role-based scadono annualmente e si rinnovano con un assessment online gratuito su Learn, non con un nuovo esame completo.

2 · Esercizio guidato in sandbox

Si apre dopo aver visto tutte le slide della lezione. Lavoro solo in sandbox, mai in produzione.

Esercizio guidato — Sezione 9: il tuo piano di studio e la checklist pre-pubblicazione

Non copiare un piano altrui: costruisci il tuo, in ordine, e tienilo come documento di lavoro per i Moduli 2–5.

  1. Apri la pagina Learn “Find development resources for building applications” e applica i filtri: prodotto Business Central, ruolo Developer, tipo Learning path.
  2. Scrivi il tuo percorso in ordine: orientamento nel prodotto, Get started with development, Discover the foundation of customizing, Application foundation with AL, Data management foundation, Essential development standards.
  3. Per ogni percorso, annota una riga: cosa sai già fare, cosa ti manca, quale esercizio del Modulo 1 lo copre e quale no.
  4. Segna come “dopo il Modulo 1, non dentro”: Build reports, Tailor roles e UI, Interface e integrazioni, Git e CI/CD con AL-Go.
  5. Scrivi in una riga la tua decisione sulle certificazioni: obiettivo MB-820 (sviluppatore); MB-800 solo come eventuale cultura funzionale facoltativa, mai come tappa obbligatoria.
  6. Annota le regole d’esame verificate che hai letto sulla guida ufficiale: punteggio minimo 700, scadenza annuale, rinnovo con assessment online su Learn. Non annotare prezzi, durate o numero di domande: non sono verificati sulle pagine ufficiali aperte.
  7. Imposta il tuo aggiornamento continuo: a ogni release wave, leggi What’s New e verifica cosa è GA e cosa è solo preview prima di usarlo.
  8. Chiudi con la checklist qui sotto: è la stessa disciplina della Sezione 8, applicata al tuo prossimo lavoro pubblicabile.

Checklist pre-pubblicazione — Sezione 9

3 · Mini-test

Leggi ogni domanda, scegli la risposta, poi premi “Mostra risposta” per leggere la spiegazione. Le risposte sono nel testo per il controllo locale: l'obiettivo è attraversare lezione, esercizio e test, non barare sul punteggio.

Mini-test — Sezione 9

1. Quale filtro usi su Microsoft Learn per trovare i percorsi per sviluppatori Business Central?

  1. Prodotto Business Central, ruolo Developer, tipo Learning path.
  2. Prodotto Dynamics 365, ruolo Functional Consultant, tipo Documentation.
  3. Qualsiasi percorso con “Business Central” nel titolo.
  4. Il primo risultato della ricerca, senza filtri.

Risposta corretta: A.

B porta ai contenuti per consulenti funzionali, non agli sviluppatori. C e D non filtrano per ruolo né per tipo: trovano anche documentazione e contenuti funzionali, e non garantiscono un percorso ordinato per sviluppatori.

2. Uno sviluppatore AL vuole una certificazione-obiettivo. Quale sceglie?

  1. MB-800, perché viene prima in ordine numerico.
  2. MB-820 Developer Associate: AL, debug, deploy, test, integrazioni, ALM e CI/CD.
  3. MB-800, perché “expand functionality by using extensions” significa scrivere extension.
  4. Nessuna: le certificazioni non hanno guide allo studio ufficiali.

Risposta corretta: B.

A confonde il numero con un prerequisito: nessuna pagina ufficiale indica MB-800 come prerequisito di MB-820. C fraintende la frase ufficiale: in MB-800 si usano extension, non si scrivono. D è falso: MB-820 ha una guida allo studio ufficiale con aree e pesi, da usare come mappa di ripasso.

3. Quale argomento NON metti nel percorso immediato di un programmatore AL principiante?

  1. Application foundation with AL, modulo per modulo.
  2. Data management foundation: file, XMLport, query.
  3. MB-800 come tappa obbligatoria prima di MB-820.
  4. Essential development standards.

Risposta corretta: C.

A, B e D fanno parte del percorso verificato dopo le fondamenta. C è l’errore tipico: l’idea “prima MB-800, poi MB-820 perché aiuta” circola solo su siti di provider e terze parti, non è una regola Microsoft, e il peso di MB-800 è configurazione gestionale, non programmazione.

4. Che cosa è verificato sulle pagine ufficiali riguardo al rinnovo delle certificazioni role-based?

  1. Scadono annualmente e si rinnovano con un assessment online gratuito su Learn.
  2. Si rinnovano solo ripetendo l’esame completo a pagamento.
  3. Non scadono mai.
  4. Il rinnovo richiede prima la certificazione MB-800.

Risposta corretta: A.

B contraddice le pagine ufficiali: il rinnovo non è un nuovo esame completo. C è falso: le certificazioni role-based scadono annualmente. D inventa un prerequisito: nessun prerequisito formale tra MB-800 e MB-820 risulta dalle pagine ufficiali aperte.

Per completare servono: tutte le slide viste, tutte le spunte dell'esercizio, testo dell'esercizio compilato, spunta del mini-test.

Consegna verificabile del Modulo 1

Questa è la prova finale in sandbox, da mostrare a chi controlla. Chi controlla non fa lezione e non spiega da capo: verifica solo che la consegna esista e funzioni.

Consegna verificabile del Modulo 1 (controllo in 10 minuti)

Principio: chi controlla non fa lezione, non corregge il percorso, non spiega da capo. Controlla solo che la consegna esista e funzioni. Se una voce manca o non funziona, lo studente torna alla sezione indicata, senza tutoraggio live.

Cosa deve consegnare lo studente (tutto in sandbox, mai in produzione):

  1. Sandbox attiva e identificata (1 minuto di controllo). Nome esatto dell'ambiente sandbox e tipo verificato in Admin Center (Sandbox, non Production). Prova: nome ambiente dichiarato e corrispondente a environmentName in launch.json. Bocciato se: ambiente di tipo Production, o nome in launch.json diverso dal nome reale.
  2. Mappa del codice esistente (2 minuti). Documento breve (una pagina) con: tenant → ambiente → aziende; dove sta la Base Application e dove sta la sua extension; tabella di riconoscimento degli oggetti (table, page, codeunit, report, permissionset e rispettive extension) con un esempio reale per tipo trovato in sandbox o nei simboli. Prova: lo studente indica, per un oggetto a scelta di chi controlla (es. Customer Card), se è base o extension e dove vive il codice che lo estende. Bocciato se: confonde tenant, ambiente e azienda, o indica un oggetto base come “modificabile direttamente”.
  3. Prima extension pubblicata in sandbox e funzionante (3 minuti). Progetto AL generato da AL: Go! (non copiato da un tutorial vecchio), con app.json coerente (id GUID originale, version incrementata rispetto a eventuali pubblicazioni precedenti, idRanges dentro 50.000–99.999, platform, application e runtime allineati alla sandbox, dipendenze System e Base tramite application e non come dipendenze esplicite obsolete). Simboli scaricati (.alpackages presente, nessun errore “symbol not found”). Pubblicazione da VS Code in sandbox (Ctrl+F5 / Run Without Debugging, o AL: Publish — una sola strada dichiarata) con verifica attesa: apertura della pagina 22 Customer List e message box “Hello World”. Prova: screenshot o breve video della message box, oppure dimostrazione di 1 minuto in sandbox. Bocciato se: app.json copiato con valori datati, simboli mancanti, pubblicazione in Production, message box assente.
  4. Estensione “senza rompere niente” funzionante (2 minuti). Table extension + page extension (es. campo aggiuntivo su Customer mostrato su Customer Card) oppure esempio publisher e subscriber dell'indirizzo (messaggio solo con “+”), pubblicata in sandbox. Prova: campo o evento visibile e funzionante in sandbox; nessun oggetto base modificato (lo studente indica quali file sono suoi e quali sono base). Bocciato se: la modifica è stata fatta toccando un oggetto base, o l'extension non compila o non si installa in sandbox.
  5. Permission set e prova non-SUPER (1 minuto). Permission set dell'extension presente (oggetti + tabledata + X dove serve), oppure dichiarazione esplicita di quali permessi mancano e perché. Prova: funzionalità provata (o dichiarata provabile) con un utente non-SUPER con i soli permission set previsti, oppure elenco dei permessi necessari per l'extension consegnata. Bocciato se: “funziona solo da SUPER” senza spiegazione, o nessun permission set per oggetti nuovi.
  6. Checklist “prima di pubblicare” compilata (1 minuto). La checklist della Sezione 7.3, parte A, compilata per la sua extension (spunte + note dove una voce non si applica), con particolare attenzione a: schemaUpdateMode = Synchronize (non Recreate), ID immutabile, version univoca, warning di obsolescenza letti, CodeCop attivo. Bocciato se: Recreate lasciato attivo senza motivazione, o warning soppressi in blocco senza motivazione.

Criterio di passaggio al Modulo 2: tutte le 6 voci presenti e funzionanti. Se una voce è bocciata, lo studente rifà solo quella sezione e riconsegna solo quella voce. Chi controlla non deve spiegare la sezione: rimanda al numero di sezione del modulo e alla pagina Learn indicata.

Cosa NON va controllato (fuori perimetro del Modulo 1): logica di business complessa, report con layout elaborati, integrazioni reali, CI/CD con AL-Go, test AI, telemetria KQL, container Docker (salvo che lo studente lo abbia scelto come approfondimento), certificazione MB-800 o MB-820 (obiettivo successivo, non di questo modulo).

Domande di fine modulo (36) e riepilogo

Rispondi per iscritto alle domande aperte e a scelta multipla, e fai in sandbox le domande pratiche, verificando il risultato (non basta scrivere la risposta). Non passare al Modulo 2 finché la consegna sopra non è completa.

Domande di fine modulo (36)

Istruzioni. Rispondi per iscritto alle domande aperte e a scelta multipla, e fai in sandbox le domande pratiche, verificando il risultato (non basta scrivere la risposta). Non passare al Modulo 2 finché la consegna verificabile sopra non è completa. Le domande sono divise per livello. Nessuna domanda richiede argomenti non trattati nel modulo, tranne le pratiche, che chiedono di applicare quanto studiato in sandbox.

Tipi: SC = scelta multipla; AP = aperta (risposta scritta breve); PR = pratica in sandbox (da verificare guardando il risultato, non la risposta scritta).

Livello base (12 domande)

  1. [SC] In Business Central moderno, come si personalizza il comportamento standard senza “rompere” gli aggiornamenti? A) Modificando direttamente gli oggetti della Base Application. B) Creando un'extension separata che estende gli oggetti esistenti. C) Modificando il database con SQL. D) Copiando gli oggetti base con un nuovo ID sotto 50.000.
  2. [SC] Quale ambiente si usa per sviluppare e provare una prima extension da VS Code? A) Produzione. B) Sandbox. C) Qualsiasi ambiente, purché si abbia SUPER. D) Solo un container on-premises.
  3. [SC] Quale intervallo di ID oggetto è riservato alle personalizzazioni e ai test? A) 0–49.999. B) 50.000–99.999. C) 100.000–999.999. D) 70.000.000–74.999.999.
  4. [AP] Spiega con parole tue la differenza tra tenant, ambiente e azienda (company) in Business Central.
  5. [SC] In una tabella AL, quale chiave è la chiave primaria? A) Quella chiamata PK. B) La prima chiave definita. C) Quella con Clustered = true. D) Quella con più campi.
  6. [SC] Cos'è un FlowField? A) Un campo memorizzato nel database. B) Un campo calcolato da una CalcFormula, non memorizzato. C) Un campo che contiene un filtro inserito dall'utente. D) Un campo chiave fittizio.
  7. [SC] Una pagina può essere collegata a quante tabelle sorgente? A) A tutte quelle che mostra. B) A una sola; gli altri dati arrivano tramite parti. C) A due: testata e righe. D) A nessuna: le pagine non hanno sorgente.
  8. [AP] Spiega la differenza tra licenza, permission set e profilo (ruolo) in Business Central.
  9. [SC] Nelle lettere di permesso RIMD, cosa significa la lettera X? A) Delete. B) Execute (esecuzione). C) Export. D) Exclude.
  10. [SC] Quale comando VS Code genera un nuovo progetto AL con app.json e launch.json? A) AL: Package. B) AL: Download Symbols. C) AL: Go!. D) AL: Clear credentials cache.
  11. [AP] Perché, in una sandbox cloud, non puoi “sistemare una riga direttamente nel database” come faresti on-premises?
  12. [SC] Cosa sono i simboli (symbols) in un progetto AL? A) Il codice sorgente della Base Application. B) File .app di riferimento in .alpackages che descrivono schema e firme degli oggetti esistenti. C) Le icone delle pagine. D) I file di traduzione .xlf.

Livello intermedio (12 domande)

  1. [SC] In app.json, cosa succede se cambi l'id (GUID) di un'extension dopo la prima pubblicazione? A) Nulla: l'ID è solo un'etichetta. B) I dati delle vecchie tabelle non vengono più usati. C) Viene rigenerato automaticamente. D) Cambia solo il nome visualizzato in Extension Management.
  2. [AP] Spiega la differenza tra Global app, Per-tenant extension (PTE) e DEV extension, indicando per ciascuna dove può esistere e cosa succede in upgrade della sandbox.
  3. [SC] In app.json, la versione indicata in una dipendenza in dependencies è: A) La versione esatta che verrà usata a runtime. B) La versione minima: verrà restituita l'ultima versione che soddisfa nome, publisher e versione minima. C) La versione massima consentita. D) Un'informazione puramente documentale, ignorata dal compilatore.
  4. [PR] In sandbox: crea una table extension che aggiunge un campo alla tabella Customer e una page extension che lo mostra sulla Customer Card. Verifica che la Customer Card base non sia stata modificata.
  5. [SC] Un metodo publisher di evento: A) Contiene la logica da eseguire quando l'evento scatta. B) Contiene solo la firma (più commenti): niente codice, ritorno, variabili o costanti di testo. C) Può contenere codice solo se è un evento trigger. D) Viene eseguito automaticamente all'installazione dell'extension.
  6. [AP] Spiega la differenza tra table e tabledata in un permission set, e perché confonderli non sblocca l'accesso ai dati.
  7. [SC] Quale schemaUpdateMode in launch.json conserva i dati e applica solo modifiche compatibili? A) Recreate. B) ForceSync. C) Synchronize. D) Nessuno: ogni pubblicazione ricrea le tabelle.
  8. [PR] In sandbox: pubblica l'esempio publisher e subscriber dell'indirizzo (Sezione 6.5) e verifica che il messaggio compaia solo quando l'indirizzo contiene “+”. Poi spiega perché la Customer Card base non è stata toccata.
  9. [SC] Quale affermazione sui subscriber è corretta? A) Vengono eseguiti in un ordine che lo sviluppatore può specificare. B) Il publisher conosce sempre i suoi subscriber. C) Vengono eseguiti uno alla volta in nessun ordine particolare, e l'ordine non può essere specificato. D) Se non ci sono subscriber, la chiamata al publisher genera un errore.
  10. [AP] Un utente con licenza Team Member e permission set SUPER ha le stesse funzionalità di un utente con licenza Essential e SUPER? Spiega perché sì o perché no.
  11. [SC] Per un'extension per singolo tenant (PTE), quali analyzer vanno attivati in VS Code? A) Solo AppSourceCop. B) CodeCop + PerTenantExtensionCop (+ UICop). C) Solo UICop. D) Nessuno: gli analyzer servono solo per AppSource.
  12. [AP] Spiega il percorso corretto di deprecazione in AL: cosa si fa quando un campo o un oggetto non serve più, e perché non va semplicemente cancellato. Cita ObsoleteState, ObsoleteReason e ObsoleteTag e la timeline minima di Microsoft.

Livello trabocchetto / pratico (12 domande)

  1. [PR] Trabocchetto sandbox: dopo l'upgrade della tua sandbox, la tua DEV extension “è sparita”, ma i dati ci sono ancora. Spiega cosa è successo secondo il comportamento documentato e cosa devi fare per rimetterla in funzione — e perché NON è un bug.
  2. [SC] Trabocchetto: in sandbox, una chiamata HTTP a un servizio esterno fallisce con “The request was blocked by the runtime to prevent accidental use of production services”. Qual è la causa più probabile? A) Il servizio esterno è giù. B) Le chiamate HTTP in uscita sono bloccate di default in sandbox e vanno approvate per app in Extension Management (Allow HttpClient Requests). C) Manca il permission set SUPER. D) Il firewall del PC blocca VS Code.
  3. [PR] Trabocchetto permessi: la tua extension “funziona in sandbox” ma in produzione l'utente reale riceve errori di permesso. Elenca le due cause più probabili secondo il modulo e come le verifichi (permission set generato dal progetto, test con utente non-SUPER, TestPermissions).
  4. [SC] Trabocchetto: hai pubblicato un'extension con schemaUpdateMode: Recreate ereditato da un launch.json di sviluppo. Cosa rischi alla prossima pubblicazione? A) Nulla: Recreate è il default sicuro. B) La perdita di tutti i dati delle tabelle e delle table extension ricreate. C) Solo un warning di CodeCop. D) La disinstallazione automatica delle app dipendenti.
  5. [AP] Trabocchetto eventi: pubblichi un evento ma “non succede niente”. Elenca le due spiegazioni possibili secondo il modello publisher e subscriber (evento mai sollevato; nessun subscriber) e come le distingui.
  6. [PR] Trabocchetto simboli: apri un progetto AL e “Customer List” è sottolineato in rosso, anche se il codice sembra corretto. Qual è la prima diagnosi da fare (simboli, launch.json, credenziali) e qual è il controllo affidabile che i simboli sono a posto? Spiega anche perché “devono essere 3 file in .alpackages” NON è un controllo affidabile.
  7. [SC] Trabocchetto versioni: copi da un tutorial un app.json con application: 21.0.0.0, runtime: 10.0 e dipendenze System e Base esplicite in dependencies per un corso su BC 27/28. Perché è sbagliato? (Indica almeno due motivi: esempio datato; dipendenze System e Base ora catturate da application, non elencate esplicitamente.)
  8. [AP] Trabocchetto IsHandled: un collega usa IsHandled come meccanismo ordinario per “personalizzare” Business Central. Perché Microsoft raccomanda di limitarlo al minimo indispensabile? (Un solo subscriber può gestire l'evento; gli altri devono uscire se già gestito; aumento dei percorsi di codice possibili.)
  9. [PR] Trabocchetto upgrade: il cliente chiede un campo “Codice fedeltà” sulla scheda cliente. Descrivi la soluzione corretta (table extension + page extension in PTE versionata) e cosa succede alla major successiva, contrapposta alla soluzione scorretta (modifica della base on-premises) e al suo costo a ogni wave.
  10. [SC] Trabocchetto certificazioni: un programmatore AL che vuole certificarsi come sviluppatore deve puntare a: A) MB-800, perché è la certificazione da sviluppatore. B) MB-820 (Developer Associate); MB-800 è Functional Consultant e copre configurazione contabile e operatività, non codice AL. C) Prima MB-800 obbligatoriamente, poi MB-820, perché è un prerequisito formale. D) Nessuna: Microsoft non ha certificazioni per Business Central.
  11. [AP] Trabocchetto produzione: perché “debuggare in produzione con una sessione live” è sbagliato, e qual è lo strumento “sicuro” per la produzione secondo il modulo (snapshot debugging: permesso richiesto, condizione sui simboli, snappoint)? Perché prima si deve comunque debuggare in sandbox con F5?
  12. [PR] Trabocchetto finale — prova di orientamento: ti danno un progetto AL sconosciuto. In 10 minuti, senza eseguirlo, devi dire: (a) se tocca la base o estende; (b) quali oggetti contiene e cosa fa ciascuno (riconoscimento dalla prima riga); (c) se i permessi sono sufficienti per un utente non-SUPER; (d) qual è il rischio maggiore alla prossima major. Scrivi la checklist che usi, nell'ordine in cui la applichi.

Fine del Modulo 1. Per passare al Modulo 2 devi aver completato la consegna verificabile sopra e aver risposto alle 36 domande. Non cercare le risposte in questa pagina: questa pagina insegna, non valuta con chiave allegata.