L’ambiente di sviluppo: VS Code e AL Language extension

L’ambiente di sviluppo ufficiale di Business Central è Visual Studio Code con la AL Language extension, che porta compilatore, IntelliSense, snippet, debugger e code analyzer. Un progetto AL è una cartella con app.json, i file .al e la cartella .alpackages, dove risiedono i symbol: i riferimenti compilati agli oggetti della base application e delle estensioni da cui si dipende. Senza symbol aggiornati il compilatore non “vede” nulla della base app, ed è il motivo per cui vanno riscaricati dopo ogni aggiornamento dell’ambiente.

Gli analyzer si abilitano nelle impostazioni del progetto e la scelta non è estetica: CodeCop copre le regole generali di scrittura, UICop l’interfaccia delle page, PerTenantExtensionCop i vincoli delle personalizzazioni per singolo cliente, AppSourceCop le regole di validazione del marketplace, incluso il rilevamento delle breaking change rispetto a una versione baseline e l’obbligo di affix (prefix o suffix) registrati sui nomi degli oggetti e dei campi introdotti.

app.json: identità, versione, ID range e dipendenze

app.json è il manifest dell’estensione: identità dell’app (id come GUID, name, publisher), version a quattro cifre, idRanges degli oggetti, versione minima della base application e runtime version, che determina quali costrutti del linguaggio AL sono utilizzabili. La proprietà target distingue un’app cloud (SaaS) da una on-premises, e resourceExposurePolicy governa se il sorgente è scaricabile e debuggabile da terzi.

La parte che l’esame ama di più sono le dependencies: ogni voce dichiara id, nome, publisher e versione dell’app da cui si dipende, e la versione indicata è quella minima richiesta. Una dipendenza dichiarata deve essere installata nell’ambiente di destinazione prima di poter pubblicare l’app dipendente. Sugli ID, l’intervallo 50000-99999 è riservato alle personalizzazioni per singolo tenant, mentre un’app destinata ad AppSource riceve da Microsoft un intervallo assegnato, da riportare in idRanges.

launch.json e la gestione del workspace

Mentre app.json descrive l’app, launch.json descrive dove la si pubblica: tipo di ambiente (Sandbox, Production, on-premises), nome dell’ambiente, server e server instance per gli scenari locali o in container, oggetto di avvio e schemaUpdateMode, che decide come il database viene allineato alle modifiche di schema. Le modalità che accettano modifiche distruttive hanno senso solo in sandbox, dove la perdita di dati è irrilevante.

Quando un’app dipende da un’altra sviluppata in parallelo, la strada corretta è un workspace multi-root: più cartelle di progetto in un unico workspace, ciascuna con il proprio app.json. Si compila e si pubblica seguendo l’ordine delle dipendenze, così che i symbol dell’app di base siano disponibili a quella dipendente: molto meglio che duplicare gli oggetti, perché mantiene una sola fonte del codice condiviso.

Distribuzione: Per-Tenant Extension o AppSource

La Per-Tenant Extension (PTE) è l’estensione su misura per un singolo cliente: usa gli ID liberi, non passa da alcuna validazione Microsoft e vive solo nel tenant di quel cliente, prima in sandbox per i test e poi in produzione tramite il Business Central admin center o dagli strumenti di sviluppo con i permessi adeguati.

L’app AppSource è invece un prodotto commerciale: sottomessa via Partner Center, supera una validazione tecnica e funzionale, ha target cloud, affix registrati e ID assegnati, ed è installabile da qualunque tenant. Il prezzo di questa portata è la disciplina: niente breaking change fra versioni pubblicate, test automatizzati e un ciclo di rilascio più lento. In entrambi i casi l’aggiornamento di un’app già installata si fa alzando la version e migrando i dati con il codice di upgrade, mai disinstallando e reinstallando in produzione.

Trappole tipiche d’esame

  • L’app A usa oggetti dell’app B, sviluppata contemporaneamente → workspace multi-root e dependency in app.json: si dichiara B nelle dependencies di A e si pubblica B per prima; copiare gli oggetti o unire i progetti è la risposta sbagliata.
  • Personalizzazione per un solo cliente, in fretta → Per-Tenant Extension: ID nell’intervallo 50000-99999, PerTenantExtensionCop, nessuna validazione Microsoft. AppSource serve solo se l’app va offerta a tenant qualsiasi.
  • App da vendere sul marketplace → AppSource: target cloud, AppSourceCop attivo, affix registrati, ID range assegnato da Microsoft e nessuna breaking change rispetto alla versione già pubblicata.
  • Cambiare ambiente di destinazione o abilitare il debug → launch.json, non app.json: l’ambiente (sandbox o produzione) e lo schemaUpdateMode stanno nella configurazione di lancio; app.json non contiene l’ambiente.
  • Modifica di schema distruttiva (campo rimosso o tipo cambiato) → solo in sandbox: in produzione la sincronizzazione forzata non è la via; servono una nuova version e il codice di upgrade per migrare i dati.
  • Il compilatore non riconosce oggetti standard o di un’altra app → symbol mancanti: vanno scaricati di nuovo dopo un aggiornamento dell’ambiente o dopo aver aggiunto una dependency, non è un problema di permission set.