È stato un lungo percorso quello che ha portato allo sviluppo delle “Extensions V2” per Dynamics NAV. Chi ha provato con gli eventi e poi con le prime estensioni, ricorderà i tanti tentativi di rendere “modulare” NAV, che “modulare” per sua natura non è.

Oggi però l’attesa è finita e già con NAV 2018 chiunque può sperimentare l’efficacia del nuovo sistema di sviluppo, senza prodotti in anteprima o “beta”. Il set di strumenti è completo, stabile e cosa più importante: funziona! In Ahead abbiamo sviluppato negli anni passati molte personalizzazioni per NAV ed alcuni verticali. Come molti partner abbiamo uno “strato” aggiuntivo alla localizzazione italiana comprensivo delle richieste più frequenti fatte dai clienti, poi abbiamo la soluzione per il retail, per la distribuzione farmaceutica e recentemente anche per il settore automotive.

Bene è stato possibile portare oltre il 90% di tutto questo codice nel nuovo sistema di estensioni! Ciò significa modificare in minima parte il database standard di NAV con grande beneficio per gli aggiornamenti futuri. In altre parole significa ridurre da 100 a 10 l’effort per un aggiornamento di release.

L’editor

Il nuovo ambiente di sviluppo è Visual Studio Code, una versione light (ma innovativa) del classico Visual Studio. Una rivoluzione per chi è abituato al cosiddetto “classic” ma finalmente NAV ha il suo editor di codice, che produce file come un qualsiasi altro linguaggio, pienamente integrato con Git per il versioning.

Questa dell’editor non è cosa da poco. Nel 2009, quando iniziai a lavorare con NAV, arrivavo da più 10 anni di sviluppo in vari linguaggi OOP. Ci misi un bel po’ per abituarmi al fatto che il codice stava dentro il database e che non c’erano file sorgenti. Non a caso, prima ancora di iniziare il mio primo progetto, sviluppai un tool per estrarre automaticamente il codice dal database e pubblicarlo in un repository centrale. All’epoca usavamo SVN e regalai addirittura quel tool ad altri partner: per me era inconcepibile lavorare senza il versioning del codice.

Da NAV a 365

I vari rumours dello scorso anno sono stati chiariti da Microsoft in occasione dell’ultimo Directions di Madrid ad Ottobre ’17. Il tema era la migrazione di NAV verso un nuovo prodotto, esclusivamente cloud. Tralasciando la discussione “on premises” vs cloud, che esula da questo articolo, la preoccupazione di tutti era quella di perdere la possibilità di personalizzare (anche profondamente) lo strumento.

Essere ben strutturato e facilmente modificabile è una delle chiavi del successo di NAV che lo ha reso popolare, affidabile e trasversale a moltissimi settori merceologici. Lavorare con le “Extensions V2” e raggiungere lo stesso livello di efficacia del precedente sistema, certamente rasserena gli animi e tranquillizza coloro che vogliono continuare a sviluppare per questa magnifica piattaforma anche se fosse solo più cloud.

Dopo un po’ di confusione iniziale, la strategia di Microsoft con Dynamics 365 ora è abbastanza chiara. NAV ha già il suo nuovo nome: “Dynamics 365 for Finance and Operations, Business Edition” e la tecnologia sottostante è quella di NAV 2018!

Vedere e sviluppare in anteprima la nuova piattaforma è possibile. Infatti Microsoft rilascia periodicamente il software di Dynamics 365 F&O su Docker. Sì sì, proprio Docker: il famoso repository di immagini open source! Ciò se vogliamo è l’ovvia conferma che alla base di 365 ci sono tecnologie “on premises” che sicuramente saranno alternative alla sola offerta cloud. Basti pensare a PowerBI: da quando è disponibile il gateway per l’uso dei dati locali, lo strumento è passato da essere un “giochino” ad una valida e seria proposta per qualsiasi tipo di azienda.

Cambiare approccio

Facciamo l’esempio della codeunit “Undo Sales Shipment Line”. A standard non è possibile annullare la spedizione di righe conto (si può fare solo per gli articoli). Con il sistema precedente era scontato aprire il sorgente, commentare un po’ di righe standard ed integrare la mancanza con del proprio codice personalizzato.

Lavorare con le “Extensions V2” obbliga invece ad un approccio migliore, più modulare e pienamente compatibile con un aggiornamento di versione. Si intercetta il momento in cui l’utente preme il tasto “Annulla spedizione”, se la riga è di tipo articolo si procede come da standard, se la riga invece è di tipo conto si avvia la funzione estesa. Tutto questo sull’evento “OnBeforeAction”.

Altro aspetto innovativo è l’uso delle dipendenze per rendere modulare non solo NAV ma anche la propria soluzione.

Sempre per fare esempi noi abbiamo sviluppato un modulo di supporto per le comunicazioni ODETTE (una versione di Edifact specifica per il settore automotive). Questo modulo, che prima era disperso tra vari oggetti NAV di cui fare il merge ogni volta, è stato migrato in 4 “pacchetti” legati tra loro tramite dipendenze. Alla base c’è “Essentials” estesa con “Network” estesa con “EDI” estesa infine con “EDI Odette”.

Il vantaggio? 4 progetti separati, 4 librerie che crescono indipendentemente, possibilità di assegnare lo sviluppo a team differenti. Banalità per chi sviluppa con altri linguaggi e che finalmente sono disponibili anche per NAV.

Tips & tricks

Non potevo terminare l’articolo senza un classico “tips & tricks”! La versione attuale di Visual Studio Code effettua un cleanup dell’estensione ogni volta che si fa una compilazione. Ciò significa che se avete dei dati in una tabella estesa e ricompilate, li perdete ogni volta.

Questo comportamento in parte è corretto, perché consente di avviare sempre una estensione “sul pulito”, ma è frustrante se avete dei dati di esempio con cui state facendo lo sviluppo. Il team su GitHub di Microsoft è molto attivo e reattivo ai bug segnalati, confido che nelle prossime versioni sarà risolto. Intanto abbiamo sviluppato uno script in PowerShell per aggiornare l’estensione senza perdere i dati. Si può facilmente richiamare da Visual Studio Code con uno shortcut da tastiera, praticamente in modo trasparente.