Web.UP interfaccia comune per i frontend grazie alla funizzazione di RDS ERP

Sme.UP LAB ha realizzato un progetto che prevedeva la funizzazione di RDS ERP in Sme.UP ERP. Questo progetto aveva l’obiettivo di consentire l’utilizzo del front-end messo a disposizione da Web.UP per visualizzare le mappe ed alcune altre funzioni di RDS ERP, senza utilizzare l’AS400. Con funizzazione intendiamo infatti la possibilità di utilizzare Web.UP in totale assenza dell’AS400, facendo sì che la parte connessa a valle sia un’entità a questo totalmente estranea, in questo caso RDS ERP. E’ stato quindi sviluppato un nuovo tipo di provider, chiamato OpenProvider, che implementa il protocollo di comunicazione delle richieste di Web.UP, fornendo schede ed eseguendo delle FUN. 

Il progetto

Prima della realizzazione di questo progetto, Web.UP si interfacciava, attraverso l’architettura di Sme.UP ERP,  ad un provider a cui richiedeva l’esecuzione delle fun. Il provider trasmetteva l’input ad AS400 e attendeva la risposta; quando la riceveva trasmetteva l’informazione nuovamente a  Web.UP, che creava l’interfaccia di conseguenza. 

Il progetto di funizzazione aveva l’obiettivo di ricostruire questo processo senza passare dall’AS400. Eliminare il passaggio da AS400 aveva tre implicazioni sostanziali:

• Dover rifare un provider che non utilizzasse AS400, il che implica il rischio di buttare tutto quello che c’era dietro a Web.UP
• l provider deve essere in grado di implementare il protocollo di comunicazione con Web.UP: saper leggere il formato delle richieste di Web.UP e infine di rispondere a Web.UP nel formato atteso.
• Ricevere le richieste in un formato e rispondere in formato consono ed eventualmente connettere una terza parte.

Sme.UP LAB ha trovato una soluzione sfruttando le potenzialità di RDS ERP e di OpenProvider per svolgere una parte di quello che prima svolgeva AS400. In questo senso è stato possibile mettere dietro a Web.UP un applicativo terzo, operazione che ha richiesto di implementare il protocollo di comunicazione corretto per permettere la comunicazione con OpenProvider. 

Obiettivo del progetto era infatti quello di consentire l’utilizzo di Web.UP come interfaccia comune per i frontend, indipendentemente dalla tecnologia che c’è dietro, mantenendo lo stesso protocollo di comunicazione.

Come funziona

OpenProvider implementa le risposte alle richieste di schede e fun di sistema che consentono a Web.UP di operare correttamente. Questo set di risposte rappresenta il comportamento di default del provider. Tutte le funzionalità aggiuntive o la personalizzazione di quelle di default vengono implementate a valle. Nella definizione del modulo di login viene indicato unicamente l’url del OpenProvider al quale ci si vuole collegare. E’ possibile aggiungere all’url anche una seconda parte, che abilita le personalizzazioni sul comportamento di default, a valle. Nel primo caso il login si collegherà all’OpenProvider di release; nel secondo caso ogni richiesta verrà prima valutata utilizzando le eventuali personalizzazioni presenti e gestita se presente (da RDS ERP nel caso specifico), oppure verrà girata al gestore di release.

Il progetto è stato realizzato attraverso servizi Rest, ovvero servizi Web chiamati in modo standard attraverso i quali Web.UP comunica con il nuovo provider. La stessa cosa avviene anche lato RDS ERP: RDS espone un servizio per fornire i dati in base ai parametri richiesti. Tutto quello che non è servito da servizi interni di Web.UP o servizi di RDS ERP è gestito lato provider attraverso dei file xml.
Quando viene richiesta una fun, OpenProvider attiva un servizio di ricerca a più livelli: 

• Ricerca il servizio corrispondente nella parte a valle. 
• Se non lo trova, ricerca un servizio di default implementato all’interno del provider stesso (che consente di inserire logiche arbitrarie all’interno delle fun di sistema) 
• Se non lo trova, ricerca il risultato della fun all’interno di un file statico; la ricerca del file statico avviene a sua volta su più livelli, in primis nella repository indicata nella parte aggiuntiva indicata nell’url, se non viene trovato qui viene ricercato all’interno della directory principale, ovvero quella di release; i file statici rappresentano la risposta in formato xml alla fun invocata; vengono dinamicizzati grazie alla possibilità  di utilizzo di Placeholders, markers il cui valore viene sostituito run-time.

L’ultima parte del progetto ha inoltre introdotto una modifica importante all’interno di  Web.UP: il protocollo di comunicazione tra provider e Web.UP attualmente avveniva in formato xml; sono stati eseguiti dei test per fare in modo che la comunicazione tra Web.UP e OpenProvider avvenisse in formato JSON, formato diverso per la rappresentazione dei dati più compatta e moderna. E’ stato quindi fatto in modo che OpenProvider rispondesse in formato JSON. Sono state apportate alcune modifiche all’interno di Web.UP per fare in modo che questo fosse in grado di gestire le risposte anche nel nuovo formato; questa gestione ha introdotto la possibilità di gestire il protocollo di comunicazione in base ad una versione.

I vantaggi

Questo progetto ha diversi vantaggi: 

• Dimostrare la possibilità di eliminare l’utilizzo di AS400
• Uniformare il frontend per tutti i prodotti ERP smeup, che fino ad oggi avevano ognuno un aspetto diverso, uniformando anche la percezione dell’utente come di un unico prodotto. 
• Aumentare il peso di Web.UP: la parte di frontend è in grado di funzionare a prescindere dalla tecnologia che c’è dietro. Potenzialmente, infatti, Web.UP può essere utilizzato come frontend per un vasto numero di sistemi ERP.
• Potenziamento dell’architettura utilizzata da smeup, per cui il risultato che verrà visualizzato sarà sempre lo stesso.
• Rendere unitario il metodo di scrittura del frontend, a prescindere dalla tecnologia che c’è dietro. Di conseguenza, il dipartimento di delivery lavora sempre allo stesso modo a prescindere dall’applicativo che c’è dietro. 
• Rendere possibile l’utilizzo di schede preesistenti anche con un’architettura differente  dietro.