ETL

Creare un XML complesso con Pentaho Data Integration

Caso di studio: Delibera AEEG n.65/2012 del 12 Marzo 2012

L’Autorità per l’Energia Elettrica e il Gas (AEEG) è un organo indipendente, istituito nel 1995 (Legge n.481 del 14 Novembre 1995). Ha funzioni di regolazione e di controllo sul mercato vincolato dei servizi di energia elettrica e gas per beni considerati di pubblica utilità.

Il cliente

SNIE c/o SMS engineering

La SNIE SpA opera da più di un secolo nel settore dell’energia elettrica. La sua principale attività consiste da sempre nella DISTRIBUZIONE di energia elettrica in Media e Bassa Tensione nell’area Nolana.

La SMS Engineering srl è un’azienda che opera nel settore dell’ICT, progettando e realizzando soluzioni rivolte all’innovazione e alla qualità.

Il problema

L’autorità per l’energia elettrica e il gas con la delibera 65/2012 approva l’introduzione di contenuti e modalità operative standardizzate con riferimento ai flussi informativi relativi ai dati di misura e ai dati di switching nel settore elettrico, identificando una soluzione tecnologicamente adeguata allo scambio dei dati nell’ambito del Sistema Informativo Integrato.

In pratica viene richiesto al Distributore di provvedere alla fornitura di alcuni file in formato xml (formato testo strutturato) contenente i flussi dati relativi alle curve di consumo per ogni singolo punto presa (contatore), mediante sito web dedicato ai Trader (società venditrici) e/o comunque attraverso un canale telematico.

La soluzione

La sorgente dati è costituita dal sistema IBM AMM (Automatic Meter Management ) su DBMS DB2. Per l’estrazione, l’elaborazione e la pulizia del dato, è stato utilizzato Microsoft SQL Server Integration Services (SSIS) dal collega della SMS engineering.

Per la creazione dei file XML ho utilizzato Pentaho Data Integration.

Per trasformare l’origine dati tabellare (con n trader e m punti presa) in un file XML complesso compilance con il relativo schema XSD fornito da AEEG, è stato necessario predisporre tre JOB per flusso, ed un numero non sempre uguale di TRANSFORMATION che comunque è possibile inquadrare nella tassonomia sotto riportata:

Job

              • Restart – Reset tabelle temporanee.
  • Ciclo esterno – Loop su Partita IVA Trader.
  • Ciclo interno – Loop su codice POD del singolo Trader.

Transformation

  • Load – Di pulizia e caricamento dati in tabelle temporanee.
  • Set Variable – Di estrazione dati e definizioni variabili utili al ciclo di lavorazione.
  • Transform – Di creazione del file XML.

A scopo esemplificativo si riportano e commentano gli schemi relativi ai tre JOB ed alla TRASFORMATION di creazione del file XML per il flusso SOS (FLUSSO DI SWITCHING PUNTI DI PRELIEVO TRATTATI ORARI – DATI STORICI).

job1

Il primo passo svolto dal JOB che avvia l’intera trasformazione (Ciclo esterno) è quello di lanciare un ulteriore JOB (SOS_Restart) che provvede al popolamento corretto delle tabelle temporanee sulle quali imporre le condizioni per il ciclo di lavorazione.

Il passo Verifica Trader da lavorare effettua un query sulla tabella temporanea. Se esiste ancora un record che rispetta la condizione di ciclo, vuol dire che non sono stati ancora prodotti i file per almeno un Trader e pertanto viene lanciata la trasformazione PIvaUtente semplicemente per impostare delle variabili di procedura, compresa appunto la partita IVA del Trader, utili alle trasformazioni ed ai job successivamente invocati.

Le azioni svolte dai passi successivi sono:

  • SOS_XML. Crea i flussi XML per il Trader lavorato.
  • Zip file. Comprime in un unico file zip tutti quelli xml generati dal precedente step.
  • Delete file. Elimina dal workspace tutti i file con estensione xml.

Il passo SOS_XML avvia il JOB (ciclo interno) che lavora con la medesima logica tutti i POD del singolo Trader.

job2

Di seguito una breve descrizione delle azioni di ogni singolo:

  • Verifica POD da lavorare. Effettua una query sulla tabella temporanee verificando che ci sia o meno un POD da lavorare per il Trader che si sta elaborando.
  • DataElaborazione. Imposta la data di elaborazione ed altre varibili utili alle trasformazioni successive.
  • generaSOSXml. E’ il cuore della procedura. Crea e salva i file XML di flusso sul file system del server.
  • Esito verifica XSD. In caso di fallimento, termina l’intera trasformazione (compreso il ciclo esterno) ed inoltra una mail con il dettaglio dell’errore al reparto tecnico. Pertanto l’errore va ricercato nell’ultimo file XML generato.
  • SQL. Frase SQL che aggiorna la condizione per il POD/Trader lavorato.
  • DA. Imposta delle varibili di procedura utili per procedere con la paginazione dei risultati (POD da lavorare) essendo stato posto un limite (10 MB) alle dimensioni del singolo file XML.

All’interno della trasformazione generaSOSXml è riportata tutta la logica per la generazione del file xml compilance al suo schema XSD fornito da AEEG (compreso verifica) ed il salvataggio sul file system.

transf1

All’estrema sinistra ritroviamo i blocchi Generate Rows e Table Input (Generate Rows, IdentificativiFlusso, DatiPOD, DatiCurva, DatiEA e DatiER) che effettuano le query che estraggono la porzione dati contenuta all’interno di un “pezzo” del file xml da generare.

I blocchi successivi (Crea XML root element, Crea IdentificativiFlusso, Crea DatiPOD, Crea Dati Curva, Crea Dati EA, Crea Dati ER) mappano i dati estratti sul valore di un elemento e/o attributo del flusso.

La chiave per generare un XML “complesso”, ovvero con TAG annidati, risiede nell’utilizzo dei blocchi XML join (XML Join Step 1 – 5) che consentono di innestare gli stream predisposti mediante un XPath Query. A scopo esemplificativo si riporta la configurazione del blocco XML Join Step 3.

xmlJoin

Per finire i passi Replace String E0 -> Ex, Insert CRLF e Indent, effettuano delle elaborazioni sullo stream delle join, tese a ben formare e formattare il risultato, che viene salvato su un file di testo (xml) e contestualmente validato con il suo schema (XSD Validator). Il passo EsitoValutazione acquisice il risultato da XSD Validator e lo inserisce in una variabile di procedura resa disponibile al JOB chiamante che in caso negativo termina l’intera trasformazione (compreso ciclo esterno) per consentire l’analisi dell’errore.

Di seguito il risultato del lavoro

xmlResult