Differenziare l'app di base e l'app di sistema
Gli sviluppatori AL possono estendere la funzionalità di Business Central in diversi modi. Possono estendere tabelle, enumerazioni, aree di applicazione, pagine, report, flussi di codice e addirittura il modello di sicurezza. Possono inoltre contribuire direttamente all'applicazione di base nei progetti open source per i moduli dell'applicazione di sistema.
L'applicazione Business Central è costituita da più livelli:
Applicazione di sistema: si tratta di un insieme di moduli open source che facilitano la creazione, la manutenzione e l'aggiornamento delle app locali e online. Questi moduli permettono di concentrarsi sulla logica di business e sulle esigenze degli utenti o dei clienti.
Applicazione di base: questa è la logica di business per la funzionalità in Business Central.
Panoramica dell'applicazione di sistema
L'applicazione di sistema contiene moduli che interagiscono con la piattaforma e con l'ecosistema online di Dynamics 365 Business Central per supportare la logica di business nell'applicazione di base. Se si stanno sviluppando estensioni o componenti aggiuntivi per Dynamics 365 Business Central, probabilmente sarà necessario usare uno o più oggetti nei moduli.
Per una panoramica dei moduli nell'applicazione di sistema, consultare Panoramica dei moduli nell'applicazione di sistema.
Riferimento al sistema e all'applicazione di base per Dynamics 365 Business Central
Nella sezione Applicazione di sistema è disponibile una panoramica di tutti gli oggetti che costituiscono il livello dell'applicazione di sistema in Business Central, inclusi gli oggetti obsoleti ordinati per tipo di oggetto. Nella sezione Applicazione di base è disponibile una panoramica di tutti gli oggetti che costituiscono il livello dell'applicazione di base in Business Central. Comprende inoltre una sezione di oggetti obsoleti, ordinati per tipologia di oggetto.
Per altre informazioni consultare Riferimento al sistema e all'applicazione di base per Dynamics 365 Business Central.
Architettura del modulo
Sebbene l'architettura interna dei vari moduli possa presentare delle differenze, esistono regole che garantiscono coerenza e affidabilità nell'architettura dei moduli dell'applicazione. Per ridurre l'associazione e aumentare la coerenza, ogni modulo è un'entità separata con una facciata accessibile al pubblico, mentre l'implementazione interna non è pubblica, come mostrato nell'immagine seguente.
I moduli sono progetti indipendenti e dispongono dei propri file app.json.
I moduli possono appartenere a un pacchetto specifico o a un livello funzionale. Un modulo diventa parte di un livello quando viene aggiunto alla struttura di cartelle del pacchetto del livello. Un modulo può appartenere a più pacchetti poiché è un pacchetto a sé stante e può essere raggruppato in pacchetti di stratificazione funzionale più grandi.
Le dipendenze verso altri moduli possono essere incluse solo nei moduli nello stesso livello funzionale o in livelli inferiori. Ad esempio, un modulo nell'applicazione principale può includere dipendenze solo ai moduli dell'applicazione principale o dell'applicazione di sistema, ma mai alle estensioni.
Ogni modulo deve inizialmente avere come riferimento l'ambiente più restrittivo, ovvero l'ambiente cloud. Se sono necessarie operazioni non sicure, queste dovrebbero risultare in un modulo dell'applicazione di sistema in cui le operazioni non sicure sono racchiuse in API sicure. A tale scopo, impostare Target su OnPrem. I moduli nei livelli superiori all'applicazione di sistema devono avere Target impostato su Cloud nel file app.json.
Possono essere accessibili solo le codeunit, le pagine e le tabelle della facciata richieste nell'API pubblica del modulo. I dettagli dell'implementazione interna devono essere contrassegnati come tali impostando il modificatore di accesso su Interno. Ad esempio, è possibile accedere alle entità all'interno del modulo ma non è possibile chiamare le entità dall'esterno del modulo.
Ogni modulo deve avere una facciata che rispetti le seguenti regole:
L'accesso deve essere pubblico. Deve essere impostato esplicitamente per chiarire che si tratta di una facciata o di una codeunit simile ad API che espone la funzionalità principale del modulo.
Tutti gli editori di integrazioni ed eventi aziendali devono trovarsi nella facciata come funzioni interne. Ciò impedisce loro di essere richiamati all'esterno del modulo.
Gli editori di eventi devono essere contrassegnati come interni. Le eccezioni devono essere documentate.
Tutti i metodi esterni devono essere inseriti nella facciata.
Le facciate non possono contenere logica o funzioni locali.
Poiché la facciata è la codeunit cui fanno riferimento gli altri moduli, deve avere un nome breve e significativo. Le codeunit di implementazione interna possono avere il suffisso Impl, ad esempio, perché non sono oggetto di riferimento all'esterno del modulo.
Le codeunit di implementazione contengono la logica di business. Le pagine e le tabelle possono contenere codice, ma solo quando ciò è assolutamente necessario.
L'implementazione interna di ogni modulo deve tenere presente l'estendibilità. Se un modulo non deve essere estensibile, la proprietà Extensibility su tabelle, pagine ed enumerazioni deve essere impostata su False per impedire che tali oggetti vengano estesi.
Di seguito sono elencate alcune opzioni per consultare la documentazione su come sviluppare i moduli:
Se si vuole fornire codice all'applicazione di sistema open source Business Central, è necessario determinare il tipo di contributo:
Piccole correzioni di bug, miglioramenti del prodotto o utilità per il cliente
Nuove funzionalità o modifiche più ampie alla piattaforma applicativa esistente
Per altre informazioni sui contributi, consultare Contributi all'applicazione di sistema open source Business Central.
Per saperne di più sull'applicazione di sistema, sull'architettura del modulo e su come modificare o creare nuovi moduli, andare ad Architettura del modulo.