L’architettura a livelli

Business Central è una pila di livelli sovrapposti, e sapere chi sta sopra a chi è il presupposto di tutto il resto del programma d’esame.

Alla base c’è la piattaforma: il runtime AL, il server e il database. Sopra la piattaforma Microsoft pubblica la System Application, un insieme di moduli che espongono funzionalità tecniche e non di business — crittografia e gestione delle chiavi, chiamate HTTP verso servizi esterni, informazioni sull’ambiente (per sapere a runtime se si è in produzione o in sandbox, online o on-premises), gestione di file e stream, telemetria. Sopra la System Application poggia la Base Application, che contiene la funzionalità gestionale vera e propria: contabilità, vendite, acquisti, magazzino, progetti. All’ultimo livello stanno le estensioni: quelle di Microsoft (localizzazioni nazionali e add-on), quelle degli ISV distribuite su AppSource e quelle scritte per il singolo cliente come Per-Tenant Extension.

Le dipendenze vanno in una sola direzione: la tua estensione dipende dalla Base Application e dalla System Application, mai il contrario. È la ragione per cui in app.json dichiari la versione di application e di platform su cui l’estensione è compilata, oltre alle dependencies verso altre app. Sbagliare quelle dichiarazioni è un errore di deploy, non di codice.

Estendere, mai modificare

Da questa gerarchia discende il principio che l’esame verifica in ogni dominio: il codice base non si modifica, si estende. Il motivo è economico prima che tecnico. Microsoft rilascia aggiornamenti maggiori due volte l’anno e correttivi più frequenti su Base Application e System Application; se un partner ne avesse alterato il codice, ogni aggiornamento diventerebbe un merge manuale e il servizio online non potrebbe aggiornarsi da solo.

Gli strumenti del modello sono quelli che ritrovi in tutta la parte AL objects: table extension e page extension per aggiungere campi e controlli a oggetti esistenti, enum con la relativa estensione per allargare gli elenchi di valori, interface per disaccoppiare le implementazioni. Il collante comportamentale sono gli eventi: il codice base espone event publisher e la tua estensione vi si aggancia con un event subscriber dentro una codeunit, invece di inserire righe nel flusso originale. Ogni oggetto che crei vive in un range di ID tuo — quello libero per le soluzioni per-tenant, oppure il range assegnato da Microsoft per le app pubblicate su AppSource.

Online contro on-premises

Nella versione online (SaaS) l’infrastruttura è di Microsoft: gli ambienti di produzione e di sandbox si gestiscono dall’admin center, gli aggiornamenti arrivano da soli. On-premises sei tu a possedere server, database e ciclo di aggiornamento.

Per chi scrive AL la differenza operativa è netta. In SaaS le estensioni girano in un runtime isolato: non esiste accesso al file system del server né al database. Qualunque logica che li presupponga va riprogettata — richieste HTTP verso servizi esterni, isolated storage per i segreti, stream con upload e download lato client per i file, API page e web service per i dati, job queue per i processi differiti. L’interoperabilità .NET resta prerogativa dell’on-premises e si dichiara nel target di app.json: un’estensione così marcata non pubblichi online.

Edizioni e criteri di scelta

Le edizioni sono due: Essentials, che copre finance, vendite, acquisti, magazzino, progetti e assistenza di base, e Premium, che aggiunge Service Management e Manufacturing. Esistono inoltre licenze Team Members per l’uso leggero in sola consultazione e approvazione. Il criterio è secco: se il cliente produce o gestisce interventi di assistenza in modo strutturato serve Premium, altrimenti Essentials basta.

La scelta fra online e on-premises, invece, dipende da vincoli non funzionali: requisiti normativi o di residenza dei dati, integrazioni legacy che vivono sulla stessa macchina, localizzazioni non disponibili nel servizio online. A parità di condizioni la risposta corretta all’esame è online, perché è l’unico scenario in cui il modello a estensioni dà il suo beneficio pieno.

Trappole tipiche d’esame

  • Serve un campo in più su una tabella standard → table extension: la risposta che propone di aprire l’oggetto base e aggiungere il campo è sempre sbagliata, anche on-premises dove tecnicamente sarebbe possibile.
  • Serve logica aggiuntiva alla registrazione di un documento → event subscriber: ci si aggancia a un event publisher esistente; la risposta “inserire la chiamata nella codeunit di posting” è il distrattore classico.
  • Codice che legge o scrive file in una cartella del server → riprogettazione su stream e servizi: in online il file system del server non esiste; nessuna impostazione dell’ambiente lo riabilita.
  • Estensione che usa .NET interop → resta on-premises: il target dichiarato in app.json ne impedisce la pubblicazione nel servizio online, e la soluzione è sostituire quella dipendenza con moduli della System Application o con chiamate HTTP.
  • Soluzione per un solo cliente contro soluzione da rivendere → PTE contro AppSource: la Per-Tenant Extension si pubblica sul singolo tenant, l’app AppSource passa dalla validazione Microsoft e usa un range di ID dedicato.
  • Il cliente ha bisogno di Manufacturing solo per un reparto → Premium per tutti: le edizioni non si mescolano nello stesso ambiente, quindi la risposta “Essentials per gli altri utenti” non regge.