Business Central Universal Code: prima o poi doveva succedere
Salve lettore, in questo articolo ti voglio parlare di un’iniziativa di Microsoft riguardo lo sviluppo di app chiamata Business Central Universal Code.
Andiamo con ordine. L’11 gennaio 2022 Microsoft ha presentato ufficialmente l’iniziativa Business Central Universal Code (http://aka.ms/BCUniversalcode).
In sintesi, con questa nuova offerta, la vendita di quello che viene chiamato “codice non universale” (cioè estensioni non destinate a funzionare online) ai nuovi clienti on-premise di Business Central, potrebbe richiedere la licenza di due moduli aggiuntivi. Questo avverrà dal 2022. I nomi dei due moduli sono (ma non è detto che cambi la nomenclatura):
- “Implemented code is not in extensions“: cioè se il codice partner implementato include modifiche direttamente nell’applicazione di base, questo modulo deve essere concesso in licenza.
- “Implemented code is not cloud-optimize“: cioè se le estensioni sviluppate hanno il target (nell’app.json) uguale a OnPrem. Tale modulo deve essere anch’esso concesso in licenza.
Le tariffe di questi moduli contenenti codice non universale hanno un prezzo per utente completo (Premium o Essential) con una tariffa annuale a partire dal 2023.
La roadmap annunciata è la seguente:
Seguendo le reazioni post-presentazione della community di Business Central, ho notato una certa preoccupazione tra i partner. Evidentemente non ci si aspettava una decisione così drastica (cioè far pagare il modulo per codice non ottimizzato per il cloud), ma la linea guida di Microsoft era ben chiara già da un paio di anni, se non anche prima. Il futuro è il cloud, pertanto quando sviluppi un’app se funziona per il cloud allora funzionerà sicuramente anche per le installazioni OnPrem.
Dicevo che Microsoft vorrà applicare un costo a queste soluzioni non cloud-oriented. Qui di seguito una tabella dei costi, che forse verrà rivista in termini di cifre, ma che dà l’idea di cosa Microsoft ha in mente.
Ricorda che queste tariffe non verranno applicate per tutti i clienti licenziati prima del 01/04/2022. Da notare, anche, come il modulo “Implemented code is not in extensions” quello che prevede la modifica dell’app base di Microsoft venga iper tassato perché è una pratica fattibile, ma sempre sconsigliata, per via appunto della poca integrabilità con la nuova architettura.
Tornando alle perplissità dei partner, che cosa veramente preoccupa? Sicuramente le funzionalità che in una soluzione Windows-based erano all’ordine del giorno con le vecchie versioni di Dynamics Nav:
- .Net Interop: cioè l’utilizzo di chiamate a dll tramite variabili .Net Interop.
- Operazioni coi file: cioè accessi al file system. Upload e download di file.
- Operazioni di stampa.
- Accessi diretti a SQL Server.
- .Net control addins
E sicuramente tante altre situazioni. Per ovviare a questo, però, possiamo utilizzare, ad esempio, gli strumenti di Azure. A sostituzione di .Net Interop, potresti utilizzare delle Azure Functions. Oppure delle WebAPI. Oppure per le operazioni coi file, potresti utilizzare servizi come l’Azure Blob Storage.
Come vedi, questi sono argomenti che cominciano ad esulare dal singolo pezzo di codice in AL. Ora la figura dello sviluppatore / consulente Business Central, deve entrare nell’ottica di conoscere anche il mondo cloud, attraverso l’acquisizione di nuove competenze.
D’altronde devi pensare la tua soluzione ERP non come un componente singolo a sé stante, ma come una parte di un ecosistema più complesso che deve interagire con i diversi servizi cloud. Una soluzione che ha i file memorizzati all’interno dell’ERP, le integrazioni con altri sistemi sono eseguite tramite chiamate AL, xmlports, ecc non è una soluzione solida cloud-oriented. Viceversa una soluzione moderna dovrebbe contenere:
- estensioni AL per la gestione dei processi aziendali.
- File archiviati nel cloud (ad esempio utilizzando l’archiviazione di Azure)
- Integrazioni complesse eseguite esternamente con servizi serverless come funzioni di Azure o Logic App o processi web.
- Utilizzare lo schedulatore solo per i processi gestionali. Per altre integrazioni da schedulare si utilizzano attività pianificate esternamente.
Un altro punto cruciale sono i costi del cloud. Ce ne sono? La risposta è sì, il fatto che siano più o meno alti dipende dall’architettura cloud che si sta utilizzando. Ad esempio l’archiviazione di un file può avere costi diversi in base al servizio utilizzato. Oppure l’utilizzo di un database cloud ha costi diversi in base al livello di utilizzo. Alla fine i costi sono variabili a seconda delle scelte in fase di implementazione che si fanno; però un buon ingegnere del software ne tiene sicuramente conto.
Personalmente, col team di sviluppo di cui faccio parte, abbiamo iniziato fin da subito ad attivare tutti i controlli severi del compilatore (quelli che utilizza Microsoft per accettare un’app sul marketplace per intenderci). Molto codice scritto in C/AL in una certa maniera è stato ristrutturato in modo che sia più vicino al mondo cloud possibile, dico vicino perché purtroppo ci sono ancora utilizzi di .Net Interop in alcuni punti, così come gli accessi ai file sono ancora nel vecchio modo, ma queste funzionalità sono ormai ridotte all’osso. Abbiamo sempre cercato di trovare una soluzione che sia più cloud-oriented possibile. Da questo punto di vista credo che ci possiamo ritenere soddisfatti perché i ritocchi non sono molti e sono mirati, lo switch sul file app.json da Target = OnPrem a Target = Cloud non è così utopico.
E tu lettore che cosa ne pensi dell’iniziativa di Microsoft di “Universal Code”. Sei favorevole o contrario? Se vuoi approfondire l’argomento, oltre al link che ti ho messo all’inizio dell’articolo (occorre accedere con il proprio account Microsoft), ti voglio lasciare quello sul blog di Waldo che è molto esaustivo; nonché quello di Stefano Demiliani.
