Il pattern MVC
Fino a qualche anno fa, il tipico gestionale ERP di produzione italiana rappresentava un ecosistema fine a sé stesso, chiuso nei suoi rigidi confini client/server. Mentre dal punto di vista contabile alcuni di questi software erano all’avanguardia, la loro architettura chiusa rendeva complesso riuscire a costruire interfacce verso altri sistemi, magari in seguito alla richiesta di un cliente di poter gestire logiche di business più complesse in ambiti esterni a quello contabile, come la logistica o la produzione.
Alcuni di questi software, al massimo, permettevano di implementare uno scambio dati con sistemi esterni solo al prezzo di costruire delle interfacce su tabelle di frontiera o FTP di complessa realizzazione o soggette a frequenti e fastidiosi problemi di sincronizzazione.
Questo limite rimase scottante per un lungo periodo, nonostante molti gestionali diffusi in Italia fossero sviluppati a partire da un’architettura di matrice Adonix, quindi già predisposti a un’implementazione di pattern MVC. Questo pattern rappresenta una logica di sviluppo improntata alla separazione tra le logiche di business dedicate alla gestione dei dati e il modulo di presentazione, che si occupa dell’interfaccia utente.
Nell’acronimo, infatti, “M” indica il Model, ossia il Modello dei dati, “V” indica la Vista, ossia l’interfaccia utente, e “C” indica il Controller, ossia la logica che si occupa di estrarre i dati e collegarli all’interfaccia.
La predisposizione a sistemi di interscambio dati era quindi presente, ma non sfruttata nella sua piena potenzialità. I gestionali ERP venivano prodotti come software desktop, cioè i classici eseguibili costruiti con tecnologia basata su Form o, al massimo, la sua variante responsive WPF. Non erano perciò software pensati per essere esposti all’esterno del perimetro della LAN aziendale su cui erano installati, ma applicativi Windows che operavano solo con un sistema client server.
Tuttavia, la presenza di un’architettura MVC, oppure la predisposizione a essa, fece sì che alcuni team R&D iniziassero a fare dei test per sviluppare sistemi per esporre via web le logiche di business che questo pattern permetteva di astrarre agevolmente dal pacchetto software.
Database
La necessità principale per i sistemi esterni non era tanto di innescare le logiche interne del gestionale (seppure qualche volta i Web Services vengano impiegati anche per avviare elaborazioni massive o Workflow), quanto quella di poter effettuare operazioni CRUD (ossia sia di consultazione sia di scrittura dati) sulle tabelle del database ERP.
La crescente complessità delle integrazioni con i sistemi esterni (si pensi, ad esempio, a CRM impiegati dagli agenti venditori, oppure MES che inviano avanzamenti di produzione al gestionale), aveva infatti reso scomode e limitate le integrazioni basate su sistemi FTP.
I principali limiti di questo tipo di integrazione erano questi:
– la difficoltà di avere dati in tempo reale;
– la gestione delle scritture simultanee a uno stesso record;
– una generale degradazione di performance;
– problemi di sincronizzazione dovuti ad eventi non controllabili.
L’architettura delle interfacce su FTP o tabella di frontiera prevede, infatti, che i dati siano ricevuti per mezzo di importazioni di file CSV o a formato a campi di lunghezza fissa, generati a partire da viste o, nel caso di logiche di estrazione molto complesse, da tabelle compilate per mezzo di procedura batch schedulate.
Questi sistemi introducono latenze tra il momento in cui il dato viene compilato e quello in cui viene fruito: ad esempio, un estratto contro generato da una procedura pianificata a mezzanotte, consultata da un agente il giorno seguente, non è aggiornata con le modifiche alle partite eseguite la mattina successiva all’elaborazione. Questo e gli altri problemi elencati hanno fatto sì che le soluzioni di interscambio dati basate su questa tecnologia non fossero più adatte per situazioni particolarmente critiche.
L’integrazione con i Web Services
La soluzione ottimale per rendere fruibili i dati contenuti nelle tabelle del database ad applicazioni esterne è l’uso dei Web Services. I Web Services permettono di esporre le tabelle del database per mezzo di URL raggiungibili con chiamate simili alle chiamate HTTP con cui navighiamo nel web con il nostro browser. In ambiente Microsoft esistono framework di sviluppo ideali per la realizzazione di Web Services, come ad esempio .Net Framework o .Net Core.
Questi ambienti offrono la possibilità di realizzare con il linguaggio C# delle API fruibili da qualsiasi device o APP residente al di fuori del perimetro della LAN aziendale. Le API vengono esposte per mezzo di un server web (IIS) o, in soluzioni ancora più tecnologicamente avanzate, utilizzando dei microservizi su Azure. Le API hanno diversi modi per recuperare i dati dalle tabelle del gestionale. Se si tratta di API esposte con un web server sulla stessa LAN del gestionale, si può utilizzare un framework dedicato come Entity Framework, che permette di preparare la base dati impiegata dalle API anche da personale senza specifiche competenze di programmazione.
Entity Framework è un tool molto evoluto che, tra i tanti vantaggi, offre anche la possibilità di impiegare LINQ per le interrogazioni sui dati, creando direttamente nel codice C# delle query che ricordando le interrogazioni SQL, ma con il vantaggio che vengono validate in fase di compilazione.
Se, invece, le API sono contenute in un microservizio su Azure, è possibile avvalersi di una replica direttamente su Azure SQL, realizzata con delle console pianificate che trasferiscono i dati dal database del gestionale al SQL ospitato in cloud.
Utilizzando dei Web Services realizzati con queste tecnologie si ottengono numerosi vantaggi rispetto alle classiche interfacce realizzate con scambi di file FTP o tabelle di frontiera:
1. Maggiore indipendenza dalle configurazioni della LAN e del firewall, che spesso rendono complessa la configurazione e la manutenzione dell’interfaccia;
2. Migliori performance;
3. Possibilità di fruire di dati aggiornati in tempo reale;
4. Semplicità di manutenzione.
Inoltre, se si impiegano dei micro servizi su Azure, un altro vantaggio è la semplicità con cui è diventato possibile scalare la soluzione, qualora dovesse sorgere la necessità di gestire un pool maggiore di connessioni simultanee ai dati.
