Perchè Sme.UP ERP è pronto per il futuro

In queste pagine introduco alcune tecnologie che riguarderanno con buona probabilità i software enterprise nei prossimi anni.  Sme.UP ERP è stato progettato per l’evoluzione, l’ha già dimostrato, quindi è già pronto anche per questi cambiamenti. Vediamo come.

Microservice, l’architettura fisica del gestionale del futuro

Il concetto di API (Application Programming Interface) è presente da molti anni nel mondo del software ed indica il modo in cui un software o il sistema operativo espone dei servizi richiamabili da altri programmi, nelle maniere più disparate. Oggi il termine API è più comunemente usato per indicare il fatto che un software espone le sue funzioni all’esterno, è un servizio. La fruibilità remota di queste funzioni è quasi sempre legata alla tecnologia dei webservice, dei sistemi software che comunicano tramite il protocollo http, da cui il prefisso web. Su questo si poggia l’integrazione di sistemi: oggi sono disponibili servizi web che fanno qualunque cosa, dal meteo, alla borsa, al calcolo matematico, allo storage di dati.

L’integrazione è la chiave per costruire delle soluzioni complete. Ma non è tutto, non basta: un sistema software complesso, mission-critical, ha anche al suo interno il problema dell’integrazione tra i suoi stessi componenti.

Per risolvere questo problema è stata introdotta una delle più importanti rivoluzioni dell’informatica moderna, che si poggia sulle API e sui webservice: l’architettura a microservice.

Si tratta di uno stile architetturale, evoluzione del SOA, che ha iniziato a diffondersi con prepotenza tra il 2011 e il 2013 nella comunità mondiale degli ingegneri del software, che definisce un sistema complesso come un insieme di webservice “piccoli” e stateless, indipendenti, isolati, capaci di sopravvivere all’indisponibilità degli altri, replicabili, sostituibili “a caldo”. La grande sfida è che questi servizi sono spesso fisicamente distribuiti su macchine hardware differenti, quindi portano il concetto di disponibilità ad un livello più alto: una di queste macchine può spegnersi, senza inficiare il funzionamento del sistema, anche perchè ogni microservice è replicabile, non avendo uno stato, quindi ridondato.

I microservice parlano tramite le API: devono dichiarare la propria interfaccia, ossia i loro dati di input e di output (si parla di “contratto”, non esiste nulla di più rigoroso e vincolante!). Così si rendono incapsulati, sono una scatola nera e possono cambiare internamente senza che il mondo esterno se ne accorga.

Perché diciamo questo? Perchè questo è il futuro di tutti i sistemi con ambizione enterprise, quindi anche dei sistemi gestionali complessi, se vogliono garantire scalabilità e affidabilità.

In Sme.UP le funzioni generali, che possono essere utilizzate in più posti e richiamate, dette /copy, sono state catalogate e definite in maniera rigorosa, come i contratti delle API (per essere precisi in Sme.UP le /copy sono sempre state definite API).

Sme.UP è stato progettato in questo modo quando i microservice non erano stati ancora pensati, perché i vantaggi dell’incapsulamento e del contratto tra funzioni erano già evidenti, quindi è già intrinsecamente pronto per l’architettura a microservice. Le /copy sono disaccoppiate, isolabili e remotizzabili. Verranno man mano rese dei microservice, finché l’intero sistema non potrà essere distribuito su più server, diventando sempre più scalabile e affidabile.

Infine, una precisazione: nel 2017, quando si parla di sistemi distribuiti, si sottintende ormai che essi girano in un ambiente composto non tanto da più server, ma da più “container”, cioè dei “mini” sistemi operativi virtualizzati, che contengono solo ciò che serve a far girare un’applicazione, diversamente macchine virtuali classiche, in voga dai primi anni 2000, che invece contengono un “intero” sistema operativo appoggiato su hardware virtualizzato.

Questa è un’altra recente rivoluzione, detta “containerizzazione”.

Interfacce evolute e rich client

Un sistema software che si pone l’obiettivo di interagire con gli utenti deve necessariamente avere un’interfaccia ricca, veloce, evoluta. Questa interfaccia deve cambiare spesso, perché deve adattarsi alle necessità di efficienza degli utenti, alla disponibilità di componenti e all’isteria delle tecnologie. E’ la parte di qualunque sistema software più incline al cambiamento.

Nel 2015 nasce un progetto capitanato dal gigante Google, denominato Angular 2 (poi rinumerato in 4 e infine semplicemente Angular). Si tratta di un framework, cioè un insieme di strumenti e tecniche per costruire software, il cui seguito è immediato e globale. Angular propone un modello per costruire interfacce utente evolute, veloci, manutenibili, testabili, basato sul concetto di componente, che è molto comune, ma con alcune caratteristiche peculiari. Ogni componente è responsabile solo dei suoi dati e della sua visualizzazione, lancia eventi e qualcuno li ascolta (tipicamente un componente di più alto livello). Il componente chiede i dati a servizi.

E’ emblematico come questo tipo di rappresentazione dei componenti rispecchi il modello di componenti adottato da Sme.UP ERP, in cui la schermata principale (scheda) è divisa in componenti, ognuno capace da solo di reperire i propri dati tramite servizi (le FUN), di disegnarsi e di inviare eventi, che altri componenti ascolteranno.

Perchè questo è importante? Perchè se i componenti hanno queste caratteristiche, la loro evoluzione è garantita: essendo isolati sono semplici da realizzare e da sostituire. E’ semplice trovare componenti già pronti. E’ semplice testarli. Questa architettura ha permesso a Sme.UP ERP di cambiare velocemente la tecnologia per la realizzazione dei propri client e di realizzarne per diverse necessità e piattaforme, senza cambiare il modello e concentrandosi sui componenti. Ovviamente Sme.UP sta usando anche Angular per realizzare il nuovo client grafico.

Internet of Things: il sistema informativo distribuito

L’acronimo IOT indica l’Internet delle Cose, perché le cose, gli oggetti fisici, sono interconnessi, si scambiano dati ed eseguono operazioni.

L’IOT è una grande opportunità per il mondo produttivo, non è il caso di elencarne qui le possibilità; basti pensare che è possibile, ad esempio, dotare oggetti prodotti in uno stabilimento di sensori che comunicheranno con la sede centrale anche dopo che l’oggetto sarà venduto. Questo cambia l’ordine della cose: la vita di un articolo all’interno del sistema informativo, che in molti casi sarebbe finita nel momento in cui è stato consegnato, continua. Si può pensare quindi che i sensori che sono a bordo dell’articolo, fanno anch’essi parte del sistema informativo stesso, rendendolo un sistema distribuito.

Solo un ERP flessibile e ben progettato, incentrato sulle entità, può adattarsi a un cambiamento simile.

Esattamente come Sme.UP ha sempre descritto gli oggetti del mondo fisico, economico e produttivo, definendone le proprietà (OAV) e le funzioni, così Sme.UP descrive gli oggetti connessi.

Questa descrizione è la base per il controllo e l’evoluzione: non è possibile gestire una rete di oggetti interconnessi senza una rappresentazione organica delle loro caratteristiche statiche (cosa sono) e dinamiche (come si stanno comportando).

L’ERP del futuro non sarà più relegato al freddo della sala server o in un datacenter tra le montagne: sarà sparso per il mondo insieme agli oggetti che lo compongono.

Database a grafi e big data: i dati sono una rete, non delle tabelle.

I database a grafi si propongono di descrivere in modo più naturale le proprietà e le relazioni tra oggetti, mentre il db relazionale di fatto descrive solo relazioni. Quindi c’è il concetto di Class e il concetto di Edge, che riprende quello di entità e relazione dei relazionali, ma con molta più enfasi e con funzione (che in un database sono le query).

Se in un DB relazionale, per dire che Mauro lavora per Sme.UP e Google devi avere la tabella Dipendenti, la tabella Aziende, e la tabella di relazione tra Dipendenti e Aziende, in uno a grafi esiste la classe Dipendente, la classe Azienda e le relazioni “lavora-per” e “ha-come-impiegato”. La query diventa “prendi tutti i dip che hanno la relazione lavora-per con azi smea e query”.

Questo genera una rete di interconnessione tra le entità, navigabile in maniera molto efficiente e naturale.

Per capire meglio vediamo un esempio basato su GraphQL, un liguaggio di interrogazioni per estrarre dati da API, nell’accezione di webservice che rispondono con json strutturato. Altri linguaggi di interrogazione sono simili, anche se più vicini all’sql; questo però è il più bello e moderno, perché basato su una sintassi JSON-like.

In pratica una query si basa su sugli oggetti e su quello che in Sme.UP definiamo OAV, attributo di un oggetto.

QUERY:

# Dammi gli eroi (OGGETTO) di cui voglio il nome (OAV) e, per
# ognuno, i suoi amici (OGGETTO) di cui voglio il nome (OAV).
# Amici è una relazione, un edge
{
  hero { #oggetto
    name # oav I/37
     friends { # edge oav multiplo J/31
      name # oav I/08
    }
  }
}

RISULTATO:

{
  "data": {
    "hero": {
      "name": "R2-D2",
      "friends": [
        {
          "name": "Luke Skywalker"
        },
        {
          "name": "Han Solo"
        },
        {
          "name": "Leia Organa"
        }
      ]
    }
  }
}

Bene, possiamo dire che Sme.UP è già pronto per questo tipo di modello.

Esiste ad esempio un servizio che dato un tipo oggetto (Cliente, Articoli, Ubicazione, Offerta, …) e gli attributi che si vogliono ottenere di quell’oggetto e della condizioni di filtro,  risponde con una lista di oggetti di quel tipo, che rispettino quelle condizioni, espandando gli attributi richiesti. Un esempio in pseudo-codice:

request: 

tipo_oggetto(cliente) attributi(ragione_sociale, codice, indirizzo, giorni_medi_pagamento) condizione(descrizione contiene 'srl' AND località='Roma')

response:

{ 

Gino Trasposti srl |  12345 | via Verdi 31, 00100 Roma (RM) | 131,7;

Giovanni Laterizi srl |  54321 | via Gialli 1, 00118 Roma (RM) | 40,9;

Da Carlo srl |  13579 | via Rossi 9, 00131 Roma (RM) | 30,0;

Marsrla spa |  09754 | piazza Rosa 132, 00118 Roma (RM) | 241,7

}

Allo stesso modo ad esempio un servizio che dato un tipo oggetto (Cliente, Articoli, Ubicazione, Offerta, …) il codice istanza di quell’oggetto e gli attributi che si vogliono ottenere, risponde con gli attributi richiesti. Un esempio in pseudo-codice:

request: 

tipo_oggetto(cliente) codice(12345) attributi(ragione_sociale, codice, indirizzo, giorni_medi_pagamento, prodotti_acquistati)

response:

{ 
Gino Trasposti srl;
12345;
via Verdi 31, 00100 Roma (RM);
 131,7;
prodotto A, prodotto B, prodotto C, prodotto D
}

La composizione di questi servizi permette di navigare il sistema di conoscenza come un grafo, rendendo Sme.UP ERP pronto per questo tipo di evoluzione.

Le chiamate basate su pattern testuali

Una parte fondamentale di internet sono (mi vergogno quasi a dirlo, tanto è banale) le URI, gli indirizzi, quelle stringhe di testo che, basandosi su semplici convenzioni permettono di identificare qualunque risorsa (Universal Resource Identifier) tra miliardi.

Lanciare una URI significa far avvenire diverse operazioni di identificazione e instradamento fino alla risposta del server che possiede la risorsa, tendenzialmente un testo, in un formato, HTML, che in base a semplici convenzioni diviene una pagina su uno schermo. Questo modello permette efficienza, scalabilità, disaccoppiamento, evoluzione.

Ad esempio, se oggi a

http://api.smeup.com/servizi/lista_articoli/viti.html 

risponde un server e domani un altro, per chi chiama è trasparente. E se la pagina viti.html è generata da un programma, scritta a mano, letta da un dispositivo o chiesta a un terzo elemento, è lo stesso: dietro una URI può esserci un mondo.

Bene, le FUN in Sme.UP si basano sugli stessi principi ed hanno gli stessi vantaggi: stringhe di testo che, in base a una convenzione semplice, permettono di chiamare qualunque servizio e rispondono tendenzialmente con un testo, XML, che sempre in base a semplici convenzioni viene interpretato e genera un componente visuale su schermo

F(EXB;*LIS;) 1(AR;VIT;)  //leggi Lista Articoli di tipo Vite