POLITECNICO DI TORINO
Facoltà di Ingegneria dell’Informazione
Corso di Laurea Specialistica in Ingegneria Informatica
Tesi di Laurea Specialistica
Enterprise Application Integration
Studio e realizzazione di una soluzione di Data Integrity in
un’architettura di integrazione software
Relatore:
prof. Fulvio Corno
Candidato:
Ivo Gianluca Vitiello
Anno accademico 2008-2009
II
Indice
Introduzione
1
1 EAI - Enterprise Application Integration
11
1.1
Panoramica sulle EAI . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2
I livelli di integrazione . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3
1.2.1
Il livello dato . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.2
Il livello applicazione . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.3
Il livello metodo . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.4
Il livello interfaccia utente . . . . . . . . . . . . . . . . . . . . 20
Tecnologie middleware . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.1
RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.2
Message Oriented Middleware . . . . . . . . . . . . . . . . . . 22
1.3.3
Gli oggetti distribuiti . . . . . . . . . . . . . . . . . . . . . . . 23
1.3.4
Database oriented . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.4
Metodologie per l’implementazione . . . . . . . . . . . . . . . . . . . 24
1.5
Potenziali criticità
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.5.1
Problemi nel processo di integrazione . . . . . . . . . . . . . . 31
1.5.2
Dati non allineati . . . . . . . . . . . . . . . . . . . . . . . . . 32
2 Il Data Integrity in un’architettura EAI
35
2.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2
Fasi per la realizzazione di un’applicazione di Data Integrity . . . . . 39
2.2.1
Analizzare le entità di business dell’azienda . . . . . . . . . . . 40
2.2.2
Analizzare il contesto operativo ed i sistemi informativi . . . . 40
III
2.3
2.4
2.2.3
Analizzare gli aspetti fisici di memorizzazione . . . . . . . . . 41
2.2.4
Effettuare transcodifiche sui campi . . . . . . . . . . . . . . . 45
2.2.5
Implementare le politiche di confronto sui dati . . . . . . . . . 47
2.2.6
Valutare le performance . . . . . . . . . . . . . . . . . . . . . 52
2.2.7
Visualizzare i risultati . . . . . . . . . . . . . . . . . . . . . . 53
2.2.8
Analizzare possibili processi di riallineamento . . . . . . . . . 53
2.2.9
Monitoraggio e test continui . . . . . . . . . . . . . . . . . . . 54
Vantaggi e svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.3.1
Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.3.2
Svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Un caso reale: introduzione ad un progetto di Data Integrity . . . . . 57
3 IBM Datastage: uno strumento di elaborazione dati
59
3.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.2
I componenti principali . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3
L’applicazione Designer . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4
Server job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.5
3.4.1
Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4.2
Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Job sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.5.1
Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.5.2
Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.6
L’applicazione Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.7
L’applicazione Director . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4 Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
77
4.1
I sistemi controllati . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.2
Descrizione del progetto . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3
Il database delle repliche e degli esiti . . . . . . . . . . . . . . . . . . 88
4.4
Le procedure e funzioni PL/SQL . . . . . . . . . . . . . . . . . . . . 91
4.4.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
IV
4.5
4.4.2
Aggiornamento dati . . . . . . . . . . . . . . . . . . . . . . . . 91
4.4.3
Controllo coerenza dati . . . . . . . . . . . . . . . . . . . . . . 93
Server job e job sequence Datastage . . . . . . . . . . . . . . . . . . . 97
4.5.1
I job di caricamento . . . . . . . . . . . . . . . . . . . . . . . 100
4.5.2
I job per richiamare l’aggiornamento dei dati . . . . . . . . . . 102
4.5.3
I job per richiamare gli algoritmi di confronto . . . . . . . . . 104
4.6
Interfaccia utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.7
Generazione report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.8
Interazione con l’ambiente di schedulazione . . . . . . . . . . . . . . . 110
5 Valutazioni del progetto di Data Integrity realizzato in azienda
111
5.1
Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.2
Riscontri numerici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.3
Considerazioni finali . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.4
Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Conclusioni
121
Allegato A
127
Glossario
139
Bibliografia
141
Sitografia
143
V
Elenco delle figure
1
EAI: esempio di architettura . . . . . . . . . . . . . . . . . . . . . . .
5
1.1
EAI: esempio di architettura per il livello dato . . . . . . . . . . . . . 15
1.2
EAI: esempio di architettura per il livello applicazione . . . . . . . . . 16
1.3
EAI: esempio di architettura per il livello metodo . . . . . . . . . . . 19
1.4
EAI: possibile problema di Data Integrity nell’architettura EAI
2.1
Data Integrity: esempio di applicazione di controllo dati in un’archi-
. . . 33
tettura EAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2
Data Integrity: esempi di transcodifiche sui dati (1) . . . . . . . . . . 45
2.3
Data Integrity: esempi di transcodifiche sui dati (2) . . . . . . . . . . 46
2.4
Data Integrity: esempi di dati assenti . . . . . . . . . . . . . . . . . . 48
2.5
Data Integrity: esempi di dati differenti . . . . . . . . . . . . . . . . . 50
3.1
Datastage: screenshot Designer . . . . . . . . . . . . . . . . . . . . . 64
3.2
Datastage: tipologie di stage Database . . . . . . . . . . . . . . . . . 66
3.3
Datastage: screenshot server job . . . . . . . . . . . . . . . . . . . . . 68
3.4
Datastage: screenshot job sequence . . . . . . . . . . . . . . . . . . . 71
3.5
Datastage: screenshot Director . . . . . . . . . . . . . . . . . . . . . . 75
4.1
Progetto Data Integrity: caricamento sistemi sul database centralizzato 83
4.2
Progetto Data Integrity: esecuzione degli algoritmi di aggiornamento
- controllo dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.3
Progetto Data Integrity: strumenti di monitoraggio . . . . . . . . . . 87
4.4
Progetto Data Integrity: database delle repliche e degli esiti . . . . . 88
VI
4.5
Progetto Data Integrity: la parte di progetto sviluppata su Datastage 97
4.6
Progetto Data Integrity: tipologie job Datastage . . . . . . . . . . . . 99
4.7
Progetto Data Integrity: server job / job sequence per il caricamento
dati
4.8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Progetto Data Integrity: server job per richiamare l’aggiornamento
dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.9
Progetto Data Integrity: server job per richiamare il confronto di
un’entità tra due sistemi . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.10 Progetto Data Integrity: applicazione WEB per la visualizzazione
degli esiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.11 Progetto Data Integrity: esempio di report contenente gli esiti dei
controlli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.1
Progetto Data Integrity: calendario controlli . . . . . . . . . . . . . . 112
5.2
Progetto Data Integrity: riepiloghi controlli contratti - annunci SAPSEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.3
Progetto Data Integrity: riepiloghi controlli contratti - annunci SAPTCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
VII
Introduzione
La presente dissertazione ha come obiettivo principale la definizione e la descrizione di una possibile soluzione del problema di Data Integrity all’interno di un
contesto di integrazione dei sistemi informativi di un’azienda o di un’organizzazione.
In un’architettura di integrazione il Data Integrity fa riferimento all’integrità delle
informazioni che sono distribuite su più basi dati e che devono essere congruenti tra
loro.
Negli ultimi anni, l’esigenza di scambiare informazioni tra i sistemi è diventata una
questione delicata sempre più rilevante. Per questa ragione è in continua crescita
il numero di dati distribuiti tra applicazioni diverse. Per mantenere le informazioni distribuite le aziende stanno ricorrendo con maggior frequenza ad architetture
di integrazione EAI, ovvero a delle applicazioni specifiche il cui compito è la realizzazione di canali di comunicazione per condividere dati e processi di business.
Un’applicazione di Data Integrity si colloca in questo contesto come un’applicazione
EAI rivolta a verificare l’allineamento dei dati condivisi all’interno dell’infrastruttura di integrazione.
La tesi vuole mettere in evidenza perché è importante realizzare una procedura che
implementi dei controlli di Data Integrity sulle basi dati distribuite, definendo in
modo puntuale quali sono i passi fondamentali per una possibile realizzazione. I
risultati prodotti dalle verifiche sulle basi dati potranno essere utilizzati per monitorare e correggere le operazioni svolte dalle altre applicazioni EAI presenti in
un’azienda. Risulta evidente che il problema di Data Integrity rientra tra i requisiti
che le applicazioni EAI devono possedere per gestire con successo l’infrastruttura di
integrazione.
1
Introduzione
In questo elaborato verranno descritte brevemente che cosa sono le EAI, giustificando quali sono i motivi che spingono ad avere un’applicazione che si occupa
di operazioni di Data Integrity, intesa come strumento di verifica di funzionamento
dell’infrastruttura d’integrazione stessa.
Per fornire a questi aspetti teorici un contesto più applicativo sarà illustrato il progetto di controllo di Data Integrity, realmente implementato e su cui ho lavorato,
realizzato presso un’azienda operante nel settore pubblicità in collaborazione con il
team di Reply, società di ICT che lavora sull’architettura EAI di tale azienda.
Il termine EAI rappresenta l’acronimo di Enterprise Application Integration, con
il quale si intende la realizzazione di un’architettura software, di tipo middleware,
dedicata all’integrazione dei sistemi informativi di un’azienda o di un gruppo di
aziende. Il termine Data Integrity, in questo contesto di integrazione, viene assunto
con il significato di garanzia di allineamento e coerenza dei dati distribuiti, memorizzati sui diversi sistemi coinvolti nel processo di integrazione. La creazione di
un’applicazione di Data Integrity viene fatta con l’intento di realizzare uno strumento di controllo di congruenza delle informazioni presenti nelle applicazioni che
costituiscono il sistema informativo complessivo di un’azienda.
L’esigenza di avere un controllo di coerenza sui dati si riscontra soprattutto in aziende di dimensioni medio grandi all’interno delle quali coabitano diverse applicazioni,
quest’ultime utilizzate per formare un’infrastruttura IT complessa ed articolata. Generalmente, in questi contesti, il patrimonio informativo prevede una suddivisione
in vari applicativi differenti con propri database interni e distinti. Ciò avviene per
ragioni tecniche, di gestione ed anche per ragioni storiche. Ad esempio, in certe
realtà come banche ed assicurazioni, sono presenti ancora vecchi sistemi mainframe
e nel frattempo è stata sviluppata una serie di nuove applicazioni, utilizzando le
tecnologie più moderne, che devono interagire con questi sistemi più datati: da qui
la necessità di convivenza di applicazioni diverse.
La suddivisione in applicativi differenti può implicare l’utilizzo di sistemi operativi e
piattaforme tra loro incompatibili, creando di fatto delle “isole di automazione” non
comunicanti. Molto spesso, però, queste applicazioni non possono rimanere isolate.
Capita sovente di riscontrare la necessità di fare comunicare un sistema con un altro
2
Introduzione
per condividere, ad esempio, delle informazioni comuni o delle regole di business. È
evidente che ci si trova di fronte ad un problema di interoperabilità tra le applicazioni. Tale problema può essere risolto tramite un’architettura EAI, sviluppando parti
di software che si occupano di creare dei canali di comunicazione tra le applicazioni
esistenti, senza dover stravolgere la situazione attuale.
La prima parte della tesi, nello specifico il primo capitolo, ha lo scopo di introdurre e definire gli aspetti generali di un’architettura EAI. Verranno descritte
solo le caratteristiche principali e si cercherà di motivare perché le aziende ricorrono a questo tipo di approccio, senza però scendere nei dettagli troppo tecnici i
quali sono variabili a seconda del problema di integrazione. L’obiettivo di questo
primo capitolo è di definire il contesto in cui si può riscontrare l’esigenza di controllo dei dati su sistemi eterogenei e ricorrere ad implementazioni di meccanismi
di Data Integrity. Come già anticipato in precedenza, realizzare applicazioni EAI
significa ottenere un’integrazione dei dati, dei processi o delle interfacce tra i sistemi
informativi presenti ed utilizzati da un’azienda. Tale processo di integrazione può
essere di fatto realizzato su vari livelli, in base alle necessità aziendali. Tali livelli di integrazione saranno brevemente illustrati, evidenziandone le motivazioni e le
loro principali caratteristiche. L’intento è di mettere in evidenza i benefici che si
possono ottenere puntando su architetture di questo genere. Per contro, visto che
per creare delle architetture di integrazione è necessario realizzare del software che
metta in comunicazione i vari sistemi tra loro disomogenei, lo sviluppo di tali applicazioni presenta delle difficoltà di analisi e di realizzazione non di poco conto. La
prima criticità che si incontra nell’implementare applicazioni EAI è data dalla sua
collocazione all’interno dell’infrastruttura dei sistemi informativi di un’azienda. Più
precisamente le applicazioni EAI generalmente si pongono al centro dell’infrastruttura informativa, in modo del tutto analogo alla presenza di un HUB o SWITCH
utilizzati per realizzare una rete locale di computer. Come un HUB, tramite i cavi di
rete, fa comunicare i diversi computer ad esso collegati, l’architettura EAI si occupa
di mettere in comunicazione tutte le applicazioni che necessitano un continuo e duraturo passaggio di informazioni. Un esempio di questa situazione è riportata nella
figura 1 dove sono presenti tre sistemi che condividono la stessa entità Contratti e
3
Introduzione
necessitano di un’architettura EAI per poter propagare le informazioni aggiornate
da un sistema verso gli altri, in modo da mantenere l’allineamento delle informazioni distribuite. Questa sua collocazione, al centro dell’infrastruttura informativa,
da una parte potrà essere un punto di criticità, infatti, se non funzionerà l’architettura EAI le varie applicazioni non riusciranno a scambiarsi i dati e verrà meno lo
strumento di comunicazione. Dall’altro canto la sua posizione potrà rappresentare
un punto di forza, perché ponendosi al centro sarà più facile realizzare procedure
di controllo e di monitoraggio. Lavorando a livello centralizzato sarà più semplice
sfruttare e riutilizzare le parti già fatte per eventuali realizzazioni future. Da quanto
detto l’EAI dovrà necessariamente interagire con i diversi sistemi e sarà fondamentale avere la conoscenza dei processi di business e delle varie entità in gioco presenti
nell’azienda.
Possiamo ancora citare questo particolare sulle EAI: tale architettura potrà essere
utilizzata per evitare la situazione in cui ogni coppia di sistemi, per mettere in atto
la comunicazione utile per i fini già descritti, vada a crearsi un canale differenziato personalizzato a proprio uso e consumo. Adottando una modalità del genere
si rischierebbe di creare un numero via via sempre più elevato di questi canali.
L’eccessivo aumento di quest’ultimi potrebbe portare ad una situazione ingestibile
dell’intero sistema informativo e diventerebbe davvero difficile capire e comprendere
eventuali errori e problemi. Quindi, una soluzione EAI vuole mettere a disposizione
degli strumenti di comunicazione più semplici e generali rispetto ad altri approcci.
Questa breve introduzione sull’architettura EAI servirà successivamente, nel seguito della tesi, a comprendere l’importanza del problema di un’applicazione di Data
Integrity in un contesto del genere. Considerato che la realizzazione di un’architettura di integrazione è una fase molto delicata e critica, può risultare utile adottare
strumenti di verifica di allineamento di queste informazioni condivise. Infatti, a seguito di un errore nello sviluppo e nell’esecuzione delle applicazioni dell’architettura
EAI, corrisponderà molto probabilmente all’introduzione di disallineamenti sui dati
distribuiti. Di conseguenza è molto importante avere uno strumento che verifichi
l’integrità dei dati condivisi e scambiati tra le applicazioni in un contesto di integrazione.
4
Introduzione
Applicazione 1
Sull’applicazione 1 viene modificato il contratto avente il
codice 1234
1
Database
1
Tramite
un’applicazione
presente
nell’architettura EAI
viene prelevato il
dato modificato e
questo dovrà essere
comunicato agli altri
sistemi che
possiedono la stessa
entità
Applicazione 2
Tabella
Contratti
2
Database
2
Architettura EAI
Tabella
Contratti
Tabella
Contratti
Viene comunicato agli altri sistemi il dato
aggiornato del contratto con il codice 1234
modificato dall’applicazione 1
3
Database
3
L’entità contratto è distribuita su
tre database distinti su cui
fanno accesso
altrettante applicazioni.
Applicazione 3
Figura 1. EAI: esempio di architettura
5
Introduzione
Lo sviluppo di un’applicazione di Data Integrity sarà ampiamente descritto nel secondo capitolo dove saranno evidenziate le motivazioni ed i casi in cui potrà essere
utile implementarla. L’intento del secondo capitolo è di illustrare come un’applicazione di Data Integrity possa essere effettivamente uno strumento concreto di
controllo per mantenere l’allineamento dei dati. Verranno forniti i dettagli di come
è possibile affrontare l’analisi per effettuare una buona implementazione, partendo
dall’analisi generale del sistema fino al momento di definire le specifiche informazioni
sui campi da verificare.
Per dare un aspetto pratico al tema del Data Integrity, nel contesto delle EAI, sarà illustrato il progetto di controllo allineamento dati implementato in un’azienda
pubblicitaria. Introducendo brevemente quello che sarà poi descritto con maggiore
dettaglio nel quarto capitolo, in questa azienda è presente un’architettura EAI che
ricopre un ruolo chiave nel processo di comunicazione tra i sistemi. Questi sistemi
sono composti generalmente da una parte di front-end e back-end. L’obiettivo di una
soluzione di Data Integrity, in questo contesto, è di occuparsi di garantire la coerenza
dei vari back-end lavorando parallelamente alle altre applicazioni dell’architettura
EAI già presenti. I back-end sono i possessori fisici delle informazioni utilizzate dalle
applicazioni, ovvero i front-end, i quali devono essere supportati dalla garanzia di
qualità e congruenza dei dati per poter funzionare bene.
Le informazioni che possiamo definire come gli oggetti del core business di quest’azienda sono principalmente i contratti con i relativi annunci, le campagne pubblicitarie ed i dati associati ai clienti. Queste informazioni sono memorizzate in modo
distribuito su più database, i quali, sovente, sono gestiti da gruppi di lavoro diversi.
Dalla situazione appena descritta, nasce l’esigenza di mettere in comunicazione i vari
sistemi per mantenere allineati i dati distribuiti. Di conseguenza, si avrà la tabella
associata all’entità contratto definita su più database, ogni applicazione attingerà
alla propria tabella prendendo i campi di interesse, in modo analogo a quanto rappresentato nella figura 1. Se le informazioni tra le tabelle di una stessa entità, ad
esempio il contratto, non saranno allineate le applicazioni che vi accederanno potranno andare in errore.
L’architettura EAI implementata ha richiesto e richiede tuttora la collaborazione di
6
Introduzione
tanti attori che devono cooperare per il raggiungimento del fine comune. A maggiore
ragione in questo momento in cui sta avvenendo un aggiornamento di alcuni sistemi informativi. Le applicazioni CRM, contabili ed amministrative sono in una fase
di migrazione da un’applicazione personalizzata, chiamata CLIC verso il pacchetto
software SAP. Questa situazione porta con sé tutte le problematiche di allineamento
dati con il sistema CLIC e la modifica delle procedure di integrazione con i sistemi
che non sono stati sostituiti con l’avvento di SAP.
La situazione attuale può, quindi, presentare delle forti criticità in caso di differenze
nei dati. Infatti, nel caso in cui si verifichino delle anomalie o ci siano degli errori
nel passaggio di queste informazioni, il rischio principale sarà di causare disallineamenti di dati, generando incongruenze tra le informazioni memorizzate sui diversi
back-end che costituiscono la nuova infrastruttura informativa. Le differenze che
si possono generare sui dati sono molto pericolose in quanto, come già accennato,
le applicazioni potrebbero non funzionare correttamente oppure lavorando su dati
incoerenti o non aggiornati, potrebbero portare ad errori nel processo produttivo
e nella fornitura dei prodotti da parte dell’azienda stessa. Ad esempio, prendendo
come riferimento l’azienda analizzata in questo caso di studio, possiamo illustrare
una tipologia di criticità in cui è possibile incorrere se le informazioni della stessa
inserzione pubblicitaria presenti nei database di due sistemi aziendali fossero differenti tra loro. In un caso del genere potrebbe accadere di emettere la fattura ad un
cliente, dal sistema gestionale, per un annuncio il quale, per problemi di aggiornamento dati, potrebbe non essere lo stesso di quello in realtà pubblicato e presente
sul sistema dedicato alla produzione. O ancor peggio, nel caso in cui le informazioni dell’inserzione presenti sul sistema gestionale non riuscissero ad arrivare, sempre
per problemi di integrazione EAI, al sistema di produzione: in questa situazione
l’annuncio non verrebbe pubblicato, creando un disservizio perché non averebbe la
fornitura richiesta dal cliente. In definitiva, più le informazioni tra le diverse basi
dati risulteranno allineate meno anomalie dovranno essere gestite. Un’applicazione
che svolge operazioni di Data Integrity sarà utile proprio per questo motivo: permetterà di individuare rapidamente le differenze sui dati e di decidere, il prima possibile,
come operare per effettuare il riallineamento dei dati.
7
Introduzione
La realizzazione di un’applicazione di Data Integrity dovrà avvalersi di strumenti molto potenti e flessibili che possano adattarsi alle diverse situazioni e che
permettano un accesso facile ai dati, visto che il dato inteso come informazione presente nei campi delle tabelle, in questo contesto, è al centro dell’attenzione e deve
essere salvaguardato. Per la realizzazione del progetto Data Integrity nell’azienda
pubblicitaria, citata nel caso di studio, è stato utilizzato un software di IBM, Datastage, uno strumento molto potente di ETL utilizzato per estrarre, trasformare
e caricare dati tra sistemi eterogenei. IBM Datastage è uno dei possibili strumenti
per poter estrapolare i dati tra i sistemi, considerando che sul mercato sono presenti
altri prodotti. Visto che in questa tesi è presente la descrizione di un progetto di
Data Integrity dove è stato utilizzato Datastage sarà necessario fornire al lettore un
introduzione minima su questo strumento. L’obiettivo del terzo capitolo sarà proprio di descrivere le funzionalità principali di Datastage, illustrando come è possibile
impostare le operazioni di prelievo dati da database differenti.
Nel quarto capitolo si procederà a definire i punti chiave dell’applicazione di Data
Integrity realizzata, giustificando gli sforzi compiuti per l’analisi, l’implementazione ed i test. Posso affermare che l’applicazione di Data Integrity realizzata viene
utilizzata per controllare, in determinati giorni, gli allineamenti di sei sistemi che si
scambiano i dati tramite l’utilizzo dell’architettura EAI. I risultati forniti dall’applicazione di Data Integrity sono serviti e servono ancora oggi per localizzare gli
eventuali errori nella comunicazione delle informazioni tra i sistemi, permettendo di
analizzare la distribuzione dei disallineamenti e di valutare le operazioni di modifica
delle applicazioni EAI che realizzano l’architettura di integrazione.
Posso anticipare che nel processo di controllo si sono verificate due tipologie di anomalie: i dati assenti e quelli differenti. Come dati assenti intenderemo un record
di un entità monitorata, come ad esempio un contratto, che è presente in un sistema e non nell’altro, mentre per dati differenti intenderemo un record, sempre di
un’entità, che è presente su entrambi i sistemi ma che differisce su alcuni campi che
sono oggetto di controllo. L’operazione di correzione dei dati dovrà tenere conto
della tipologia di anomalia riscontrata ed attivare la funzione di riallineamento più
appropriata.
8
Introduzione
La tesi terminerà con l’analisi dei risultati ottenuti tramite l’utilizzo dell’applicazione di Data Integrity realizzata e dei possibili sviluppi futuri che potranno essere
implementati su tale applicazione.
9
Capitolo 1
EAI - Enterprise Application
Integration
1.1
Panoramica sulle EAI
Lo scopo di questo capitolo è di fornire un’introduzione sulle EAI, definendo
l’ambito in cui tale architettura può essere applicata ed utilizzata. Con il termine
EAI è possibile intendere lo sviluppo di una serie di applicazioni software il cui
obiettivo principale è la creazione di un’architettura per l’integrazione dei sistemi
informativi vecchi e nuovi di un’azienda.
Perché è necessario raggiungere un’integrazione? Per capire meglio i motivi che
spingono a raggiungere quest’obiettivo è importante fornire una panoramica della
situazione attuale che si riscontra nella complessa architettura dei sistemi informativi di molte aziende ed organizzazioni. Al giorno d’oggi molte aziende, soprattutto
quelle medio grandi, si ritrovano con tante applicazioni differenti, come ad esempio
sistemi CRM, applicazioni di contabilità, gestione vendite ecc., le quali non possono
interagire tra di loro, trovandosi in una evidente assenza di comunicazione. Una
prima causa dell’assenza di tali collegamenti può essere dovuta al fatto che queste applicazioni sono state scritte con linguaggi di programmazione differenti per
determinati sistemi operativi, creando di conseguenza il classico problema di interoperabilità. Inoltre si sono venute a creare situazioni in cui le aziende hanno fatto
11
1 – EAI - Enterprise Application Integration
sviluppare le loro applicazioni, investendo anche molti capitali, senza pensare minimamente al problema dell’integrazione. Infatti, il loro obiettivo principale è stato
(ed in certi casi lo è ancora) di avere un’applicazione personalizzata creata nel più
breve tempo possibile, utilizzando anche la tecnologia più in voga in quel momento,
senza considerare, però, la problematica di come questa possa integrarsi, scambiando
informazioni con i sistemi e le architetture già funzionanti. Utilizzando un approccio
del genere è evidente il rischio di duplicare delle funzionalità già presenti e collaudate
che, tramite un intervento di integrazione, potrebbero invece essere riutilizzate, con
la conseguente razionalizzazione di tempo e di denaro.
In aggiunta a quanto appena descritto, sono presenti, soprattutto in grosse organizzazioni come banche ed assicurazioni, applicazioni che funzionano ancora su sistemi
mainframe che per problemi di costi di porting su nuove piattaforme si preferisce mantenere piuttosto che dismettere e riscrivere da zero. Anche in questo caso
è necessario prevedere dei meccanismi di comunicazione con le nuove applicazioni
sviluppate, le quali, molto probabilmente, avranno necessità di attingere ad informazioni memorizzate su tali sistemi mainframe.
In questo contesto così eterogeneo è fondamentale studiare ed implementare delle
soluzioni per realizzare architetture di integrazione. Infatti, se alle applicazioni venisse fornito un canale di comunicazione queste potrebbero predisporre, ad esempio,
di una condivisione di dati e potrebbero definire delle regole di business comuni.
Invece, utilizzando dei sistemi isolati, il rischio a cui si può andare incontro è di
avere dell’inefficienze ed anomalie, come ad esempio l’eccessiva ridondanza dei dati
replicati sui database delle varie applicazioni e l’impossibilità di creare delle semplici
automazioni di processo per mezzo di regole di business comuni. Non a caso alle
singole applicazioni che non prevedono un’integrazione con l’architettura generale
di un’organizzazione viene attribuito il termine di “isola di automazione”, vista la
loro chiusura rispetto all’architettura informativa complessiva.
Una possibile modalità per realizzare l’integrazione tra i sistemi è di adottare
un’architettura orientata alle EAI. Dunque è facile capire il ruolo importante che
può svolgere e le responsabilità che deve assumersi un’architettura EAI, la quale
può “mettere in comunicazione” queste applicazioni così differenti, con l’obiettivo
12
1.2 – I livelli di integrazione
principale di semplificare ed automatizzare i processi di business. Ovviamente per
essere considerata una buona soluzione EAI questa, se implementata, dovrà rispettare le caratteristiche di flessibilità e di apertura a possibili future estensioni. In
caso contrario, si potrebbe incorrere in un fallimento dell’architettura stessa, con
l’inutile spreco di tempo e denaro.
Negli ultimi decenni l’interesse nel ricorrere alle architetture di tipo EAI è stato
sempre più forte e guidato da diversi fattori, come ad esempio la forte pressione
dell’ambiente competitivo del mercato che ha obbligato di fatto ad accorciare sempre di più i tempi di sviluppo dell’applicazioni e la prudenza del settore finanziario
che costringe ad utilizzare le applicazioni esistenti piuttosto che crearne di nuove,
evitando perciò i rischi di investimenti di lungo periodo. È evidente che la possibilità di continuare ad utilizzare le applicazioni già esistenti e funzionanti può portare
ad un importante risparmio di denaro, un fattore questo che viene tenuto molto in
considerazione dai manager dell’aziende.
Uno dei compiti che sicuramente dovrà svolgere un gruppo di lavoro sulle EAI
è la definizione e le modalità di implementazione di questi collegamenti tra tutti i
sistemi che necessitano lo scambio di informazioni, prevedendo, in alcune situazioni,
analisi e sviluppi di integrazione dei dati stessi.
La parte seguente intende descrivere a quali livelli è possibile realizzare un’integrazione e quali sono le caratteristiche distintive per ogni categoria.
1.2
I livelli di integrazione
La scelta di dove è possibile e necessario effettuare l’integrazione dipende molto dalle specificità e criticità della singola organizzazione. È importante effettuare
un’analisi precisa per scegliere quali sono i processi ed i dati che richiedono l’integrazione, perché la scelta di questi elementi implicherà in modo sensibile e determinante
il livello di dove intervenire per realizzare la soluzione EAI.
È possibile definire quattro grandi categorie differenti di integrazione:
• il livello dato
• il livello applicazione
13
1 – EAI - Enterprise Application Integration
• il livello metodo
• il livello interfaccia utente
1.2.1
Il livello dato
Si tratta dell’implementazione dei processi, tecniche e tecnologie per spostare
direttamente i dati tra i differenti database presenti, così come indicato nell’esempio di figura 1.1. L’integrazione dei dati può essere definita come un’operazione di
estrazione di un’informazione da un database, la modifica e aggiornamento se necessari, e la copia di questa su di un altro database. Operando a questo livello la
logica delle applicazioni rimarrà invariata. È probabile che durante il processo di
trasporto dell’informazione da un database ad un altro siano presenti delle attività
di trasformazione e di applicazione di logiche di business sul dato stesso.
Uno dei vantaggi più significativi nell’adottare una soluzione EAI a livello di dato è
sicuramente il costo. Infatti, le applicazioni, visto la loro situazione di isolamento,
non necessitano di modifiche del loro codice sorgente. Si risparmiano così tutti i
costi di modifiche, testing e messa in produzione di un’applicazione da aggiornare.
Inoltre, le tecnologie che consentono di spostare i dati tra i diversi database sono
relativamente più economiche rispetto alle tecnologie necessarie per implementare
architetture EAI agli altri livelli.
Per contro, il fatto che le applicazioni siano indipendenti rappresenta allo stesso
tempo uno svantaggio. Per realizzare l’integrazione a livello di dato vengono escluse
tutte le logiche delle applicazioni e si effettuano estrazioni e caricamenti dei dati
utilizzando l’interfaccia nativa del database. Quest’ultimo aspetto implica diverse
problematiche e richiede di ottenere le autorizzazioni necessarie di accesso ai dati
dalle persone che li gestiscono. È importante anche considerare come sono strettamente accoppiati i dati con la logica dell’applicazioni. Spostare i dati tra i diversi
database senza comprendere la logica di funzionamento dell’intera architettura potrebbe risultare un manovra pericolosa, portando a inserire informazioni errate e
causando disallineamenti tra i sistemi.
14
1.2 – I livelli di integrazione
Interfaccia
utente
Interfaccia
utente
Logica applicativa
Logica applicativa
Database
Processi di
trasformazione
formattazione
dati
Database
Figura 1.1. EAI: esempio di architettura per il livello dato
Esempio di EAI livello dato
Un’azienda manifatturiera ha la necessità di integrare il suo sistema di controllo
della produzione con il proprio applicativo ERP utilizzato per gestire la parte amministrativa. In una situazione del genere è presente la necessità di comunicare i dati
degli ordini registrati sull’applicativo ERP all’applicazione di gestione della produzione, in modo che possa essere presa in carico e gestita con strumenti meccanizzati
la lavorazione del nuovo ordine. A seguito della conferma di un ordine sul sistema
ERP questo dovrà essere inviato, tramite un’applicazione EAI di aggiornamento dati, al sistema di produzione. Per realizzare questa esigenza, tramite un’applicazione
EAI che funziona da connettore tra i sistemi, potranno essere prelevati i dati dal
database del sistema ERP ed inviati sul database dell’applicazione di controllo di
15
1 – EAI - Enterprise Application Integration
produzione, effettuando eventuali variazioni sul contenuto dei dati per rispettare
i vincoli del sistema ricevente. L’applicazione di controllo produzione si ritroverà
nei propri archivi, in maniera automatizzata, le informazioni del nuovo ordine e di
conseguenza potrà essere gestito, senza doverlo ricaricare in maniera manuale.
1.2.2
Il livello applicazione
Applicazioni
Interfacce
Database
Logica applicativa
Middleware
Figura 1.2. EAI: esempio di architettura per il livello applicazione
L’integrazione EAI a livello applicazione ha lo scopo di attivare delle interfacce
comuni disponibili e richiamabili. Tramite l’utilizzo di queste interfacce sarà possibile mettere insieme più applicazioni, con l’opportunità di condividere la logica
di business e le informazioni. Il problema più grande che bisogna affrontare nelle
situazioni reali è proprio la definizione di queste interfacce comuni. Nella figura 1.2
16
1.2 – I livelli di integrazione
è riportato un possibile schema di integrazione EAI a livello applicazione.
Questa tipologia di EAI è molto spesso implementata in situazioni in cui sono presenti applicazioni come SAP e similari, dove tali sistemi espongono interfacce per i
loro processi ed i loro dati. Quindi, per integrare questi sistemi con gli altri, che fanno parte dell’infrastruttura informativa dell’organizzazione, è necessario utilizzare e
richiamare queste interfacce. Così facendo sarà possibile accedere ai processi ed ai
dati, estrarre le informazioni di cui si ha bisogno, trasformarle in formato comprensibile al sistema destinatario ed infine inviargliele.
Abbiamo parlato di interfacce a livello di applicazione, ma a cosa servono? Sono
interfacce che gli sviluppatori espongono da un’applicazione per fornire l’accesso ai
dati oppure per l’utilizzo di certi servizi presenti sull’applicazione stessa. Alcune
serviranno per accedere ai processi di business, altre per accedere direttamente ai
dati, altre ancora che permetteranno di fare entrambe le cose.
Perché utilizzarle? Un motivo importante è dato dal fatto che in questo modo viene
fornito un accesso ai processi di business ed ai dati utilizzando delle funzionalità
presenti ed incapsulate all’interno dell’applicazione che le detiene, evitando in questo modo l’accesso diretto al database per ottenere l’informazione necessaria, come
accade in una soluzione di integrazione a livello dato.
Per concludere, è possibile dire che questo approccio rappresenta il miglior modo di
integrare le applicazioni consentendo di invocare facilmente logiche di business, con
l’intenzione di preservare l’integrità dei dati. Ovviamente questi metodi richiamabili
dovranno offrire garanzie di qualità di funzionamento. In alcuni casi, data l’elevata
complessità nella creazione e manutenzione di queste procedure, la verifica di correttezza dati effettuata tramite un’applicazione di Data Integrity permetterebbe di
rilevare eventuali errori di implementazione e di apportare le opportune modifiche
correttive.
Esempio di EAI livello applicazione
Una compagnia assicurativa ha la necessità di integrare due sistemi: un sistema
ERP che è stato adottato recentemente per la gestione delle polizze assicurative ed
un sistema mainframe, presente da più tempo, che permette la gestione delle stesse
17
1 – EAI - Enterprise Application Integration
polizze. Il sistema mainframe invece di essere sostituito dal nuovo applicativo ERP
viene mantenuto in parallelo. Questo perché si è deciso che certe funzionalità per
la gestione della polizza assicurativa verranno richiamate dal sistema ERP ed altre
dal sistema mainframe. È evidente che a questo punto sarà necessario mantenere
allineate le informazioni condivise tra i due sistemi per non incorrere in errori e
problemi sulle applicazioni.
In questo contesto possiamo assumere che una possibile soluzione EAI a livello dato potrebbe non essere di facile implementazione per via della complessità dei vari
database coinvolti nel processo di integrazione. Di conseguenza, il punto più naturale di integrazione è a livello di interfaccia di applicazione, in modo da utilizzare
dei metodi richiamabili esternamente per eseguire l’aggiornamento dei dati. Visto
che di solito i fornitori di soluzioni ERP fornisco delle API specifiche per accedere
ai metodi ed ai dati dell’applicazione, sarà possibile creare delle applicazioni EAI,
che utilizzando tali metodi, magari esposti come Web Services, richiameranno delle
funzionalità di business o permetteranno l’aggiornamento dei dati. In modo analogo
sarà possibile progettare delle interfacce particolari da esporre alle applicazioni EAI
che permetteranno l’accesso ai sistemi mainframe. In questo caso appena descritto,
utilizzando l’integrazione a livello di interfaccia di applicazione, si potranno mantenere allineati i dati tra i sistemi senza dovere conoscere gli aspetti tecnologici delle
basi dati coinvolte.
1.2.3
Il livello metodo
In questo livello lo scopo principale è la condivisione delle logiche di business
presenti all’interno di un’organizzazione, così come illustrato nella figura 1.3. L’esempio classico per descrivere una situazione del genere è l’aggiornamento di un
record memorizzato negli archivi di un’anagrafica cliente. Quest’operazione potrebbe essere richiesta da più applicazioni le quali potrebbero utilizzare lo stesso metodo
senza doversi riscrivere una procedura specifica all’interno di ogni applicazione che
intende effettuare questa operazione.
Esistono meccanismi differenti per condividere i metodi: gli oggetti distribuiti, gli
application servers oppure attraverso la creazione di una nuova applicazione la quale
18
1.2 – I livelli di integrazione
Applicazione 1
(es. Gestione contabilità)
Oggetto 1
(es. Anagrafiche)
Applicazione 2
(es. Marketing)
Oggetto 2
(es. Magazzino)
…..
…..
Oggetto n
Applicazione n
Frameworks
Figura 1.3. EAI: esempio di architettura per il livello metodo
metta insieme le funzionalità presenti sulle applicazioni già esistenti.
Lavorando a questo livello, però, si riscontrano difficoltà maggiori rispetto al livello
applicazione. Questo fattore rappresenta una forte limitazione la quale ne riduce
l’impiego nelle situazioni reali di produzione.
Esempio di EAI livello metodo
Un esempio di EAI a livello metodo può essere rappresentato dall’unione di due
o più applicazioni per integrare funzionalità di business e dati. Supponendo che in
un’azienda siano presenti due applicazioni, una che funziona su piattaforma Linux
ed un’altra sviluppata per ambiente Windows, per effettuare un intervento EAI a
livello di metodo:
19
1 – EAI - Enterprise Application Integration
• è possibile creare una nuova applicazione che comprenda le funzionalità delle
vecchie che saranno sostituite;
• utilizzare meccanismi come gli oggetti distribuiti per consentire un facile accesso ai metodi ed a dati presenti nelle applicazioni.
1.2.4
Il livello interfaccia utente
Un approccio di questo genere intende utilizzare come punto di integrazione l’interfaccia utente delle applicazioni. Nonostante questa non sia la soluzione migliore
in termini di stabilità, si è lavorato molto sull’integrazione dell’interfacce utente,
risolvendo diversi problemi di performance, stabilità e scalabilità.
In questa tesi l’integrazione a livello di interfaccia risulta essere poco attinente
alla problematica del Data Integrity, questa tipologia è stata riportata solo per
completezza della descrizione dei livelli di integrazione.
1.3
Tecnologie middleware
Dopo avere descritto i possibili vari livelli di integrazione è importante dare una
collocazione dell’EAI all’interno del contesto architetturale di un sistema informativo. La domanda che ci si può porre potrebbe essere la seguente: “ma quali sono le
tecnologie che possono essere adottate per realizzare un’architettura EAI?”
La risposta è semplice, ma non lo è assolutamente la sua realizzazione pratica.
Un’architettura EAI, ponendosi in mezzo ai sistemi informativi che necessitano di
comunicazione, deve lavorare come uno strato middleware. Questa caratteristica
rappresenta un punto di forza e di debolezza allo stesso tempo. Infatti, se da un
lato tutto ciò che viene integrato passa all’interno dell’architettura EAI, tutto il
meccanismo è centralizzato e si ha la possibilità di semplificarne il monitoraggio.
Per contro, se qualcosa non funziona il rischio è di bloccare tutta la comunicazione
instaurata tra i sistemi. È importante prevedere meccanismi di recupero e ripristino
di situazioni in caso di errore o blocco.
Dato che lo strato software di riferimento è di tipo middleware, a questo livello
20
1.3 – Tecnologie middleware
avremo dei meccanismi che consentiranno ad entità, come un’applicazione o un database, di comunicare con un’altra o un gruppo di entità. Realizzare applicazioni
EAI significherà analizzare ed implementare soluzioni middleware, che, come abbiamo detto, rappresentano il modo migliore per muovere informazioni tra applicazioni
e database.
È necessario, però, fare molta attenzione all’implementazione visto che risultano essere presenti diverse tecnologie di tipo middleware. Alcune di esse potrebbero non
essere le migliori a risolvere in modo efficace specifiche problematiche delle EAI. Ad
esempio, i middleware di tipo punto-punto, come possono essere le RPC (remote
procedure call) possono certamente fornire punti di connessione tra le applicazioni
ed essere impiegate in un’architettura EAI. Attraverso l’utilizzo di questa tecnologia,
però, potrebbe diventare ingestibile l’architettura EAI, soprattutto nel caso in cui
si avesse un numero di collegamenti tra i sistemi elevato, perché diventerebbe più
difficile effettuare il monitoraggio e la manutenzione delle procedure di integrazione.
A differenza della tecnologia appena descritta, un’altra tipologia è basata sul concetto di gestore dei messaggi, denominato message broker. L’idea alla base è di
ridurre il numero di interfacce, posizionando il gestore dei messaggi in mezzo e di
conseguenza facilitando il controllo del suo funzionamento. Se un’applicazione dovrà
cambiare il formato, andrà modificata solo una connessione e questa all’interno del
message broker. Allo stesso modo, se una nuova applicazione dovrà essere aggiunta
al sistema di integrazione, sarà necessario solo aggiungere questa nuova connessione,
senza dovere stravolgere altri sistemi.
Da quanto appena descritto è possibile affermare che non esiste un’unica tipologia
di middleware per risolvere un problema specifico, ma risulta comunque difficile definire delle categorie ben distinte. Sicuramente ogni tipologia avrà caratteristiche
adatte a risolvere meglio determinati problemi.
Nel seguito verranno illustrate, senza scendere nei particolari, alcune tra le principali
categorie di middleware utilizzabili per un’architettura EAI:
• RPC
• Message Oriented Middleware
21
1 – EAI - Enterprise Application Integration
• Oggetti distribuiti
• Database oriented
1.3.1
RPC
Le RPC sono le remote procedure call, le quali rappresentano una possibile modalità di comunicazione con un computer remoto. La parte client ha la facoltà di
richiamare una procedura presente sul server utilizzando una semplice chiamata a
funzione. Il client si mette in attesa della risposta dal server per avere i risultati.
L’idea alla base è abbastanza semplice e la tecnologia generalmente riesce a nascondere bene le problematiche di rete. Gli svantaggi nell’optare per le RPC consistono
nel ritrovarsi in una configurazione di tipo punto-punto e nel richiedere una comunicazione sincrona che potrebbe degradare in modo significativo le performance
dell’infrastruttura EAI implementata.
1.3.2
Message Oriented Middleware
Una caratteristica importante di questa categoria è data dalla presenza di una
coda di messaggi.
I messaggi sono inviati da un’applicazione e messi in una struttura di memorizzazione di tipo coda (struttura FIFO, first input - first output). Da qui, i messaggi
potranno essere prelevati o spediti all’applicazione destinataria in un tempo successivo senza dovere bloccare necessariamente la prima che si è occupata semplicemente
di mettere a disposizione i dati sulla coda. Di conseguenza, si capisce che si tratta di
una soluzione di tipo asincrono, ben diversa dall’utilizzo delle RPC che rappresentano una modalità sincrona. Questa tipologia di soluzione, chiamata anche MOM
(Message Oriented Middleware), è utilizzata, ad esempio, quando i computer su cui
sono installate le applicazioni non sono sempre accesi. Saranno presenti dei sistemi
mittenti che invieranno i dati sulla coda e poi un’applicazione EAI, che potremmo
chiamare “integratore”, si occuperà di convertirli, se necessario, e di trasferirli al
sistema destinatario. Il trasferimento potrà essere realizzato con un invio di dati
22
1.3 – Tecnologie middleware
su un’altra coda oppure attraverso la scrittura su file system, ad esempio, con la
creazione di un file o la memorizzazione di dati in un database.
1.3.3
Gli oggetti distribuiti
Per quanto riguarda l’integrazione a livello di metodo le applicazioni sono integrate tramite la condivisione di metodi comuni.
Questi metodi possono esistere all’interno di oggetti distribuiti raggiungibili attraverso la rete. Adottando questo tipo di approccio sarà molto probabile utilizzare una
specifica tecnologia basata su ORB, basandosi su specifiche come CORBA o DCOM,
attenendosi, quindi, a degli standard ben definiti. Una caratteristica importante degli oggetti distribuiti è data dal fatto che questo approccio supporta e valorizza gli
sforzi per il riuso degli oggetti. Uno dei principali svantaggi, invece, è attribuibile
al seguente problema: l’utilizzo di queste tecnologie, ovvero degli oggetti distribuiti,
richiede forti modifiche alle applicazioni esistenti. In generale, la soluzione offre di
spostare i metodi dalle applicazioni agli oggetti distribuiti. Si tratta di un approccio
di impatto sull’architettura esistente e, per questo motivo, di difficile utilizzo in un
contesto operativo reale.
1.3.4
Database oriented
Il middleware orientato ai database è una parte necessaria in tutte le applicazioni di integrazione, specialmente per quelle che devono lavorare a livello dato. Non
fornisce solo un’accesso ai dati contenuti nel database, ma si occupa anche di mappare eventuali differenze di formato. Il middleware in questo contesto può prendere
forma di chiamata a livello di interfaccia. Infatti, può tradurre una chiamata nello
specifico dialetto del database di interesse e ritornare la risposta in un formato unico. Degli esempi per questa tipologia di middleware sono l’ODBC e JDBC. Il primo
rappresenta un livello di traduzione per i database relazionali su piattaforme Windows, mentre il secondo, JDBC, è anch’esso un livello di traduzione per i database,
ma legato al mondo Java.
23
1 – EAI - Enterprise Application Integration
1.4
Metodologie per l’implementazione
Dopo avere brevemente descritto quali sono alcune delle possibili tecnologie per
l’implementazione dell’architettura EAI, in questa sezione si discuterà sull’esistenza
o meno di una metodologia da seguire per la realizzazione di tali architetture di
integrazione.
Possiamo subito dire che una metodologia comune per realizzare architetture EAI
non esiste, nonostante da diversi anni si parli di EAI e molti professionisti vengano
utilizzati nel loro sviluppo. I processi di integrazione tramite l’EAI si trovano ancora
in una situazione poco matura e consolidata. Quanto detto è riconducile alla storia
dei modelli e delle architetture dei computer. Infatti, molti software per l’EAI sono
proprietari, ciascun produttore ha creato una particolare metodologia per implementare il proprio prodotto. In più, ogni prodotto non consiste in un’architettura
vera e propria di integrazione, ma piuttosto rappresenta solo una parte di essa. Le
implementazioni EAI sono partite con l’intento di arrivare a degli standard, ma i
metodi con cui sono stati implementati per ora sono molto lontani da diventarlo.
In aggiunta a tutto ciò bisogna considerare questo aspetto: la definizione di tutto il
processo di integrazione e dell’architettura è più vicina all’arte che ad una scienza
esatta. Quindi, molto viene demandato alle capacità ed esperienza delle persone
che analizzano ed implementano le procedure di integrazione. Infatti, ci sono diversi
metodi che sono utilizzabili per analizzare i dati e flussi dei processi. In base al problema si potrebbero scegliere semplici processi di sincronizzazione dei dati oppure
implementare paradigmi di tipo SOA. Per fare questo, però, non sono presenti delle
regole ben definite, dipende da cosa si vuole ottenere come risultato dell’integrazione
e da quanto l’azienda è disposta ad investire su questa tematica.
Quanto appena detto mette in luce le difficoltà nella scelta di un determinato modello di implementazione delle procedure di integrazione EAI. È molto importante
comprendere le reali esigenze e valutare per le possibili soluzioni i pro ed i contro.
Visto l’assenza di precise regole per poter scegliere un modello specifico di architettura di integrazione è possibile fornire al lettore le linee guida formulate da
uno dei massimi esperti di EAI, David S. Linthicum1 , il quale ha definito 12 punti
1
Autore di un libro tra i più conosciuti sulla tematica EAI.
24
1.4 – Metodologie per l’implementazione
chiave da seguire durante la realizzazione di un’architettura EAI.
I punti chiave da lui definiti sono i seguenti:
1. conoscere l’azienda e capire quali sono le esigenze;
2. dare un significato ai dati;
3. dare un significato ai processi;
4. identificare le interfacce di applicazione;
5. identificare gli eventi di business;
6. identificare gli scenari di trasformazione dei dati;
7. fornire una mappatura degli spostamenti delle informazioni;
8. utilizzare le tecnologie presenti;
9. fare più test possibili;
10. valutare le performance;
11. definire il valore aggiunto;
12. creare delle procedure mantenibili nel tempo.
Conoscere l’azienda e capire quali sono le esigenze
Questo primo punto potrebbe sembrare banale e scontato, ma in realtà non è
così. Molto spesso questo rappresenta il momento più complicato e può occupare
anche una lunga parte del periodo necessario all’adozione di un’architettura EAI.
Sicuramente è un momento fondamentale ed irrinunciabile. È molto importante
comprendere quali sono i problemi e le esigenze dell’azienda per trovare la soluzione
più idonea. Sarà necessario collaborare con i responsabili dei vari sistemi informativi
presenti per conoscere e comprendere la struttura informativa e ciò che è in essa
contenuta. L’interazione con le persone ed i sistemi porterà a determinare quali
sono le informazioni che dovrà gestire la soluzione EAI. Inoltre, è fondamentale
25
1 – EAI - Enterprise Application Integration
ricordare che le informazioni ottenute in questo passo influenzeranno direttamente
le due operazioni seguenti, ovvero dare un significato sia ai dati che ai processi.
Dare un significato ai dati
È importante questo passaggio per diversi motivi. Il primo è dovuto al fatto
che molti progetti EAI sono presenti a livello dato e di conseguenza si deve definire il significato delle informazioni ed avere una comprensione chiara di come sono
strutturate e memorizzate. Il secondo motivo è legato al fatto che anche i progetti
sviluppati sugli altri livelli di EAI necessitano molto spesso di comprendere l’organizzazione dei dati sui differenti database.
Per implementare un’architettura EAI a livello dato sono presenti tre operazioni
operazioni che possiamo definire di “base” e che nel dettaglio sono:
1. l’identificazione dei dati;
2. la catalogazione dei dati;
3. la costruzione del modello dei meta dati aziendale, quest’ultimo utilizzato
come guida principale per integrare i diversi database che esistono all’interno
dell’organizzazione.
Dare un significato ai processi
Una volta che si sono compresi i dati è possibile decidere come approcciarsi al
modello di business dell’azienda. Tale decisione dipenderà sicuramente dal particolare dominio di EAI che si intende raggiungere.
In questa attività l’obiettivo è di ottenere una vista dell’azienda a livello di processo. Il lavoro principale sarà la comprensione e documentazione di tutti i processi di
business presenti all’interno dell’organizzazione.
Identificare le interfacce dell’applicazioni
Una fase da affrontare corrisponde alla raccolta delle informazioni sulle interfacce delle applicazioni. Si tratta di un lavoro molto utile per supportare l’integrazione
26
1.4 – Metodologie per l’implementazione
EAI a livello d’interfaccia oppure per implementare l’integrazione dell’interfaccia
delle applicazioni con gli altri livelli di EAI.
Le interfacce, di solito, non vengono prodotte secondo in modo standard, esse generalmente sono differenti da applicazione ad applicazione, di conseguenza è utile
avere un elenco di queste memorizzandole in uno specifico repository facilmente
accessibile.
Identificare gli eventi di business
L’operazione consiste nell’identificazione di tutti gli eventi di business rilevanti
che sono presenti all’interno dell’organizzazione. Ciò significa che quando avverrà
un evento si avrà la conoscenza degli attori in gioco presenti e sarà più facile capire
l’esito della azione risultante.
Infatti, è fondamentale comprendere chi ha invocato un evento di business, chi ha
partecipato all’evento e quali sono stati gli altri eventi che possono essere stati
invocati come conseguenza dell’avvio di uno iniziale.
In un’architettura EAI un obiettivo possibile è di automatizzare gli eventi su tutti i
sistemi eliminando i processi manuali.
Identificare gli scenari di trasformazione dei dati
L’obiettivo di questo punto è di ottenere la conoscenza delle trasformazioni che
avvengono tra i dati scambiati tra i diversi sistemi. È importante realizzare questo
lavoro perché i dati che esistono in un sistema potrebbero non avere significato
su di un altro senza opportune modifiche al dato stesso. Effettuando le opportune
trasformazioni sul dato è possibile mantenere la corretta semantica sulle applicazioni.
Fornire una mappatura degli spostamenti delle informazioni
Arrivati in questa fase è necessario creare una mappatura degli spostamenti delle
informazioni da sistema a sistema memorizzando le informazioni che vengono spostate e memorizzate. Si dovranno memorizzare gli eventi che limitano gli spostamenti
delle informazioni, oppure gli eventi richiesti o le condizioni necessarie per attivare
lo spostamento dell’informazione dal sistema sorgente verso il relativo destinatario.
27
1 – EAI - Enterprise Application Integration
Applicare la tecnologia
Una volta terminate tutte le operazioni di catalogazione delle informazioni, si
arriva al punto in cui è necessario selezionare e decidere quale tecnologia adottare
per risolvere il problema di integrazione EAI. In questo contesto sono presenti molte
tecnologie, che abbiamo già descritto in precedenza, come gli oggetti distribuiti, le
rpc ed i message brokers. In generale, la scelta della tecnologia da adottare è un mix
di prodotti di fornitori differenti i quali insieme riescono a soddisfare le esigenze di
un’architettura EAI. È molto raro che un singolo fornitore sia in grado di risolvere
tutti i problemi che la soluzione di solito richiede. È evidente che la scelta della tecnologia sia un processo molto difficile che può richiedere un grande sforzo di tempo
e di risorse.
In questa fase vengono definiti dei requisiti che una tecnologia e suoi prodotti devono
raggiungere e soddisfare. Con questa attività è possibile comprendere le soluzioni
disponibili e scegliere quelle che rispondono meglio alle proprie necessità. Per capire
se un requisito potrà essere raggiunto o meno da un prodotto a volte sarà necessario provare con un “progetto pilota”. In questo modo si arriverà a conoscere come
tale tecnologia funziona e come questa potrà essere utilizzata nell’architettura EAI.
Il tempo per scegliere la giusta tecnologia potrebbe, a volte, essere lungo quanto lo sviluppo dell’intera soluzione EAI. Un’eventuale scelta errata causerà quasi
sicuramente il fallimento del progetto EAI.
Fare più test possibili
La parte di test è sempre molto costosa e di solito tende ad occupare molto
tempo e molte risorse. Per contro se un’architettura EAI non viene testata in modo sufficiente è possibile avere degli effetti collaterali devastanti dal punto di vista
dell’integrità di tutto il sistema. Ad esempio, potrebbero essere sovrascritti dei dati
importanti, oppure informazioni errate potrebbero essere inserite all’interno delle
applicazioni. La fase di test è fondamentale per verificare che la soluzione implementata sia scalabile, possa funzionare in modo adeguato ed accettabile nell’uso
quotidiano, prevedendo anche carichi di lavoro normalmente non presenti.
28
1.4 – Metodologie per l’implementazione
Utilizzare delle applicazioni di controllo dati può essere uno degli strumenti per
verificare determinate funzionalità dell’architettura EAI.
Valutare le performance
Le performance sono un punto che solitamente viene considerato troppo tardi,
quindi, bisogna fare attenzione a considerare questo aspetto con la giusta attenzione. Generalmente i sistemi su cui non si valutano correttamente le performance sono
destinati a fallire.
Con le tecnologie attuali sono presenti molte architetture EAI che non forniscono
una latenza bassa nel rispondere alle operazioni richieste. Gli spostamenti tra sistemi, l’invocazione di comuni processi di business dovrebbero rispondere con un
tempo inferiore al secondo. Lo stesso tempo di risposta dovrebbe essere mantenuto
a prescindere dall’aumentare del numero di utenti e processi caricati.
Come è possibile valutare le performance di un sistema? Innanzitutto possiamo
affermare che le performance non rappresentano un requisito definito all’inizio dello
sviluppo e poi, in seguito, ignorato. Le performance sono valutate dall’inizio alla
fine di tutto il periodo di utilizzo di un’architettura EAI. Quanto appena affermato implica che una soluzione EAI deve necessariamente fornire degli strumenti per
le verifiche delle performance. Queste verifiche devono essere fatte sotto differenti
condizioni. Ad esempio verificando con 100 utenti oppure 1000 utenti, controllando
l’affidabilità ed i tempi di risposta del sistema.
Definizione del valore
A questo punto è arrivato il momento di definire il valore di un’architettura EAI,
per capire il valore di business legata all’integrazione dei sistemi. Un modo per fare
ciò è di valutare i soldi che si sono risparmiati utilizzando con successo l’architettura
EAI.
Per raggiungere questo obiettivo si devono considerare due fattori:
• il valore dell’architettura EAI intesa come la capacità di eliminare i processi
costosi, come i processi manuali, ottenendo di conseguenza una riduzione degli
errori;
29
1 – EAI - Enterprise Application Integration
• il valore fornito dall’incremento della produttività.
Creare delle procedure mantenibili nel tempo
Ultimo punto da considerare, ma non meno importante, è la definizione di come
mantenere nel modo migliore un’architettura EAI. In questo caso ci si deve porre
delle domande del tipo:
• chi gestirà la sicurezza?
• chi controllerà le performance e risolverà i problemi?
Per raggiungere anche quest’ultimo obiettivo è utile documentare tutte le attività in
modo da poterle assegnare a persone diverse in caso di necessità. Bisogna ricordarsi
che un’architettura EAI rappresenta il cuore di un’azienda perché muove informazioni vitali tra i sistemi e quindi un’operazione errata potrebbe compromettere la
stabilità e la coerenza tra i sistemi.
1.5
Potenziali criticità
Un’architettura di integrazione EAI deve essere vista come la realizzazione di
un obiettivo che porta a migliorare i processi aziendali, necessaria per migliorare
il lavoro dell’azienda. Ma ovviamente, come in tutte le scelte, bisogna considerare
anche i potenziali aspetti negativi che possono comportare anche delle criticità non
indifferenti.
In certe situazioni, nei casi peggiori, si può arrivare addirittura ad un fallimento vero
e proprio della architettura EAI. Questo evento porterà con sé tutte le conseguenze
legate all’insuccesso dell’investimento di persone e risorse impiegate per l’implementazione dell’infrastruttura EAI. Per evitare che questo accada, è necessario, prima
di procedere a realizzare un’architettura EAI, analizzare i possibili problemi a cui si
potrà andare incontro, valutando le probabilità di incorrere in queste casistiche.
La parte che segue vuole illustrare alcuni dei possibili problemi che si possono
incontrare nella realizzazione di un’architettura EAI.
30
1.5 – Potenziali criticità
1.5.1
Problemi nel processo di integrazione
Quando si lavora con lo sviluppo di processi di integrazione si possono verificare
delle situazioni che creano forti problemi e rallentamenti e che possiamo riassumere
nei punti seguenti.
• La reale implementazione risulta essere più complessa e costosa di quella attesa
e preventivata. A volte capita perché si commettono errori nell’analisi progettuale ed in fase di realizzazione si rilevano delle difficoltà tecniche che non si
riescono a superare facilmente se non stravolgendo alcune parti del progetto
o, nei casi peggiori, ricominciando di nuovo dalla fase di analisi, aumentando di conseguenza i costi. Ma i costi possono aumentare anche perché molti
fornitori per realizzare architetture EAI tentano di convincere gli sviluppatori
che utilizzando il loro prodotto questo li aiuterà a creare in breve tempo la
soluzione di integrazione. Magari alla fine si scoprirà che avrà solo aumentato
i costi senza portare effettivi miglioramenti.
• Può capitare che le singole business unit2 associate ai sistemi informativi non
vogliano comunicare e cooperare. Prima dell’avvento di un’architettura EAI
ogni business unit considerava la sola propria applicazione, senza avere necessariamente una visione dell’infrastruttura informativa globale. Invece, realizzando un’architettura EAI sarà richiesta una collaborazione molto forte tra le
unità che si occupano dei vari sistemi ed il gruppo centrale a supporto dell’EAI. Questo perché i singoli sistemi dovranno condividere con le persone che
lavoreranno sulle EAI procedure per richiamare le operazioni sui propri sistemi
e dovranno comunicare eventuali modifiche e manutenzioni. In caso contrario,
il gruppo EAI potrebbe rimanere con informazioni non aggiornate, con tutti i
rischi di fare operazioni non più coerenti.
• In grosse organizzazioni il gruppo che si occupa di EAI ed i responsabili dei vari sistemi possono fare riferimento a capi diversi i quali non voglio incentivare
questo dialogo tra i gruppi; in situazioni del genere eventuali problemi legati
2
Parte di un’azienda che rappresenta una specifica funzione di business, chiamata anche area
funzionale o dipartimento.
31
1 – EAI - Enterprise Application Integration
agli eccessivi costi del progetto di integrazione potrebbero diventare cause scatenanti di scontro tra il gruppo EAI e gli altri attori dei vari sistemi, rendendo
la situazione ancora più difficile.
1.5.2
Dati non allineati
Un sistema di memorizzazione di dati per garantire la qualità delle informazioni
dovrebbe lavorare utilizzando un paradigma di tipo transazionale, modalità questa
che permetterebbe di essere affidabile. L’utilizzo di un paradigma di questo tipo,
ovvero quello transazionale, darebbe la possibilità di semplificare le problematiche di
consistenza, di recupero dati e gestione errori in un sistema di integrazione. Il problema che solitamente si riscontra in un’architettura EAI è di trovare molto spesso
processi di natura asincrona. Questi processi potenzialmente possono durare anche
molto tempo all’interno di ciascun sistema, quindi difficilmente potrà essere realizzato un sistema transazionale come quello che riscontriamo su una singola base dati.
Quanto appena detto evidenzia il pericolo di trovare incoerenze nelle basi dati perché
le operazioni eseguite dai processi EAI a volte potrebbero incorrere in degli errori e
quindi bloccarsi. In caso di errore di una procedura EAI, difficilmente sarà possibile
richiamare una funzione di rollback per annullare le operazioni eseguite, in modo
analogo a quello che avviene su una base dati transazionale. Si potranno ritrovare,
perciò, delle informazioni disallineate tra i sistemi, ovvero non ci sarà più garanzia
di Data Integrity tra le basi dati delle diverse applicazioni. Questa situazione è illustrata nell’esempio della figura 1.4, dove sul sistema di partenza viene modificata
l’informazione relativa ad un contratto e questa, per problemi sull’architettura EAI,
non sarà propagata agli altri sistemi, che di conseguenza avranno dei dati non più
allineati.
Per ovviare a questo grosso inconveniente si potrebbe pensare di mettere a disposizione dell’architettura EAI dei meccanismi per accorgersi di queste situazioni
di disallineamento dei dati. Questa criticità, ovvero il rischio di avere dei dati non
allineati tra i vari sistemi, è proprio quella che ci porta a giustificare la realizzazione di un sistema di controllo di allineamento effettuando direttamente le verifiche
sui dati. A questo controllo di coerenza delle informazioni memorizzate nelle basi
32
1.5 – Potenziali criticità
Applicazione 1
Sull’applicazione 1 viene modificato il contratto 1234
1
Database
1
Tramite
un’applicazione
presente
nell’architettura EAI
viene prelevato il dato
modificato e questo
dovrà essere
comunicato agli altri
sistemi che
possiedono la stessa
entità
Applicazione 2
Tabella
Contratti
2
Database
2
Architettura EAI
Tabella
Contratti
3
Si verifica un errore nelle operazioni EAI per
aggiornare i dati sull’entità contratto degli altri
sistemi
Tabella
Contratti
Database
3
Si hanno dei dati disallineati sulle tabelle dei contratti!
Applicazione 3
Utilizzare dei controlli di
Data Integrity per riscontrare
questi disallineamenti
Figura 1.4. EAI: possibile problema di Data Integrity nell’architettura EAI
33
1 – EAI - Enterprise Application Integration
dati possiamo assegnare il nome di Data Integrity. Quindi, un sistema di controllo
di Data Integrity potrà aiutare a rispettare uno dei requisiti più importanti nello
sviluppo di processi di integrazione, ovvero il mantenimento della coerenza dei dati
scambiati. La correttezza delle informazioni condivise sarà un buon indicatore per
capire se l’architettura EAI starà operando in modo corretto o meno.
Il prossimo capitolo si occuperà proprio della problematica dell’integrità dei dati
distribuiti in un sistema informativo complesso. Sarà illustrato come sia possibile
definire ed implementare un’applicazione che si occupa di Data Integrity all’interno
di un’architettura di integrazione come le EAI.
34
Capitolo 2
Il Data Integrity in un’architettura
EAI
2.1
Introduzione
Il Data Integrity, inteso come strumento di verifica e controllo dei dati in un’architettura complessa all’interno della quale sono presenti sistemi diversi, è fondamentale per garantire la correttezza e la validità delle informazioni scambiate. La
figura 2.1 riporta un possibile schema di controllo dati tra tre sistemi differenti che
condividono l’entità contratti. L’applicazione si occuperà di prelevare i dati da controllare ed eseguirà delle procedure di controllo per verificare l’allineamento delle
informazioni.
La presenza di dati disallineati nei back-end potrebbe compromettere le funzionalità delle varie applicazioni del sistema informativo o causare malfunzionamenti
nel richiamare le procedure che usufruiscono di quelle informazioni. Quindi è importante avere degli strumenti di controllo di allineamento dati.
Ad esempio, un’azienda che si occupa di pubblicità e servizi, come quella che sarà
descritta nel seguito di questa tesi, potrebbe decidere di gestire i dati di un contratto
di un’inserzione pubblicitaria dal punto di vista sia amministrativo che editoriale.
Questa suddivisione potrebbe fare decidere ai responsabili dei sistemi informativi di
definire l’entità del contratto su entrambi i sistemi. L’entità, intesa come tabella
35
2 – Il Data Integrity in un’architettura EAI
Applicazione 1
Database
1
Applicazione 2
Tabella
Contratti
Data Integrity
Database
2
Preleva le informazioni delle
entità condivise sui vari
sistemi e verifica se i dati
sono allineati
Tabella
Contratti
Tabella
Contratti
Fornisce strumenti per calcolare e visualizzare i
disallineamenti riscontrati tra le entità distribuite
sui vari sistemi
Database
3
Applicazione 3
Figura 2.1. Data Integrity: esempio di applicazione di controllo dati in
un’architettura EAI
36
2.1 – Introduzione
o insieme di tabelle costituite da specifici campi, sarebbe presente in due database
distinti, i quali dovranno richiedere un processo di integrazione che prevederà dei
flussi di allineamento dati per avere gli aggiornamenti delle informazioni in caso di
modifica effettuata in uno dei due sistemi. Se nel processo di aggiornamento tra i
due sistemi si verificasse un errore, ancora più grave se non segnalato o monitorato,
questo porterebbe a creare disallineamenti tra le due basi dati. Il compito di un’applicazione di Data Integrity, in questo caso, sarà di evidenziare le anomalie tra le
due entità, effettuando i controlli con una cadenza temporale da definire in base alla
periodicità dei flussi che sono presenti nel processo di integrazione. Sarà possibile,
in questo modo, predisporre uno strumento con cui fornire delle interfacce utente e
dei report di dettaglio o aggregati dove riportare le anomalie riscontrate sui dati.
Questi strumenti saranno utili per pianificare dei recuperi delle informazioni con la
possibilità di integrare le procedure di riallineamento all’interno dello strumento di
controllo allineamento dati.
Uno dei primi compiti per la realizzazione di una soluzione di Data Integrity è l’identificazione delle entità critiche presenti sui sistemi informativi, definendo cosa
esattamente è necessario controllare. L’attività appena citata può essere realizzata
definendo quali tabelle sono da monitorare e di queste, quali campi è necessario
mantenere allineati. Questa considerazione ne fa derivare subito un’altra molto importante: bisogna tenere presente che una gestione di Data Integrity ha un costo di
analisi ed implementazione da non sottovalutare e deve essere implementata quando la mole di informazioni scambiate è molto grande e di conseguenza il controllo
manuale sarebbe impensabile. Generalmente la necessità di utilizzare procedure di
Data Integrity può essere effettivamente richiesta nei casi in cui sono presenti sistemi
informativi medio grandi, dove i flussi di integrazione sono molteplici e si trovano
tante procedure automatizzate. Come già detto, le procedure, anche se automatizzate, molto spesso hanno un sistema di monitoraggio che deve essere verificato da un
gruppo di utenti il quale ne controllerà il corretto funzionamento. Uno strumento
di segnalazione e monitoraggio aggiuntivo per l’architettura EAI potrebbe arrivare
da un’applicazione di Data Integrity, la quale riscontrando o meno disallineamenti,
permetterà di capire se qualcosa non sta funzionando nei processi di integrazione.
37
2 – Il Data Integrity in un’architettura EAI
Inoltre, la scelta di ricorrere ad applicazioni di Data Integrity può avvenire anche
per verificare l’allineamento dei dati nel caso in cui un’azienda decida di effettuare
operazioni di migrazioni di alcuni sistemi informativi. Ad esempio, considerando
l’azienda su cui ho realizzato il progetto di Data Integrity, all’interno della quale si
stanno spostando dati e procedure delle applicazioni CRM e amministrative verso
SAP, la fase di migrazione di questi sistemi costituisce un momento molto delicato
per il dato. Risulterà utile verificare, oltre al corretto funzionamento delle nuove
applicazioni, anche il corretto trasferimento delle informazioni dal sistema vecchio
a quello nuovo, controllando eventuali assenze e differenze sui dati. Questo aspetto
è importante perché generalmente in casi di spostamento di grosse quantità di dati
ci si affiderà di solito a flussi di integrazione, i quali ovviamente se non saranno
impostati correttamente genereranno malfunzionamenti che potranno fare perdere
informazioni importanti. Anche per questi motivi implementare una soluzione di
Data Integrity può essere una strategia vincente per certificare e validare il successo
della migrazione dei dati tra i sistemi (vecchio e nuovo).
Nello scenario di un’architettura EAI, vista la complessità dello sviluppo e la difficoltà di effettuare operazioni di debug in tempo reale, la presenza di uno strumento
di controllo di Data Integrity può rappresentare un ausilio per il successo dell’implementazione dell’architettura stessa. Se le informazioni movimentate dai flussi di
EAI saranno allineate, questa situazione rappresenterà un segnale positivo di funzionamento dell’architettura, giustificando di fatto l’investimento e gli sforzi effettuati
nella scelta di adottare tale architettura di integrazione. Inoltre, nella fase di nuove implementazioni di procedure di integrazione, il rilevamento di disallineamenti
nei dati potrà essere utilizzato per comprendere i motivi di queste anomalie. Con
uno strumento di controllo dati si avrà la possibilità di definire casistiche di errore
e di conseguenza apportare le correzioni sui flussi di integrazione. Quanto appena
detto permette di considerare il Data Integrity come un’attività che collabora con
l’architettura EAI, garantendone il funzionamento a livello di dato.
38
2.2 – Fasi per la realizzazione di un’applicazione di Data Integrity
2.2
Fasi per la realizzazione di un’applicazione di
Data Integrity
Un’applicazione di Data Integrity per essere implementata in modo corretto dovrà prevedere delle fasi di analisi puntuali sui dati e sull’architettura in cui si andrà
ad operare, per arrivare a progettare un sistema funzionante ed utilizzabile. Bisogna ricordare che l’obiettivo di un’applicazione di Data Integrity, in questa tesi, è
di fornire garanzie di qualità dei dati in un contesto di integrazione su architetture
complesse. Trattandosi di un ambito in cui sono presenti molti attori sarà necessario
puntare alla collaborazione con i diversi gestori dei sistemi per avere tutti i dettagli
possibili, in modo del tutto analogo alle problematiche EAI già discusse. In caso di
modifiche nelle logiche applicative o di dati sarà importante avere subito le informazioni per evitare di effettuare dei controlli con logiche non più coerenti. Un progetto
di Data Integrity per essere valido dovrà essere mantenuto nel tempo allineato con
le logiche presenti sui sistemi in modo analogo alle altre procedure di integrazione di
EAI. Altrimenti, in caso contrario, si correrà il rischio di generare delle segnalazioni
definibili come “falsi positivi”, nel senso che verranno indicati come errori situazioni
corrette, oppure non si riscontreranno gli errori quando questi saranno presenti.
Le fasi che fanno parte del processo di implementazione di una soluzione di Data
Integrity sono in parte riconducibili alle linee guida per l’implementazione di un’architettura EAI definite nel primo capitolo, nello specifico possono essere condensate
nei punti seguenti:
• analizzare le entità di business dell’azienda;
• analizzare il contesto operativo e dei sistemi informativi;
• analizzare gli aspetti fisici di memorizzazione;
• effettuare transcodifiche sui campi;
• implementare le politiche di confronto sui dati;
• valutare le performance;
39
2 – Il Data Integrity in un’architettura EAI
• visualizzare i risultati;
• analizzare possibili processi di riallineamento;
• monitoraggio e test continui.
2.2.1
Analizzare le entità di business dell’azienda
In primo luogo è molto importante avere una minima conoscenza del “core business” dell’azienda su cui si deve costruire un’applicazione di Data Integrity. Questo
passaggio è fondamentale perché l’analisi a questo livello determinerà le scelte delle fasi successive. Si tratta di un attività molto critica che deve essere fatta con i
responsabili interni dell’azienda per capire e comprendere gli oggetti di business fondamentali. Ad esempio, oggetti critici di business potrebbero essere i dati dei clienti
per un sistema CRM, il documento di vendita per un programma gestionale ecc..
L’individuazione a livello logico delle entità da controllare è il passaggio obbligatorio
prima di intraprendere qualsiasi altra attività di implementazione. Sarà possibile
decidere, in seguito, di controllare anche altri oggetti di business mentre si starà già
lavorando alle fasi successive, ma queste aggiunte non dovranno comunque stravolgere il percorso fino a quel momento intrapreso, per evitare di dovere annullare il
lavoro già svolto.
2.2.2
Analizzare il contesto operativo ed i sistemi informativi
Dopo avere selezionato e deciso le entità che si intendono mettere sotto controllo
tramite un’applicazione di Data Integrity, sarà molto importante effettuare un’analisi abbastanza specifica dell’architettura dei sistemi presenti. L’attività permetterà
di definire un primo insieme di potenziali strumenti che potranno essere adottati.
Conoscendo la tecnologia utilizzata per la memorizzazione dei dati, ad esempio su
di un database, si potrà optare per l’utilizzo di uno strumento compatibile con la
tecnologia riscontrata ed eventualmente già a disposizione dell’azienda. Si potranno
anche valutare eventuali acquisti di strumenti specifici che permetterebbero migliori
performance e stabilità.
40
2.2 – Fasi per la realizzazione di un’applicazione di Data Integrity
In questa fase di analisi si verrà a conoscenza delle specifiche piattaforme e dei sistemi informativi presenti. Sarà molto importante ottenere le informazioni di accesso
alle basi dati associate ai sistemi. Ad esempio, per un database sarà necessario conoscere la stringa di connessione e le utenze per accedervi. Se i dati fossero invece
salvati su file, come ad esempio avviene con dei backup, sarà necessario conoscere
la cartella dove saranno memorizzati, richiedendo eventualmente i diritti di accesso
almeno in sola lettura.
Effettuando l’analisi dell’entità di business e del contesto operativo sarà possibile
fare una valutazione di quanti e quali sono i sistemi che richiedono questo monitoraggio da parte della soluzione di Data Integrity. A questo punto sarà possibile
iniziare anche a valutare i modi ed i tempi di realizzazione della soluzione.
2.2.3
Analizzare gli aspetti fisici di memorizzazione
Determinare i campi
Una volta che si è riusciti ad individuare le piattaforme ed i sistemi che contengono le entità da monitorare, si dovrà scendere di livello andando a verificare
ed ottenere le informazioni sulle modalità di memorizzazione dei dati. Come già
detto precedentemente, molto probabilmente, si dovrà accedere ad un database e di
questo sarà necessario ottenere le informazioni circa la modalità di memorizzazione
dei dati dell’entità all’interno dei campi della tabella. Infatti, una volta definite
l’entità e le informazioni da controllare sarà necessario effettuare un mapping tra
i dati dell’entità logica e di come questi siano effettivamente presenti all’interno di
una o più tabelle.
Questa operazione che può sembrare banale, molto spesso non lo è, perché i campi possono anche essere poco autodescrittivi, ovvero il loro nome non ci fornisce
un’informazione esplicita di quale attributo dell’entità si riferisce. Si tratta di una
situazione abbastanza frequente nei casi in cui vengono utilizzate applicazioni complesse tipo SAP, nella quale sono presenti migliaia di tabelle e ciascuna di essa è
costituita da una moltitudine di attributi. Inoltre, molto spesso si trovano delle
tabelle con tanti campi perché l’entità che viene memorizzata su queste strutture
41
2 – Il Data Integrity in un’architettura EAI
deve essere caratterizzata da molte informazioni perché è costituita da tanti attributi. Di conseguenza il passaggio dal modello logico dell’entità a quello fisico su una
tabella di un database prevederà la creazione di tanti attributi per poter al meglio
descrivere l’entità stessa.
È importante sottolineare che difficilmente un’applicazione di Data Integrity dovrà
controllare tutti i campi delle tabelle di un sistema. Questo perché sarebbe molto
oneroso dal punto di vista di controllo e di realizzazione, e poi c’è da considerare il
fatto che generalmente quando ci sono tanti attributi non è detto che questi contengano valori significativi in tutti i record e soprattutto per tutti i sistemi. Sarà
fondamentale circoscrivere le informazioni condivise tra i sistemi che necessitano di
controllo e lavorare solo su quelle. Per raggiungere quest’obiettivo si dovranno contattare le persone responsabili dei vari sistemi informativi i quali dovranno fornire
le informazioni necessarie per estrapolare questi dati.
Il data dictionary del database
Come ausilio alla fase di riconoscimento dei campi all’interno delle tabelle sarà
possibile accedere anche al dizionario dei dati, ovvero il Data Dictionary, il quale, se
presente, mantiene le informazioni associate alla struttura di un database e da cui
possono essere prelevate indicazioni tra le quali:
• il proprietario dell’oggetto;
• la tabella di appartenenza;
• il formato del campo ovvero se si tratta di un intero, di una stringa (con quanti
caratteri), ecc.
Il data dictionary può essere utile per ricercare, con delle interrogazioni SQL specifiche, i nomi e gli attributi di campi particolari all’interno della struttura. Generalmente si tratta di uno strumento abbastanza comune tra i database. Tuttavia, questi
dizionari sono stati implementati dai produttori in maniera diversa sia per quanto
riguarda la forma che per i contenuti. Per questo motivo, a volte, le informazioni
da ricercare non sempre si riescono ad ottenere facilmente.
42
2.2 – Fasi per la realizzazione di un’applicazione di Data Integrity
Comprendere i vincoli di integrità
Quando si analizza un singolo database, si presentano costantemente problematiche di integrità sui dati. Per gestire bene queste situazioni è importante comprendere
le regole applicate per la costruzione del database. Ad esempio, quando abbiamo una
tabella contenente i dati di testata di una fattura ed un’altra contenente i dettagli
di riga collegati alla testata tramite una chiave esterna, l’operazione di inserimento
dati corretta prevederà prima il caricamento della testata del documento fattura poi
l’inserimento di tutte le righe ad essa associata. In caso contrario, se l’integrità non
fosse stata impostata, sarebbe possibile avere delle righe di fattura senza i relativi
dati di testata e quelle informazioni, molto probabilmente, non sarebbero più raggiungibili dall’applicazione. Ovviamente per mantenere questi vincoli, le tabelle dei
diversi database prevederanno delle chiavi primarie che permetteranno di distinguere i record in modo univoco.
Conoscere questi vincoli di integrità, analizzando chiavi primarie ed indici, sarà di
ausilio alle politiche di confronto di un’applicazione di Data Integrity per riconoscere
la stessa entità presente su database diversi.
Considerare il Data Latency
È una caratteristica associata al dato che definisce quando e come l’informazione
da verificare risulta essere presente e valida. Il Data Latency deve essere conosciuto
per determinare il momento in cui l’informazione potrà essere presa in considerazione
da una procedura di controllo allineamento dati come il Data Integrity.
Per quanto concerne la parte di controllo delle informazioni possiamo avere tre
categorie di data latency:
1. real time
2. near time
3. batch time
Real-time
Significa che il dato è presente nel database in ogni momento con una piccola o
43
2 – Il Data Integrity in un’architettura EAI
addirittura latenza nulla rispetto ad una possibile modifica su un altro sistema. In
sistemi real time i dati sono aggiornati immediatamente all’interno del database e
le informazioni sono subito disponibili a qualsiasi persona o applicazione che ne farà
richiesta. Per un’applicazione di Data Integrity il fatto di avere dati aggiornati in
real time non dovrebbe creare problemi per quanto riguarda il momento in cui prelevare l’informazione. Nonostante questo converrà accedere ai dati per effettuare i
confronti in momenti in cui ci saranno meno utenti che lavoreranno sui sistemi, in
modo da essere il più possibile sicuro di prendere i dati aggiornati.
Near-time
Con il termine near-time si intende che il dato relativo ad un certa informazione è aggiornato a determinati intervalli rispetto agli aggiornamenti istantanei come avviene
invece in real-time. Un esempio può essere il valore all’interno di una tabella che
per essere aggiornato deve aspettare la terminazione di un’operazione molto lunga
e fino a quando questa non sarà terminata le due basi dati risulteranno differenti.
Batch-time
Con il termine batch-time si intende che il dato relativo ad un certa informazione è
aggiornato a distanza di diverse ore, generalmente con il ritardo di un giorno, rispetto agli aggiornamenti in real-time e near-time. Un tipo esempio di operazione batch
time l’abbiamo quando l’operazione di allineamento tra sistemi avviene con dei job
notturni, schedulati appositamente per trasportare le informazioni da un sistema
all’altro. Questo significa che durante tutto il giorno si potrà avere un’informazione
diversa sulla stessa entità tra i due i sistemi, ma questo non sarà un errore. La situazione non sarà risolta finché non arriverà il processo notturno, ovvero un processo
batch, ad occuparsi dell’aggiornamento delle informazioni.
Per quanto riguarda l’applicazione di Data Integrity sarà necessario conoscere
queste situazioni per sapere quando prendere i dati su cui effettuare il confronto.
44
2.2 – Fasi per la realizzazione di un’applicazione di Data Integrity
2.2.4
Effettuare transcodifiche sui campi
Una volta recuperato tutte le informazioni circa i nomi dei campi e delle tabelle
che contengono le entità il processo di analisi dei dati non è ancora terminato.
Infatti, quando si integrano applicazioni differenti è facile che queste abbiano nei
loro database valori diversi per rappresentare la stessa semantica per un certo dato.
Sarà importante definire le corrispondenze di codifica tra gli attributi di un’entità
memorizzata su i diversi sistemi.
In altri casi, una specifica informazione può essere memorizzata in un solo campo in
un sistema, mentre per recuperarla dall’altro sarà necessario concatenare due o più
campi. Sarà anche possibile trovarsi in situazioni dove il dato per essere confrontato
dovrà essere estratto dal valore di un campo, quindi si dovranno utilizzare operazioni
di manipolazione di stringhe oppure di conversione da stringa a numero e viceversa
Per rappresentare meglio queste casistiche è possibile riportare gli esempi seguenti:
Sulla tabella del sistema A lo stato del contratto può assumere diversi valori tra i quali:
“Confermato” ed “Annullato”, mentre sul sistema B i corrispettivi stati citati per il sistema A
corrispondono ai valori “C” e “A”.
In fase di confronto dei record di questi due sistemi sarà necessario rendere uguale la
semantica trasformando:
•sul sistema B il valore “C” con “Confermato”, ed in modo analogo anche gli altri valori;
•oppure sul sistema A il valore “Confermato” sarà sostituito con “C”, anche in questo caso si
dovranno effettuare le opportune variazioni per gli altri stati.
“Confermato” = “C”
Codice
Data
Cliente
Stato contatto
Codice
Data
Cliente
Stato contatto
1234
24/06/2009
ROSSI
Confermato
1234
24/06/2009
ROSSI
C
Contratto
Contratto
Sistema A
Sistema B
Figura 2.2. Data Integrity: esempi di transcodifiche sui dati (1)
45
2 – Il Data Integrity in un’architettura EAI
Sulla tabella del sistema A il codice di un contratto è memorizzato in un solo campo (Codice),
mentre nella tabella del sistema B per ottenere in modo congruente la stessa informazione è
necessario concatenare due campi (Codice + Sottocodice)
Codice
Cliente
Stato contatto
Codice
Sottocodice
Cliente
Stato contatto
1234
ROSSI
Confermato
123
4
ROSSI
Confermato
Tabella contratto
Tabella contratto
Sistema A
Sistema B
Sulla tabella del sistema A il codice è memorizzato in formato numerico, mentre sulla tabella del
sistema B è memorizzato in formato carattere. Quando è presente un codice costituito da degli
zeri iniziali questi verranno persi nella memorizzazione sul campo numerico, mentre su quello in
formato carattere ciò non avverrà. Nel momento in cui sarà necessario confrontare il dato
numerico con quello carattere si dovrà ricostruire correttamente l'informazione prima di
procedere con il controllo: si dovranno aggiungere gli zeri a sinistra persi sul campo numerico
oppure questi zeri saranno da eliminare sul campo di tipo carattere.
Codice
Data
Cliente
Stato contatto
Codice
Data
Cliente
Stato contatto
1234
24/06/2009
ROSSI
Confermato
001234
24/06/2009
ROSSI
Confermato
Contratto
Contratto
Sistema A
Sistema B
Figura 2.3. Data Integrity: esempi di transcodifiche sui dati (2)
46
2.2 – Fasi per la realizzazione di un’applicazione di Data Integrity
2.2.5
Implementare le politiche di confronto sui dati
Questa è la fase in cui avviene il passaggio dall’analisi alla realizzazione vera e
propria. A questo punto sarà necessario definire e realizzare gli algoritmi di caricamento, aggiornamento e confronto dei dati. Sarà importante considerare il numero
di righe presenti nella diverse tabelle da cui estrapolare i dati su cui effettuare il
confronto. In particolare, dato che nei grossi sistemi generalmente le entità di business avranno una cardinalità molto grande, è ragionevole pensare di utilizzare delle
strutture dati di ausilio dove caricare temporaneamente i dati dei sistemi da controllare. In queste strutture sarà possibile applicare le logiche di transcodifiche sui
determinati campi analizzati nello step precedente in modo da ottenere dei dati confrontabili. Ovviamente per realizzare queste politiche di confronto sarà necessario
riconoscere ed utilizzare quei campi che rappresentano in modo univoco una determinata entità. Sarà necessario definire delle chiavi primarie sulle tabelle temporanee
dove saranno memorizzati i dati ed utilizzare queste come chiave di confronto per
riconoscere l’assenza o meno del record tra i sistemi. A parità di chiave di confronto
invece si potranno valutare le differenze sugli altri campi.
Aiutandoci con un esempio per rappresentare meglio la situazione, possiamo immaginare che una volta prelevato i dati dell’entità contratti dai due sistemi da controllare
si utilizzerà come chiave di confronto il campo che conterrà il codice identificativo.
Questo potrà essere un id numerico, oppure potrà essere costituito da una serie di
campi che renderanno univoco il record all’interno della tabella. Adottando questo metodo per entrambe le tabelle sarà possibile ricercare un record dell’entità del
primo sistema all’interno della tabella del secondo sistema, evidenziando di conseguenza eventuali anomalie.
Le possibili anomalie che possiamo riscontrare sono:
• l’assenza del dato
• la differenza su uno o più campi
47
2 – Il Data Integrity in un’architettura EAI
Assenza del dato
Con assenza del dato possiamo intendere un record od un insieme di record
che sono presenti su un sistema, che possiamo chiamare A, e non presenti sull’altro
sistema che rinominiamo B, così come indicato negli schemi presenti nella figura 2.4.
Con il termine “record assente” intendiamo due tipologie:
• le informazioni si trovano sul sistema A e non su B;
• le informazioni si trovano sul sistema B e non su A.
Codice
Data
Cliente
Stato contatto
Codice
Data
Cliente
Stato contatto
1234
24/06/2009
ROSSI
Confermato
9999
24/06/2009
NERI
Sospeso
9999
24/06/2009
NERI
Sospeso
Il dato manca sul sistema B
Contratto
Contratto
Sistema A
Sistema B
Codice
Data
Cliente
Stato contatto
Codice
Data
Cliente
Stato contatto
1234
24/06/2009
ROSSI
Confermato
1234
24/06/2009
ROSSI
Confermato
9999
24/06/2009
NERI
Sospeso
Il dato manca sul sistema A
Contratto
Contratto
Sistema A
Sistema B
Figura 2.4. Data Integrity: esempi di dati assenti
La scelta delle tipologie di assenze da ricercare dipendono in senso stretto dalle
applicazioni di integrazione, quindi, sarà importante conoscere quali sono i dati che
vengono aggiornati. In particolare, bisognerà conoscere qual è il sistema che detiene
la versione del dato corretta, perché tale informazione verrà propagata alle altre
48
2.2 – Fasi per la realizzazione di un’applicazione di Data Integrity
applicazioni. In questo modo saremo in grado di valutare se lo stesso dato presente
sugli altri sistemi sarà da considerarsi corretto oppure no al fine del nostro controllo.
Inoltre, sarà necessario sapere se determinate categorie di record e di campi saranno
presenti su entrambi i sistemi. Tale caratteristica è importante perché il calcolo delle
assenze potrà essere fatto partendo dall’analisi dei dati presenti sul sistema A e non
su B o viceversa se necessario, oppure in entrambe le direzioni.
Da quanto appena descritto possiamo affermare che quando effettuiamo il controllo
di assenza sarà importante verificare l’introduzione o meno di filtri di selezione dei
dati da confrontare, altrimenti potremmo avere delle segnalazioni di assenza inesatte.
Questo serve per giustificare il fatto che non tutti i record presenti nelle tabelle
associate alle entità dovranno essere presi in considerazione. Si tratta di un aspetto
fondamentale nel processo di realizzazione di una soluzione di Data Integrity, in
quanto si dovranno selezionare e mettere a confronto solo i dati che per logiche di
business e per impostazioni dell’architettura EAI dovranno trovarsi su entrambi i
sistemi, eventualmente focalizzandosi solo su quelli assenti su un determinato sistema
oppure considerando le assenze su entrambi i sistemi.
Differenza su uno o più campi
Una differenza, o più differenze, sui campi di una entità le possiamo riscontrare
quando troviamo lo stesso record sui sistemi coinvolti nel confronto e troviamo dei
valori diversi sui campi che invece dovrebbero essere uguali. Nella figura figura 2.5
è riportato un esempio. In questo caso partendo da un sistema A troviamo, tramite
la sua chiave primaria univoca, il record sul sistema B ma andando a confrontare
i singoli valori riscontriamo delle informazioni diverse per almeno un campo, tra
quelli che rientrano nelle politiche di confronto. Siamo in una situazione in cui, per
qualche motivo da accertare, i dati non sono stati aggiornati correttamente sui vari
sistemi. Le cause che possono concorrere a questa tipologia di anomalia potrebbero
essere le seguenti:
• l’applicazione di integrazione che si occupa di aggiornamento dei dati non
funziona correttamente, potrebbe essere presente un errore nel mapping tra i
campi che deve aggiornare oppure si potrebbe riscontrare un baco nel codice
49
2 – Il Data Integrity in un’architettura EAI
Codice
Cliente
Stato contatto
Codice
Cliente
Stato contatto
1234
ROSSI
Confermato
123
ROSSI
Confermato
9999
BIANCHI
Confermato
9999
NERI
Confermato
Tabella contratto
Tabella contratto
Sistema A
Sistema B
In questo caso il record relativo al contratto con il codice 9999 è presente su entrambi i sistemi,
ma il campo cliente risulta essere diverso. Questa situazione rappresenta un disallineamento
dovuto a differenza di dati tra i sistemi.
Codice
Cliente
Stato contatto
Codice
Cliente
Stato contatto
1234
ROSSI
Confermato
123
ROSSI
Confermato
9999
BIANCHI
Confermato
9999
Confermato
Tabella contratto
Tabella contratto
Sistema A
Sistema B
Anche la non presenza di un valore in un campo (valore blank o null), oggetto di controllo nella
procedura di Data Integrity, rappresenta un disallineamento dovuto a differenza sui dati tra i due
sistemi.
Figura 2.5. Data Integrity: esempi di dati differenti
50
2.2 – Fasi per la realizzazione di un’applicazione di Data Integrity
e l’applicazione di integrazione termina senza effettuare tutte le operazioni
previste;
• si è verificato un errore occasionale sull’applicazione di integrazione e per un
certo periodo il dato rimarrà disallineato; in questo caso si potrebbe essere
verificato un problema di funzionamento dell’applicazione EAI dovuto ad errori
nella comunicazione. Potrebbero capitare problematiche di rete, ad esempio
la rete non funziona oppure una risorsa remota per un po’ di tempo non è
raggiungibile. In alternativa, potrebbe capitare di inviare delle informazioni
generate dal sistema mittente contenente dati “sporchi” e di conseguenza questi
dati sbagliati causeranno un disallineamento sul sistema che li riceverà;
• è intervenuta la modifica sul dato da parte di un operatore tramite l’utilizzo
dell’applicazione front-end e tale aggiornamento non è stato propagato agli altri sistemi. In questa situazione è necessario capire se un’operazione del genere
può avere un senso oppure è presente un problema nella logica applicativa che
permette di fatto la modifica di un dato su cui non avrebbe i diritti di farlo. Gli utenti, tramite l’applicazione che presenta bug, possono diventare altri
fonti di disallineamento sui dati. Inoltre, con un’applicazione che possiede dei
bug, possono essere cancellati dei dati senza la reale intenzione di farlo.
Memorizzare le anomalie
Nel processo di verifica di assenze e differenze queste anomalie dovranno essere
memorizzate in qualche struttura per essere facilmente interrogabili da eventuali
applicazioni per essere esposte a degli utenti. Per questo è ragionevole pensare
che tutte le anomalie che vengono riscontrate, passo dopo passo dagli algoritmi di
confronto, vengano memorizzate in tabelle opportunamente create. In questo modo
sarà possibile creare delle applicazioni le quali espongano in forma aggregata o di
dettaglio gli esiti dei confronti effettuati sui sistemi.
Per tenere traccia delle varie anomalie che si sono succedute sarà possibile prevedere
anche delle tabelle di storico degli esiti dei confronti. Queste tabelle potrebbero
ritornare utili anche per verificare eventuali correlazioni sulle anomalie riscontrate
51
2 – Il Data Integrity in un’architettura EAI
nell’ultima operazione di confronto e quindi capire se, ad esempio, un determinato
errore si presenta con una cadenza temporale specifica.
2.2.6
Valutare le performance
Le performance, intendendo i tempi per calcolare le anomalie, rappresentano
un aspetto molto delicato, in quanto i caricamenti dei dati e i relativi algoritmi di
confronto devono essere il più possibile veloci in proporzione alle dimensioni delle
tabelle che contengono gli attributi associati alle entità.
Non avrebbe senso che un controllo su una entità contratti ci mettesse qualche giorno per restituire dei risultati, in quanto coprirebbe un arco temporale troppo lungo
e le basi dati non sarebbero le stesse rispetto al momento di partenza del controllo.
Questi algoritmi di caricamento devono essere il più possibile veloci prediligendo
eventuali funzionalità di caricamento e confronto da svolgere in parallelo per massimizzare le performance e ridurre i tempi di attesa.
Prima di implementare tutte le politiche di confronto per tutti i sistemi risulta utile
scegliere una coppia di sistemi abbastanza significativi come dimensioni per progettare gli algoritmi di confronto e verificarne i tempi di risposta. In questo modo si
partirebbe con un confronto su un sotto insieme di entità al fine di utilizzarlo come
“progetto pilota” e coglierne eventuali criticità, pensando a come ottenere prestazioni migliori e come sarebbe possibile rivedere l’algoritmo in termini di velocità di
esecuzione.
La fase di valutazione di performance è un momento molto importante per il reale
utilizzo di una procedura di Data Integrity in un sistema di integrazione. Se l’applicazione fosse troppo lenta per fornire i risultati sarebbe ragionevole pensare che
alla fine tale procedura non verrebbe utilizzata proprio a causa di questo difetto. È
buona norma, quindi, testare se l’approccio implementativo di un singolo algoritmo fornisce risultati accettabili in termini di prestazioni. Ovviamente è importante
considerare anche l’affidabilità in quanto l’algoritmo deve produrre segnalazioni di
anomalie corrette.
In definitiva un’applicazione di Data Integrity deve essere costituita da un sistema di
52
2.2 – Fasi per la realizzazione di un’applicazione di Data Integrity
controllo veloce ed affidabile, altrimenti tutti gli sforzi fatti per la sua realizzazione
potrebbero risultare vani.
2.2.7
Visualizzare i risultati
Tutte le anomalie riscontrate nei processi di controllo devono essere memorizzate in qualche struttura. Le anomalie rilevate devono essere organizzate in modo
tale da essere semplici da consultare. L’obiettivo è di potere creare dell’applicazioni
per l’esposizione dei risultati, in forma di riepilogo e di dettaglio, ed eventualmente
integrare degli strumenti che permettano funzionalità di riallineamento a partire da
un elenco di anomalie.
Nella fase di studio per la visualizzazione dei risultati sarà possibile pensare di creare
dei report per visualizzare delle informazioni di riepilogo. Questi report potranno
essere utili per capire eventuali errori cronici.
Inoltre, sarà possibile creare delle applicazioni specifiche le quali permetteranno l’interrogazione dell’elenco dei disallineamenti sui dati e si potranno creare delle interfacce grafiche per esporre questi risultati agli utenti. Si potrà pensare di visualizzare
i dettagli delle sole assenze, differenze oppure tutte insieme. Si potranno inserire
delle funzioni di ricerca per verificare se un determinato record risulta disallineato
su qualche sistema, ecc.
Sulle applicazioni di visualizzazione degli esiti sarà possibile sviluppare delle procedure che consentano il recupero e l’allineamento dei dati per integrare, quindi, la
funzionalità di Data Integrity con l’infrastruttura delle applicazioni EAI già presenti.
2.2.8
Analizzare possibili processi di riallineamento
La possibilità anticipata nell’ultimo passo appena descritto viene ripresa in questa fase. In particolare con l’ausilio dell’elenco dei risultati delle anomalie sui dati
sarà necessario effettuare delle operazioni di recupero, in quanto quei dati risultati
disallineati potrebbero compromettere la stabilità delle applicazioni.
Per effettuare queste operazioni di riallineamento si potrebbero creare delle estrazioni dei dati disallineati e utilizzando questi elenchi si potrebbero richiamare le
53
2 – Il Data Integrity in un’architettura EAI
opportune applicazioni di integrazione EAI per effettuarne l’aggiornamento. Una
volta eseguite questi aggiornamenti rieseguendo il controllo con la procedura di Data Integrity si andrebbe a verificare il successo o meno dell’operazione eseguita.
È possibile pensare di includere dei processi di allineamento all’interno delle funzionalità di visualizzazione delle assenze e differenze sui dati. Ad esempio si potrebbe
creare un’applicazione che interrogando la base dati, contenente gli esiti dei confronti, permetta un’interazione con l’utente, tramite la quale sarà possibile decidere
quali sono i dati da riallineare e qual è il sistema che possiede il dato corretto. Dalle
varie impostazioni effettuate dall’utente sarà possibile fare partire delle operazioni
di recupero dati in real-time.
2.2.9
Monitoraggio e test continui
L’applicazione analizzata e creata a supporto del Data Integrity, molto probabilmente, dovrà essere avviata con strumenti di schedulazione automatici. Questi
strumenti consentiranno l’avvio e l’esecuzione in modo tale da impostare i controlli
di coerenza dati in periodi e momenti prestabiliti. Questo perché è molto probabile
che i controlli debbano essere eseguiti in orari notturni, che, di solito, sono i momenti in cui i sistemi hanno già fatto eseguire i loro processi EAI per passaggio dati
e quindi potenzialmente dovrebbero essere allineati. In più, il vantaggio di operare
di notte è dato dal fatto che ci sarà meno carico applicativo per via del presumibile
minor numero di utenti che saranno collegati ai sistemi.
Visto la necessità di un’automazione nell’esecuzione, le procedure di Data Integrity
devono essere costantemente tenute sotto controllo da sistemi di monitoraggio che
dovranno avvisare in caso di errore nell’esecuzione degli algoritmi di caricamento e
controllo dati. Questo è importante per essere certi del successo delle operazioni
compiute e quindi poter elaborare i dati prodotti dai confronti e visionarli insieme
ai responsabili dei vari sistemi, senza fornire informazioni errate.
La parte di monitoraggio servirà anche per il continuo test degli algoritmi di confronto. I test rappresentano un’attività che si muoverà di pari passo con l’esecuzione
delle procedure di Data Integrity. Infatti, le basi dati saranno in continuo aggiornamento, di conseguenza bisogna prevedere operazioni di modifica alle procedure di
54
2.3 – Vantaggi e svantaggi
confronto in caso di variazione delle logiche di business e di introduzioni di nuovi
dati che non verranno scambiati tra i sistemi. Si tratta di operazioni necessarie per
apportare eventuali correzioni sui filtri impostati nei controlli, aggiungendo o eliminando delle condizioni sui campi per considerare oppure no determinati record nelle
politiche di confronto. Il Data Integrity deve cercare di non fornire segnalazioni di
falsi positivi, in quanto un errore non presente ma segnalato dalla procedura sarebbe
un errore dell’algoritmo di confronto.
In definitiva, possiamo affermare che l’attività di monitoraggio e l’operazioni di test
saranno necessarie fino a quando il progetto di Data Integrity sarà mantenuto in
vita ed utilizzato.
2.3
Vantaggi e svantaggi
Progettare una soluzione che certifichi la qualità dei dati possiede dei pro e
contro che necessitano di essere analizzati prima di procedere nella realizzazione
vera e propria. L’obiettivo di questa sezione è di riassumere i possibili vantaggi e
svantaggi nell’utilizzo di un’applicazione di Data Integrity.
2.3.1
Vantaggi
Sicuramente uno dei vantaggi più importanti è di avere un controllo di qualità
del dato distribuito sui sistemi informativi. Questo aspetto rappresenta un requisito
fondamentale per fare funzionare le applicazioni correttamente. L’applicazione di
Data Integrity permetterà di avere il monitoraggio ed il controllo di congruenza dei
dati sui sistemi che continuamente si scambiano informazioni attraverso procedure
di integrazione. Potremmo ricevere in modo automatico degli avvisi, ad esempio
tramite mail, in caso di un’eccessiva presenza di anomalie nei sistemi. Così facendo
sarà possibile intervenire il più prontamente possibile su problematiche di integrazione EAI. Il Data Integrity potrà essere utilizzato come supporto alle applicazioni
di EAI in quanto fornirà degli strumenti per verificare il corretto passaggio dei dati
tra un sistema ed un altro.
55
2 – Il Data Integrity in un’architettura EAI
Inoltre, un’applicazione di Data Integrity potrà essere molto utile in caso di migrazioni di grosse quantità di dati da un sistema ad un altro nei casi in cui l’azienda
scelga di cambiare alcune sue applicazioni. In questi casi, i dati è probabile che
vengano spostati un po’ per volta. Saranno presenti le applicazioni, quelle vecchie
e quelle nuove, che dovranno convivere per un certo periodo. In una situazione
così delicata avere uno strumento per verificare la congruenza dei dati permetterà
un passaggio più facile da un sistema all’altro. Durante la fase di migrazione si
potrà verificare che il processo di spostamento dati avvenga correttamente, con la
possibilità di riscontrare eventuali errori.
2.3.2
Svantaggi
L’utilizzo di una procedura di Data Integrity può portare con sé alcuni svantaggi:
1. l’analisi ed implementazione di una soluzione di Data Integrity costituisce di
fatto un costo aggiuntivo oltre a quelli preventivati per la gestione dell’architettura EAI;
2. prevede una manutenzione costante delle procedure, dovuta alle situazioni in
cui è necessario rivedere le procedure di confronto quando cambiano regole
di business, transcodifica sui campi e vengono introdotti nuovi dati che non
dovranno essere propagati sugli altri sistemi;
3. in modo analogo a quanto può capitare per realizzare l’architettura EAI, nella
fase di analisi ed interazione con i diversi referenti dei sistemi informativi si
potrebbe avere lo stesso ostruzionismo ad ottenere le informazioni sulle regole
di business e su come reperire le informazioni direttamente dai database.
56
2.4 – Un caso reale: introduzione ad un progetto di Data Integrity
2.4
Un caso reale: introduzione ad un progetto di
Data Integrity
Dopo la descrizione della problematica dell’integrità dei dati (Data Integrity) in
un ambiente di integrazione, nel seguito dell’elaborato sarà illustrata un’implementazione reale di un progetto di Data Integrity, realizzato per effettuare il controllo
di specifici database di un’azienda del settore pubblicitario.
Questa azienda rappresenta uno dei principali operatori a livello mondiale nel settore della pubblicità multimediale. Uno dei suoi punti di forza è rappresentato dal
disporre di un patrimonio informativo e di una struttura informatica estremamente
sofisticata. L’insieme dei database e delle applicazioni sono strutturati per gestire
una quantità di dati estremamente significativa. Il raggiungimento di un sistema
informativo così sofisticato è stato reso possibile anche grazie all’implementazione
di un’infrastruttura EAI che, mediante un reengineering dei sistemi informatici, ha
consentito di realizzare un’architettura in grado di supportare e rispecchiare i processi di business. Per questo tipo di soluzioni è stato adottato il paradigma SOA
(Service Oriented Architecture) dove la logica di business è stata realizzata mediante
l’implementazione di servizi atomici, indipendenti dalla piattaforma e riutilizzabili
nell’intera azienda. Questo tipo di servizi ha consentito di riorganizzare in maniera efficiente sia le funzionalità legacy, sia i nuovi sviluppi, secondo una visione per
processi.
La fase che sta attraversando ora l’azienda è molto critica per quanto riguarda l’integrità del dato. È in atto da diversi mesi una migrazione, a passi successivi, verso
l’applicazione SAP per quanto concerne il sistema informativo CRM e amministrativo. Questo ha portato e sta portando a conseguenti modifiche su tutte le applicazioni
che si interfacciavano precedentemente al vecchio sistema. Il passaggio che durerà
ancora diversi mesi potrebbe introdurre un pericoloso rischio di disallineamento sui
dati che dovrà essere monitorato per evitare malfunzionamenti e disagi sulle applicazioni coinvolte. L’operazione di migrazione che sta avvenendo è complessa per via
dell’eterogeneità dei sistemi presenti. Tale complessità potrebbe portare al fallimento della nuova integrazione nel caso in cui l’interoperabilità non sia garantita dalla
57
2 – Il Data Integrity in un’architettura EAI
consistenza dei dati scambiati. In quest’ottica un sistema di Data Integrity ha la
possibilità di assumere un ruolo fondamentale, il quale potrà consentire di verificare
costantemente l’allineamento sui dati dei sistemi coinvolti nelle modifiche.
Per realizzare la soluzione di Data Integrity sono stati considerati due importanti fattori: l’ambiente complesso in cui è stato implementato e la grossa mole di dati
che i sistemi possiedono nei loro back-end. Per l’effettiva implementazione è stato
necessario adottare uno strumento di ETL (Execute, Transform, Load) adatto per
progetti che implicano una comunicazione tra database eterogenei e che riguardano
una notevole quantità di informazioni. Questo strumento è stato utilizzato per poter
accedere ai diversi database che dovevano essere monitorati e sono state utilizzate
delle procedure, scritte nel linguaggio PL/SQL1 di Oracle, per implementare gli algoritmi di aggiornamento e confronto dati. Utilizzando queste procedure PL/SQL
si è sfruttato il vantaggio di eseguire direttamente il codice sul server ed ottenere
buoni tempi di esecuzione.
I prossimi capitoli saranno dedicati a descrivere il software IBM Datastage ed ad
illustrare l’implementazione del progetto di Data Integrity in questa azienda di
pubblicità.
1
Nell’allegato A è riportato una breve introduzione al linguaggio PL/SQL di Oracle.
58
Capitolo 3
IBM Datastage: uno strumento di
elaborazione dati
3.1
Introduzione
IBM Datastage è uno strumento molto potente che permette il caricamento, la
trasformazione ed il trasferimento dei dati da un sistema sorgente ad uno destinatario, quindi si tratta di un software orientato all’ETL (Extraction, Trasformation,
Load). I dati che possono fare parte dei sistemi sorgenti e destinatari rientrano nelle
categorie dei file indicizzati, file sequenziali, code di messaggi e soprattutto, per il
nostro caso di studio, database relazionali.
Con Datastage è possibile creare differenti progetti e per ognuno di essi si potranno creare tante applicazioni che in questo contesto di lavoro vengono chiamate job.
Ciascun job avrà il compito di eseguire determinate funzioni di estrazioni di informazioni da un sistema sorgente, esempio da file Ascii o tabella Oracle, eseguire
eventuali trasformazioni sui dati estratti per poi scrivere i risultati su un sistema
destinatario. Ovviamente anche il sistema destinatario potrà essere un file, una tabella o comunque una struttura per ricevere dati. Le applicazioni Datastage, ovvero
i job, possono essere avviate in modalità real-time su richiesta specifica dell’utente,
oppure utilizzando dei particolari processi batch i quali permetteranno di attivarne
l’esecuzione in orari e giorni prestabiliti.
59
3 – IBM Datastage: uno strumento di elaborazione dati
La caratteristica importante e principale di Datastage è di riuscire a gestire spostamenti e modifiche dei valori di grosse quantità di dati in tempi molto rapidi. Per
essere il più possibile efficiente supporta le piattaforme hardware multiprocessore
che permettono di parallelizzare le operazioni di caricamento e trasformazione. Le
peculiarità appena descritte sono risultate fondamentali nella scelta di Datastage
come strumento da adottare nel nostro progetto di controllo dati.
Nel seguito saranno illustrati i componenti principali di Datastage. Ci focalizzeremo
maggiormente sugli strumenti specifici riguardanti le parti utilizzate nello sviluppo
del progetto Data Integrity che sarà descritto nel prossimo capitolo.
3.2
I componenti principali
Datastage è costituito da diversi componenti software le cui funzionalità operano
a livello differente: sono presenti applicazioni per la parte server ed altri per la parte
client.
La parte server include tutte le applicazioni di gestione dei servizi, dei repository e
delle area di lavoro per lo sviluppo dei progetti di Datastage. In questa categoria
abbiamo tre componenti specifici che svolgono i compiti appena descritti:
• il repository, che rappresenta l’area di memorizzazione contenente le informazioni di tutti i progetti Datastage presenti su uno specifico server;
• il server, che costituisce il “motore” di Datastage, di conseguenza è il componente che si occupa eseguire ed interpretare i job definiti nei vari progetti;
• il package installer, si tratta di un’interfaccia utente per installare package e
plug-in aggiuntivi.
Tra i componenti client troviamo tutte le applicazioni più operative, ovvero quelle
necessarie per la progettazione e la creazione delle applicazioni Datastage, includendo gli strumenti per la loro esecuzione e schedulazione.
L’obiettivo che si pone questo capitolo su Datastage è di introdurre brevemente i
componenti principali della parte client di Datastage nella quale sono inclusi tutti
60
3.2 – I componenti principali
gli strumenti che ho utilizzato per l’implementazione dell’applicazione di Data Integrity, necessaria per il controllo delle basi dati dell’azienda descritta nel caso di
studio.
Innanzitutto è necessario effettuare una distinzione tra i componenti client, dove
possiamo definire due categorie importanti:
• client per gli amministratori;
• client per gli sviluppatori.
Entrambe le tipologie di client sono dotate di un’interfaccia Desktop, quindi accessibile in modo semplice ed intuitivo.
Client per gli amministratori
Il client per gli amministratori è lo strumento che permette di gestire le aree
legate alle tematiche di sicurezza, alla gestione delle licenze, alla gestione delle operazioni di log e di scheduling di un singolo progetto di Datastage.
In questa categoria è presente un solo applicativo client: si tratta dell’applicazione
chiamata Datastage Administrator. Tramite l’Administrator si gestiscono e si mantengono i progetti sul server di Datastage. Questo client viene anche utilizzato per
impostare le proprietà dei progetti, per impostarne le variabili di sistema e per la
risoluzione di alcuni tipi di problemi. Per eseguire questi compiti lo strumento Administrator, attraverso la sua interfaccia grafica, permette di accedere al repository
dei progetti, su cui è possibile impostare i parametri dei diversi job, i privilegi dei
vari utenti che vi accedono e modificare particolari opzioni di schedulazione.
Client per gli sviluppatori
In questa tipologia di client sono presenti gli strumenti per creare, gestire e
progettare i job. Questi client includono anche tutte le procedure che vengono
utilizzate per le funzionalità di validazione, esecuzione, schedulazione e monitoring
dei job stessi.
I compiti svolti da questa categoria di client vengono ricoperti sostanzialmente da
tre applicazioni:
61
3 – IBM Datastage: uno strumento di elaborazione dati
1. il Designer, strumento che permette la progettazione e l’implementazione delle
applicazioni che abbiamo già chiamato job. Il Designer rappresenta il modulo
principale per gli sviluppatori, infatti al suo interno i job creati potranno
essere disegnati e poi compilati, diventando di fatto dei programmi eseguibili
e quindi avviabili. Questo client si presenta con un’interfaccia grafica che
permette di visualizzare in modo intuitivo gli oggetti inseribili in un job. Tali
oggetti rappresentano le operazioni da eseguire sui dati per le funzionalità di
estrazione, pulizia, trasformazione ed integrazione delle informazioni;
2. il Manager, che rappresenta un’interfaccia per accedere al repository di un
progetto Datastage consentendone l’esplorazione e la modifica degli oggetti
contenuti.
3. il Director, che è lo strumento che permette l’esecuzione in real-time e la
schedulazione dei job creati e compilati attraverso il Designer.
3.3
L’applicazione Designer
L’applicazione Designer consente, in modo intuitivo tramite un apposito pulsante, di creare un nuovo job. In alternativa alla creazione di uno nuovo job sarà
possibile sceglierne uno tra quelli già definiti per il progetto corrente, presente nella
finestra repository (riportata nella figura 3.1). Esistono differenti tipologie di job che
possiamo creare a seconda della versione di Datastage installata. Per quanto riguarda l’ambito del nostro progetto di Data Integrity è sufficiente illustrare le seguenti
categorie:
• i server job, sono le applicazioni che vengono eseguite sul server di Datastage e
consentono di eseguire connessioni, estrazioni e caricamento da e verso le basi
dati nei formati che abbiamo già definito in precedenza;
• le job sequence, sono le applicazioni che permettono di specificare una sequenza
di server job da eseguire e consentono di definire delle azioni da intraprendere
in base a risultati delle elaborazioni dei vari passi precedenti che compongono
una job sequence.
62
3.3 – L’applicazione Designer
Dopo la scelta di creazione di un job o il richiamo di uno già esistente, l’applicazione
Designer generalmente presenterà nella parte centrale la finestra di progettazione,
chiamata Diagram Window (visibile nella figura 3.1), dove sarà possibile inserire gli
oggetti all’interno dei server job o delle job sequence. In generale, oltre alla Diagram Window, saranno visualizzate altre due finestre molto importanti contenenti
rispettivamente l’elenco degli oggetti presenti nel repository del progetto e l’elenco
degli oggetti inseribili nei differenti job (anche queste due finestre sono presenti nella
figura 3.1). Attraverso la visualizzazione del contenuto del repository del progetto
corrente sarà possibile richiamare gli altri job già definiti, mentre con la finestra di
elenco oggetti saremo in grado di selezionare e trascinare nella Diagram Window gli
elementi da aggiungere nel job corrente.
Un’applicazione di Datastage, nell’esempio specifico un server job, consiste sostanzialmente in una serie di oggetti uniti tra loro attraverso degli elementi di collegamento chiamati link. L’insieme risultante descriverà il flusso di spostamento delle
informazioni da una base dati di input ad una di output. In generale, gli oggetti
inseribili in un server job possiedono un link di input e/o un link di output. Ciò non
esclude di avere anche degli oggetti specifici che possono ricevere più link di input
ed inviare informazioni su più link di output.
È importante ricordare che in base alla categoria del job correntemente visualizzato,
la finestra contenente l’elenco degli oggetti cambierà dinamicamente il suo contenuto,
visualizzando volta per volta solo gli oggetti che potranno essere inseriti nell’applicazione. Nello specifico possiamo inserire, per i server job, gli oggetti stage e link,
mentre per le job sequence avremo a disposizione le activity collegabili mediante i
link su cui sarà possibile definire dei trigger per attivare o meno tali activity.
63
3 – IBM Datastage: uno strumento di elaborazione dati
Repository
Diagram Window
Contiene la lista delle applicazioni
memorizzate in un progetto Datastage
E’ la finestra di progetto dove poter inserire
gli oggetti per comporre un’applicazione
Datastage
Lista oggetti
Contiene la lista degli oggetti che possono essere
inseriti in un’applicazione di Datastage
Figura 3.1. Datastage: screenshot Designer
64
3.4 – Server job
3.4
3.4.1
Server job
Stage
L’applicazione Designer offre differenti tipi di stage precostruiti da adoperare nei
server job. Questi elementi vengono di solito utilizzati per rappresentare basi di dati
sorgenti e destinatari. Sono presenti anche degli oggetti dedicati per le operazioni
specifiche di conversione di formato e contenuto sui dati.
Gli stage possono essere suddivisi in due tipologie: attivi o passivi. Quelli attivi
modellano il flusso delle informazioni fornendo dei meccanismi per operazioni di
passaggio, aggregazione, e conversione tra formati dei dati. Al contrario la tipologia passiva consente di accedere ai database o ai file per realizzare le operazioni di
estrazione o di scrittura dei dati. Da quanto detto ne consegue che sono gli stage
di tipo passivo che si occupano dell’effettiva lettura o scrittura di informazioni da o
verso una base dati. I riferimenti sui dettagli di connessione alla base dati e sulle effettive informazioni da prelevare od inserire sono definibili all’interno delle proprietà
del singolo stage specifico, il quale presenta una serie di opzioni configurabili dallo
sviluppatore.
Gli oggetti inseribili in un server job sono organizzati in differenti gruppi a seconda
delle funzioni che possiedono, in particolare abbiamo le seguenti categorie:
• Database
• File
• Plug-in
• Processing
• Real Time
Per concludere la breve descrizione dell’oggetto stage dei server job riporto questo dettaglio: nel progetto Data Integrity realizzato si è sempre utilizzato lo stage
appartenente al gruppo di Database, in particolare quello chiamato Oracle OCI (riferimento figura 3.2). Questa tipologia di stage ci ha permesso di collegarci ai diversi
65
3 – IBM Datastage: uno strumento di elaborazione dati
back-end di tipo Oracle presenti nell’azienda su cui abbiamo impostato le operazioni
di estrazione dati. Nello specifico per ogni entità da monitorare di ciascun sistema
abbiamo creato dei server job per poter implementare le operazioni di selezione,
estrazione e caricamento dati in opportune tabelle di appoggio.
Figura 3.2. Datastage: tipologie di stage Database
3.4.2
Link
I link rappresentano i collegamenti che permettono di unire i differenti stage
presenti in un server job. Servono, quindi, per specificare come i dati si dovranno
muovere nel momento in cui il server job sarà mandato in esecuzione. Un collegamento è rappresentato da un oggetto di tipo freccia che è costituito da un verso di
partenza ed uno di arrivo. Il verso di partenza rappresenta la parte chiamata output
link, mentre il verso di arrivo, ovvero la punta della freccia, rappresenta l’input link.
66
3.4 – Server job
Un link di input collegato ad uno stage di scrittura consentirà a quest’ultimo di
ricevere i dati prelevati da uno stage di lettura. Lo stage di scrittura ricevendo
questi dati, tramite il link di input, si occuperà di scriverli in determinate strutture
destinatarie. Al contrario, un output link si occuperà di inviare i dati letti tramite
un opportuno stage di selezione ed estrazione di informazioni, ovvero uno stage di
lettura. I dati selezionati da uno stage di lettura saranno inviati sullo specifico link
di output e tali informazioni prelevate saranno ricevute da uno stage di scrittura
attraverso un link di input, come precedentemente descritto.
Per gli stage di lettura e scrittura è importante realizzare la seguente operazione:
definire quali sono le colonne dei campi da considerare e decidere come questi devono essere mappati tra i due stage. In particolare, la definizione delle colonne sullo
stage di scrittura collegato all’input link permetterà di definire i campi che dovranno
essere scritti sulla base dati ricevente. Mentre la definizione delle colonne dello stage
di lettura collegato all’output link servirà per definire i campi che dovranno essere
letti dalla base dati mittente (riferimento figura 3.3).
I server job supportano due tipologie di input link:
• stream, si tratta di un link che rappresenta un flusso di dati, questo è il
principale tipo di link e viene utilizzato per gli stage sia di tipo attivo che
passivo;
• reference, si tratta di un link che viene utilizzato solo per gli stage di tipo attivo
per fornire informazioni su come i dati devono essere cambiati nel passaggio
da una base dati mittente ad una destinataria, hanno una funzione similare
alle tabelle di lookup.
Le due tipologie di link sono rappresentate nell’applicazione Designer in modo differente: gli stream link sono rappresentati da frecce continue, mentre i link di tipo
reference si riconoscono perché sono costituiti da delle frecce tratteggiate.
Riporto nella figura 3.3 un esempio di server job, in cui sono presenti due stage di
tipo Database (uno di lettura ed uno di scrittura) per estrazione ed inserimento dati
su database Oracle, collegati mediante uno stream link per definire la direzione degli
spostamenti dei dati.
67
3 – IBM Datastage: uno strumento di elaborazione dati
Stage di lettura
Stage di scrittura
con cui estrarre i dati dal
sistema sorgente
con cui scrivere i dati sul
sistema ricevente
Link (parte di output)
Link (parte di input)
dove transitano i dati
prelevati dallo stage di lettura
dove arrivano i dati letti dallo
stage di lettura e vengono
scritti sullo stage di scrittura
Figura 3.3. Datastage: screenshot server job
68
3.5 – Job sequence
3.5
Job sequence
Servono per specificare una sequenza di server job / job sequence da mandare in
esecuzione. Una sequenza può contenere informazioni di controllo, in particolare è
possibile prendere determinate decisioni se un job all’interno della sequenza è stato
eseguito con successo oppure no. Le decisioni che si possono prendere possono essere,
ad esempio, la continuazione nell’esecuzione del prossimo server job, l’invio di una
e-mail di segnalazione, il lancio di un’eccezione, ecc.
La progettazione di una sequence è molto simile alla creazione di un server job. La
differenza principale che si riscontra è la seguente: al posto degli stage abbiamo le
activity le quali sono collegate una con l’altra attraverso dei link. Sui link è possibile
definire delle condizioni di trigger, necessarie per attivare o meno una determinata
activity. Ogni activity possiede delle proprietà che possono essere testate come
espressioni in trigger per decidere se andare avanti nella sequenza o meno. Alle
activity possono essere passate, se necessario, dei parametri.
3.5.1
Activity
Le job sequence supportano le seguenti tipologie di activity:
• job, per specificare un server job od un’altra job sequence;
• routine, per specificare una routine;
• execCommand, per specificare un comando di sistema da eseguire;
• emailNotification, per inviare una mail con il protocollo SMTP;
• waitForFile, per attendere la presenza oppure l’assenza di un file in una cartella
(funziona da semaforo);
• run-activity-on-exception, da eseguire quando la sequence genera un’eccezione.
69
3 – IBM Datastage: uno strumento di elaborazione dati
3.5.2
Trigger
Il flusso di controllo della job sequence dipende da come sono interconnesse le
activity dai vari link e come sono state impostate le condizioni sui trigger. Sono
presenti tre tipologie di trigger:
• conditional, una condizione di trigger viene attivata per passare alla prossima
activity collegata se le condizioni impostate per il trigger sono state soddisfatte;
• unconditional, non viene controllata alcuna condizione e si passa alla prossima
activity, ovvero quella destinataria, appena termina l’activity precedente;
• otherwise, quest’ultima viene utilizzata come default quando una activity
sorgente possiede più output trigger, ma nessuno dei trigger condizionali è
scattato.
Nella figura figura 3.4 viene riportato un esempio di job sequence dove sono state evidenziate alcune activity e per una di queste, nello specifico l’activity
Controllo_Caricamenti, sono visibili le condizioni di trigger.
70
3.5 – Job sequence
Activity
Condizioni di trigger
Figura 3.4. Datastage: screenshot job sequence
71
3 – IBM Datastage: uno strumento di elaborazione dati
3.6
L’applicazione Manager
Nell’applicazione Manager abbiamo la visibilità di tutti gli oggetti facenti parte
del progetto a cui siamo collegati. In particolare sono visibili i job, le sequence, la
definizione delle tabelle di input / output e le eventuali routine create.
Questa applicazione permetterà di effettuare le classiche operazioni di gestione degli
oggetti all’interno dei progetti Datastage, come le operazioni di copia, di rinomina,
di eliminazione degli oggetti, ecc. Facendo riferimento al progetto di Data Integrity
implementato, l’applicativo Manager è stato utilizzato soprattutto per le operazioni
di backup di tutti gli oggetti del progetto su file in modo da salvaguardare il lavoro
fino a quel momento realizzato.
Il Manager, oltre alla gestione degli oggetti di un progetto, può ritornare utile per
specificare le proprietà sui server job e le job sequence. Tali proprietà possono essere definite anche all’interno dell’applicazione Designer ma attraverso l’utilizzo nel
Manager è possibile accedere in modo più rapido su queste proprietà per tutti gli
oggetti del progetto.
Per concludere, è utile ricordare che in questo specifico client è presente una procedura chiamata Usage Analysis con cui è possibile verificare le relazioni di un oggetto
con tutti gli altri presenti nel progetto. In particolare, tale strumento è risultato
molto comodo per capire, in modo rapido, se un determinato server job è stato
incluso o meno in una job sequence.
3.7
L’applicazione Director
Questa applicazione permette di avviare, manualmente o tramite l’utilizzo di
funzioni di schedulazione, i job e le sequence di un progetto di Datastage. Con il
client Director è possibile anche accedere e visionare le informazioni di tutti i log
registrati sulle diverse applicazioni.
La finestra del client Director consente di visualizzare l’elenco dei server job e delle
job sequence di uno specifico progetto Datastage. In particolare è possibile scegliere
tra tre tipologie di viste differenti:
72
3.7 – L’applicazione Director
• job status, che rappresenta la vista di default in cui vengono visualizzati gli
stati di tutti i job;
• job schedule, per visualizzare un riepilogo dei job su cui è stata impostata una
schedulazione automatica;
• job log, che rappresenta la visualizzazione del dettaglio del log di uno specifico
job selezionato.
Attraverso la vista job status è possibile, come abbiamo detto, visualizzare gli stati
dei vari job, in particolare quelli di nostro interesse sono i seguenti:
• compiled, il job è stato compilato ma non è stato più eseguito dopo la compilazione;
• not compiled, il job è ancora in fase di sviluppo e non è stato ancora compilato;
• running, il job è correntemente in esecuzione;
• finished, il job è terminato;
• finished (see log), il job è terminato ma ci sono dei messaggi di warning che
converebbe controllare;
• stopped, il job è stato fermato dall’utente;
• aborted, il job è andato in errore;
• has been reset, il job è stato reinizializzato, operazione da fare necessariamente
dopo una situazione di aborted.
Quindi, per concludere, attraverso l’utilizzo dell’applicazione Director abbiamo la
possibilità:
• di mandare in esecuzione un job che si trova in una stato avviabile come
compiled, finished o has been reset;
• di interrompere un job che si trova in stato di running;
73
3 – IBM Datastage: uno strumento di elaborazione dati
• di effettuare un’operazione di reset su un job che si trova in stato di stopped
o aborted.
Tutte le operazioni appena citate sono facilmente eseguibili attraverso dei pulsanti
intuitivi presenti nella barra degli strumenti del Director e visibili nella figura 3.5.
74
3.7 – L’applicazione Director
Pulsante di avvio
Pulsante di stop
Pulsante di reset
Stato del job
Figura 3.5. Datastage: screenshot Director
75
Capitolo 4
Realizzazione di un progetto di Data
Integrity per un’azienda pubblicitaria
Il progetto di Data Integrity è stato realizzato con l’obiettivo di mettere a disposizione dei meccanismi di verifica di allineamento sui dati presenti nei sistemi
informativi, ed in parte coinvolti nella migrazione verso SAP, all’interno dell’azienda pubblicitaria oggetto di questo caso di studio. Il progetto è stato realizzato
all’interno del gruppo di Reply che si occupa delle problematiche di integrazione
EAI per tale azienda. La collaborazione con il gruppo EAI è stata di fondamentale
importanza sia per la fase di analisi che di sviluppo. Infatti, lavorando a stretto contatto con chi si occupa direttamente dell’integrazione dei sistemi è stato possibile
definire in modo puntuale le entità da monitorare, risolvendo in modo rapido anche
le problematiche di accesso ai vari sistemi back-end.
La finalità principale di questa soluzione di Data Integrity è di fornire un supporto
per mantenere la congruenza dei dati distribuiti sui vari back-end, in modo tale che
le applicazioni front-end eroghino i servizi e le funzionalità previste senza errori o
disfunzioni. La segnalazione degli errori presenti sui dati distribuiti sui vari sistemi
deve essere utilizzata come ausilio per intervenire e prevedere delle opere di correzione sui diversi back-end, cercando di anticipare i possibili problemi che potrebbero
essere evidenziati dagli utenti delle applicazioni in caso di disallineamenti. Quindi, se
l’applicazione di Data Integrity sarà in grado di fornire, in modo tempestivo, queste
77
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
informazioni di anomalie sui dati sarà possibile evitare di dovere eseguire i recuperi
e le operazioni di riallineamento solo dopo le segnalazioni di malfunzionamento da
parte degli utenti, migliorando di conseguenza il servizio offerto dall’intera struttura
informativa. Inoltre, gli utenti avranno la sensazione di una migliore affidabilità dei
sistemi dovuta alla probabile diminuzione degli errori applicativi.
Un’applicazione di Data Integrity in una grossa azienda, dove generalmente sono presenti molti sistemi informativi, permette di salvaguardare, con strumenti di controllo
e segnalazione, la qualità e validità delle informazioni possedute. Più i dati sotto
monitoraggio risulteranno corretti maggiore sarà la funzionalità delle applicazioni.
4.1
I sistemi controllati
In questa sezione sono riportati i sistemi su cui vengono eseguite le operazioni di
verifica allineamento dei dati, giustificandone la presenza all’interno del complesso
sistema informativo aziendale:
• SAP è il sistema amministrativo preposto alla gestione del ciclo attivo/passivo (emissione richieste di acquisto, ordini, contratti), della contabilità, del
magazzino, dei dipendenti e delle strutture organizzative;
• SEM è il sistema che permette una produzione editoriale multimediale integrata e flessibile per tutte le esigenze pubblicitarie del cliente, indipendentemente
dal media utilizzato;
• TCC serve per la gestione particolare dei contratti cartacei: si tratta di un
sistema per garantire che oltre al contratto in formato digitale, sia inviata
dagli agenti all’azienda, anche la copia cartacea dello stesso;
• CLIC è il vecchio sistema amministrativo che sarà sostituito da SAP;
• CDB si tratta di un sistema CRM analitico che serve all’azienda per il suo
business particolare: contiene informazioni di dettaglio sui clienti per fornire
più valore a chi cerca le informazioni;
• DBLocal è un sistema utilizzato per la parte relativa ai call center.
78
4.1 – I sistemi controllati
Tutti i sistemi sopra riportati condividono specifiche entità, come contratti, annunci, anagrafiche, ecc., che devono essere mantenute allineate per garantire il funzionamento dell’architettura informativa. Ad esempio, l’entità relativa ai contratti è
presente sia sul sistema SAP che su SEM: sarà molto importante mantenerla correttamente allineata per non incorrere in errori delle applicazioni front-end che faranno
richiesta dei dati di un contratto presente su entrambi i sistemi.
Riporto nella Tabella 4.1 tutti i controlli sulle entità che sono stati implementati tra
i differenti back-end. È importante sottolineare che le verifiche eseguite sono state
realizzate tra coppie di sistemi, ovvero confrontando i dati, a livello di record, di un
back-end con un altro sulle entità condivise.
Coppia di sistemi
Entità condivise / controllate
SAP-SEM
Contratti, Annunci, Sigle
CLIC-SAP
Contratti, Annunci, Campagne pubblicitarie
SAP-TCC
Contratti, Annunci
SAP-DBLocal
Contratti, Annunci, Campagne pubblicitarie
CDB-SAP
Anagrafiche, Sedi
CLIC-SEM
Contratti, Annunci, Sigle
Tabella 4.1. Progetto Data Integrity: controlli suddivisi per coppia di sistemi / entità
La scelta dei sistemi da monitorare è stata presa in accordo tra i tecnici di
Reply che si occupano dell’architettura EAI di quest’azienda e le figure responsabili
dei vari sistemi informativi coinvolti in questo progetto di Data Integrity. Nell’elenco
riportato nella tabella 4.1 il sistema citato per primo, in generale, è quello detentore
del dato mentre il secondo è quello ricevente. Con la coppia SAP-SEM si intende
che SAP possiede i dati aggiornati dei contratti, degli annunci e delle sigle, mentre
SEM, tramite flussi di integrazione EAI, riceve gli aggiornamenti da SAP.
79
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
Nel seguito riporto, per ciascuna coppia di sistemi, le tipologie di controlli effettuati
sulle entità condivise. In particolare, il controllo di assenza è associato alla mancanza
del record su uno dei due sistemi, mentre per ricerca di disallineamenti dovuti a
differenza è inteso la presenza di valori diversi (considerando le opportune variazioni
per le transcodifiche) di almeno un campo di un record oggetto di controllo.
Entità
Contratti
Annunci
Sigle
Controllo assenza
Sì
Sì
No
Controllo differenza
Sì
Sì
Sì
Tabella 4.2. Tipologia di controlli entità per la coppia di sistemi SAP-SEM
Entità
Contratti
Annunci
Campagne pubblicitarie
Controllo assenza
Sì
Sì
Sì
Controllo differenza
Sì
Sì
No
Tabella 4.3. Tipologia di controlli entità per la coppia di sistemi CLIC-SAP
Entità
Contratti
Annunci
Controllo assenza
Sì
Sì
Controllo differenza
Sì
Sì
Tabella 4.4. Tipologia di controlli entità per la coppia di sistemi SAP-TCC
80
4.1 – I sistemi controllati
Entità
Contratti
Annunci
Campagne pubblicitarie
Controllo assenza
Sì
Sì
Sì
Controllo differenza
Sì
Sì
No
Tabella 4.5. Tipologia di controlli entità per la coppia di sistemi SAP-DBLocal
Entità
Anagrafiche
Sedi
Controllo assenza
Sì
Sì
Controllo differenza
Sì
Sì
Tabella 4.6. Tipologia di controlli entità per la coppia di sistemi CDB-SAP
Entità
Contratti
Annunci
Sigle
Controllo assenza
Sì
Sì
No
Controllo differenza
Sì
Sì
Sì
Tabella 4.7. Tipologia di controlli entità per la coppia di sistemi CLIC-SEM
81
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
4.2
Descrizione del progetto
Per la realizzazione del progetto è stato scelto di caricare periodicamente, in
modo massivo, tutte le basi dati, che si è deciso di tenere sotto controllo e di cui
abbiamo già parlato, su una struttura di appoggio, così come è mostrato nella figura
4.1. I dati estratti dai vari sistemi vengono memorizzati in un database Oracle,
che per standard aziendali è stato chiamato DBADI1DATAINT. Questo archivio
conterrà, in apposite tabelle di replica, le entità dei vari sistemi sui cui dovremo
controllare la coerenza delle informazioni. Infatti, proprio su queste tabelle, caricate
con applicazioni Datastage e script specifici, che avverranno tutte le operazioni di
aggiornamento e confronto di congruenza dei dati, così come è illustrato nella figura
4.2.
Per la realizzazione della parte che abbiamo appena descritto, ovvero il caricamento
e controllo dati, sono stati utilizzati i seguenti componenti:
• una base dati grande e affidabile per memorizzare le informazioni associate
a determinate entità prelevate dai sistemi, in particolare, come abbiamo già
detto, si utilizza un database Oracle su cui vengono effettuate quotidianamente
le operazioni di caricamento. Questo database, chiamato DBADI1DATAINT,
oltre a contenere le repliche delle tabelle dei diversi sistemi, conterrà le tabelle
degli esiti relativi ai vari confronti effettuati, includendo anche delle tabelle di
storico esiti per mantenere traccia dei disallineamenti risolti;
• stored procedure e funzioni create nel linguaggio PL/SQL. Queste procedure e
funzioni, tramite l’utilizzo dei cursori, sono state utilizzate per la realizzazione
degli algoritmi di aggiornamento dati sulle tabelle di replica e per l’implementazione degli algoritmi di confronto; tali stored procedure e funzioni sono
memorizzate in opportuni package presenti sul database DBADI1DATAINT;
• job sequence e server job di Datastage. Mediante il loro utilizzo sono stati
realizzati la maggiore parte dei connettori specifici per l’estrapolazione dei
dati dai vari sistemi da controllare. I job di Datastage permettono l’accesso al
back-end specifico di un sistema e tramite la definizione di opportune query di
82
4.2 – Descrizione del progetto
SAP
LOAD_TABELLE_SAP
LOAD_TABELLE_SEM
SEM
TCC
DB
di replica dei
sistemi esiti sui controlli
di allineamento
LOAD_TABELLE_CLC
LOAD_TABELLE_TCC
DBADI1DATAINT
CLIC
CDB
LOAD_TABELLE_CDB
LOAD_TABELLE_DBL
DBL
Job sequence Datastage per attivare le operazioni di caricamento delle varie
entità per ciascun sistema
SCRIPT SQL*Loader per effettuare il caricamento a partire da file di testo
Figura 4.1. Progetto Data Integrity: caricamento sistemi sul database centralizzato
83
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
Aggiornamento dati sulle
entità da controllare
(aggiornamento transcodifiche calcolo codice hash)
Procedure PL/SQL
2
1
AGGIORNA_DATI
Evento
esterno
DB
di replica dei
sistemi esiti sui controlli
di allineamento
CHECK_SYSA_SYSB
DBADI1DATAINT
3
Calcolo disallineamenti
ricerca record assenti e
differenti tra le entità controllate archiviazione delle anomalie
non più presenti
4
Procedure PL/SQL
ESEGUI_CONTROLLI
Job sequence Datastage per coordinare le operazioni di aggiornamento e
controllo allineamento dati su una coppia di sistemi (SYSA - SYSB)
Server job Datastage per attivazione delle procedure PL/SQL utilizzate per
l’aggiornamento dati ed il calcolo disallineamenti
Figura 4.2. Progetto Data Integrity: esecuzione degli algoritmi di aggiornamento - controllo dati
84
4.2 – Descrizione del progetto
selezione permettono di prelevare i soli dati di interesse che saranno caricati
giornalmente sulle tabelle di replica del database Oracle DBADI1DATAINT
(riferimento figura 4.1). I job di Datastage sono stati impiegati anche per
richiamare le procedure e funzioni PL/SQL utilizzate per l’aggiornamento ed
il confronto dei dati prelevati dai vari sistemi e memorizzati sulle tabelle di
replica del database DBADI1DATAINT (riferimento figura 4.2).
È necessario sottolineare che non tutti i dati, prelevati dai sistemi da controllare,
sono stati estratti tramite l’utilizzo dei server job di Datastage. Sono presenti delle
eccezioni, in particolare per due basi dati non Oracle (CLIC e DBLocal), per cui
sono state realizzate delle procedure di estrazione ad hoc. Sono state create delle
funzioni che consentono di effettuate degli scarichi massivi dei valori di interesse
dalle tabelle su file. Da questi file, tramite opportune procedure SQL*Loader1 , sono
state realizzate le operazioni di caricamento sul database DBADI1DATAINT.
È stato scelto di prelevare i dati dalle tabelle dei sistemi da monitorare, replicandoli su di un database centralizzato (DBADI1DATAINT), perché si è cercato
di minimizzare il più possibile il carico elaborativo sui sistemi possessori dei dati,
i quali sono già sollecitati dalle diverse applicazioni front-end e dalle operazioni di
integrazione. Per impattare il meno possibile su questi back-end è stato deciso di
impostare i caricamenti massivi sul database DBADI1DATAINT, sia tramite Datastage che con le procedure ad hoc, in orari notturni. Infatti, in quella fascia oraria
i back-end sono meno sollecitati dalle applicazioni front-end e non prevedono particolari applicazioni di integrazione. In tale periodo abbiamo il momento migliore
per prelevare delle “fotografie” dai sistemi su cui andare ad effettuare i controlli di
allineamento dati.
Lo scopo della fase di controllo dati è di generare dei risultati contenenti le anomalie
riscontrate, considerando i casi di assenza dei record di un’entità e di differenza su
uno o più campi dell’entità stessa. Visto che i caricamenti avvengono negli orari
notturni, le anomalie riscontrate potranno essere disponibili in tarda mattinata o al
1
Utilità per caricare velocemente dati memorizzati in file di testo su database Oracle.
85
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
più nel primo pomeriggio del giorno in cui è stato avviato il controllo di coerenza. In
questo modo, appena terminato il confronto ed ottenute le anomalie, sarà possibile
prendere eventuali contromisure in caso di presenza di particolari errori e differenze
sui dati. L’utilizzo di questi risultati servirà per effettuare le opportune segnalazioni
ai diretti responsabili dei sistemi informativi e decidere le possibili mosse correttive.
Per realizzare la parte di monitoraggio delle anomalie riscontrate, dagli algoritmi di
controllo, vengono utilizzati i seguenti strumenti:
1. dei report di riepilogo, dove i dati delle anomalie vengono estratti dalle tabelle
degli esiti ed aggregati in questi specifici report, creati in modo automatico,
tramite il richiamo di un servizio custom aziendale2 , dopo la fase di controllo
di allineamento per una coppia di sistemi;
2. un’applicazione WEB, che rappresenta l’interfaccia con cui sono sempre fruibili i disallineamenti sui dati dei sistemi controllati, memorizzati nel database
DBADI1DATAINT. Le informazioni visualizzabili tramite l’interfaccia WEB
sono dei riepiloghi aggregati e delle informazioni di dettaglio sui disallineamenti. Lo scopo dell’applicazione WEB è, quindi, di fornire una visualizzazione degli esiti dei controlli sui disallineamenti in modo sia riepilogativo che
dettagliato.
La figura 4.3 riporta i due strumenti appena descritti, ovvero un esempio di report
e l’applicazione WEB, utilizzati per il controllo dei risultati prodotti dalle verifiche
di allineamento dei dati.
2
Servizio a cui è possibile passare un template di report e genererà in output un documento
Excel.
86
4.2 – Descrizione del progetto
Generazione report sui
disallineamenti
memorizzati sul database
degli esiti
(DBADI1DATAINT)
WEB application per:
• esporre i risultati ottenuti dagli algoritmi di
confronto esiti per ogni coppia di sistemi
• scaricare i report sui disallineamenti
DB
di replica dei
sistemi esiti dei controlli
di allineamento
DBADI1DATAINT
Figura 4.3. Progetto Data Integrity: strumenti di monitoraggio
87
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
4.3
Il database delle repliche e degli esiti
Tabelle di replica
Per memorizzare le informazioni relative alle
entità dei sistemi da controllare. Ogni entità di
ciascun sistema è memorizzata in una tabella
apposita, in cui sono presenti i soli campi oggetto
di controllo allineamento.
Tabelle degli esiti
DB
di replica dei
sistemi esiti sui controlli
di allineamento
DBADI1DATAINT
Per memorizzare i disallineamenti riscontrati sulle
varie entità dei sistemi controllati. Per ogni coppia di
sistemi / entità è presente una tabella di esiti per
memorizzare i disallineamenti riscontrati
dall’algoritmo di confronto. In queste tabelle è
presente un campo specifico per riconoscere il tipo
anomalia (A=Assenza del record, D=Differenza in
almeno un campo)
Tabelle di storico
Per memorizzare i disallineamenti non più presenti.
Sono tabelle che tengono traccia delle anomalie che
sono state risolte e di conseguenza non più
riscontrate dall’algoritmo di controllo.
Package
Contiene le stored procedure e funzioni da
richiamare per svolgere le funzioni di aggiornamento
dati e calcolo disallineamenti
3 tipologie principali di stored procedure / funzioni:
-Aggiornamento dati per transcodifiche, prima di
calcolare il codice hash ed eseguire gli algoritmi di
confronto
-Calcolo hash utilizzato per il controllo differenze
-Calcolo disallineamenti
Figura 4.4. Progetto Data Integrity: database delle repliche e degli esiti
88
4.3 – Il database delle repliche e degli esiti
Come è illustrato nella figura 4.4 il database Oracle DBADI1DATAINT, utilizzato come parte di repository dell’applicazione di Data Integrity, è stato realizzato
con lo scopo di:
• ospitare le tabelle di replica delle entità presenti sui sistemi che sono oggetto
di controllo;
• ospitare le tabelle contenenti i risultati dei controlli di allineamento dati, ovvero quelle contenenti gli esiti relativi alle verifiche effettuate sui dati prelevati
dai diversi sistemi;
• ospitare le tabelle di storico esiti per memorizzare le anomalie che risultano
essere state risolte e che possiamo definire chiuse.
In aggiunta alle tabelle appena descritte, questo database contiene anche i package
Oracle dove sono presenti le stored procedure e le funzioni PL/SQL utilizzate per
le operazioni di aggiornamento e controllo allineamento dei dati prelevati dai vari
sistemi.
Le tabelle di replica possiedono tutti i campi necessari per memorizzare i record
prelevati dalle basi dati sorgenti che saranno oggetto di confronto. Per questo motivo
i campi all’interno delle tabelle di replica sono stati creati seguendo, in linea generale,
la stessa struttura, per quanto riguarda il tipo e la dimensione del campo, del dato
originale presente sul sistema di partenza.
Per quanto riguarda le tabelle predisposte alla memorizzazione degli esiti queste
sono state progettate per memorizzare le anomalie rilevate di un’entità tra due
sistemi. Ad esempio, il controllo di coerenza delle informazioni dei contratti tra il
sistema SAP e SEM ha una tabella specifica per memorizzare le anomalie riscontrate.
Nella tabella verranno memorizzati i dati assenti e differenti risultanti dal confronto
SAP-SEM. È presente anche una tabella, molto simile nelle caratteristiche a quella
degli esiti dei contratti tra SAP e SEM, che viene utilizzata per memorizzare le
informazioni di storico dove si manterranno le anomalie risolte.
In ogni tabella contenente gli esiti, considerando anche quelle di storico, sono presenti
89
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
dei campi che ci forniscono informazioni sull’anomalia riscontrata. In particolare
abbiamo:
• un campo specifico (chiamato [prefisso_tabella]3 _tipo_anom_cod) per determinare il tipo di anomalia rilevata; in particolare tale campo assumerà i
seguenti valori: ’A’ per un’anomalia dovuta all’assenza del dato e ’D’ per
l’anomalia dovuta alla differenza su uno o più campi oggetto di controllo;
• un campo per specificare il sistema possessore del dato (chiamato [prefisso_tabella]_SYS_A) da cui si prelevano i valori e si controllano con l’altro
sistema, quello che dovrebbe possedere l’informazione congruente;
• un campo per specificare il sistema (chiamato [prefisso_tabella]_SYS_B) che
dovrebbe avere lo stesso dato del sistema possessore;
• un campo (chiamato [prefisso_tabella]_stat_cod) per specificare se l’anomalia
è aperta, quindi ancora presente, o chiusa, ovvero non più presente;
I due campi relativi ai sistemi, SYS_A e SYS_B (omettendo la parte di prefisso
tabella), sono importanti perché consentono di capire dove si è riscontrata l’anomalia. Ad esempio, se sull’entità contratti tra SAP-SEM sono presenti le seguenti
informazioni:
• tipo_anom_cod=’A’, SYS_A =’SAP’, SYS_B =’SEM’, si tratta di un’anomalia assenza che rappresenta la mancanza di un contratto su SEM;
• tipo_anom_cod=’D’, SYS_A =’SAP’, SYS_B =’SEM’, si tratta di un’anomalia differenza che rappresenta la differenza su uno o più campi del contratto
memorizzato su SEM;
3
Tutti i campi delle tabelle del database DBADI1DATAINT devono iniziare con 4 caratteri fissi
associati al nome della tabella di appartenenza. È lo standard aziendale.
90
4.4 – Le procedure e funzioni PL/SQL
4.4
4.4.1
Le procedure e funzioni PL/SQL
Introduzione
Nel linguaggio PL/SQL è presente un meccanismo per elaborare i risultati delle
query orientato alle tuple. Per realizzare questo meccanismo vengono utilizzati i
cursori. Nello specifico, un cursore è una sorta di puntatore al risultato di una query
e questo viene impiegato per scorrere e leggere i valori dei campi associate alle righe
selezionate.
La presenza dei cursori all’interno del linguaggio PL/SQL mi ha permesso, in modo
agevole, di creare le procedure di aggiornamento e di controllo dei dati associate
alle entità da monitorare con l’applicazione di Data Integrity. Ad esempio, per
quanto riguarda l’aggiornamento dei dati, per la problematica delle transcodifiche,
viene utilizzato un cursore sulla tabella associata all’entità prelevata dal sistema di
partenza. Questo cursore permette di scorrere in modo rapido tutto l’insieme dei
dati memorizzati e per tutti i campi che necessitano di essere aggiornati è possibile
richiamare delle funzioni di transcodifica specifiche a seconda del tipo confronto.
Inoltre, utilizzando sempre i cursori, ho implementato con opportune procedure
gli algoritmi di confronto necessari per la ricerca di anomalie dovute all’assenza e
differenza sui dati. Questi algoritmi, creati nel linguaggio PL/SQL, sono richiamati
dai server job progettati e definiti nella parte di progetto di Datastage, che sarà
descritta più avanti.
4.4.2
Aggiornamento dati
I dati prelevati dai vari sistemi, come abbiamo già anticipato, non possono essere
controllati non appena terminata l’operazione di caricamento. Sui dati memorizzati
nelle tabelle di replica devono essere prima eseguite delle funzioni/procedure di aggiornamento che hanno compiti ben specifici: aggiornare le transcodifiche sui campi
e calcolare un codice hash per la rilevazione delle differenze.
91
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
Aggiornamento transcodifiche
Si tratta delle funzioni che si occupano di aggiornare i dati per quanto riguarda
le transcodifiche sui campi in modo che la semantica presente sulle informazioni
da confrontare sia congruente. L’obiettivo di questo tipo di funzioni è di fare in
modo che il valore di uno specifico campo tra i due sistemi da controllare sia lo
stesso, a meno ovviamente di errori in uno dei due. Le funzioni di transcodifica
dei campi sono state realizzate in base ai confronti sulle coppie dei sistemi. Ad
esempio, sul sistema SAP le entità contratti ed annunci devono essere confrontate
con i sistemi SEM, TCC, DBLocal e CLIC. Di conseguenza, sono presenti delle
funzioni di aggiornamento transcodifiche per i campi delle entità contratti ed annunci
di SAP per il confronto con SEM, altre funzioni per il confronto SAP-TCC, altre
ancora per il confronto SAP-DBLocal e così via.
Calcolo codice hash
Questa categoria di procedure, invece, si occupa di calcolare un codice hash
([prefisso_tabella]_hash_val_cod) relativo a i campi che rientrano nelle politiche
di confronto tra i sistemi. Attraverso l’utilizzo di questo accorgimento è stato possibile semplificare gli algoritmi di confronto, controllando nella fase di ricerca differenze
solo il codice hash calcolato anziché implementare un controllo campo per campo;
soluzione quest’ultima che avrebbe comportato la scrittura di un codice molto più
lungo ed avrebbe aumentato il rischio di introdurre bachi.
Il controllo delle anomalie sulle differenze avviene, quindi, sul codice hash calcolato,
la differenza di tale codice sulla stessa entità, per i due sistemi oggetto di controllo,
comporterà la memorizzazione di un record di disallineamento. Nella tabella degli
esiti per evidenziare la presenza di una differenza di due valori diversi sullo stesso
campo questi saranno concatenati e memorizzati all’interno della tabella degli esiti
separandoli con il carattere ’|’. Dalla scelta effettuata ne consegue che la presenza del carattere ’|’ all’interno dei campi delle tabelle degli esiti rappresenterà, in
modo immediato ed anche di facile ricerca, tramite l’utilizzo dell’operatore SQL LIKE(’%|%’), l’esistenza di una differenza tra i valori dei due sistemi confrontati.
Il funzionamento della procedura è abbastanza semplice: tramite l’utilizzo di un
92
4.4 – Le procedure e funzioni PL/SQL
cursore associato alla tabella contenente l’entità di un sistema, si leggeranno i vari
record e per ciascuno sarà effettuato il calcolo del codice hash, utilizzando come base
di input della funzione hash i campi da controllare. Inoltre sarà possibile chiamare
contestualmente alla funzione di hash anche le funzioni di transcodifica, descritte in
precedenza, sui campi coinvolti. Il vantaggio di operare in questo modo sta nel fatto
di condensare in un’unica procedura le operazioni di aggiornamento dati e calcolo
codice hash, risparmiando di fatto il tempo di elaborazione.
4.4.3
Controllo coerenza dati
I confronti vengono fatti a partire dal sistema possessore del dato verso quello
che dovrebbe avere la stessa informazione, ovvero verso il ricevente, il quale viene
aggiornato tramite applicazioni di integrazione EAI. Di conseguenza, si controllerà se
l’informazione, sotto forma di record, contenuta sul sistema possessore è presente o
meno sul ricevente. Nel caso in cui l’informazione venga trovata sul sistema ricevente
si verificherà se i campi, oggetto di controllo, saranno uguali oppure no. Nella tabella
degli esiti si memorizzeranno le assenze dei dati dati del sistema ricevente rispetto
a quello possessore e le differenze riscontrate sui dati presenti in entrambi.
Per fare quanto appena descritto, superata la fase di aggiornamento transcodifiche e
valorizzazioni dei codici hash sulle varie entità, sarà necessario avviare gli algoritmi
che hanno il compito di svolgere le funzioni di quadratura dei dati, inteso come
allineamento dati. Questi algoritmi si occupano di rilevare i disallineamenti di una
specifica entità (contratti, annunci, ecc) tra due sistemi per volta. In base alle regole
di business e di integrazione è stato definito il sistema possessore e ricevente dei dati
per ciascuna entità. Quindi, saranno effettuati i confronti tra i sistemi possessori
con i diversi riceventi, come abbiamo già illustrato in precedenza.
È importante precisare che non tutti i dati devono essere presenti su entrambi i
sistemi per una specifica entità, in quanto per regole di business esistenti certe
informazioni non devono arrivare o per via delle tempistiche di adozione di un sistema
rispetto ad un altro è possibile che certi dati non siano stati mai inviati. Ad esempio,
esistono contratti, aventi determinate caratteristiche, presenti sul sistema SAP che
non vengono passati a SEM per logiche di business. Quanto detto ha il seguente
93
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
effetto: nella fase di controllo di ricerca assenze si dovranno escludere dal confronto
tali record, altrimenti si forniranno dei falsi disallineamenti, che possiamo chiamare
falsi positivi. È importante definire in modo accurato quali sono i filtri da adottare
nella selezione dei record da confrontare per la ricerca delle assenze.
Una volta che si sono sistemate correttamente le logiche di confronto, i disallineamenti individuati vengono registrati periodicamente in queste tabelle di esiti,
create in modo specifico per coppia di sistemi ed entità. Contestualmente all’operazione di controllo, vengono eseguiti dei movimenti di storicizzazione delle anomalie
non più presenti rispetto alla verifica in corso.
Descrizione dell’algoritmo di confronto dati
In questo paragrafo si intende descrivere per passi le operazioni svolte dall’algoritmo di confronto. Per ogni entità controllata sulla coppia di sistemi è stata creata
una procedura apposita che implementa lo schema logico che sarà a breve illustrato.
L’algoritmo di confronto realizzato è costituito dai seguenti passi.
1. Spostamento dei dati degli esiti di un’entità nella relativa tabella di storico.
In questa fase sono previste le seguenti operazioni:
• un inserimento nella tabella di storico dei dati presenti in quella degli esiti
dell’entità da controllare;
• una cancellazione dei dati presenti nella tabella degli esiti dell’entità da controllare;
2. Selezione ed inserimento nella tabella degli esiti dei disallineamenti dovuti ad
assenza di record sull’entità, riscontrati nel confronto tra due sistemi.
94
4.4 – Le procedure e funzioni PL/SQL
In questa fase sono previste le seguenti operazioni:
• una selezione dei dati, con gli opportuni filtri, presenti sul sistema possessore
ed assenti sul sistema ricevente;
• i dati selezionati al passo precedente sono caricati in un cursore;
• si effettua lo scorrimento del cursore caricato e per ogni record recuperato
questo sarà inserito nella tabella degli esiti opportuna, indicando, oltre ai
dati dell’entità specifica, il sistema possessore, quello ricevente, stato esito
’APERTO’ e come tipo anomalia il valore ’A’;
3. Selezione ed inserimento nella tabella degli esiti dei disallineamenti dovuti a differenza sui campi di un record di un’entità, riscontrati nel confronto tra due sistemi.
In questa fase sono previste le seguenti operazioni:
• una selezione dei dati, con gli opportuni filtri, presenti sia sul sistema possessore che quello ricevente, dove però viene riscontrato un codice hash differente;
nella selezione dei campi si utilizza una funzione particolare che si aspetta
in input i due campi relativi alla stessa informazione prelevata dai sistemi e
ritorna un unico valore se i due di input sono uguali oppure li concatenata,
separandoli con il carattere ’|’, quando sono diversi;
• i dati selezionati al passo precedente sono caricati in un cursore;
• si effettua lo scorrimento del cursore caricato e per ogni record recuperato
questo sarà inserito nella tabella degli esiti opportuna, indicando, oltre ai dati
dell’entità, il sistema possessore, quello ricevente, stato esito ’APERTO’ e
come tipo anomalia il valore ’D’;
95
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
4. Eliminazione dalla tabella di storico dei disallineamenti ancora presenti nella
tabella degli esiti appena ripopolata con il nuovo confronto.
In questa fase è prevista la seguente operazione:
• una cancellazione dalla tabella dello storico dei disallineamenti che sono ancora
presenti all’interno della corrispondente tabella degli esiti, in modo tale da
lasciare nello storico solo i disallineamenti non più presenti per poterli definire
chiusi.
5. Aggiornamento del campo stato esito sullo storico.
In questa fase è prevista la seguente operazione:
• un aggiornamento del campo stato esito sulla tabella dello storico. Tutti i
record che sono rimasti nello storico con l’indicazione di disallineamento ’APERTO’, dopo l’operazione di cancellazione, saranno da considerare come disallineamenti chiusi, ovvero non più esistenti, perché non aventi più riscontro
nella tabella degli esiti.
Tutti gli algoritmi di confronto implementati nel progetto Data Integrity seguono,
in linea di massima, lo schema logico appena illustrato.
96
4.5 – Server job e job sequence Datastage
4.5
Server job e job sequence Datastage
SERVER
DATASTAGE
Progetto
DATA_INTEGRITY
LOAD
CHECK
CDB
CDB
SAP
SAP
SEM
SEM
TCC
TCC
CDB-SAP
CDB-SAP
CLC-SAP
CLC-SAP
CLC-SEM
CLC-SEM
SAP-DBL
SAP-DBL
SAP-SEM
SAP-SEM
SAP-TCC
SAP-TCC
SERVER JOB
SERVER JOB
JOB SEQUENCE
JOB SEQUENCE
Contiene tutti i server job e le
job sequence necessari per il
caricamento dei dati dei
sistemi sul database
DBADI1DATAINT
Contiene tutti i server job e le
job sequence necessari per
l’esecuzione delle procedure di
aggiornamento e controllo dati
sulle tabelle di replica presenti
nel database DBADI1DATAINT
Figura 4.5. Progetto Data Integrity: la parte di progetto sviluppata su Datastage
97
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
Per quanto riguarda la parte di caricamento e di avvio delle procedure in PL/SQL si utilizzano i server job di Datastage, i quali sono stati composti attraverso
strutture di controllo più complesse in differenti job sequence. I server job e le job
sequence sono state memorizzate all’interno del progetto di Datastage secondo la
struttura riportata nella figura 4.5.
In questo progetto Datastage possiamo definire tre tipologie differenti di server job,
come evidenziato nella figura 4.6. In particolare abbiamo:
1. i job di caricamento dei dati dai sistemi di partenza nelle tabelle di replica;
2. i job, che richiamando le stored procedure e le funzioni PL/SQL, avviano le
procedure di aggiornamento dati e calcolo hash sulle tabelle di replica prima
del confronto di allineamento;
3. i job, che richiamando le stored procedure e le funzioni PL/SQL, avviano le
procedure di confronto di allineamento dati, dopo l’operazione di aggiornamento.
98
4.5 – Server job e job sequence Datastage
Lettura dati dal
sistema sorgente
Link di input
Link di ouput
Stage Oracle
1. Scrittura sulla tabella
di replica dei dati letti
2. Memorizzazione log
Stage Oracle
Job di caricamento dei dati dai sistemi da monitorare
Link di input
Preparazione log
Link di ouput
Stage Oracle
1. Avvio stored procedure
per aggiornamento dati
2. Memorizzazione log
Stage Oracle
Job per l’esecuzione degli aggiornamenti sui dati
Link di input
Preparazione log
Link di ouput
Stage Oracle
1. Avvio stored procedure
per il confronto dati
2. Memorizzazione log
Stage Oracle
Job per l’avvio degli algoritmi di confronto
Figura 4.6. Progetto Data Integrity: tipologie job Datastage
99
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
Come già anticipato, i server job che appartengono ad una specifica operazione
sono stati collegati uno con l’altro attraverso l’utilizzo delle job sequence. Quest’ultime, ovvero le job sequence, hanno consentito di indicare l’ordine con cui
attivare i singoli server job in funzione del compito svolto. Procedendo in questo modo è più semplice richiamare le operazioni di caricamento, aggiornamento
e confronto. Ad esempio, per il caricamento dei dati delle tabelle appartenenti al
sistema SAP è sufficiente richiamare solo una job sequence, nello specifico chiamata
LOAD_TABELLE_SAP, che a sua volta richiamerà tutte le job sequence ed i server job che si occupano di effettuare il caricamento di una singola entità (contratti,
annunci, sigle ecc), come riportato nella figura 4.7.
4.5.1
I job di caricamento
I server job di caricamento sono costituiti da due stage Oracle collegati da uno
specifico link, come è possibile osservare nella parte 1 della figura 4.7. Uno stage
viene utilizzato per la selezione dei dati, mentre l’altro per la memorizzazione delle
informazioni estratte nelle tabelle di replica del database DBADI1DATAINT. Tramite lo stage di caricamento Oracle si effettua la selezione ed il prelievo dei dati dal
database di un sistema da controllare. I dati risultanti dalla selezione sul sistema
di partenza vengono trasferiti sul link. Sulla relativa parte di input di questo link
è collegato lo stage di scrittura dati per la memorizzazione delle informazioni nella
tabella di replica presente nel database DBADI1DATAINT. La tabella di replica
riceverà tutti i record prelevati dalla selezione del primo stage.
Terminata l’operazione di caricamento sarà scritto un record di “successo” in una
struttura di log. Questa struttura è sostanzialmente una tabella utilizzata per tenere
traccia delle varie operazioni eseguite nel processo di controllo. Anche la tabella di
log è memorizzata sul database DBADI1DATAINT.
I nomi dei server job che ricoprono il compito di caricamento sono stati definiti secondo lo standard seguente:
LOAD_[nome entità abbreviata]_[sistema]
ad esempio, LOAD_ANN_SAP è il nome del server job di caricamento degli annunci di SAP, come è anche riportato nella parte 1 della figura 4.7.
100
4.5 – Server job e job sequence Datastage
1
SERVER JOB LOAD_ANN_SAP
Stage che permette l’estrazione dei
dati degli annunci da SAP
Stage che permette la scrittura dei dati
estratti da SAP sulla tabella specifica
del database DBADI1DATAINT
2 JOB SEQUENCE
LOAD_CON_ANN_SIGLE_SAP
3 JOB SEQUENCE LOAD_TABELLE_SAP
Job sequence per il
caricamento delle entità
contratti – annunci – sigle di
SAP sul database
DBADI1DATAINT
Job sequence per il
caricamento dell’entità
campagne pubblicitarie
Job sequence per il
caricamento dell’entità
anagrafica
Figura 4.7. Progetto Data Integrity: server job / job sequence per il caricamento dati
101
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
I diversi server job di caricamento sono stati collegati e sono richiamabili utilizzando
delle job sequence che permettono di avviare i singoli server job in parallelo. Un
esempio di questa tipologia di job è riportata nella parte 2 della figura 4.7 che consente di caricare le entità dei contratti, annunci e sigle del sistema SAP.
Inoltre, sono state create delle job sequence particolari che ne richiamano altre. Il
loro compito è di richiamare tutti job (sia job sequence che server job) per attivare
le funzionalità di caricamento di uno specifico sistema. Queste job sequence sono
state chiamate secondo il seguente standard:
LOAD_TABELLE_[nome sistema]
La job sequence LOAD_TABELLE_SAP richiama tutti i job utilizzati per il caricamento del sistema SAP, come è mostrato nella parte 3 della figura 4.7. Tramite
una sola chiamata ad una job sequence siamo in grado di attivare i caricamenti di
tutte le entità da monitorare del sistema SAP.
4.5.2
I job per richiamare l’aggiornamento dei dati
In questa categoria sono presenti i job incaricati di richiamare le stored procedure e funzioni per eseguire l’aggiornamento dei dati per le transcodifiche ed per il
calcolo del codice hash, prima dell’esecuzione degli algoritmi di confronto. In questa
fase si renderanno uguali le codifiche di campi e contestualmente saranno calcolati
i codici hash utilizzati come campi di confronto nella fase di verifica dei disallineamenti dovuti a differenze sui dati.
I server job di questa categoria sono costituiti da due stage Oracle in modo analogo
a quelli utilizzati per il caricamento. Nella figura 4.8 è riportato il server job per
il richiamo della stored procedure utilizzata per l’aggiornamento dati dell’entità annunci di SAP, prima di effettuare il confronto tra i sistemi SAP-SEM.
A differenza dei job di caricamento dati, lo stage che genera flussi dati sull’output
link metterà solo un record di log che sarà memorizzato dallo stage ricevente l’input
link. Lo stage Oracle ricevente scriverà il record nella opportuna tabella di log solo
se la specifica procedura PL/SQL di aggiornamento dati, configurata sullo stage
ricevente, avrà eseguito il suo compito correttamente senza restituire errori. In definitiva, tutte le stored procedure PL/SQL di aggiornamento dati sono richiamate
102
4.5 – Server job e job sequence Datastage
SERVER JOB AGGIORNA_ANN_SAP_PER_SAP_SEM_1
Carica log
Scrivi log
Definizione della stored procedure da richiamare all’interno delle proprietà dello stage
WRITE_TDI07_LOG (la stored procedure è memorizzata all’interno del database DBADI1DATAINT)
Figura 4.8. Progetto Data Integrity: server job per richiamare l’aggiornamento dei dati
dai relativi stage Oracle di scrittura log (come nell’esempio riportato in figura 4.8).
I server job per eseguire l’aggiornamento dei dati sono stati chiamati secondo il seguente standard:
AGGIORNA_[Entita]_[Sistema]_PER_[SYS_A]_[SYS_B]_1,
ad esempio il server job:
AGGIORNA_ANN_SAP_PER_SAP_SEM_1 serve per richiamare la stored procedure PL/SQL che si occupa di aggiornare i dati sulle transcodifiche e sul codice
hash per i campi dell’entità annunci di SAP relativi al confronto tra i sistemi SAP SEM. Dato che si tratta del confronto SAP-SEM è per questo motivo che è presente
nel nome del server job il suffisso “PER_SAP_SEM”.
103
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
4.5.3
I job per richiamare gli algoritmi di confronto
SERVER JOB CONTROLLA_ANN_SAP_SEM_2
Carica log
Scrivi log
Definizione della stored procedure da richiamare all’interno delle proprietà dello stage
WRITE_TDI07_LOG (la stored procedure è memorizzata all’interno del database DBADI1DATAINT)
Figura 4.9. Progetto Data Integrity: server job per richiamare il confronto
di un’entità tra due sistemi
In questa categoria appartengono i server job che richiamano le stored procedure PL/SQL incaricate di effettuare il calcolo delle anomalie sulle entità oggetto
di confronto. I job sono strutturati in maniera simile a quelli utilizzati per il caricamento e l’aggiornamento dei dati nelle tabelle di replica, come è possibile vedere
nella figura 4.9. Anche questi server job consentono la memorizzazione di un log per
tenere traccia dei risultati delle diverse operazioni.
I job appartenenti a questa categoria sono stati chiamati secondo il seguente standard:
CONTROLLA_[Entita]_[SYS_A]_[SYS_B]_2
ad esempio il server job:
104
4.6 – Interfaccia utente
CONTROLLA_ANN_SAP_SEM_2 serve per richiamare la stored procedure PL/SQL che si occupa di calcolare le anomalie sull’entità annunci tra il sistema SAP e
SEM (come riportato in figura 4.9).
Per richiamare in modo coordinato tutti i server job necessari per realizzare l’intera procedura di confronto tra due sistemi sono state impiegate delle job sequence
che permettono di sincronizzare prima tutte le rispettive operazioni di aggiornamento dei dati e poi, in seguito, di avviare quelle di confronto. Tali job sequence sono
predisposte a richiamare, in parallelo per ottimizzare i tempi, prima tutti i server
job di aggiornamento dei dati e poi, previa verifica di successo delle operazioni precedenti, di avviare tutti i server job che hanno il compito di attivare le procedure
di confronto su tutte le entità di una coppia di sistemi. Una volta terminate le
operazioni appena descritte, le job sequence permetteranno di inviare delle e-mail di
notifica del successo o dell’insuccesso delle operazioni di aggiornamento e controllo
dati.
Le job sequence appartenenti alla categoria appena descritta sono state chiamate
secondo il seguente standard:
CHECK_[SYS_A]_[SYS_B]
ad esempio la job sequence:
CHECK_SAP_SEM permette di avviare i controlli sulle entità contratti, annunci,
sigle tra i sistemi SAP e SEM.
4.6
Interfaccia utente
L’interfaccia utente è stata realizzata con lo scopo di fornire delle viste specifiche
sulle tabelle del database DBADI1DATAINT contenenti i risultati dei controlli di
disallineamento sui vari sistemi/entità. Per rendere l’applicazione facilmente fruibile
è stata realizzata come una interfaccia WEB con cui è possibile interrogare le basi
dati degli esiti e visualizzare rapidamente l’elenco dei disallineamenti suddivisi per
sistema / entità. Tale interfaccia è costituita da un menù con cui selezionare il
sistema di cui richiedere gli esiti (parte 1 della figura 4.10). Per il sistema selezionato
sarà visualizzato l’insieme delle entità che vengono monitorate e di cui disponiamo
105
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
gli esiti (parte 2 della figura 4.10). Nella pagina di visualizzazione delle entità per
sistema sarà possibile scaricare dei report contenenti i dati aggregati e di dettaglio
sull’ultimo controllo effettuato (parte 2 della figura 4.10 - pulsante “download”). Per
ogni entità controllata saranno riportate anche le informazioni relative al numero
di disallineamenti, suddividendo per assenze e differenze (parte 2 della figura 4.10).
Sempre dalla pagina di visualizzazione entità per sistema, sarà possibile accedere ad
una pagina di dettaglio (riportate nella parte 3 della figura 4.10) per vedere tutte
le anomalie visualizzando un determinato numero di esiti per ogni pagina risultato,
evitando liste dati troppo lunghe, che potrebbero influenzare i tempi di risposta
della pagina WEB stessa.
106
4.6 – Interfaccia utente
1
2
3
Figura 4.10. Progetto Data Integrity: applicazione WEB per la visualizzazione degli esiti
107
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
4.7
Generazione report
I report sono creati nel formato XML contenente i tag di un file XLS, quindi
sono stati realizzati per essere aperti con un programma di elaborazione di fogli di
calcolo come Microsoft Excel. I report contengono delle informazioni di riepilogo
sui dati degli esiti associate a tutte le entità di una coppia di sistemi confrontati:
vengono creati i report per i confronti SAP-SEM, SAP-TCC, CDB-SAP, ecc. In
ognuno di essi saranno presenti i riepiloghi di tutte le entità confrontate (contratti,
annunci, ecc). Per ogni riepilogo saranno indicate le informazioni numeriche sui disallineamenti dovute alle assenze e alle differenze. Per i disallineamenti dovuti alle
differenze verranno riportate i dati numerici relativi ai campi che hanno prodotto
queste anomalie durante la fase di confronto.
Nella figura 4.11 è riportato un esempio di report contenente i dati numerici dei
disallineamenti riscontrati dai controlli sui sistemi SAP-SEM. In questa visualizzazione avremo un riscontro numerico immediato sulle quantità dei disallineamenti
rilevati dall’ultima esecuzione dell’algoritmo. Tramite questi report si potrà decidere se operare o meno con interventi di urgenza per il riallineamento dei dati. In
alternativa, si potranno utilizzare tali informazioni per effettuare delle analisi più
precise per capire le cause di questi disallineamenti. In questi report, oltre ai dati
di riepilogo, sono riportati anche degli elenchi con i primi 10.000 record disallineati
per ciascuna entità controllata, suddividendo per disallineamenti dovuti ad assenza
e differenza.
108
4.7 – Generazione report
Figura 4.11. Progetto Data Integrity: esempio di report contenente gli esiti dei controlli
109
4 – Realizzazione di un progetto di Data Integrity per un’azienda pubblicitaria
4.8
Interazione con l’ambiente di schedulazione
Tutti i job di Datastage precedentemente descritti devono essere richiamati in
modo automatico per evitare di lasciare il compito di attivazione delle applicazione
all’utente. Per questo è stato necessario valutare come poter attivare in maniera
automatica questi job, sia di caricamento che di richiamo delle procedure PL/SQL.
Come abbiamo visto nel capitolo di introduzione a Datastage è presente il programma Director che permette di impostare l’avvio dei server job e delle job sequence in
orari prestabiliti. L’utilizzo di tale strumento poteva essere una soluzione, ma dato
che in questa azienda è presente un altro strumento di schedulazione automatica,
chiamato CA dSeries, si è preferito optare verso questa soluzione.
CA dSeries permette tramite una semplice interfaccia grafica, di impostare in modo
avanzato e flessibile la schedulazione, in date e orari precisi e configurabili, per avviare processi e programmi presenti su diverse macchine della rete, creando di fatto
una piattaforma di automatizzazione di processo. In più, questo schedulatore può
lavorare, senza problemi, su piattaforme diverse. In particolare può essere installato
su ambienti Unix/Linux, Windows, ecc. Quindi, i programmi e processi che necessitano di operazioni di schedulazione possono essere realizzati su piattaforme anche
molto differenti tra loro.
Ritornando al contesto del progetto descritto, per avviare i job di Datastage abbiamo utilizzato degli script Unix da far richiamare da questo schedulatore dSeries.
Gli script Unix hanno il compito di invocare gli specifici job direttamente sulla
macchina su cui è stato installato il server di Datastage. Inoltre, attraverso lo schedulatore dSeries è stato possibile prevedere l’attivazione di un programma custom
per la creazione dei report di riepilogo una volta terminate le operazioni di controllo
allineamento dati. Attraverso l’infrastruttura creata l’applicazione WEB avrà accesso sempre ai dati degli esiti aggiornati e permetterà di scaricare gli ultimi report
generati.
110
Capitolo 5
Valutazioni del progetto di Data
Integrity realizzato in azienda
5.1
Risultati ottenuti
Il progetto di Data Integrity che è stato realizzato permette, come ho illustrato
nel precedente capitolo, di effettuare il caricamento dei dati, prelevati dai vari sistemi, in tabelle di replica su cui vengono eseguiti i controlli di allineamento dati.
Una volta constatato le cardinalità relative alle tabelle da controllare presenti sui
sistemi, che risultano essere dell’ordine di milioni di record per ciascuna entità, sono
riuscito, con l’ausilio del gruppo EAI, ad impostare dei controlli quotidiani fino a tre
coppie di sistemi differenti. Per ogni coppia di sistemi vengono controllate le entità
condivise che abbiamo definito precedentemente. Nella tabella 5.1 sono riportati
i giorni in cui vengono eseguiti i controlli su queste coppie di sistemi. È possibile
osservare che in alcuni casi le operazioni di controllo allineamento vengono eseguite
ogni giorno, nello specifico questo è vero per i controlli SAP-SEM e CDB-SAP. Il
motivo è dovuto al fatto questi sistemi condividono dati critici per le finalità di produzione ed è molto importante avere un riscontro sulla quantità di disallineamenti
presenti e, di conseguenza, avere delle situazioni giornaliere sulla qualità dei dati
condivisi. Per gli altri sistemi, invece, è sufficiente avere una situazione settimanale
sui disallineamenti, perché meno critici dal punto di vista della produzione.
111
5 – Valutazioni del progetto di Data Integrity realizzato in azienda
SAP - SEM
Lunedì
X
Martedì
X
Mercoledì
X
Giovedì
X
Venerdì
X
CLIC - SEM
SAP - TCC
SAP - DBL
CLC - SAP
CDB - SAP
X
X
X
X
X
X
X
X
X
Figura 5.1. Progetto Data Integrity: calendario controlli
Per ricevere in modo immediato un riscontro sui controlli eseguiti, al termine delle
procedure di verifica allineamento sono richiamate delle funzioni di creazione report,
di cui abbiamo già parlato nel capitolo precedente, in cui vengono riportati i dati
numerici relativi all’assenze ed alle differenze rilevate sui dati. Questi report vengono mandati, in modo automatico, al gruppo EAI ed ai vari responsabili dei sistemi
coinvolti nelle operazioni di controllo. In questo modo è stato impostato un sistema
di avviso immediato: le persone che riceveranno questi report potranno verificare i
dati numerici relativi ai disallineamenti riscontrati ed in base ai confronti precedenti
potrà valutare l’aumento o la diminuzione di questi, decidendo eventualmente di
ricorrere ad operazioni correttive sui dati.
5.2
Riscontri numerici
I dati numerici relativi alle quantità di disallineamenti rilevati nei vari confronti
effettuati, come riportati negli esempi delle figure 5.1 e 5.2, hanno consentito di
112
5.2 – Riscontri numerici
prendere delle decisioni sia dal punto di vista di processo, modificando di fatto delle modalità di migrazione ed operando correttive sulle applicazioni di integrazione,
che dal punto di vista dei singoli dati, operando con delle procedure di riallineamento specifiche. I report generati dopo ogni confronto offrono costantemente una
visualizzazione dei disallineamenti:
• dal punto di vista aggregato, visualizzando numeriche relative alle quantità di
dati disallineati per assenza del dato e per differenza;
• dal punto di vista dettagliato, riportando i primi 10000 record disallineati per
problemi di assenza e differenza.
Le visualizzazioni aggregate sui disallineamenti permettono di avere una situazione
rapida di quali campi risultano essere maggiormente interessati dal problema delle
differenze. Allo stesso tempo, la visualizzazione dei dati di dettaglio permette di
avere il riferimento puntuale su un singolo record disallineato.
I dati dei confronti che vengono maggiormente utilizzati sono quelli relativi alle
verifiche di allineamento tra i sistemi SAP-SEM, CLIC-SEM, SAP-TCC e CDBSAP. I report contenenti questi dati disallineati hanno permesso di individuare delle
criticità e, in seguito, di rimuoverle nei flussi di integrazione.
Per quanto riguarda le procedure di riallineamento sono state adottate tre tipologie
di operazioni:
1. l’utilizzo di applicazioni, già esistenti, di integrazione, opportunamente mandate in esecuzione con parametri specifici, con l’intento di riprovare ad inviare
al sistema l’informazione che doveva essere già aggiornata, ma che per problemi
di integrazione non lo è stata.
2. interventi diretti sulla base dati per effettuare dei riallineamenti puntuali;
3. la creazione di applicazioni ad-hoc per le operazioni di ripristino; per alcuni
dati disallineati tra i sistemi SAP-TCC si è ricorso a questa tipologia, ovvero
sono stati creati dei nuovi flussi di integrazione per correggere i dati.
Nel seguito riporto le informazioni riguardanti alle anomalie più evidenti che sono
state corrette:
113
5 – Valutazioni del progetto di Data Integrity realizzato in azienda
• tramite i risultati dei confronti SAP-TCC e SAP-SEM sono stati recuperati
circa 20 mila record di dati assenti nei sistemi TCC e SEM;
• il confronto SAP-SEM sull’entità annunci ha permesso di scoprire un bug su
un’applicazione di integrazione esistente tra SAP e SEM. Questa applicazione
inviava un’informazione errata: nello specifico veniva passata la località in
cui era pubblicato l’annuncio, mentre il sistema ricevente aveva bisogno della
località in cui era stato venduto l’annuncio, di conseguenza una volta scoperta
l’anomalia si è operato un bug fixing sul processo di integrazione;
• sono stati riallineati migliaia di codici contratto presenti sul sistema SEM che
per problemi di integrazione non erano stati aggiornati;
• sono stati riallineati migliaia di codici categoria sugli annunci che risultavano
essere differenti tra i sistemi SAP-SEM;
• è stato scoperto un errore sull’applicazione front-end di SEM che, dopo un’operazione particolare di modifica dell’annuncio, perdeva il valore di un campo
relativo alla prenotazione annuncio, risultando, di conseguenza, disallineato
con il sistema SAP.
Allo stato attuale i controlli continuano ad essere eseguiti secondo il calendario
riportato nella tabella 5.1. Contestualmente a queste operazioni di controllo i report vengono generati di pari passo, creando di conseguenza un archivio storico dei
disallineamenti riscontrati nei vari giorni.
Inoltre, c’è un ultimo aspetto da considerare nella fase di analisi dei dati prodotti
dagli algoritmi: è ancora presente buon un numero di anomalie che l’azienda ha
deciso di non voler ripristinare per due motivi:
• sono relativi a dati troppo vecchi e non servono più per la parte di produzione;
• il costo di ripristino risulta essere troppo altro rispetto ai benefici che può
portare un’operazione di riallineamento.
114
5.2 – Riscontri numerici
Controllo SAP-SEM effettuato in data 18/06/2009
Entità contratti
# record
SAP
# record
SEM
4.181.433
4.217.407
Disallineamenti totali
74.373
Record assenti su SEM
Record differenti su SEM
70.771
3.602
Campi su cui è stata riscontrata la differenza
Codice interno SAP
Codice offerta
Entità annunci
# record
SAP
# record
SEM
3.106
497
9.911.643
9.636.913
Disallineamenti totali
329.708
Record assenti su SEM
Record differenti su SEM
189.935
139.773
Campi su cui è stata riscontrata la differenza
Prodotto
Tipo pubblicazione
Volume
Edizione
Localita
Categoria
Flag prenotazione
1
440
2.256
1.589
29.141
128.893
4.958
Figura 5.2. Progetto Data Integrity: riepiloghi controlli contratti - annunci SAP-SEM
115
5 – Valutazioni del progetto di Data Integrity realizzato in azienda
Controllo SAP-TCC effettuato in data 17/06/2009
Entità contratti
# record
SAP
# record
TCC
4.181.433
5.406.511
Disallineamenti totali
201.582
Record assenti su TCC
Record differenti su TCC
133.946
67.636
Campi su cui è stata riscontrata la differenza
Stato contratto
Entità annunci
# record
SAP
# record
TCC
67.636
9.911.643
13.151.216
Disallineamenti totali
207.383
Record assenti su TCC
Record differenti su TCC
207.333
50
Campi su cui è stata riscontrata la differenza
Prodotto
Tipo pubblicazione
36
28
Figura 5.3. Progetto Data Integrity: riepiloghi controlli contratti - annunci SAP-TCC
116
5.3 – Considerazioni finali
Le anomalie, che si è deciso di non ripristinare, sono rimaste negli archivi degli esiti
perché l’azienda vuole tenere traccia di tali disallineamenti. Di conseguenza, si dovranno modificare i report contenenti le informazioni numeriche sui disallineamenti,
evidenziando diversamente questa categoria di anomalie.
5.3
Considerazioni finali
Lo sviluppo dell’applicazione di Data Integrity, che è stata descritta in questo
caso di studio, ha richiesto molti sforzi di analisi ed il coinvolgimento di diverse persone responsabili dei sistemi informativi. È stato speso diverso tempo per decidere le
entità ed i suoi attributi da sottoporre al controllo di allineamento. Questo aspetto
è stato amplificato dal fatto che l’azienda sta effettuando una migrazione di uno dei
suoi sistemi più importanti, da un’applicazione custom (CLIC) verso una di tipo
package (ovvero SAP). Il passaggio verso SAP sta coinvolgendo tutte le applicazioni
che precedentemente si interfacciavano con il sistema vecchio, ovvero CLIC. In aggiunta ai problemi di controllo delle funzionalità EAI, si è creata l’esigenza di avere
la verifica di allineamento dei dati migrati tra i sistemi CLIC - SAP, considerando
tutti i problemi di conversione alle strutture del nuovo sistema adottato.
Un fattore, che ho dovuto tenere molto in considerazione nell’implementazione delle
procedure di caricamento e controllo, è relativo alle performance dell’applicazione
di Data Integrity. Questo strumento di controllo allineamento dati per essere effettivamente utilizzato deve produrre i risultati dei confronti in tempi ragionevoli. Se
così non fosse non sarebbe possibile prendere le opportune contromisure in caso di
un numero elevato di disallineamenti.
È stato compiuto uno sforzo importante per realizzare delle procedure di caricamento, aggiornamento e calcolo disallineamenti il più veloci possibili. Quanto detto è
fondamentale per via delle cardinalità notevoli presenti nelle tabelle dei sistemi da
controllare. Per rendere l’applicazione Data Integrity più efficiente sono state predisposte in parallelo, dove è stato possibile e compatibilmente con le potenzialità delle
macchine a disposizione, tutte le funzionalità di caricamento e controllo dei vari sistemi da monitorare. È stato scelto come momento di esecuzione delle operazioni di
117
5 – Valutazioni del progetto di Data Integrity realizzato in azienda
caricamento e confronto dati l’orario notturno. Infatti, nelle ore notturne abbiamo
il momento migliore per questo tipo di operazioni: i sistemi sono più scarichi dal
punto di vista computazionale e di conseguenza anche le macchine su cui verranno
eseguite le diverse operazioni saranno più veloci.
Nel capitolo precedente ho descritto che il caricamento dei dati, prelevati dai vari
sistemi da monitorare, avviene in modo massivo sul database centralizzato Oracle.
Questa scelta si è resa necessaria perché:
• non sono presenti su tutte le tabelle, dei sistemi da controllare, dei riferimenti espliciti alla data di ultima modifica del record, di conseguenza, senza
tale informazione non abbiamo un discriminante agevole per effettuare delle operazioni aggiornamento sulla tabella di replica, presente sul database
DBADI1DATAINT, associata ad un entità di un sistema da controllare;
• risulta essere un’operazione molto lunga individuare i record cancellati sul
sistema di produzione, per aggiornare in modo congruente le informazioni sulla
tabella di replica; sarebbe necessario scorrere tutto l’insieme dei record della
tabella di replica e verificare o meno la presenza sul sistema di produzione e
questo costituisce un’operazione molto lenta.
Considerati questi due aspetti, si è scelto di svuotare e caricare di continuo le tabelle di replica presenti sul database Oracle DBADI1DATAINT. Sono riuscito, come
già affermato in precedenza, a velocizzare le fasi di caricamento dei dati tramite
l’utilizzo di procedure eseguite, il più possibile, in parallelo. Tutte le entità dei sistemi coinvolti nel controllo di Data Integrity sono replicate sulle tabelle del database
DBADI1DATAINT in quattro ore al massimo. Considerato il caricamento massivo
dei dati ne consegue che le procedure di aggiornamento e confronto disallineamenti
effettueranno le loro operazioni sulla maggior parte dei dati presenti nelle tabelle di
replica: non possiamo limitarci ad un sottoinsieme, perché caricando i dati ogni volta
questi devono essere aggiornati, sia per le operazioni di transcodifica che per quelle relative al calcolo del codice hash. Ovviamente anche gli algoritmi di confronto
utilizzeranno come base di input tutti i dati caricati nelle tabelle di replica.
In una fase così concitata che sta attraversando questa azienda di pubblicità,
118
5.4 – Sviluppi futuri
avere uno strumento di controllo dati ha permesso ed attualmente permette ancora
di monitorare l’allineamento dei dati condivisi tra i sistemi. Posso affermare che lo
strumento di controllo viene utilizzato dal gruppo EAI a tutti gli effetti e, quindi,
sta raggiungendo lo scopo per cui è stato realizzato.
5.4
Sviluppi futuri
Considerato il periodo di tempo, nello specifico di sei mesi, che mi è stato concesso per l’analisi e lo sviluppo dell’applicazione Data Integrity, abbiamo deciso, con
l’ausilio del gruppo EAI di Reply, di focalizzarci sui sistemi che presentavano le criticità più urgenti, ovvero quelli coinvolti maggiormente dalla migrazione verso SAP.
Quanto detto non esclude il fatto di potere aggiungere altre procedure di controllo
su entità e sistemi differenti. Una volta deciso ed impostato un modello di procedimento questo è possibile ripeterlo anche per gli altri. In particolare, le operazioni
che sicuramente sono da svolgere in questo contesto di Data Integrity sono:
• il caricamento dei dati su una struttura di appoggio;
• l’aggiornamento per le rispettive transcodifiche in base al tipo di confronto;
• l’esecuzione degli algoritmi di confronto;
• l’esposizione dei risultati sui controlli di allineamento dati.
Per concludere il discorso sul progetto di Data Integrity, posso illustrare quali sono
i possibili sviluppi futuri, in particolare è possibile pensare di:
• aggiungere nuovi attributi da controllare sull’entità già monitorate;
• aggiungere nuove entità/sistemi da monitorare;
• aggiungere nuovi report sugli esiti, creando delle viste specifiche sulle tabelle
degli esiti, aggregando i dati diversamente;
• visualizzare, in modo differente, sui report e sull’applicazione WEB i dati che
l’azienda ha deciso di non correggere;
119
5 – Valutazioni del progetto di Data Integrity realizzato in azienda
• velocizzare maggiormente le funzionalità di caricamento, aggiornamento e controllo dati, aumentando la parallelizzazione delle procedure;
• per una questione di scalabilità, con l’aumentare del numero di sistemi / entità
da controllare, ed ottenere un miglioramento delle performance è possibile
suddividere l’archivio centralizzato in più sottoarchivi dove caricare le tabelle
di replica e degli esiti; in modo opportuno saranno da spostare anche le stored
procedure e funzioni PL/SQL che faranno riferimento a tali tabelle;
• integrare le funzionalità di ripristino dati e di riallineamento all’interno dell’interfaccia WEB già presente.
Quest’ultimo punto, ovvero le funzionalità di ripristino da inserire nell’interfaccia
WEB, permetterebbe di velocizzare il riallineamento dei dati sulle anomalie riscontrate. Con questa funzionalità aggiuntiva sarebbe possibile sistemare in tempo reale
i dati differenti, anziché ricorrere a flussi batch che di solito vengono lanciati la notte e sono time consuming, ovvero ci mettono molto tempo per completare la loro
esecuzione. Intervenendo in tempo reale, invece, sarebbe possibile risolvere alcune
segnalazioni di errore, dovute a problemi sui dati, provenienti dagli utenti dell’applicazioni. Si fornirebbe in questo modo un servizio di assistenza migliore e gli utenti
percepirebbero un incremento di affidabilità dei sistemi utilizzati, migliorando di fatto la qualità del sistema. Maggiore sarà la qualità dei dati condivisi, di conseguenza
ci saranno meno errori e potrà aumentare la produttività complessiva dell’azienda.
120
Conclusioni
Il problema dell’integrità dei dati distribuiti è un aspetto molto importante nelle
architetture di integrazione EAI ed un’applicazione di Data Integrity deve essere
considerata come un supporto per gestire questo problema. Un’applicazione di Data
Integrity permette, come ampiamente illustrato, di verificare il funzionamento del
sistema di integrazione partendo dal punto di vista dei dati, ovvero si occupa di
verificare l’allineamento delle informazioni distribuite e condivise tra i vari sistemi
della struttura informativa di un’azienda, fornendo degli strumenti per visualizzare
i disallineamenti riscontrati. In questo modo si potrà decidere tempestivamente le
eventuali contromisure in caso di disallineamenti che potrebbero rendere instabili le
funzionalità presenti nei sistemi e creare dei disservizi.
Il lavoro per mantenere il più possibile allineati i dati distribuiti rappresenta un
requisito fondamentale nello sviluppo di applicazioni di integrazione di sistemi. Infatti, se i dati condivisi fossero continuamente disallineati, il patrimonio informativo
legato alle informazioni memorizzate rischierebbe di essere compromesso seriamente.
In un contesto del genere, molto probabilmente, l’integrazione realizzata ricadrebbe
in un fallimento, causando danni economici a tutti gli attori coinvolti nel processo
di integrazione: dall’azienda su cui è stata realizzata l’integrazione a quelle di consulenza che hanno partecipato alla sua messa in funzione.
Quanto appena detto ci porta a dire che è molto importante tenere sotto controllo i
dati relativi alle entità di business condivise e che rappresentano gli “oggetti critici”
per un’azienda. L’obiettivo è di realizzare delle soluzioni di integrazione che possano
essere il più facilmente gestibili, mantenendo allineate tali informazioni distribuite
sui vari back-end di ciascun sistema. In questo contesto dobbiamo considerare i
121
Conclusioni
seguenti fattori:
• più sono complessi i sistemi informativi che condividono informazioni maggiore
è il rischio di avere dei disallineamenti sui dati;
• più i dati sono disallineati maggiore è la probabilità di avere errori o malfunzionamenti sulle applicazioni che vi accedono.
Per prevenire queste situazioni si potrebbe pensare di intervenire in due modi:
• rivedere le funzionalità di certi sistemi informativi, cercando di semplificare le
operazioni più critiche; in questo caso l’obiettivo da perseguire è di avere meno
sistemi da integrare, accorpando basi dati ed applicazioni;
• altrimenti, oltre allo sviluppo dell’integrazione sui sistemi presenti, prevedere
dei meccanismi automatici per valutare la qualità dei dati condivisi, ovvero
realizzare un’applicazione di Data Integrity.
La prima casistica, relativa ad una semplificazione delle procedure, è difficile da realizzare perché in molte situazioni reali rivedere le funzionalità delle applicazioni già
esistenti, riscrivendo dall’inizio o riutilizzando in parte codice esistente, rappresenta
di solito “l’ultima scelta” che i vari responsabili IT vogliono perseguire. Cambiare le
applicazioni, che funzionano e danno garanzia di affidabilità, generalmente è una responsabilità che nessuno vuole prendersi e costituisce un investimento a medio lungo
termine che non da certezza di successo, visto tutti i rischi legati all’implementazione
e test. Anche se in prospettiva si potrebbe optare per l’adozione di nuove soluzioni
e applicazioni, che sulla carta potrebbero dare maggiore vantaggi in termini di integrazione, il rischio di intraprendere a volte è troppo grande e ci si accontenta di
mettere in comunicazione, con strumenti di integrazione come le EAI, i sistemi che si
hanno a disposizione. Quindi, pochi investimenti nel cambiare le applicazioni, anche
quando obsolete, ma molti nel creare infrastrutture di comunicazione, cercando di
condividere informazioni tra sistemi anche molto diversi tra loro, come ad esempio
applicazioni mainframe con architettura .Net o Java.
Da quanto detto, la seconda ipotesi, ovvero utilizzare degli strumenti di controllo dati, potrebbe essere la strada da perseguire per verificare se le architetture di
122
Conclusioni
integrazione realizzate stanno funzionando o meno. Realizzare strumenti di controllo sui dati, di solito, non prevedono la modifica delle applicazioni già esistenti e
generalmente hanno un costo inferiore rispetto alle modifiche delle applicazioni dell’infrastruttura informativa. È possibile affermare che la verifica della correttezza
dei dati distribuiti sui sistemi rappresenta un fattore di successo per la soluzione di
integrazione adottata in un’azienda.
Una volta che si è deciso di implementare un’applicazione di Data Integrity è
necessario scegliere in che modo realizzarla. Una possibile domanda che ci si potrebbe porre è la seguente: ma quali sono le metodologie da utilizzare per realizzare
un’applicazione di Data Integrity? La risposta purtroppo non è immediata per via
dei seguenti problemi:
• dalle ricerche che ho effettuato per svolgere questa tesi ho constatato che non
esiste una bibliografia importante sull’argomento Data Integrity in un contesto di integrazione software e, quindi, non esistono standard specifici. Per
giustificare questo aspetto c’è da considerare che è difficile avere dei paradigmi
ben definiti per implementare dell’applicazioni di Data Integrity considerata
la varietà dei sistemi tra di loro molto differenti presenti nell’architettura informativa di un’azienda. Molto spesso è necessario una valutazione caso per
caso e risulta difficile proporre degli standard;
• le difficoltà, non indifferenti, nella creazione del processo di controllo considerate le notevoli cardinalità delle tabelle e la corretta definizione degli output
che deve restituirci un’applicazione di Data Integrity. Questo secondo aspetto
è molto importante e se viene analizzato bene può permetterci di sopperire
alla mancanza di standard.
Quindi, l’aspetto fondamentale nella realizzazione di applicazioni di Data Integrity
è di effettuare delle buone analisi coinvolgendo le figure responsabili dei vari sistemi
per avere più informazioni possibili. In questo modo si avranno dei riscontri immediati sulle ipotesi di implementazione e si potrà discutere costruttivamente per
decidere i controlli da fare, selezionando le entità e gli attributi più critici.
123
Conclusioni
Dalla esperienza personale che ho fatto posso affermare che il problema del Data
Integrity deve essere inteso come l’utilizzo di una serie di contromisure e di segnalazioni per avere delle garanzie di qualità dei dati in contesti eterogenei e complessi
dal punto di vista informativo. In queste realtà abbiamo di solito la presenza di
molti attori che da una parte rappresentano un punto di forza perché ci sono più
persone che collaborano e lavorano per un fine comune, ma dall’altro canto possono
rappresentare una situazione critica perché con l’aumentare del numero di persone
è probabile che aumentino anche le possibilità di avere errori nelle procedure. Infatti, quando ci sono tanti gruppi di persone che lavorano su un’architettura comune,
uno degli aspetti più difficili da affrontare è legato al corretto coordinamento degli
sviluppi e messa in produzione delle modifiche. Infatti, se un gruppo, che lavora
su una specifica applicazione, sviluppa delle modifiche che impattano sul sistema di
integrazione e queste non vengono comunicate per tempo agli altri gruppi, si correrà il rischio, portando in produzione tali modifiche, di creare malfunzionamenti
nelle applicazioni di integrazione. I sistemi potrebbero non funzionare, creando un
disservizio, ed i dati potrebbero non essere più allineati. Nel caso appena descritto
un’applicazione di Data Integrity fornirebbe una modalità per rilevare questi disallineamenti e ricorrere il prima possibile ad operazioni correttive.
Una soluzione di Data Integrity, implementata come applicazione di verifica sulla
qualità di integrazione, si pone l’obiettivo di aiutare ad individuare i disallineamenti
analizzando i dati. Se quest’ultimi saranno allineati tale situazione potrà rappresentare un sintomo di buon funzionamento complessivo dell’architettura di integrazione.
Al contrario, riscontrare degli errori sui dati farà pensare subito ad un possibile problema di integrazione o comunque evidenzierà una situazione non allineata che dovrà
essere presa in considerazione.
È importante sottolineare che un’applicazione di Data Integrity presumibilmente
potrà essere gestita dalle persone del gruppo di integrazione, le quali possiederanno già le conoscenze e competenze necessarie per sapere come intervenire e come
attivarsi in caso di problemi. In generale, riscontrando errori nei dati, dopo aver
effettuato le opportune analisi, si potrà pensare di attivare i meccanismi specifici di
aggiornamento per effettuare le cosiddette “operazioni di allineamento”. In seguito
124
Conclusioni
a queste operazioni di allineamento, sarà ragionevole verificarne il successo avviando nuovamente lo strumento di controllo di Data Integrity per aver evidenza della
buona riuscita dei meccanismi di ripristino.
125
Allegato A
Linguaggio PL/SQL
Introduzione
Lo scopo di questa sezione è di illustrare i principali costrutti specifici del linguaggio
PL/SQL utilizzati per la realizzazione delle procedure di aggiornamento dati e controllo presenti nel progetto di Data Integrity descritto nel caso di studio del quarto
capitolo. Non saranno trattate, in dettaglio, le istruzioni del linguaggio SQL base di
cui fanno parte le operazioni di SELECT, INSERT, UPDATE, DELETE, CREATE,
ecc, considerando che il lettore abbia già questa conoscenza. La mia intenzione, in
questa breve descrizione, è di focalizzarmi sulle peculiarità del PL/SQL rispetto alle
caratteristiche del linguaggio SQL base.
Il PL/SQL è un linguaggio procedurale, strutturato e a blocchi. Questo tipo di
linguaggio permette l’interrogazione delle basi dati Oracle con la possibilità di effettuare operazioni di manipolazione ed estrazione dei dati memorizzati.
L’unità minima che rappresenta il costrutto di base in PL/SQL è il block (blocco).
Il concetto di blocco può essere utilizzato dal programma per combinare secondo sequenze logiche i comandi SQL in unità. In un blocco si possono dichiarare
costanti e variabili e quest’ultime possono essere utilizzate per memorizzare i risultati di una query. Le istruzioni che possiamo ritrovare in un blocco PL/SQL sono
istruzioni SQL, strutture di controllo (loop), istruzioni di condizione (if-then-else),
manipolazione delle eccezioni (controllo errori) e chiamate ad altri blocchi PL/SQL.
127
Allegato A
I blocchi PL/SQL con cui è possibile creare procedure e funzioni possono, per
una questione di organizzazione, essere raggruppati in pacchetti denominati packages. Ciascuno di essi è costituito da una parte di interfaccia ed una parte di
implementazione.
Costrutti fondamentali
Declare-Begin-End
La scrittura del codice PL/SQL deve rispettare uno schema ben definito. Infatti
una procedura o una funzione deve seguire questa struttura:
• DECLARE, è opzionale, permette di indicare una sezione dove dichiarare e
definire le variabili, i cursori e le eccezioni dell’utente che saranno usate nel
blocco di codice.
• BEGIN serve per indicare l’inizio di un blocco di codice, da lì in poi seguiranno tutte le istruzioni PL/SQL della procedura o funzione, fino ad arrivare
all’istruzione END.
• EXCEPTION, è opzionale, specifica l’azione da intraprendere quando occorre
una particolare eccezione, ovvero cattura l’errore e ne permette la sua gestione.
• END; è l’istruzione per determinare la fine del blocco, bisogna notare che il
punto e virgola è obbligatorio.
Riassumendo una procedura o una funzione è costituita dal seguente schema:
1
declare
−− Blocco di dichiarazione (opzionale)
3
begin
−− Codice da eseguire
5
exception
−− Gestione eccezioni(opzionale)
7
end;
128
Allegato A
Riportiamo a titolo di esempio il codice PL/SQL per la parte dichiarativa di
alcune variabili e costanti.
1
declare
variabileIntera number(3);
3
variabileString varchar2(80) := ’STRINGA’;
costanteIntera constant number(3) := 1;
5
begin
...
7
end
Osservazioni sulle variabili:
• le variabili devono essere necessariamente dichiarate prima del loro utilizzo;
• alle variabili di tipo BOOLEAN possono essere assegnati solo i valori TRUE
e FALSE;
• %TYPE è un attributo particolare che può essere utilizzato per definire variabili il cui tipo è associato allo stesso di una colonna di una tabella presente
nel database;
• %ROWTYPE specifica un record adatto a memorizzare tutti i valori degli attributi di una riga di una tabella o risultato di una query. Ad esempio se nel database fosse presente la tabella PIPPO la dichiarazione PIPPO%ROWTYPE
servirebbe per specificare un record formattato per contenere tutti i campi di
tale tabella.
Dichiarazioni cursore
La dichiarazione di un cursore serve per specificare un insieme di righe che possono
appartenere ad una tabella oppure ad un risultato di una query attraverso un’operazione di select. In questo modo le righe estratte possono essere processate una ad
129
Allegato A
una, attraverso l’utilizzo dell’istruzione fetch.
Per dichiarare un cursore si può adoperare la seguente sintassi:
1
cursor <nome cursore> [(<lista parametri>)]
is
3
<istruzione di selezione>;
Il nome del cursore è associato al valore indicato nella posizione <nome cursore>.
Ad un cursore può essere passata una lista di parametri, questi saranno separati dal
carattere ’,’. Ciascun parametro dovrà essere passato secondo la sintassi:
1
<nome parametro> <tipo parametro>
I parametri che possono essere inviati al cursore sono di tipo char, varchar2,
number, date, boolean e tutti i corrispondenti sotto-tipi come integer, ecc. Questi
parametri servono per assegnare valori alle variabili che sono indicate nell’istruzione
select.
Elaborazioni cursore
Il cursore una volta dichiarato dovrà essere aperto prima di essere utilizzato. Quindi
è presente un’istruzione chiamata open, dove contestualmente al nome del cursore
da aprire sarà necessario specificare anche l’eventuale lista dei parametri da passare
in input.
1
open <nome cursore> [(<lista di parametri>)];
Una volta richiamata l’istruzione open l’operazione di select associata al cursore
sarà processata e il cursore stesso punterà alla prima riga selezionata. Per poter scorrere le righe seguenti si utilizzerà il comando fetch, il quale permetterà di proseguire
nell’operazione di estrazione delle singole righe restituite dall’istruzione select.
1
fetch <nome cursore> [(<lista di variabili>)];
Il comando fetch si occuperà di assegnare i valori degli attributi selezionati
dalla riga corrente alla lista di variabili definita dopo il nome del cursore (<nome
130
Allegato A
cursore>). Utilizzando il comando fetch il cursore avanzerà alla prima riga presente
nell’insieme del risultato dell’istruzione select dopo aver eseguito il comando open.
Bisogna prestare attenzione che le variabili definite nella lista (<lista di variabili>)
devono avere lo stesso tipo di dati rispetto ai valori delle righe selezionate. Una
volta che tutte le righe saranno state processate sarà necessario chiudere il cursore.
Per quest’operazione si adopererà il comando close, così il cursore sarà chiuso e
disabilitato:
1
close <nome cursore>;
Riportiamo un esempio per riepilogare le operazioni da eseguire per l’utilizzo di
un cursore:
1
declare
cursor cursore_di_esempio is select ∗ from TABELLA;
3
record_tabella TABELLA%ROWTYPE;
begin
5
open cursore_di_esempio ;
loop
7
fetch cursore_di_esempio into record_tabella;
exit when record_tabella%NOTFOUND;
9
...
<sequenza di istruzioni>
11
...
end loop;
13
close cursore_di_esempio;
...
15
end;
Il loop viene interrotto utilizzando la clausola exit:
1
exit when <condizione>
La condizione può essere un semplice paragone di valori oppure far riferimento
alla proprietà del cursore. Nel caso dell’esempio sopra riportato il ciclo continuerà
finché ci saranno righe da leggere attraverso il cursore.
131
Allegato A
Loop for
L’istruzione loop for viene utilizzata per semplificare l’utilizzo di un cursore:
1
for <nome record> in
<nome cursore> [(lista di parametri>)]
3
loop
...
5
<sequenza di istruzioni>
...
7
end loop;
In questo modo viene dichiarato implicitamente un record per memorizzare una
riga recuperata da un cursore e questa sarà accessibile utilizzando l’oggetto <nome
record>.
Attraverso l’istruzione loop for saranno eseguite:
• un’operazione di fetch per estrarre la riga ad ogni iterazione;
• un’operazione di open prima dell’ingresso nel ciclo;
• ed infine una close dopo la terminazione del ciclo.
Quando su un’iterazione non sarà recuperata alcuna riga il ciclo verrà terminato in
modo automatico senza utilizzare l’istruzione exit.
In alternativa al nome del cursore è possibile specificare una query di selezione direttamente, sostituendo il nome del cursore con l’istruzione SQL, perciò sarà possibile
scrivere:
1
for <nome record> in
(<istruzione select>)
3
loop
...
5
<sequenza di istruzioni>
...
7
end loop;
132
Allegato A
Nella situazione appena descritta il cursore non dovrà essere specificato prima
dell’ingresso del ciclo ma sarà definito nell’istruzione select.
Ad esempio, per definire velocemente un cursore che punti ad una tabella possiamo
scrivere:
1
for record_tabella in
(select ∗ from tabella)
3
loop
...
5
end loop;
Inoltre, sull’istruzione loop possiamo specificare il numero di iterazioni facendo uso
di due interi, uno per il limite inferiore ed uno per quello superiore. Quanto appena
descritto non è possibile ottenerlo con l’istruzione loop while perché il numero di
iterazioni è sconosciuto.
Quindi con il costrutto loop for possiamo scrivere:
1
for <nome record> in
<estremo inferiore>..<estremo superiore>
3
loop
...
5
<sequenza di istruzioni>
...
7
end loop;
While
Un costrutto loop while ha la seguente forma:
1
while <condizione> loop
...
3
<sequenza di istruzioni>;
...
5
end loop;
133
Allegato A
If-then-else
Per il controllo condizionale, PL/SQL offre il classico costrutto if-then-else nella
forma:
1
if <condizione> then
...
<sequenza di istruzioni>
3
...
5
[elsif] <condizione> then
...
<sequenza di istruzioni>
7
...
9
[else]
...
<sequenza di istruzioni>
11
...
13
end if;
Il comportamento è analogo alle istruzioni if-then-else dei linguaggi di programmazione classici.
Procedure e funzioni
Il linguaggio PL/SQL fornisce sofisticati costrutti di linguaggio per programmare
procedure e funzioni come blocchi PL/SQL separati. Questi possono essere richiamati da altri blocchi PL/SQL, altre funzioni e procedure, anche in questo caso in
modo del tutto analogo ai linguaggi di programmazione.
La sintassi per la definizione di una procedura è
134
Allegato A
1
create [or replace] procedure <nome procedura>
[(<lista di parametri>)]
3
is
[<dichiarazione di variabili>]
5
begin
<sequenza di istruzioni>
7
[exception <routine di gestione dell’eccezione>]
end [<nome procedura>];
La sintassi di una funzione è molto simile:
create [or replace] function <nome funzione>
2
[(<lista di parametri>)]
return <tipo di dati> is
4
...
La clausola opzionale “or replace” serve per ricreare la procedura o funzione.
Una procedura, o funzione, può essere cancellata utilizzando il comando:
drop procedure <nome procedura>
2
drop function <nome funzione>
Contrariamente ai blocchi PL/SQL anonimi1 , la clausola declare non può essere
usata nella definizione di procedure/funzioni.
Alle procedure e funzioni è possibile passare dei parametri. Ciascuno è specificato
come segue:
<nome parametro> [IN | OUT | IN OUT] <tipo di dato>
2
[{:= | DEFAULT} <espressione>]
La clausola opzionale IN, OUT, e IN OUT serve per specificare il modo con cui
utilizzare il parametro. Se non viene specificato nulla il default è IN.
• IN significa che al parametro si può fare riferimento all’interno del corpo della
procedura o funzione, ma non può essere modificato;
1
Blocchi di codice PL/SQL non inclusi in procedure e funzioni.
135
Allegato A
• OUT significa che un valore può essere assegnato al parametro nel corpo della
procedura o funzione, ma non si può fare riferimento al valore del parametro;
• IN OUT permette sia di far riferimento al parametro che l’assegnazione di
valori.
Come abbiamo visto le funzioni hanno la stessa struttura delle procedure, l’unica differenza sta nel fatto che le funzioni restituiscono un valore il cui tipo di dato
deve essere specificato.
Packages
Un package è costituito da una dichiarazione di package e da un corpo di package.
La dichiarazione del package definisce l’interfaccia che è visibile ai programmatori
di applicazione, e il corpo del package implementa la dichiarazione del package.
Gestione eccezioni
Un blocco PL/SQL può contenere istruzioni che specificano routines di gestione delle
eccezioni. Ogni errore o avviso durante l’esecuzione di un blocco PL/SQL causa una
eccezione. Si può distinguere tra due tipi di eccezioni: eccezioni definite dal sistema
ed eccezioni definite dall’utente (che devono essere dichiarate dall’utente nella parte
di dichiarazione di un blocco dove l’eccezione è utilizzata/implementata).
Il sistema definisce eccezioni che vengono automaticamente attivate quando i corrispondenti errori o avvisi vengono incontrati. Le eccezioni definite dall’utente, contrariamente, devono essere attivate esplicitamente in una sequenza di istruzioni utilizzando l’istruzione raise <nome eccezione>.
Alla fine di un blocco, dopo la parola chiave exception, le routines di gestione delle
eccezioni definite dall’utente vengono implementate. Un’implementazione di una
gestione eccezioni ha la forma seguente:
136
Allegato A
when <nome eccezione>
2
then <sequenza di istruzioni>;
I più comuni errori che possono avvenire durante l’esecuzione di programmi PL/SQL
sono gestiti dalle eccezioni di sistema.
Dopo una parola chiave when può essere specificata una lista di nomi di eccezioni
(implicitamente connesse attraverso l’operatore or). L’ultima clausola when presente
nella gestione dell’eccezioni può contenere il nome others, la quale rappresenterà la
routine di gestione delle eccezioni di default.
137
Glossario
Nell’elaborato sono stati utilizzati i seguenti acronimi.
API: Application Programming Interface, insieme di procedure disponibili al programmatore, raggruppate per formare degli strumenti specifici necessari alla risoluzione di un determinato compito.
CORBA: Common Object Request Broker Architecture, meccanismo software per
la gestione delle chiamate a procedura con oggetti di invocazione che risiedono in
uno stesso spazio degli indirizzi (applicazione) o in uno spazio degli indirizzi remoto
(stesso host o host remoti collegati in rete).
CRM: Customer Relationship Management, in ambito informatico, un’applicazione
CRM serve a tenersi in contatto con la clientela, memorizzando le informazioni in
appositi database e fornendo delle modalità per analizzare le interazioni con il cliente.
DCOM: Distributed Component Object Model, tecnologia informatica di Microsoft
che usa gli stessi paradigmi di CORBA.
ERP: Enterprise Resource Planning, sistema di gestione che integra i vari aspetti del
business e che comprende la pianificazione e realizzazione del prodotto, le vendite,
139
Glossario
gli acquisti, la gestione magazzino, ecc.
ETL: Extraction Trasformation Load, operazioni di estrazione (Extraction), trasformazione (Trasformation) e caricamento (Load) dei dati in un sistema di sintesi come
un Data Warehouse.
JDBC: Java DataBase Connectivity, si tratta di un connettore per database che
permette ad un programma scritto in Java di accedere a qualsiasi base dati.
ODBC: Open Database Connectivity, si tratta una API standard utilizzata per la
connessione ai database; si tratta di un’interfaccia indipendente dai linguaggi di
programmazione, dai sistemi di database e dai sistemi operativi.
ORB: Object Request Broker, parte di software middleware che permette ai programmatori di effettuare chiamate di programma tra computer differenti in una rete.
SAP: insieme di applicazioni ERP per integrare tutti gli aspetti del business, inclusa
la pianificazione, la realizzazione del prodotto, la logistica di magazzino, le gestione
delle vendite e degli acquisti.
SOA: Service Oriented Architecture, fornisce dei metodi per i sistemi di sviluppo e
di integrazione dove le funzionalità sono esposte come servizi richiamabili in modo
indipendente dal sistema operativo e linguaggio di programmazione utilizzato.
140
Bibliografia
[1] David Cronin Alan Cooper, Robert Reimann. About Face 3: The Essentials of
Interaction Design. John Wiley & Sons, 2007.
[2] Charles Dye. Oracle Distributed Systems. O’Reilly Media, Inc., 1999.
[3] David S. Linthicum.
Enterprise Application Integration.
Addison Wesley
Professional, 1999.
[4] Beth Gold-Bernstein; William Ruh. Enterprise Integration: The Essential Guide
to Integration Solutions. Addison Wesley Professional, 2004.
[5] Bill Pribyl Steven Feuerstein.
Oracle PL/SQL Programming, 4th Edition.
O’Reilly Media, Inc., 2005.
[6] AA. VV. IBM InfoSphere DataStage Data Flow and Job Design. IBM Redbooks,
2008.
141
Bibliografia
142
Sitografia
[1] Datastage portal. http://www.datastage.org/.
[2] Datastage tutorial and training.
http://etl-tools.info/en/datastage/
datastage_tutorial.htm.
[3] Pl/sql tutorial. http://plsql-tutorial.com/.
[4] Michael Farrell Jr Boris Lublinsky.
cembre 2002.
Top10 reasons why eai fails, Di-
http://www.sysedv.tu-berlin.de/intranet/kc-kb.nsf/
26e1753f5497bb0cc12569a50048ee1a/E5FD9F87ADB81A07C1256CA700515758/
$File/Top+10+Reasons+Why+EAI+Fails.pdf?OpenElement.
[5] Michael Crouch.
Enterprise application integration shaping the reality to-
day, Gennaio 2003.
http://www.mbconsulting-inc.com/Downloads/EAI%
20-%20Shaping%20the%20Reality%20Today.pdf.
[6] Julie Gable. Enterprise application integration, 2002. http://findarticles.
com/p/articles/mi_qa3937/is_200203/ai_n9019202.
[7] Florence Lin.
Enterprise application integration (eai) techniques, Mar-
zo 2005. http://www.cs.ucl.ac.uk/staff/ucacwxe/lectures/3C05-04-05/
EAI-Essay.pdf.
[8] David Lindqvist. Enterprise application integration – how & why?, Giugno 2005.
http://www.vxu.se/msi/forskn/exarb/2005/05088.pdf.
[9] Kedarinath Pulaparthi.
Eai best practices,
Gennaio 2007.
http:
//w3.miraclesoft.com/msws/msoft/downloads/Miracle%20EAI%
20BestPractices.doc.
[10] Gian Trotta. Dancing around eai ‘bear traps’, 2003. http://www.ebizq.net/
topics/int_sbp/features/3463.html.
143
Sitografia
[11] AA. VV.
Ittoolbox eai knowledge base.
http://it.toolbox.com/wiki/
index.php/EAI.
[12] AA. VV. Designer guide, Settembre 2002. http://www.scribd.com/doc/
209137/Data-Stage-Designer.
[13] AA. VV. Manager guide, Settembre 2002. http://www.scribd.com/doc/
209134/DataStage-Manager.
[14] Wikipedia. Enterprise application integration, 2008. http://en.wikipedia.
org/wiki/Enterprise_application_integration.
[15] Wikipedia. Customer relationship management, 2009. http://en.wikipedia.
org/wiki/Customer_relationship_management.
[16] Wikipedia. Enterprise resource planning, 2009. http://en.wikipedia.org/
wiki/Enterprise_resource_planning.
[17] Wikipedia. Object request broker, 2009. http://en.wikipedia.org/wiki/
Object_request_broker.
[18] Wikipedia. Service-oriented architecture, 2009. http://en.wikipedia.org/
wiki/Service-oriented_architecture.
144
Ringraziamenti
Un grazie a tutte le persone che sono state al mio fianco durante il percorso
universitario, in particolar modo ringrazio Stefania per il supporto nei momenti più
difficili.
Ovviamente ringrazio il relatore, prof. Fulvio Corno, per tutti i consigli forniti
durante la stesura della tesi.
Ringrazio l’azienda Blue Reply S.r.l., ed in particolar modo, Alessandro Ponte e
Federico Stentella per il supporto durante l’attività svolta.
145
