Con Providerless si intende il processo evolutivo che porterà al superamento dell’utilizzo di Sme.UP Provider e la sua sostituzione con software moderni. Diventa quindi possibile distribuire ai clienti una soluzione full-stack (da Web.UP a Sme.UP ERP) senza l’obbligo di uno Sme.UP Provider?
Da oggi è una cosa realizzabile. Come? Ve lo illustriamo.

Chiunque abbia lavorato in Sme.UP avrà sicuramente sentito parlare dello Sme.UP Provider e del suo utilizzo massivo in qualsiasi tipo di installazione per permettere lo svolgimento di funzioni interne ed il dialogo tra Web.UP e l’AS400. Con il passare del tempo Sme.UP Provider ha evidenziato limiti difficilmente superabili per un software di vecchia generazione. Da qui la nascita di AS400-proxy.

Cosa è l’AS400-proxy?

Rappresenta un salto generazionale. Consiste in un’applicazione più moderna che affronta il tema di offrire servizi a Sme.UP ERP utilizzando una tecnologia a microservizi. Questo approccio permette di migliorare di molto l’usabilità, la resilienza e la robustezza aprendo l’applicazione a nuove tecnologie.

Se dovessimo spiegare come è fatto l’AS400-proxy, potremmo dire che è un’applicazione JavaEE (ovvero un file .war) che viene installata su un application server (nello specifico Payara-micro) il quale a sua volta può essere dockerizzato all’interno di un container.
Non preoccupatevi se non avete capito alcuni concetti, verranno spiegati di seguito.

Le immagini sottostanti mostrano l’evoluzione dal funzionamento del classico Web.UP collegato ad un provider che scambia informazioni con l’AS400 e lo scenario in cui viene utilizzato il moderno AS400-proxy.
Nel primo caso Web.UP è installato su una macchina che può essere OS-indipendent all’interno di payara, lo Sme.UP Provider è installato su una macchina necessariamente Windows ed il dialogo con la parte server avviene mediante l’utilizzo di quest’ultimo.

Il secondo caso invece prevede sempre una macchina OS-indipendent in cui è installato docker al cui interno è containerizzato payara, su cui vengono eseguiti sia Web.UP che AS400-proxy ed il dialogo tra di essi avviene come tra due microservices. La connessione con l’AS400 avviene grazie all’AS400-proxy.

 

Scenario Web.UP con Sme.UP Provider

 

Scenario Web.UP con AS400-proxy

 

Perchè è nato l’AS400-proxy?

I principali motivi per cui è nato l’AS400-proxy sono elencati di seguito:

  • il crescente sforzo che la società Sme.UP sta affrontando nel cercare di portare i propri prodotti ad essere indipendenti dal sistema operativo su cui vengono fatti “girare” è uno fra i tanti motivi della nascita di questo nuovo strumento.
    Lo Sme.UP Provider era (ed è) un’applicazione fat-client-side installabile solo e unicamente su macchine Windows. Questo vincolo necessita quindi di avere sempre a disposizione almeno una macchina dedicata Windows in cui installare il software di cui prima.
    Con l’AS400-proxy invece il problema non sussiste perchè esso è un’applicazione JavaEE che viene fatta girare all’interno di un’Application-Server (nel nostro caso Payara) che è disponibile per tutte le maggiori piattaforme in commercio (GNU Linux, Windows e MacOSX) così da rendere il problema del sistema operativo un vecchio ricordo.

 

  • altro motivo (che si lega a quello precedente) è dato dal fatto che utilizza tecnologie moderne che prevedono la containerizzazione con l’utilizzo di Docker.
    Docker è un software opensource per il deployment e la gestione dei container ovvero, come dice la parola stessa, dei contenitori all’interno dei quali vengono inserite ed eseguite applicazioni specifiche.La containerizzazione utilizza un approccio che consiste nel virtualizzare solamente il sistema operativo ma non l’hardware (come per virtual machine). Utilizzando i container le risorse possono essere isolate, i servizi limitati e i processi avviati in modo da avere una prospettiva completamente privata del sistema operativo, col loro proprio identificativo, file system e interfaccia di rete. Più container condividono lo stesso kernel nativo, ma ciascuno di essi può essere costretto a utilizzare una certa quantità di risorse, come la CPU, la memoria e l’I/O.Questo si traduce nella possibilità di poter utilizzare il sistema su piattaforme differenti, indistintamente dal sistema operativo installato.
    Per chi non conoscesse Docker, la containerizzazione o semplicemente volesse approfondire l’argomento, rimando a questi utili link: DockerContainersDockerContainersGoogle.

 

  • l’architettura con cui è stato concepito l’AS400-proxy è un’ulteriore motivazione.
    La struttura a microservizi con cui ogni applicazione viene ora sviluppata e/o ristrutturata, il cui principio consiste nella disgregazione e riassegnazione delle competenze che si traduce nel creare “micro applicazioni” indipendenti, interconnesse tra di loro tramite chiamate HTTP che assolvono le richeste svolgendo un unico lavoro chiaro e ben distinto, assolve i requisiti fondamentali per rispettare i vincoli della “singola responsabilità“. Questo porta come vantaggi il fatto di avere la possibilità di cambiare il client (Web.UP o qualsiasi altra cosa) avendo a disposizione delle Rest-API interrogabili tramite semplici chiamate HTTP.
    Per vedere le funzioni richiamabili tramite API è possibile consultare la pagina delle API e tramite:
    http://<istanzaAS400-proxy>:<portaIstanzaAS400-proxy>/fun-provider/openapi.yaml

    Swagger potrebbe essere utile per la consultazione delle info delle API.

 

  • per rispondere alle attuali esigenze del mercato, le applicazioni aziendali moderne devono essere veloci nella progettazione e nel deployment, avere un accesso facile e sicuro da qualsiasi dispositivo e disponibilità sempre e ovunque.Per questo motivo “la nuvola” rappresenta l’architettura principe per i nuovi ecosistemi IT in cui i software  devono essere in grado di girare su sistemi differenti, in modalità tradizionale o SAAS (software as-a-service), nelle sedi aziendali o nei principali datacenter. Si aprono quindi scenari di progettazione differenti, spaziando dall’adozione dei container (che permettono lo sviluppo rapido del software per ambienti legacy o cloud grazie all’utilizzo di risorse elementari standard) all’application modernization per la trasposizione dei programmi tradizionali verso i modelli SAAS e sulla nuvola.Il fatto di poter essere eseguito su macchine remote (dette in Cloud) è stato dettato dal fatto di essere un’applicazione a microservizi web based  (vedi sopra).Cosa significa essere eseguito in cloud? Significa avere la possibilità di hostare l’intero pacchetto del AS400-proxy su sistemi di terze parti come S3 di AWS o Firebase di Google e funzionare nella stessa identica maniera come se fosse eseguito in locale o su una macchina dedicata.

 

  • il fatto di poter essere “containerizzato”  e installato ipoteticamente nel Cloud, introduce quindi la necessità di dover gestire più istanze contemporaneamente su sistemi differenti.
    Questo è reso possibile tramite l’utilizzo di tool dedicati a questo scopo come Kubernetes, che è un software per la gestione e l’orchestrazione di container (vedi documentazione kubernetes).

    Kubernetes offre la possibilità di distribuire i container in modo agevole e scalabile e di gestire al meglio i carichi di lavoro. Permette di creare applicazioni e servizi su più container, programmarli e gestirli a livello di scalabilità e integrità nel tempo. La complessità di gestione derivante da un numero elevato di contenitori viene semplificata raggruppando i container in “pod”, che aiutano a programmare i carichi di lavoro e ad erogare i servizi richiesti, inclusi rete e storage ai container stessi. Kubernetes è anche in grado di bilanciare automaticamente i carichi all’interno dei pod, semplificando notevolmente la gestione complessiva dell’infrastruttura. Inoltre, l’infrastruttura standard di Kubernetes è completamente ridondata, e questo riduce drasticamente il rischio di downtime, mentre con il solo uso di Docker o di altri sistemi di conteinerizzazione, l’affidabilità non è assicurata a livelli così alti.

 

  • Il fatto che è stato concepito come “proxy” prevede anche il fatto che non sia indispensabile l’AS.
    Questo punto è di fondamentale importanza perchè l’AS400-proxy è in grado di gestire le richieste anche senza avere un’AS400 collegato, ma vederlo solamente come un’entità a cui è possibile collegarsi.

 

  • la resilienza è un’altro aspetto critico che ha dettato molte scelte.
    Questo per rendere il prodotto duraturo a fronte di interferenze esterne. Interferenze possono essere viste come quelle situazioni in cui lo Sme.UP Provider viene messo a dura prova, come per esempio la caduta di un server AS400 durante la comunicazione.
    Il suo predecessore in casi come questi spesso necessita dell’intervento esterno per il ripristino della funzionalità, mentre nel caso del AS400-proxy essendo un microservice con vita a se stante, questo problema non si presenta e tenterebbe di reinstaurare la connessione non appena l’AS tornasse disponibile.

 

Tecnologie a confronto

 

Provider AS400-proxy
Dockerizzabile

Possibilità di essere eseguito in un container Docker

Kubernetes handle

Possibilità di essere eseguito e gestito contemporaneamente su più macchine

AS400 non necessario

Possibilità di essere eseguito senza una connessione ad un AS400

Resilenza

Possibilità di resistere a modifiche esterne (come disconnessione da AS400)

SaaS

Possibilità di essere eseguito in Cloud

Pool di connessioni 2.0

Nuovo pool di connessioni che rendono la comunicazione più veloce ed efficiente

Comunicazione verso AS400

Gestione di tutte le cominicazioni da e verso l’AS400

Gestione Password

Gestione possibilità di cambio password se scaduta

Componente IFL

Componente dei flussi interattivi

RFunction

Funzione da lanciare al termine di un programma

Emulazioni senza formato video

???

JA_00_05

Servizio sui files

JA_00_20

Servizio per la gestione delle variabili

JA_00_27

Servizio per la gestione immagini per oggetto

JA_00_32

Servizio per funzioni oggetti client

JA_00_44

Servizio per la gestione file di log

JA_00_55

Servizio per la gestione delle risorse remote

H53

Servizio per la generazione dei PDF

Componente FLU

Componente per Flussi batch

Legenda:
  Funzione perfettamente funzionante
  Funzione  abilitata come servizio INTERNO di Web.UP
  Funzione abilitata come servizio ESTERNO di Web.UP
  Funzione non implementata