Micro ETL Foundation - Il sistema di messaggistica per Data Warehouse e Business Intelligence in ambiente Oracle - parte 1

1. Idee e soluzioni per
progetti di
Data Warehouse
e
Business Intelligence
in ambiente Oracle
Massimo Cenci Data Warehouse Blog
http://massimocenci.blogspot.it
Il sistema di
messaggistica
(parte 1)
Micro ETL Foundation

2. Introduzione
• Un obiettivo di quella che ho definito come Micro ETL Foundation (MEF) è quello di fornire alcune semplici e immediate soluzioni
alle necessità di un Data Warehouse. Cosa c’è di più semplice (e indispensabile) di un messaggio di log ? Può sembrare strano che si
dedichi un intero articolo per descrivere come segnalare il messaggio “Hello world”; messaggio, famosissimo per tutti i
programmatori del mondo informatico. Ma scopriremo che quello che appare semplice è in realtà un po’ più complicato.
• Infatti, se prendiamo il primo paragrafo di un qualunque libro di programmazione, (per es. in java) la soluzione è espressa con una
unica riga:
System.out.println ( Hello Word! ");
• Se utilizziamo un altro linguaggio di programmazione (per es. il PL/SQL di Oracle) la soluzione è nuovamente espressa con una
unica riga:
Dbms_output.put_line ('Hello World');
• Quello che voglio sottolineare è la incompletezza del messaggio ricevuto; infatti la complessità non risiede nella segnalazione in sè
stessa: in fin dei conti è una semplice chiamata di funzione. La complessità è nella mancanza di contesto. La complessità è il
metadato.

3. Introduzione (2)
• Supponiamo che in questo momento stanno girando più processi ETL di caricamento. Il fatto di ricevere dei messaggi di
segnalazione o di anomalia non è sufficiente. Quello che interessa sapere è quando è stato inviato il messaggio, quale job lo ha
attivato, quanto tempo è trascorso dal messaggio precedente, quale era la procedura attiva al momento del messaggio.
• Scopriamo subito che rispondere a tutte queste domande non è più banale. Quando usciamo dagli esempi teorici stampati sui libri
ed entriamo nella realtà lavorativa quotidiana, tutto diventa più complicato.
• Vedremo la teoria e la pratica, quindi il codice, che darà una risposta alle esigenze contestuali descritte in precedenza. E la
soluzione sarà, (sorpresa!), nuovamente espressa in una unica riga.
• Il linguaggio di programmazione utilizzato sarà il PL/SQL di Oracle (semplicemente perchè Oracle è molto utilizzato in ambito Data
Warehouse e quindi mi rivolgo a un pubblico più vasto), ma le tecniche esposte sono facilmente riproducibili su qualunque altro
RDBMS. Dimenticavo: vedremo anche come far sì che il messaggio venga inviato anche via e-mail.
• Questo articolo comunque, non è solo per programmatori. E’ un articolo per tutti, che mostrerà il duro lavoro che sta dietro un
semplice messaggio di log. Questo aiuterà ad immaginare il lavoro che sta dietro a un intero processo di caricamento di un Data
Warehouse. Iniziamo ora con alcune definizioni.

4. Definizioni (1)
Naming Convention
Ho speso molte parole sulla importanza e necessità di utilizzare sempre una naming convention per i progetti di Data Warehouse.
Riassumo in poche parole.
In generale, la naming convention è il metodo con cui si decide di assegnare un nome alle varie entità del sistema che si sta progettando.
Questo metodo deve produrre un nome che deve essere in grado di rappresentare immediatamente la natura semantica delle entità in
gioco. Non importa se appartengono a un sistema di Data Warehouse o a un sistema operazionale.
ETL Process
Il processo ETL è l’insieme di programmi che caricano i dati che giungono dai sistemi alimentanti nelle tabelle del Data Warehouse.
Poichè questo insieme può essere molto complesso e articolato, è estremamente importante avere un sistema di messaggistica che mi
fornisca il maggior numero di informazioni possibili sull’andamento del processo.
Job
Un job è una unità logica esaustiva di un compito ben preciso, per esempio il caricamento di una dimensione di analisi o di una tabella
dei fatti o di entrambe le cose. Un insieme di job correlati fra loro è a sua volta un job che fa parte di una schedulazione. Cioè viene
attivato ad una ora prestabilita.
Unit
A sua volta un job è costituito da unità elaborative più semplici e sequenziali che possiamo chiamare unit. La unit è l’unità elaborativa
elementare (quindi è codice) che a sua volta può richiamare delle altre procedure e funzioni che possiamo definire, in modo generico,
moduli
Execution
Un job in genere gira di notte, ma potrebbe girare anche più volte al giorno. Ogni esecuzione di un job è un run che deve essere
identificato con un numero sequenziale, che possiamo definire come exec counter.
Per il momento accontentiamoci di queste definizioni molto brevi. In seguito avremo modo di analizzarle più in dettaglio. La figura
seguente mostra in modo grafico queste definizioni.

5. Definizioni (2)

6. Requisiti
• I requisiti del sistema di messaggistica sono molto semplici. Avere uno strumento che segnali tutto quello che si ritiene utile per
monitorare il corretto andamento del processo ETL.
• E’ compito del progettista decidere il contenuto di questi messaggi, che possono essere semplicemente informativi, come il
numero di righe processate, o di attenzione particolare, come l’identificazione di errori o anomalie. In questi casi deve essere
possibile inviare il messaggio anche via e-mail.
• Il sistema non deve semplicemente storicizzare tutti i messaggi generati, ma deve avere anche le informazioni di contesto. Il
contesto è quello indicato nel paragrafo delle definizioni relativamente al processo ETL. Più informazioni di contesto inseriamo, più
riusciamo a tenere sotto controllo il sistema e più saremo efficienti e veloci nell’ intervenire in caso di problemi.
• Si da per scontata una minima conoscenza di Oracle e dei linguaggi SQL e PL/SQL.

7. Design
• Il design della componente di messaggistica della Micro ETL Foundation (MEF), si compone di 3 tabelle, 2 sequenze e 1 package. Li
possiamo vedere come i componenti base. Il minimo necessario per le altre componenti del MEF che utilizzeremo in futuro.
• La naming convention utilizzata è una versione ridotta di quella da applicare agli oggetti di un Data Warehouse. [Vedi
http://www.slideshare.net/jackbim/recipes-6-of-data-warehouse-naming-convention-techniques]. Però sarebbe eccessivo
applicare a MEF la stessa logica che serve a organizzare le centinaia di tabelle tipiche di un Data Warehouse di grosse dimensioni.
Inoltre possiamo utilizzare MEF in qualunque tipo di progetto. Si utilizzerà quindi questa struttura semplificata:
<entity name> = <area code>_<logical name>_<type code>
• Farà eccezione il package base che , essendo comune a tutto, sarà ulteriormente semplificata eliminando anche il <logical name>.
• L’area code sarà “MEF”. La tabella MEF_CFT è la tabella di configurazione generale del sistema. La tabella MEF_EMAIL_CFT è la
tabella di configurazione specifica per gli indirizzi e-mail, la tabella MEF_MSG_LOT è quella che conserverà il testo dei messaggi. La
sequenza MEF_MSG_SEQ serve per dare una sequenzialità numerica ad ogni messaggio. La sequenza MEF_RUN_SEQ serve a
identificare numericamente ogni esecuzione di un job.
• Il package Oracle MEF è la libreria di programmi che gestisce quegli oggetti.
• Tutti gli script di creazione degli oggetti, possono essere scaricati nel modo indicato nella seconda parte di questo articolo che
mostrerà in modo pragmatico e divertente l’utilizzo del sistema [http://www.slideshare.net/jackbim/note-di-data-warehouse-e-
business-intelligence-il-sistema-di-messaggistica-2]. Gli script sono molto minimali, con le sole strutture principali, lasciando al
lettore il completamento di tutte le altre strutture accessorie quali indici, constraints, ecc. Le tabelle saranno create nella
tablespace di default, ma è consigliabile sempre creare delle tablespace ad-hoc

8. Design - La tabella MEF_CFT
Questa tabella contiene informazioni di tipo generale relative alla MEF e al Data Warehouse. Ai fini della messaggistica contiene poche
colonne. Altre colonne saranno aggiunte in futuro (o a vostra scelta)
• prj_cod: Codice del progetto di Data Warehouse
• user_cod: Nome dell’ utente Oracle di ETL.
• email_srv_cod: Server di posta elettronica. Poiché nella maggior parte delle realtà aziendali è sempre presente un server per la
gestione della posta elettronica, indicare qui quel server
• mef_root_txt: Path della cartella degli script MEF
• mef_dir: Oracle directory che punta alla mef_root_txt

9. Design - La tabella MEF_MSG_LOT
Questa tabella memorizza tutti i messaggi di log che vengono inviati dal processo di caricamento.
• seq_num: Numero sequenziale del messaggio ottenuto dalla sequenza Oracle
• day_cod: Time stamp di inserzione del messaggio nel formato YYYYMMDD
• sched_cod: Identificatore della schedulazione a cui appartiene il job
• job_cod: Identificatore del job. E’ una entità logica, nel senso che dobbiamo pensarla come il lancio di una sequenza di unità
elaborative
• unit_cod: Identificatore dell’unità elaborativa all’interno del job. Possiamo pensarla come una procedura o una funzione del
package Oracle.
• module_cod: Identificatore del modulo dell’unità elaborativai (se necessario). Una unit, se complessa, può a sua volta chiamare
delle sub-routine o delle sottofunzioni, cioè i moduli. In questo caso è interessante sapere nel messaggio quale sub-routine l’ha
generato.
• rows_num: Numero di righe processate. In genere questo campo non è valorizzato, ma se vogliamo segnalare il numero di righe,
per esempio, inserite in una tabella, valorizzando una opportuna variabile di package, potremmo avere anche questa informazione
• line_txt: Testo del messaggio
• cline_txt: Testo del messaggio in formato CLOB
• ss_num: Numero di secondi intercorsi dal messaggio precedente. Questa informazione, insieme alle due successive, fornisce un
dato sommabile di tipo statistico. Se volessimo sapere quanto tempo hanno impiegato tutti gli statement di un certo tipo,
saremmo in grado di calcolarlo
• mi_num: Numero di minuti intercorsi dal messaggio precedente
• hh_num: Numero di ore intercorse dal messaggio precedente
• elapsed_txt: Tempo trascorso dal messaggio precedente nel formato HH24:MI:SS
• stamp_dts: Time stamp di inserzione del messaggio
• exec_cnt: Identificatore della esecuzione del job. Ogni run di un job dovrebbe essere caratterizzato da un numero, a sua volta
estratto da una sequenza Oracle
• user_cod: Utente Oracle che ha inserito il messaggio. E’ impostato automaticamente mediante una variabile di sessione Oracle.
Può essere utile nel caso in cui più utenti concorrano al processo di caricamento (non consigliato)

10. Design - La tabella MEF_EMAIL_CFT
Questa tabella configura gli indirizzi e-mail degli eventuali destinatari di un messaggio.
• email_cod: Codice per identificare un gruppo di destinatari.
• from_txt: Mittente del messaggio. Questo nome comparirà come sender nel messaggio della e-mail. Non utilizzate caratteri
speciali, nè dei blank fra le parole. Per es. non impostate Amministratore ETL ma Amministratore_ETL altrimenti postreste ottenere
a run-time un messaggio di errore del tipo:
ORA-29279: SMTP permanent error: 501
5.5.4 Invalid arguments
• to_txt: Identificatore del destinatario del messaggio
• cc_txt: Indirizzo e-mail del destinatario in conoscenza
• subj_txt: Soggetto predefinito del messaggio
• status_cod: Stato (attivo=1, non attivo =0) del destinatario

11. Design - La sequenza MEF_MSG_SEQ
La sequenza è un oggetto Oracle. In pratica è un contatore universale che si incrementa ogni volta che lo si richiede. Ogni riga di
messaggio deve avere il suo numero sequenziale. E’ più funzionale del time stamp per poter fare l’ordinamento della tabella.
Poichè a volte i messaggi si susseguono a frazioni di secondo l’uno dall’altro, il time stamp rischierebbe di non essere sufficientemente
discriminante.
Design - La sequenza MEF_RUN_SEQ
Sequenza che indica in modo univoco, un run di esecuzione di un job.

12. Il package MEF (1)
• Questo è il package di base. Consiglio di sviluppare sempre tutto il codice all’interno di packages PL/SQL (sono in pratica delle
librerie), che permettono una migliore gestione e utilizzo del codice. In pratica, si collocano nello stesso contenitore, programmi
logicamente collegati. Inoltre possiamo utilizzare delle variabili d’ambiente, che un package mette a disposizione agli altri packages
all’interno di una sessione Oracle. (ricordiamoci che una sessione Oracle è tutto quello che avviene fra una connessione e una
disconnessione SQL).
• Ho cercato di descrivere il codice nel modo più completo possibile, non dando niente per scontato, per permettere anche ai neofiti
del linguaggio di comprenderlo. Avremo modo così di esplorare, anche in poche linee di codice, alcune caratteristiche molto
interessanti del linguaggio, come l’utilizzo delle variabili di package, il tipo record e le autonomous transactions.
• In Oracle i package sono costituiti da due componenti, una specification e un body. La specification è la parte pubblica del codice,
cioè contiene le definizioni di unità elaborative (unità elaborativa è un termine generico per comprendere funzioni e procedure) e
di variabili globali utilizzabili e visibili anche da altre unità elaborative.
• Nella specification è quindi presente solo il modo con cui chiamare le unità e non il codice che le implementa.
• Il body è la componente privata del package. Qui è presente il codice delle unità indicate nella specification,e di tutte le altre unità
a cui non si vuole dare visibilità esterna.
• Il package MEF è di carattere generale, cioè contiene tutte le procedure o funzioni che sono specifiche della messaggistica, ma
anche alcune generiche, cioè che potrebbero essere riutilizzate, ossia chiamate, da altri packages.
• Descriviamo ora le caratteristiche salienti presenti nel codice del package. (si ricorda che il source lo potete scaricare nella seconda
parte di questo articolo)

13. Il package MEF (2)
• Si parte con lo statement di creazione della package specification, terminata sempre con una istruzione di end. Di seguito devono
essere indicate tutte le variabili globali (se ci sono) e tutte le unità elaborative che possono essere richiamate dall’esterno. La
dichiarazione delle unità elaborative è seguita dalla definizione dei parametri di input.
• I parametri possono essere di input (è il default, per cui non è necessario indicare la parola chiave IN subito dopo il nome del
parametro) oppure di output (parola chiave OUT) o entrambi (parola chiave IN OUT).
• Nel package è presente la definizione di una variabile di tipo exception, che è un tipo predefinito PL/SQL. Questa istruzione
permette di definire dei messaggi di errore personalizzati che non siano quelli di default di Oracle. (che hanno sempre codici
minori di 20000). Per esempio, se a un certo punto volete abortire il processo perchè un certo valore non è presente nella tabella
anagrafica, potete farlo generando un codice di errore che a tutti gli effetti ha l’apparenza di un errore Oracle (ORA-xxxxx) ma è
invece un vostro errore personalizzato. Vi rimando, per ulteriori dettagli, al relativo manuale anche se qui ne vedremo la sua
applicazione.
• Sono poi definite delle variabili globali per definire il carriage return, il carattere “/” e gli apici “’”’ .
• Le altre variabili sono quelle che identificano il contesto di cui abbiamo bisogno. Dichiarate qui, e inizializzate al momento
opportuno, potranno in seguito essere utilizzate da qualunque package.
• Le procedure di entry point sono p send, per segnalare un messaggio e p_mail per segnalare il messaggio via e-mail. Le procedure
e funzioni hanno dei parametri di input. La presenza del default null permette al chiamante di non dovere valorizzare quel
parametro di input. Se non è presente la parola chiave default, il passaggio del parametro è obbligatorio, e la sua assenza
genererebbe un errore a run-time.
• In coda è presente l’istruzione SQL (sho errors) che permette di mostrare eventuali errori nella compilazione del package. Entriamo
ancora più in dettaglio.
• pv_pkg: Dichiarazione e inizializzazione di una variabile globale che identifica il package in esecuzione. Vedremo più avanti il suo
utilizzo. Consiglio che il nome di tutte le variabili globali siano precedute dal pv (package variable), il nome delle procedure con p_
e il nome delle funzioni con f_ (scusate la mia insistenza sulle standardizzazioni).
• type pt_work_rec: Il tipo record è una struttura dati composta, definibile dall’utente secondo le proprie necessità, i cui campi
possono essere a loro volta di diversi tipi. Nel nostro caso si è definito un record di lavoro che conterrà tutti i riferimenti necessari
alla elaborazione.

14. Il package MEF (3)
• pv_work_rec: Questa variabile del tipo appena definito, sarà globale e utilizzabile da tutte le procedure. Il tipo rowtype permette
di definire delle variabili che hanno la stessa struttura della riga di una tabella (quella che precede la clausola %rowtype). Tali
variabili, come quelle di tipi standard, possono essere passate come parametri alle unità elaborative.
• v_module_cod: Tutte le procedure/funzioni utilizzano una variabile, locale alla procedura, inizializzata al nome della procedura
stessa. E poichè una procedura con lo stesso nome potrebbe anche esistere in altri packages, concateniamo al nome della
procedura il nome del package utilizzando la variabile globale pv_pkg.
• f_str: Funzione di utilità per generare una stringa dopo avere sostituito le variabili di input.
• p_ins_msg_lot: Questa procedura, non pubblica, esegue l’inserzione del messaggio nella tabella MEF_MSG_LOT ricevendo come
parametro di input una variabile di tipo riga. L’ istruzione pragma autonomous_transaction è molto importante e necessita di una
descrizione approfondita. Sembra incredibile, ma se non esistesse, non sarebbe possibile questo sistema di messaggistica. La
pragma autonomous_transaction permette di committare (cioè di convalidare nel database) solo ed esclusivamente le istruzioni
presenti nella unità programmativa che contiene questa direttiva. Questo concetto è fondamentale perchè ci permette di segnalare
(quindi di inserire dati nel database) senza intaccare la logica del processo di caricamento. Chiariamo con un esempio. In genere,
prima di caricare i dati di un giorno su una tabella, si cancellano nnanzitutto i dati di quel giorno, per poi caricare/ricaricare i nuovi
dati. La commit si fa alla fine, se il caricamento, nella sua totalità, si è concluso positivamente. Se eseguissi una commit dopo la
delete e una dopo la insert, un qualunque problema sulla secuzione della insert mi causerebbe la perdita dei dati del giorno: la
delete ormai li ha cancellati. Poichè la messaggistica deve comunque fare una commit del messaggio in tabella, l’innocente
messaggio dell’esecuzione della delete, mi convaliderebbe anche la delete stessa. E questo è un effetto collaterale non accettabile.
La autonomous transaction mi risolve il problema: l’engine PL/SQL di Oracle, riesce a produrre una transazione “figlia” che vive di
vita autonoma, che convalida i dati nel database senza intaccare la logica della transazione padre.
• p_rae: La gestione della exception è standardizzata nel modo seguente. A fronte di un qualsiasi errore Oracle, la clausola when
others manderà in esecuzione la procedura p_rae che arricchisce il contenuto dell’errore con altre informazioni utili, come, per
esempio, dove è avvenuta l’exception. L’uscita sarà sempre l’errore standard pv_error. La clausola when pv_error si utilizza per fare
in modo che si mantenga l’errore originale. In pratica, se ci sono tre procedure annidate e l’ultima è quella che abortisce, l’errore
sarà segnalato solo dall’ultima (tramite when others) , sarà impostato a pv_error, e le procedure chiamanti non faranno altro che
uscire senza produrre delle segnalazioni fuorvianti.

15. Il package MEF (4)
• p_init: Altra procedura privata. Esegue tutte le attivit à di inizializzazione delle componenti della variabile line_row per poter poi
eseguire la insert in tabella.
• delta_time: Procedura che, in base ai parametri di input, quali la data dell’ultimo messaggio e la data corrente, calcola tutte le
informazioni delta-temporali: quanti secondi,minuti,ore sono trascorsi e un delta espresso nel formato testuale del tipo
’HH24:MI:SS’. I modi con cui si può calcolare il delta time sono numerosi: quello utilizzato è solo uno dei molti.
• f_get_seq_val: Funzione generalizzata che estrae, in modo dinamico, il numero successivo della sequenza Oracle il cui nome è
espresso nel parametro. Anche questa è globale.
• f_get_exec_cnt: Funzione che estrae il numero di esecuzione del job. Prima di chiamare la funzione generica f_get_seq_val verifica
che non sia già stato impostato come variabile globale: in quel caso usa il numero di esecuzione corrente.
• f_get_cft: Funzione che estrae la configurazione corrente dalla tabella MEF_CFT.
• p_esend: Funzione che esegue l’invio della email per mezzo del package UTL_MAIL.
• p_send: Questa è la procedura che invia il messaggio. La sua struttura è molto semplice. Valorizza la stringa sostituendo i tags “%”
con i parametri di input (di nuovo con l’utilizzo di una chiamata di funzione globale). Esegue le inizializzazioni. Inserisce il messaggio
in tabella.
• p_mail: Procedura di invio della e-mail. Sulla base del codice email ricevuto in input, cerca tutti i destinatari nella tabella
MEF_EMAIL_CFT e chiama la p_esend passandogli tutti i parametri necessari.

16. Configurazione del sistema (1)
• Prima di poter creare tutte le strutture appena descritte, bisogna eseguire alcune operazioni di verifica ambientale. Prima di tutto è
necessario verificare che l’RDBMS Oracle sia predisposto per l’invio di email. Quindi bisogna verificare che l’utente Oracle che invia
i messaggi abbia tutti i permessi necessari alla sua attività. Poi bisogna completare le due tabelle di configurazione. Vediamo in
dettaglio.
Verifiche SMTP
• Dobbiamo verificare che l’RDBMS Oracle sia predisposto per l’invio di email. infatti l’invio viene attivato tramite la chiamata di una
procedura che fa parte di un package di sistema. Per fare questa verifica, collegarsi in SQL*Plus con l’utente SYS e verificare la
presenza del package UTL_MAIL (da Oracle 11):
Sqlplus / as sysdba
SQL> descr utl_mail
ERROR:
ORA-04043: object utl_mail does not exist
• Se ottenete questo messaggio di errore, è necessario installare il package di sistema utl_mail e darne i diritti di esecuzione
all’utente . Sempre come utente SYS, eseguire lo script di installazione del package utl mail presente nella sottodirectory
rdbms/admin della Oracle Home, e dare i permessi di esecuzione all’utente ETL.
• Quindi bisogna verificare che sia valorizzata l’informazione del server smtp nei parametri di inizializzazione di Oracle; nell’esempio
seguente non è valorizzata e si indica come farlo. Ecco la sequenza di istruzioni per fare queste verifiche (ricordatevi di sostituire il
path del file utlmail.sql con il path relativo alla vostra installazione Oracle):

17. Configurazione del sistema (2)
D:>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Wed Jun 25 15:35:49 2014
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning option
SQL> @...RDBMSADMINutlmail.sql
SQL> @...RDBMSADMINprvtmail.plb
Package created.
Synonym created.
SQL> grant execute on UTL_MAIL to <utente ETL>;
Grant succeeded.
SQL> sho parameters smtp
NAME TYPE VALUE
------------------------------------ ----------- -------
smtp_out_server string
SQL> alter system set smtp_out_server = <server di posta> scope=both;
System altered.

18. Configurazione del sistema (3)
• Quasi sempre, in ambienti societari con un server di posta, il value deve essere il nome , completo di dominio, del server, per es.
exch.dev.com. La direttiva scope = both rende la modifica immediatamente attiva e permanente.
• Bisogna inoltre creare e configurare una ACL (a partire da Oracle11) utilizzando il package di sistema dbms_network_acl_admin. Le
ACL (Access Control List) sono solo un modo per definire delle risorse esterne al RDBMS (come il server di posta elettronica) e
consentirne l’accesso agli utenti.
• Ora accedete a slideshare[http://www.slideshare.net/jackbim/note-di-data-warehouse-e-business-intelligence-il-sistema-di-
messaggistica-2] in cui troverete le indicazioni di come scaricare e lanciare lo script di installazione di questo sistema. Lo script
eseguirà per voi tutte le impostazioni necessarie.
• Il tutto richiederà non più di 5 minuti di lavoro.

19. Test
• Oltre ai test mostrati nelle slide di slideshare, eseguiamo ora un altro test, sicuramente più esaustivo, che mostra chiaramente la
funzionalità dei messaggi simulando un pezzo di caricamento ETL. Iniziamo creando una tabella di test, inizializzandola da una
tabella di sistema. A questo punto mandiamo in esecuzione un blocco anonymous di codice (si definisce blocco anonimo l’insieme
degli statement SQL compresi fra una begin e una end) che simulerà un caricamento reale di una tabella con delete e insert dei
dati. La sequenza di step è abbastanza semplice: si inizializzano le variabili globali di package per identificare meglio i vari passaggi
nella tabella di messaggistica.
create table SALES as select * from tabs;
begin
mef.pv_sched_cod := 'Daily';
mef.pv_job_cod := 'Staging tables';
mef.pv_unit_cod := 'Load sales table';
mef.pv_exec_cnt := 10;
mef.p_send('proc_prova','Load of SALES table');
mef.p_send('proc_prova','Deleting...');
delete from sales;
mef.p_send('proc_prova','Deleted');
mef.p_send('proc_prova','Loading...');
insert into sales select * from tabs;
mef.p_send('proc_prova','Loaded');
mef.p_mail('MEF','ETL_administrator','Sales table loaded');
mef.p_send('proc_prova','Load ended');
end;
/
• Il risultato finale ottenuto, che si può vedere nella tabella MEF_MSG_LOT, è molto interessante, e fornisce quella ricchezza di
informazioni contestuali di cui si parlava all’inizio.

20. Conclusione
• Abbiamo visto in dettaglio i passaggi necessari per poter costruire un sistema di messaggistica, semplice, ma utilissimo, per chi
lavora nel campo della progettazione dei Data Warehouse.
• Questa implementazione, che è alla base della Micro-ETL Foundation, funziona ovviamente su qualunque processo Oracle-PL/SQL
oriented, non è invasiva, e si può applicare in qualunque momento inserendo delle semplici chiamate di procedure in un processo
ETL già esistente.