Codice RPG by Sme.UP: modernizzazione, innovazione e nuove tecnologie – parte 2

codice-rpg

Ti sei perso la prima parte dell’intervista al nostro collega Franco Lombardo su modernizzazione e linguaggio RPG? Leggilo qui.

Interprete codice RPG e Domain Specific Language

Nel precedente articolo abbiamo passato in rassegna i limiti principali che oggi presenta il linguaggio RPG. In questo articolo, vediamo insieme come noi del Gruppo Sme.UP stiamo cercando di superarli.

Abbiamo fatto un’ipotesi di lavoro: perché non creiamo un interprete open source portabile, funzionante sia principalmente su IBM i ma anche su altre piattaforme?

Con questa premessa, abbiamo iniziato a scrivere un interprete usando una tecnologia innovativa: Kotlin. È un linguaggio che gira all’interno della Java Virtual Machine molto moderno. A questo interprete possiamo dare in pasto file RPG che lui interpreta senza problemi. Il fatto però di avere il controllo del processo di interpretazione ci consente di mischiare linguaggi diversi.

Cosa significa? L’esempio può essere un programma RPG che chiama una classe java che chiama un altro programma RPG che chiama il codice Kotlin o un altro linguaggio che opera all’interno della JVM.

Qual è lo scopo di combinare linguaggi differenti? Ognuno di essi ha le sue specificità. L’esempio lampante è un programma RPG che deve andare ad interfacciarsi con il mondo esterno; può chiamare un servizio su una URL oppure può interfacciarsi con un device IoT con un protocollo particolare o proprietario. A questo punto il codice RPG non fa altro che fare una semplice call e questo programma richiamato non è un altro programma RPG ma è una classe ad esempio Java o Kotlin che esegue la connessione sfruttando una serie di librerie dell’ecosistema JVM per svolgere quel compito specifico.

Ma a questo punto, dato che stiamo scrivendo noi il linguaggio allora perché al posto di fare una call non andiamo ad introdurre una nuova keyword che fa quel compito specifico? Dato che il linguaggio è interpretato dal nostro interprete, possiamo chiedergli di fare quello che vogliamo, quindi possiamo estendere il linguaggio a seconda delle nostre esigenze.

Le esigenze tuttavia possono essere sia tecnologiche (in questo caso andiamo ad interfacciarci a un webservice) però possono anche essere quelle di creare keyword relative al mondo del business. Un esempio di questo caso può essere creare una nuova keyword “calcolo iva” che esegue il calcolo dell’iva a seconda delle regole che ho scelto per il tipo di business.

Ma in sostanza, cosa stiamo facendo?

Stiamo trasformando l’RPG da linguaggio di programmazione a DSL. I DSL sono dei linguaggi creati per risolvere dei problemi di business che parlano la lingua dell’esperto di business più che la lingua della tecnologia. Vengono creati per aiutare la comunicazione tra persone tecniche e persone non tecniche.

Un esempio è costituito dal linguaggio Open Fisca sviluppato con il patrocinio dell’agenzia delle entrate francese. Serve per dare a chi si occupa di stabilire tutte le regole della tassazione un linguaggio con il quale riesca ad esprimerle nel software che poi si occupa di verificare la correttezza delle dichiarazioni fiscali. Questo è solamente un esempio ma all’interno del Gruppo Sme.UP il concetto di DSL l’abbiamo già nel DNA. Tutte le nostre interfacce, infatti, che vengano renderizzate con l’applicazione client standard, con l’applicazione web o con quella mobile, sono descritte con un linguaggio che ne descrive le sezioni, che possono contener oggetti grafici come alberi, griglie, istogrammi e molto altro. Chi costruisce la videata ne specificare ogni parte con questo linguaggio di alto livello, che poi sarà visualizzato opportunamente sui vari dispositivi. Queste sezioni sono poi descritte con un linguaggio di programmazione inventato da noi che va a specificare ogni parte della scheda della maschera video cosa dovrà andare a contenere. Noi abbiamo la strada già aperta in casa e abbiamo già questa mentalità di costruire dei linguaggi che servano ad usi molto specifici.

Come stiamo integrando questo interprete rpg all’interno di Sme.UP ERP?

In Sme.UP ERP c’è un componente che si chiama Sme.UP Gateway che è un gestore di microservizi cioè di programmi Java che svolgono dei compiti particolari molto specifici e circoscritti. Ad esempio, si interfacciano con delle macchine utensili oppure controllano i parametri ambientali di una serra; possono anche interfacciarsi con software ERP di terze parti. Ognuno di questi programmi, come detto, svolge un compito speciale, si inserisce all’interno di questo Gateway e comunica in modo bidirezionale con delle code eventi con Sme.UP ERP.

Data questa premessa abbiamo pensato: ma perché in ognuno di questi plugin non andiamo a inserire il codice del nostro interprete che, in questo modo, può interpretare del codice RPG? Un codice Java, quindi, che sta in un Application Server Java interpreta un codice RPG. C’è un esperto di dominio RPG che può scrivere del codice di interfacciamento a basso livello verso dispositivi verso terze parti facendolo girare all’interno di Sme.UP Gateway.

È un progetto ambizioso, a che stato di avanzamento siamo?

Abbiamo fatto un prototipo e abbiamo iniziato a farlo funzionare. L’idea è buona sta in piedi però è ancora un prototipo. Oltre a noi, a questo progetto lavora Strumenta, azienda specializzata nello sviluppo di linguaggi, compilatori e DSL. Quindi, affidandoci alla loro esperienza pensiamo di riuscire ad arrivare a breve ad un livello di avanzamento del progetto notevole.

Il progetto è Open Source (non poteva essere altrimenti!), speriamo che si raccolgano tante idee e una comunità che cresce intorno ad esso. Il progetto si chiama Sme.UP RPG e si trova su GitHub; vorremmo farlo crescere con l’aiuto di tanti sviluppatori indipendenti.

Attendiamo nello spirito della comunità open source la collaborazione di tutti!


franco lombardo

Franco Lombardo
Java Team Leader e specialista DiTech – Gruppo Sme.UP
My LinkedIn Profile


Comments

  1. silvio campeggi : Novembre 5, 2019 at 1:00 pm

    Buongiorno
    quali sono le differenze con i service programs, le binding directories e i moduli presenti nativamente nell’ RPG IV ??
    grazie

    • Francesca Manocchi : Novembre 5, 2019 at 3:21 pm

      Ciao Silvio,

      Service programs e moduli funzionano solo sui sistemi IBM-i, mentre l’interprete può essere eseguito anche su altre piattaforme.

      Al momento è ancora in fase di realizzazione un supporto per emulare il comportamento di questi oggetti all’interno dell’interprete: vi terremo aggiornati!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *