Sviluppi standard (importanti) derivati dalla Fatturazione Elettronica

L’obbligo di comunicare delle fatture in formato elettronico, che scatterà per tutte le società italiane a Gennaio 2019, è un’importante sfida e opportunità per tutti i player che si occupano di informatica per le aziende. Non potevamo farci sfuggire l’occasione di generalizzare, astrarre e replicare, in puro stile Sme.UP,  dando origine a una serie di sviluppi standard che hanno migliorato (e non di poco) i nostri prodotti e la nostra offerta.

Integrazione standardizzata con web service

Le fatture agli intermediari si comunicano tramite web service (vi invitiamo a cercare questa parola nel blog e verificare quanto abbiamo scritto su questo argomento di base dell’informatica moderna). Questa è stata occasione per una generalizzazione della comunicazione con qualunque web service che rispetti delle convenzioni riconosciute a livello mondiale.

Questa standardizzazione si basa su due pilastri: EDI e LOA38.

In particolare si è proceduto all’integrazione tra la £K11, API adibita alla comunicazione client-server all’interno del costruttore A38, che permette di chiamare un webservice da un programma RPG, e l’Applicazione ED MailUP EDI che si occupa d’invio e ricezione di tracciati EDI (Electronic Data Interchange).

Questo perchè la comunicazione con un sistema terzo è il pane quotidiano per l’EDI, che contiene già tutte le funzioni di tracciatura.

È stato aggiunto un nuovo metodo di comunicazione *A38_B£01 (Richiamo generico A38) impostabile in tabella EDC che utilizza il nuovo tracciato specifico EDA38001.

Questo permette di semplificare il richiamo di un web service, scrivendo nel tracciato:

• la subsezione del costruttore A38 da richiamare
• i parametri di input
• i percorsi dei file di input e output, che rappresentano la domanda fatta al webservice e la risposta da da parte di questo.

Infatti la comunicazione smeup-webservice avviene attraverso questi due file, che vengono salvati per fini della tracciatura.

In questo modo in un programma è sufficiente scrivere, usando l'api £EDT, il tracciato EDA38001 su EDSEND0F.

Il programma standard EDB£01A si occupa del recupero dei parametri necessari, del richiamo della £K11 e della lettura della risposta, con conseguente scrittura dell’output su IFS nel file specificato nell’apposito campo del tracciato.

Testing and tracking

Vengono memorizzate su EDSEND0F nel tracciato EDA38001:

• le informazioni relative allo status della chiamata
• il response code HTTP restituito dal web service
• un indicatore di errore
• l’eventuale messaggio.

E’ stato introdotto un log specifico per la £K11 al fine di facilitare l’analisi della comunicazione e l’individuazione degli errori. Il log viene scritto su JALOGT0F ed è interrogabile con una apposita scheda.

E’ stata creata anche una scheda con un TST grafico per simulare i parametri di invio al web service e visualizzare l’esito.

Capite bene che a questo punto chiamare un webservice in modo controllato e affidabile diventa possibile, sempre nello stesso modo e con strumenti che aiutano lo sviluppo e la comprensione. Un grande risultato!

Nota tecnica

La trasmissione del file di in input e del file di output avviene su coda dati tramite codifica in Base64, inviando anche l’hash MD5 corrispondente, che serve a verificare che il file ricevuto sia integro.

Queste due nuove funzionalità risolvono un problema annoso, la comunicazione di file binari tra Sme.UP Provider, Looc.UP, Web.UP e server applicativo. Sono generali, implementate nelle API £G02 e £G80 e verranno utilizzate sempre più spesso per questo tipo di trasferimenti.

Funzioni avanzate per il trasferimento e trattamento di file binari in rete

Per consentire la trasmissione dei file verso e da un web service sono state implementate nuove funzioni e metodi delle api £H80 e £G80.

Questi sviluppi migliorano notevolmente le funzioni di copia di un file tra IFS e una cartella condivisa di rete,  in quanto non necessitano di autorizzazioni sistemistiche su IFS da parte dell’utente di esecuzione di Sme.UP Provider.

Si basano sulle due nuove funzioni di trasferimento dei file binari: copiando un file da IFS a cartella di rete il file viene letto in binario e convertito in Base64 (codifica che consente la traduzione di dati binari in stringhe di testo ASCII) e inviato dalla £H80 sulla coda dati al Provider insieme all’hash MD5 che consente il controllo di integrità del file ricevuto.

In modo speculare la copia di un file di rete su IFS avviene tramite l’invio del file in Base64 da parte del Provider sulla coda dati. La stream testuale ricevuto viene letto dalla £H80 e scritto in modo binario dalla £G80, che effettua poi il controllo rispetto al checksum MD5 ricevuto. Il tutto si basa ovviamente sulle FUN e l’XML.

Scheda di Smeup Provider

Sono state migliorate le funzioni della scheda dell’oggetto V3LSE, in modo da rendere interrogabile lo stato del Provider e altre informazioni utili a verifiche sul suo funzionamento.

Sme.UP Provider NO Sme.UP ERP

Una interessante novità, legata al concetto di SmartKit, che è spiegato in altri articoli di questo blog, è che è stata realizzata una versione di Smeup Provider  in grado di avviarsi e collegarsi ad un server IBM i senza Sme.UP ERP installato.

Questa versione espone alcune funzioni richiamabili da programmi non Sme.UP tramite scrittura su coda dati, tra cui ovviamente l’interfacciamento ai web service utilizzati per la trasmissione della fatturazione elettronica e le funzionalità di £H80.

Contestualmente è stato sviluppato un pacchetto di programmi RPG senza dipendenze Sme.UP da distribuire per la generazione e l’invio delle fatture elettroniche.

Questo rappresenta un primo esempio di sviluppo di un’unica applicazione per tutte le soluzioni del Gruppo Sme.UP, con condivisione di codice, esperienza e documentazione.

Conclusioni

In questo articolo sono stati elencati dei macro-sviluppi che riguardano la parte applicativa e le tecnologie strettamente collegate, tralasciando invece gli sviluppi relativi al solo SmartKit. Di seguito un elenco più esaustivo.