Benvenuti a un altro episodio di Microsoft Knowledge Nuggets. Sono il vostro presentatore, Miro Peters. Dunque, ecco lo scenario. State lavorando in Business Central e vi serve una piccola modifica. Magari un campo extra su una scheda cliente, un diverso passaggio di approvazione, o una regola che controlli un ordine prima che venga registrato. Poi qualcuno menziona estensioni AL, tabelle, pagine, code unit e all'improvviso quella piccola richiesta sembra una lingua completamente nuova. È una lingua, certo, ma non deve per forza sembrare misteriosa. Immaginate Business Central come un edificio per uffici. AL fornisce agli sviluppatori le istruzioni per aggiungere una stanza, un modulo o una nuova regola senza dover demolire pareti dell'edificio stesso. Questa è la perla di conoscenza di oggi. Alla fine di questo episodio saprete cosa significa sviluppo AL perché esistono le estensioni e come il lavoro personalizzato si integra in Business Central. Perché le aziende personalizzano Business Central? Business Central gestisce già molte attività quotidiane, finanza, clienti, ordini di vendita, fatture di magazzino, tutto in un sistema connesso invece di una pila di fogli di calcolo e strumenti separati. Per molte aziende quella configurazione standard copre la maggior parte del lavoro. Ma ecco il punto. Non esistono due aziende che lavorano allo stesso modo.

Prendete un distributore alimentare che necessita dei dettagli sui lotti con un'altra azienda anusa ma. Un'azienda di servizi che richiede uno speciale processo di approvazione prima della fatturazione. Un rivenditore che desidera livelli di premio per gli sconti. E qualcun altro che ha bisogno di un modulo con i propri campi personalizzati e regole interne. L'azienda non cambierà il proprio modo di operare per un solo campo mancato. E non volete nemmeno che ogni piccola richiesta si trasformi in una modifica rischiosa per l'intero sistema. In passato era un problema più grande. Nei sistemi più vecchi, gli sviluppatori aprivano e lo modificavano direttamente. Funzionava finché non arrivava il successivo aggiornamento. Poi l'azienda si ritrovava con la nuova versione di Microsoft da una parte e le proprie modifiche dall'altra e qualcuno doveva riconciliare tutto prima di poter procedere con l'aggiornamento.

Immaginate un ufficio dove ogni inquilino fa passare nuovi cavi attraverso le pareti senza un piano. Funziona per un po' ma quando l'edificio necessita di riparazioni nessuno sa chi appartenga a quale cavo. Business Central intraprende una strada di. Invece di riscrivere l'applicazione standard, gli sviluppatori creano un componente aggiuntivo separato che si collega ad essa mantenendo la parte standard al suo posto mentre le modifiche dell'azienda siedono accanto e lavorano attraverso punti supportati nel sistema. Quella separazione è importante quando arrivano gli aggiornamenti perché Microsoft aggiorna la sua parte dell'edificio mentre il lavoro personalizzato rimane nel suo spazio. Ci sono ancora test e correzioni, dopo tutto si tratta di modifiche software ma non ci si aspetta che lo sviluppatore copie e rielabori ogni cambiamento all'interno del codice originale di Microsoft. Allora cosa personalizza effettivamente un'azienda? Le personalizzazioni aggiungono dati. Il sistema standard non archivia informazioni come istruzioni di consegna, un punteggio di rischio interno, un livello di abbonamento o un collegamento a un sistema esterno e aggiungono schermate che guidano il personale attraverso un'attività nell'ordine corretto. Inoltre applicano regole come il blocco di un ordine quando manca un documento richiesto. Il lavoro personalizzato aiuta anche a evitare passaggi manuali. Immagina il personale che copia dati dei clienti da Business Central in un altro strumento ogni venerdì controllando le condizioni a mano e poi inviando un report a un manager. Una modifica ben progettata mantiene tale informazione in Business Central, applica la regola in modo coerente, fornisce al personale un pulsante e una pagina adatta al loro lavoro quotidiano. Sfatiamo un mito, non vuoi personalizzare tutto. Business Central Standard ha già molti processi integrati. Modificare qualcosa solo perché sembra diverso da un vecchio sistema a creare lavoro extra in seguito. Quindi un buon lavoro personalizzato inizia con una chiara motivazione. Quali problemi stanno affrontando le persone? Cosa dovrebbe accadere invece? Il prodotto standard può già farlo? Quando il prodotto standard non soddisfa tale esigenza entra in gioco AL. AL si concentra su Business Central leggendo, aggiungendo e modificando record a livello di database, controllando al contempo cosa accade su pagina e report ad altre parti d'applicazione. Inoltre calcola valori, sposta dati e mostra messaggi quando le regole falliscono durante i processi. È molto lavoro per un solo linguaggio, ma AL non è uno strumento generale per ogni tipo di software e non lo sceglieresti per creare un sito di shopping pubblico, un gioco per dispositivi mobili o un'app desktop autonoma. AL esiste per un unico scopo mirato, plasmare i dati e il comportamento all'interno di Business Central affinché il sistema rispecchi il modo in cui opera un'azienda. Ed è esattamente ciò che vedremo in seguito. AL ed estensioni, il modello di componenti aggiuntivi sicuri. AL sta per Application Language. È il linguaggio di programmazione di Microsoft per Business Central e offre agli sviluppatori un modo strutturato per creare nuove funzioni aziendali o modificare il comportamento delle parti esistenti del sistema. Ma la parola estensione è importante tanto quanto AL. Un'estensione è un'app separata che Business Central può installare. Contiene il lavoro personalizzato dell'azienda, mentre l'applicazione Business Central Standard rimane invariata. Pensala meno come la riscrittura di un manuale, più come l'aggiunta di pagine approvate adesso. O pagine che seguono le regole originali senza cancellarle. Potrebbe sembrare un dettaglio tecnico, ma cambia il modo in cui il lavoro personalizzato si evolve nel tempo. Magina che un'azienda abbia bisogno di un nuovo ufficio per un team speciale. Il vecchio approccio significava abbattere una parete dell'edificio principale e modificare la struttura stessa. Potrebbe risolvere il problema oggi, ma le riparazioni future diventano un incubo perché l'edificio originale non corrisponde più ai suoi progetti.

Un'estensione funziona diversamente. L'edificio ha già porte, prese elettriche e regole per aggiungere spazio. Si costruisce la nuova stanza attraverso quei collegamenti approvati. Stanza appartiene all'azienda, ma l'edificio principale può ancora ricevere manutenzione senza demolire ogni parete personalizzata. È esattamente così che funziona di Business Central. L'applicazione di base contiene il lavoro standard fornito da Microsoft. Un'estensione può aggiungere i propri campi, schermate, pulsanti, regole, report e persino collegamenti ad altri sistemi. Può reagire quando si verificano determinate azioni aziendali, ma lo fa attraverso modi supportati di connettersi all'applicazione standard. Quindi i confini sono integrati. È un'ottima cosa. Senza confini, una piccola richiesta personalizzata può raggiungere aree in cui non dovrebbe entrare. Con le estensioni, lo sviluppatore lavora con tipi di oggetti chiari e punti di connessione definiti, che rendono il codice più facile da capire quando qualcun altro deve leggerlo in seguito. Questo approccio si adatta perfettamente anche alla versione Cloud di Business Central.

Microsoft aggiorna il servizio regolarmente. Un'azienda deve comunque testare la propria estensione dopo le modifiche, specialmente se dipende da parti del prodotto che sono cambiate. Il software non elimina mai la necessità di manutenzione, ma mantenere il codice personalizzato separato riduce la possibilità che ogni aggiornamento si trasformi in una ricostruzione completa delle vecchie modifiche. Potresti sentir parlare di Cisbaro AL quando si menzionano i vecchi sistemi Dynamics Nav. Cilera AL proveniva da un modello di sviluppo precedente in cui gli sviluppatori modificavano spesso direttamente gli oggetti di applicazione originale. Molte aziende hanno utilizzato sistemi di successo in quel modo per anni, ma il lavoro personalizzato era molto più strettamente legato al codice standard e gli aggiornamenti richiedevano molto lavoro di confronto e riparazione. AL ha spostato Business Central verso uno sviluppo basato su. Ciò non significa che ogni estensione sia grande o complicata. Un'estensione potrebbe semplicemente aggiungere un campo o un record cliente e mostrarlo in uno schermato familiare.

Un'altra potrebbe contenere una soluzione completa per un particolare tipo di attività con i propri record, processi, pagine, report. Entrambe seguono lo stesso concetto di base. L'app personalizzata vive accanto a Business Central invece di nascondere una sua riscrittura. Puoi anche installare più di un'estensione. Un'azienda potrebbe utilizzare un'estensione di un partner software per le paghe, un'altra per le spedizioni e una piccola estensione interna per regole che interessano solo quell'azienda. Business Central li unisce nello stesso sistema operativo a patto che seguono le regole della piattaforma e non siano in conflitto. Quindi AL non è solo un modo per scrivere codice. È il linguaggio che gli sviluppatori usano per creare queste app aggiuntive e le estensioni sono il contenitore che trasporta tali modifiche in Business Central. Questo modello consente a un'azienda di personalizzare il sistema mantenendo il prodotto standard e conoscibile e più facile da gestire. Ora apriamo una di queste estensioni e osserviamo i blocchi costitutivi al suo interno. Principali blocchi costitutivi AL all'interno di un'estensione AL. Gli sviluppatori lavorano con gli oggetti. Un oggetto è una parte denominata dell'app con un compito preciso come archiviare informazioni, mostrare una schermata, eseguire una regola o produrre un documento. Una volta visti questi compiti separatamente all'inizio sembrare molto meno un muro di codice. Iniziamo dal luogo in cui risiedono le informazioni aziendali. Le tabelle memorizzano i dati in Business Central. Pensa a una tabella come a uno schedario digitale per un tipo di record. Uno schedario potrebbe contenere clienti, un altro articoli, un altro ancora ordini di vendita. Ogni record è un file all'interno di quello schedario. Una tabella clienti contiene un record per ogni cliente. Una tabella articoli contiene un record per ogni prodotto.

Se la tua azienda necessita di informazioni che il Business Central Standard non archivia, un'estensione può creare la propria tabella, magari per livelli premi o ispezioni di attrezzature o approvazioni di progetti. I campi sono gli spazi etichettati all'interno di ogni record. Un record cliente può includere un nome, un indirizzo, un termine di pagamento e un numero di telefono perché la tabella clienti contiene campi per quei dettagli. Campi possono contenere testo, date, importi, risposte sì o no o una scelta da un elenco fisso. Un campo può anche puntare a un altro record. Ad esempio, un cliente potrebbe contenere un campo ID premio. Invece di digitare un testo casuale, il personale seleziona un livello premio da una tabella premi separata. Quel collegamento mantiene i dati puliti perché tutti scelgono dallo stesso elenco noto, non quelle tabelle con i fatti. Ma come fanno le persone a vedere lavorare con quei fatti? Pagine. Una pagina schermata che apre in Business Central. La scheda cliente è una pagina. Un elenco di ordini di vendita è una pagina. Una pagina controlla ciò che gli utenti possono visualizzare, inserire, cercare su cui possono agire. Pagine diverse si adattano a compiti diversi. Una pagina a scheda si concentra su un record alla volta come un cliente o un articolo. Una pagina l'elenco mostra molti record in righe, il che funziona bene quando devi scansionare, filtrare o trovare qualcosa rapidamente. Una pagina a foglio di lavoro supporta il lavoro in cui le persone inseriscono o elaborano diverse righe di informazioni insieme. La tabella memorizza le informazioni. La pagina le mette di fronte all'utente. Questa separazione è utile perché puoi cambiare la schermata senza modificare dove risiedono i dati o riutilizzare la stessa tabella su più pagine quando diversi necessitano di viste diverse dagli stessi record. E se i dati appartenessero già a un record standard di Business Central? Di solito non si crea una tabella clienti sostitutiva solo perché serve un campo in più. Si utilizzano estensioni tabelle. Un'estensione di tabella aggiunge il tuo campo alla tabella clienti esistente. Il record cliente standard rimane al suo posto mentre la tua estensione aggiunge i dettagli specifici dell'azienda accanto ai campi standard.

Potrebbe trattarsi di un ID premio, una nota di consegna, un account manager o un campo che si collega a un'altra parte dell'azienda. Tuttavia aggiungere il campo alla tabella non inserisce automaticamente sullo schermo. Per questo c'è un'estensione di pagina. Un'estensione di pagina aggiunge un campo, un gruppo, un'azione e una pagina esistente. Se l'azienda ha bisogno che il personale scelga un livello premio durante la visualizzazione di un cliente, l'estensione di pagina può inserire il campo ID premio nella scheda cliente proprio dove lavorano gli operatori. Questo mantiene l'esperienza familiare. Invece di inviare gli utenti a una schermata personalizzata separata per un semplice dettaglio, l'estensione aggiunge dettagli alla pagina che già conoscono. Un'estensione di pagina può anche aggiungere un'azione, un pulsante o un comando di menu che avvia un'attività. Per esempio, una scheda cliente potrebbe includere un'azione per i premi che apre l'elenco dei premi. Dietro lo schermo serve una sede per le regole aziendali. Questa sede è spesso una code unit. Una code unit contiene procedure AL, ovvero porzioni di codice nominate che svolgono un compito specifico.

Pensala come al team di back office che gestisce un'attività quando una pagina, un report o un altro processo richiede aiuto. Supponiamo che il livello premio determini lo sconto applicato a un cliente. Il calcolo dello sconto appartiene a una code unit, non alla pagina della scheda cliente stessa. In questo modo un processo di vendita, un report o una pagina futura possono usare la stessa regola senza copiarla in più punti. Una regola ha un unico posto in cui mantenerla. Business Central include anche altri tipi di oggetti per lavori diversi. I report raccolgono dati e li presentano in un documento o layout come una fattura o un resoconto di vendita. Le query pongono domande mirate sui dati, ad esempio quali clienti hanno ordinato un determinato articolo in un certo periodo. Ad esempio, gli XML port aiutano a importare o esportare dati in un formato strutturato spesso quando un altro sistema deve scambiare informazioni con Business Central. Mettendo insieme questi elementi puoi immaginare una piccola estensione per i premi ai clienti. Una tabella premi memorizza ogni livello e la relativa percentuale di sconto. Le pagine premi consentono al personale di gestire tali livelli. Un'estensione di tabella clienti aggiunge un ID premio a ogni cliente mentre un'estensione di pagina scheda cliente lo visualizza. Un'azione di pagina apre l'elenco dei premi e la code unit calcola la regola di sconto. Ogni oggetto gestisce una parte del lavoro. Questo rende l'estensione più facile da leggere, testare e modificare quando la regola aziendale cambia dopo sei mesi. Ma una regola aziendale spesso deve essere eseguita esattamente al momento giusto, come quando qualcuno registra un ordine. È qui che entrano in gioco trigger eventi. Eventi, trigger e regole aziendali. Quindi aggiunto un campo premio cliente. Beh, ecco la vera domanda. Quando dovrebbe Business Central utilizzare effettivamente quel campo? Immagina di stare per registrare un ordine di vene. Prima che il sistema crei le voci finali vuoi un controllo aggiuntivo. Forse il cliente necessita di un livello di premio approvato prima che lo sconto si apri. O forse un documento di consegna richiesto deve esistere prima che l'ordine possa procedere. Vuoi quel controllo al momento giusto, ma non vuoi copiare l'intero processo di registrazione vendite nella tua estensione solo per aggiungere una regola. Quel processo gestisce già molto dietro le quinte. Se lo copi, la tua estensione dovrà mantenere tutti i futuri cambiamenti. Non è l'ideale. Quindi AL offre agli sviluppatori alcuni modi per eseguire il codice. La scelta dipende da cosa deve accadere. Innanzitutto i trigger. Un trigger è un punto denominato all'interno di un oggetto AL dove il codice può essere eseguito. Quando qualcuno cambia un valore in un campo di tabella, il trigger avvia il codice. Quando una pagina si apre o si chiude, il trigger avvia il codice. Report, query, XML, port, tabelle, estensioni, oggetti O. Tutti hanno questi punti in cui uno sviluppatore può aggiungere regole. Prendi il campo ID premio su un cliente. Quando un utente sceglie un livello di premio può essere eseguito un trigger di convalida. Il codice verifica il cliente bloccato.

Il livello di premio esiste? Un altro campo deve essere aggiornato? Controllo avviene proprio quando il valore cambia. Non più tardi quando qualcuno scopre un errore. I trigger funzionano bene quando la regola appartiene strettamente a quello oggetto. Ma Business Central utilizza anche gli eventi. Un evento è come un avviso. Una parte dell'applicazione lo invia quando accade qualcosa. Potrebbe annunciare che un record sta per essere inserito, che un documento sta per essere registrato o che un processo è terminato. La tua estensione può mettersi in ascolto di quell'avviso. Il codice che ascolta è chiamato sottoscrittore di eventi. Attende uno specifico evento denominato. Quando Business Central solleva quell'evento, il sottoscrittore esegue la propria procedura. Il processo standard rimane al comando. Ad esempio, quando Business Central inizia a registrare un ordine di vendita, solleva un evento prima di continuare. La tua estensione Rewards riceve tale notifica. Controlla l'ID premio del cliente, la regola di sconto. Quindi consente al processo di continuare o lo interrompe con un messaggio chiaro. Il processo di registrazione standard appartiene ancora a Business Central. La tua estensione aggiunge semplicemente la sua regola specifica aziendale in quel punto di connessione.

Sentirai spesso nomi di eventi come on before o on after. On before significa che il tuo codice viene eseguito prima che un'azione termine. È perfetto per un controllo che può impedire il passaggio successivo. O come bloccare un ordine di vendita se una condizione non è soddisfatta. After significa che l'azione è già vendita. Puoi reagire. Creare un record correlato, aggiornare una nota o avviare un altro lavoro. I nomi indicano la tempistica. È importante. Una regola che viene eseguita dopo la registrazione può impedire. Una regola che viene eseguita troppo presto potrebbe non avere i dati necessari. Quindi i sviluppatori scelgono l'evento in base a cosa deve fare la regola aziendale qua. Il codice può anche essere avviato da un'azione. Un utente clicca su un pulsante come verifica stato premio e quell'azione richiama una procedura. Il codice può essere eseguito anche quando un oggetto è una variabile. Sembra tecnico ma è semplice. Una parte dell'estensione chiede a un'altra di svolgere un compito. Le variabili aiutano in questo. Una variabile è un'area denominata che contiene un valore durante l'esecuzione del codice. Può essere un numero, un testo, una data o persino un record di business central come il cliente attuale. In AL si dichiarano con var. Ad esempio una procedura di premi potrebbe usare una variabile chiamata customer per contenere il record del cliente attuale. Un'altra variabile chiamata discount percent contiene una percentuale di sconto. Questi non sono record venenti. Sono solo valori temporanei per quella parte di codice. Ecco il punto su dove risiede il codice. Se una regola può essere usata da più di un punto inseriscila in una codice. In questo modo la scheda cliente, un processo di vendita, un report possono richiamare la stessa procedura di sconto invece di avere ciascuno la propria versione. Ciò evita un problema familiare. Una schermata applica uno sconto del 10% un'altra del 5% se nessuno sa quale regola sia quella corretta. Mantenere le regole aziendali condivise in un'unica codice offre all'estensione un'unica fonte per quella decisione. Quindi i trigger gestiscono le regole vicine a un oggetto. Gli eventi consentono all'estensione di reagire ai processi stessi di business central. Le codice mantengono unita la logica condivisa.

Una volta collegati questi pezzi la domanda successiva è dove scrivono, testano ed esaminano gli sviluppatori tutto questo codice AL. Lo sviluppo AL avviene solitamente in Visual Studio Code spesso chiamato VS Code. È il tuo spazio di lavoro per scrivere file AL. Mantiene la tua estensione organizzata. Ti aiuta a trovare problemi e invia l'app finita a un ambiente business central per il test ma VS Code di per sé è solo un editor di codice generico. Ha bisogno dell'estensione del linguaggio AL di Microsoft. Quell'estensione insegna VS Code come funziona Business Central. Può suggerire nomi di oggetti mentre scrivi. Indica gli errori prima della pubblicazione. Ti aiuta a esplorare campi e procedure. Connette il tuo progetto a un ambiente business central. Ciò evita di dover tirare in dominare. Quando inizi un nuovo progetto AL puoi eseguire il comando al go in VS Code. Crea la cartella base del progetto e i file di impostazione per nome, estensione, editore, versione e ambiente business central da usare. Pensa a quella cartella di progetto come al banco di lavoro dell'estensione. Ogni file AL appartiene a quella cartella. Un file potrebbe contenere una tabella, un'altra estensione di pagina, una code unit può avere proprio file. In questo modo quando qualcuno apre il progetto può trovare la parte giusta senza scorrere un unico documento enorme. Quando il codice è pronto per il test VS Code lo compila in un pacchetto app. Questa è la versione installabile dell'estensione. Business Central legge quel pacchetto e aggiunge l'estensione all'ambiente. Se manca un campo, c'è un errore di battitura o qualsiasi problema che impedisce la compilazione, VS Code te lo segnala prima che il pacchetto raggiunga Business Central. Il test dovrebbe avvenire prima in un ambiente senso. Una sandbox è un ambiente Business Central separato dove puoi provare le modifiche senza rischiare le attività aziendali reali. Pubblichi l'estensione, apri le pagine, le modifiche, inserisci i record di test e vedi se le regole funzionano come previsto. Quella separazione è importante. Non vuoi scoprire che una nuova regola di convalida blocca gli ordini di vendita mentre il personale sta cercando di lavorare. In una sandbox puoi commettere errori, rimuovere dati di test, modificare il codice e ripubblicare senza influenzare i record reali. A volte il codice viene eseguito ma il risultato sembra comunque errato. È qui che il debug è utile. Inserisci un punto di interruzione nel codice, avvi il processo e l'estensione si mette in pausa durante l'esecuzione. In quella pausa puoi ispezionare valori come il cliente corrente, il livello premio selezionato o la percentuale di sconto calcolata dalla procedura. Invece di provare a indovinare perché una regola ha fallito, puoi vedere esattamente cosa ha ricevuto il codice. I team di sviluppo usano anche Git per mantenere la cronologia del loro lavoro. Git registra le modifiche ai file di progetto nel corso del tempo. Se qualcuno modifica una regola e crea un problema, il team può confrontare le versioni, vedere cosa è cambiato e ripristinare se necessario. Aiuta anche quando più di uno sviluppatore lavora sulla stessa estensione. Per un principiante la strada è migliore iniziare in piccolo. Impara a orientarti in business central, poi crea una tabella o una pagina. Pagina. Dopodiché, essendo una pagina standard, aggiungi una regola aziendale semplice e impara come gli eventi e i dati di installazione si inseriscono nel progetto. Ora colleghiamo questi pezzi attraverso un piccolo componente aggiuntivo che un'azienda potrebbe davvero usare. Un esempio semplice è creare un componente aggiuntivo per i premi clienti. Come è fatta davvero un'estensione a L? Immergiamoci in un esempio semplice. Immagina che la tua azienda voglia dei livelli di premio per i clienti, ognuno con il proprio sconto. Inizi creando una tabella dei premi. Immagina la come uno schedario digitale in cui ogni file contiene un ID, una descrizione e una percentuale di sconto. Livello Gold ottiene il 10% di sconto, per esempio. Il tuo staff deve gestire quei livelli senza toccare strumenti tecnici. Quindi aggiungi due pagine, una pagina e elenco premi per vedere tutti i livelli e una pagina scheda premio per modificarlo e crearne uno. Possono aggiungere un nuovo livello, regolare una percentuale o rivedere cosa c'è senza aprire alcun ambiente di sviluppo. Successivamente estendi la tabella dei clienti con un nuovo campo chiamato ID Premio. Quel campo collega ogni cliente a un record premio e lo posizioni direttamente nella pagina scheda cliente dove il personale gestisce già i dettagli dei clienti. Poi aggiungi un'azione premi in modo che possano aprire le elenco, l'elenco dei premi direttamente da se schede. La regola dello sconto vive all'interno di una code unit. Quando un altro processo ha bisogno dello sconto di un cliente richiama quella code unit invece di calcolarlo più volte su ogni pagina. Efficiente. Una code unit di installazione aggiunge livelli di premi iniziali la prima volta che la tua estensione viene e un sottoscrittore di eventi controlla il livello di premio scelto durante un processo di vendita applicando la regola della tua azienda esattamente al momento giusto. È una piccola estensione ma nota cosa contiene? Tabelle dati, schermate utente, azioni di navigazione, logica di configurazione, regole aziendali, tutto lavora insieme. Questa è la vera potenza di A. Va bene. In conclusione il tuo punto di partenza per lo sviluppo L. Quindi ecco il concetto fondamentale. Lo sviluppo L ti permette di aggiungere a Business Central le funzionalità specifiche di cui la tua azienda ha bisogno senza toccare l'applicazione principale. E non devi costruire tutto in una volta. Inizia con un campo, un'estensione di pagina e una regola chiara. Quello è il tuo primo blocco di costruzione. Se hai trovato utile questa pillola di conoscenza iscriviti sulla tua piattaforma di podcast preferita e condividila con chi ha appena iniziato lo sviluppo in Business Central. Unisciti a noi la prossima volta quando aggiungeremo un altro testo. Sono Marco Peters e questo è stato un altro episodio delle Microsoft Knowledge Nuggets su M365FM.