EnterpriseApplicationIntegration -...

POLITECNICO DI TORINO

Facoltà di Ingegneria dell’InformazioneCorso di Laurea Specialistica in Ingegneria Informatica

Tesi di Laurea Specialistica

Enterprise Application IntegrationStudio 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

Indice

Introduzione 1

1 EAI - Enterprise Application Integration 11

1.1 Panoramica sulle EAI . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 I livelli di integrazione . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2.1 Il livello dato . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2.2 Il livello applicazione . . . . . . . . . . . . . . . . . . . . . . . 161.2.3 Il livello metodo . . . . . . . . . . . . . . . . . . . . . . . . . . 181.2.4 Il livello interfaccia utente . . . . . . . . . . . . . . . . . . . . 20

1.3 Tecnologie middleware . . . . . . . . . . . . . . . . . . . . . . . . . . 201.3.1 RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.3.2 Message Oriented Middleware . . . . . . . . . . . . . . . . . . 221.3.3 Gli oggetti distribuiti . . . . . . . . . . . . . . . . . . . . . . . 231.3.4 Database oriented . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.4 Metodologie per l’implementazione . . . . . . . . . . . . . . . . . . . 241.5 Potenziali criticità . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.5.1 Problemi nel processo di integrazione . . . . . . . . . . . . . . 311.5.2 Dati non allineati . . . . . . . . . . . . . . . . . . . . . . . . . 32

2 Il Data Integrity in un’architettura EAI 35

2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.2 Fasi per la realizzazione di un’applicazione di Data Integrity . . . . . 39

2.2.1 Analizzare le entità di business dell’azienda . . . . . . . . . . . 402.2.2 Analizzare il contesto operativo ed i sistemi informativi . . . . 40

III

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

2.3 Vantaggi e svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.3.1 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.3.2 Svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.4 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.4.1 Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.4.2 Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.5 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 pub-

blicitaria 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.4.2 Aggiornamento dati . . . . . . . . . . . . . . . . . . . . . . . . 914.4.3 Controllo coerenza dati . . . . . . . . . . . . . . . . . . . . . . 93

4.5 Server job e job sequence Datastage . . . . . . . . . . . . . . . . . . . 974.5.1 I job di caricamento . . . . . . . . . . . . . . . . . . . . . . . 1004.5.2 I job per richiamare l’aggiornamento dei dati . . . . . . . . . . 1024.5.3 I job per richiamare gli algoritmi di confronto . . . . . . . . . 104

4.6 Interfaccia utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.7 Generazione report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084.8 Interazione con l’ambiente di schedulazione . . . . . . . . . . . . . . . 110

5 Valutazioni del progetto di Data Integrity realizzato in azienda 111

5.1 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.2 Riscontri numerici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125.3 Considerazioni finali . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175.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 . . . 33

2.1 Data Integrity: esempio di applicazione di controllo dati in un’archi-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 974.6 Progetto Data Integrity: tipologie job Datastage . . . . . . . . . . . . 994.7 Progetto Data Integrity: server job / job sequence per il caricamento

dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014.8 Progetto Data Integrity: server job per richiamare l’aggiornamento

dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034.9 Progetto Data Integrity: server job per richiamare il confronto di

un’entità tra due sistemi . . . . . . . . . . . . . . . . . . . . . . . . . 1044.10 Progetto Data Integrity: applicazione WEB per la visualizzazione

degli esiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074.11 Progetto Data Integrity: esempio di report contenente gli esiti dei

controlli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5.1 Progetto Data Integrity: calendario controlli . . . . . . . . . . . . . . 1125.2 Progetto Data Integrity: riepiloghi controlli contratti - annunci SAP-

SEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155.3 Progetto Data Integrity: riepiloghi controlli contratti - annunci SAP-

TCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

VII

Introduzione

La presente dissertazione ha come obiettivo principale la definizione e la de-scrizione di una possibile soluzione del problema di Data Integrity all’interno di uncontesto di integrazione dei sistemi informativi di un’azienda o di un’organizzazione.In un’architettura di integrazione il Data Integrity fa riferimento all’integrità delleinformazioni che sono distribuite su più basi dati e che devono essere congruenti traloro.Negli ultimi anni, l’esigenza di scambiare informazioni tra i sistemi è diventata unaquestione delicata sempre più rilevante. Per questa ragione è in continua crescitail numero di dati distribuiti tra applicazioni diverse. Per mantenere le informazio-ni distribuite le aziende stanno ricorrendo con maggior frequenza ad architetturedi integrazione EAI, ovvero a delle applicazioni specifiche il cui compito è la rea-lizzazione di canali di comunicazione per condividere dati e processi di business.Un’applicazione di Data Integrity si colloca in questo contesto come un’applicazioneEAI rivolta a verificare l’allineamento dei dati condivisi all’interno dell’infrastruttu-ra di integrazione.La tesi vuole mettere in evidenza perché è importante realizzare una procedura cheimplementi dei controlli di Data Integrity sulle basi dati distribuite, definendo inmodo puntuale quali sono i passi fondamentali per una possibile realizzazione. Irisultati prodotti dalle verifiche sulle basi dati potranno essere utilizzati per mo-nitorare e correggere le operazioni svolte dalle altre applicazioni EAI presenti inun’azienda. Risulta evidente che il problema di Data Integrity rientra tra i requisitiche le applicazioni EAI devono possedere per gestire con successo l’infrastruttura diintegrazione.

1

Introduzione

In questo elaborato verranno descritte brevemente che cosa sono le EAI, giu-stificando quali sono i motivi che spingono ad avere un’applicazione che si occupadi operazioni di Data Integrity, intesa come strumento di verifica di funzionamentodell’infrastruttura d’integrazione stessa.Per fornire a questi aspetti teorici un contesto più applicativo sarà illustrato il pro-getto di controllo di Data Integrity, realmente implementato e su cui ho lavorato,realizzato presso un’azienda operante nel settore pubblicità in collaborazione con ilteam di Reply, società di ICT che lavora sull’architettura EAI di tale azienda.

Il termine EAI rappresenta l’acronimo di Enterprise Application Integration, conil 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 diaziende. Il termine Data Integrity, in questo contesto di integrazione, viene assuntocon il significato di garanzia di allineamento e coerenza dei dati distribuiti, me-morizzati sui diversi sistemi coinvolti nel processo di integrazione. La creazione diun’applicazione di Data Integrity viene fatta con l’intento di realizzare uno stru-mento di controllo di congruenza delle informazioni presenti nelle applicazioni checostituiscono il sistema informativo complessivo di un’azienda.L’esigenza di avere un controllo di coerenza sui dati si riscontra soprattutto in azien-de di dimensioni medio grandi all’interno delle quali coabitano diverse applicazioni,quest’ultime utilizzate per formare un’infrastruttura IT complessa ed articolata. Ge-neralmente, in questi contesti, il patrimonio informativo prevede una suddivisionein vari applicativi differenti con propri database interni e distinti. Ciò avviene perragioni tecniche, di gestione ed anche per ragioni storiche. Ad esempio, in certerealtà come banche ed assicurazioni, sono presenti ancora vecchi sistemi mainframee nel frattempo è stata sviluppata una serie di nuove applicazioni, utilizzando letecnologie più moderne, che devono interagire con questi sistemi più datati: da quila necessità di convivenza di applicazioni diverse.La suddivisione in applicativi differenti può implicare l’utilizzo di sistemi operativi epiattaforme tra loro incompatibili, creando di fatto delle “isole di automazione” noncomunicanti. 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 applicazio-ni. Tale problema può essere risolto tramite un’architettura EAI, sviluppando partidi software che si occupano di creare dei canali di comunicazione tra le applicazioniesistenti, senza dover stravolgere la situazione attuale.

La prima parte della tesi, nello specifico il primo capitolo, ha lo scopo di in-trodurre e definire gli aspetti generali di un’architettura EAI. Verranno descrittesolo le caratteristiche principali e si cercherà di motivare perché le aziende ricor-rono a questo tipo di approccio, senza però scendere nei dettagli troppo tecnici iquali sono variabili a seconda del problema di integrazione. L’obiettivo di questoprimo capitolo è di definire il contesto in cui si può riscontrare l’esigenza di con-trollo dei dati su sistemi eterogenei e ricorrere ad implementazioni di meccanismidi Data Integrity. Come già anticipato in precedenza, realizzare applicazioni EAIsignifica ottenere un’integrazione dei dati, dei processi o delle interfacce tra i sistemiinformativi presenti ed utilizzati da un’azienda. Tale processo di integrazione puòessere di fatto realizzato su vari livelli, in base alle necessità aziendali. Tali livel-li di integrazione saranno brevemente illustrati, evidenziandone le motivazioni e leloro principali caratteristiche. L’intento è di mettere in evidenza i benefici che sipossono ottenere puntando su architetture di questo genere. Per contro, visto cheper creare delle architetture di integrazione è necessario realizzare del software chemetta in comunicazione i vari sistemi tra loro disomogenei, lo sviluppo di tali appli-cazioni presenta delle difficoltà di analisi e di realizzazione non di poco conto. Laprima criticità che si incontra nell’implementare applicazioni EAI è data dalla suacollocazione all’interno dell’infrastruttura dei sistemi informativi di un’azienda. Piùprecisamente le applicazioni EAI generalmente si pongono al centro dell’infrastrut-tura informativa, in modo del tutto analogo alla presenza di un HUB o SWITCHutilizzati per realizzare una rete locale di computer. Come un HUB, tramite i cavi direte, fa comunicare i diversi computer ad esso collegati, l’architettura EAI si occupadi mettere in comunicazione tutte le applicazioni che necessitano un continuo e du-raturo passaggio di informazioni. Un esempio di questa situazione è riportata nellafigura 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 aggiornateda un sistema verso gli altri, in modo da mantenere l’allineamento delle informa-zioni distribuite. Questa sua collocazione, al centro dell’infrastruttura informativa,da una parte potrà essere un punto di criticità, infatti, se non funzionerà l’architet-tura EAI le varie applicazioni non riusciranno a scambiarsi i dati e verrà meno lostrumento di comunicazione. Dall’altro canto la sua posizione potrà rappresentareun punto di forza, perché ponendosi al centro sarà più facile realizzare proceduredi controllo e di monitoraggio. Lavorando a livello centralizzato sarà più semplicesfruttare e riutilizzare le parti già fatte per eventuali realizzazioni future. Da quantodetto l’EAI dovrà necessariamente interagire con i diversi sistemi e sarà fondamen-tale avere la conoscenza dei processi di business e delle varie entità in gioco presentinell’azienda.Possiamo ancora citare questo particolare sulle EAI: tale architettura potrà essereutilizzata per evitare la situazione in cui ogni coppia di sistemi, per mettere in attola comunicazione utile per i fini già descritti, vada a crearsi un canale differenzia-to personalizzato a proprio uso e consumo. Adottando una modalità del generesi rischierebbe di creare un numero via via sempre più elevato di questi canali.L’eccessivo aumento di quest’ultimi potrebbe portare ad una situazione ingestibiledell’intero sistema informativo e diventerebbe davvero difficile capire e comprendereeventuali errori e problemi. Quindi, una soluzione EAI vuole mettere a disposizionedegli strumenti di comunicazione più semplici e generali rispetto ad altri approcci.Questa breve introduzione sull’architettura EAI servirà successivamente, nel segui-to della tesi, a comprendere l’importanza del problema di un’applicazione di DataIntegrity in un contesto del genere. Considerato che la realizzazione di un’architet-tura di integrazione è una fase molto delicata e critica, può risultare utile adottarestrumenti di verifica di allineamento di queste informazioni condivise. Infatti, a se-guito di un errore nello sviluppo e nell’esecuzione delle applicazioni dell’architetturaEAI, corrisponderà molto probabilmente all’introduzione di disallineamenti sui datidistribuiti. Di conseguenza è molto importante avere uno strumento che verifichil’integrità dei dati condivisi e scambiati tra le applicazioni in un contesto di integra-zione.

4

Introduzione

Database1

Tabella Contratti

Applicazione 1

Database3

Tabella Contratti

Applicazione 3

Database2

Tabella Contratti

Applicazione 2

Architettura EAI

Sull’applicazione 1 viene modificato il contratto avente il codice 1234

1

2

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à

Viene comunicato agli altri sistemi il dato aggiornato del contratto con il codice 1234 modificato dall’applicazione 1

3

L’entità contratto è distribuita su

tre database distinti su cui

fanno accesso

altrettante applicazioni.

Figura 1. EAI: esempio di architettura

5

Introduzione

Lo sviluppo di un’applicazione di Data Integrity sarà ampiamente descritto nel se-condo capitolo dove saranno evidenziate le motivazioni ed i casi in cui potrà essereutile implementarla. L’intento del secondo capitolo è di illustrare come un’appli-cazione di Data Integrity possa essere effettivamente uno strumento concreto dicontrollo per mantenere l’allineamento dei dati. Verranno forniti i dettagli di comeè possibile affrontare l’analisi per effettuare una buona implementazione, partendodall’analisi generale del sistema fino al momento di definire le specifiche informazionisui campi da verificare.Per dare un aspetto pratico al tema del Data Integrity, nel contesto delle EAI, sa-rà illustrato il progetto di controllo allineamento dati implementato in un’aziendapubblicitaria. Introducendo brevemente quello che sarà poi descritto con maggioredettaglio nel quarto capitolo, in questa azienda è presente un’architettura EAI chericopre un ruolo chiave nel processo di comunicazione tra i sistemi. Questi sistemisono composti generalmente da una parte di front-end e back-end. L’obiettivo di unasoluzione di Data Integrity, in questo contesto, è di occuparsi di garantire la coerenzadei vari back-end lavorando parallelamente alle altre applicazioni dell’architetturaEAI già presenti. I back-end sono i possessori fisici delle informazioni utilizzate dalleapplicazioni, ovvero i front-end, i quali devono essere supportati dalla garanzia diqualità e congruenza dei dati per poter funzionare bene.Le informazioni che possiamo definire come gli oggetti del core business di quest’a-zienda sono principalmente i contratti con i relativi annunci, le campagne pubblici-tarie ed i dati associati ai clienti. Queste informazioni sono memorizzate in mododistribuito 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 varisistemi per mantenere allineati i dati distribuiti. Di conseguenza, si avrà la tabellaassociata all’entità contratto definita su più database, ogni applicazione attingeràalla propria tabella prendendo i campi di interesse, in modo analogo a quanto rap-presentato nella figura 1. Se le informazioni tra le tabelle di una stessa entità, adesempio il contratto, non saranno allineate le applicazioni che vi accederanno po-tranno 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 maggioreragione in questo momento in cui sta avvenendo un aggiornamento di alcuni siste-mi informativi. Le applicazioni CRM, contabili ed amministrative sono in una fasedi migrazione da un’applicazione personalizzata, chiamata CLIC verso il pacchettosoftware SAP. Questa situazione porta con sé tutte le problematiche di allineamentodati con il sistema CLIC e la modifica delle procedure di integrazione con i sistemiche non sono stati sostituiti con l’avvento di SAP.La situazione attuale può, quindi, presentare delle forti criticità in caso di differenzenei dati. Infatti, nel caso in cui si verifichino delle anomalie o ci siano degli errorinel passaggio di queste informazioni, il rischio principale sarà di causare disallinea-menti di dati, generando incongruenze tra le informazioni memorizzate sui diversiback-end che costituiscono la nuova infrastruttura informativa. Le differenze chesi possono generare sui dati sono molto pericolose in quanto, come già accennato,le applicazioni potrebbero non funzionare correttamente oppure lavorando su datiincoerenti o non aggiornati, potrebbero portare ad errori nel processo produttivoe nella fornitura dei prodotti da parte dell’azienda stessa. Ad esempio, prendendocome riferimento l’azienda analizzata in questo caso di studio, possiamo illustrareuna tipologia di criticità in cui è possibile incorrere se le informazioni della stessainserzione pubblicitaria presenti nei database di due sistemi aziendali fossero diffe-renti tra loro. In un caso del genere potrebbe accadere di emettere la fattura ad uncliente, dal sistema gestionale, per un annuncio il quale, per problemi di aggiorna-mento dati, potrebbe non essere lo stesso di quello in realtà pubblicato e presentesul sistema dedicato alla produzione. O ancor peggio, nel caso in cui le informazio-ni dell’inserzione presenti sul sistema gestionale non riuscissero ad arrivare, sempreper problemi di integrazione EAI, al sistema di produzione: in questa situazionel’annuncio non verrebbe pubblicato, creando un disservizio perché non averebbe lafornitura richiesta dal cliente. In definitiva, più le informazioni tra le diverse basidati risulteranno allineate meno anomalie dovranno essere gestite. Un’applicazioneche svolge operazioni di Data Integrity sarà utile proprio per questo motivo: permet-terà 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 stru-menti molto potenti e flessibili che possano adattarsi alle diverse situazioni e chepermettano un accesso facile ai dati, visto che il dato inteso come informazione pre-sente nei campi delle tabelle, in questo contesto, è al centro dell’attenzione e deveessere salvaguardato. Per la realizzazione del progetto Data Integrity nell’aziendapubblicitaria, citata nel caso di studio, è stato utilizzato un software di IBM, Da-tastage, uno strumento molto potente di ETL utilizzato per estrarre, trasformaree caricare dati tra sistemi eterogenei. IBM Datastage è uno dei possibili strumentiper poter estrapolare i dati tra i sistemi, considerando che sul mercato sono presentialtri prodotti. Visto che in questa tesi è presente la descrizione di un progetto diData Integrity dove è stato utilizzato Datastage sarà necessario fornire al lettore unintroduzione minima su questo strumento. L’obiettivo del terzo capitolo sarà pro-prio di descrivere le funzionalità principali di Datastage, illustrando come è possibileimpostare le operazioni di prelievo dati da database differenti.Nel quarto capitolo si procederà a definire i punti chiave dell’applicazione di DataIntegrity realizzata, giustificando gli sforzi compiuti per l’analisi, l’implementazio-ne ed i test. Posso affermare che l’applicazione di Data Integrity realizzata vieneutilizzata per controllare, in determinati giorni, gli allineamenti di sei sistemi che siscambiano i dati tramite l’utilizzo dell’architettura EAI. I risultati forniti dall’ap-plicazione di Data Integrity sono serviti e servono ancora oggi per localizzare glieventuali errori nella comunicazione delle informazioni tra i sistemi, permettendo dianalizzare la distribuzione dei disallineamenti e di valutare le operazioni di modificadelle applicazioni EAI che realizzano l’architettura di integrazione.Posso anticipare che nel processo di controllo si sono verificate due tipologie di ano-malie: i dati assenti e quelli differenti. Come dati assenti intenderemo un recorddi un entità monitorata, come ad esempio un contratto, che è presente in un si-stema e non nell’altro, mentre per dati differenti intenderemo un record, sempre diun’entità, che è presente su entrambi i sistemi ma che differisce su alcuni campi chesono oggetto di controllo. L’operazione di correzione dei dati dovrà tenere contodella 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’applica-zione di Data Integrity realizzata e dei possibili sviluppi futuri che potranno essereimplementati 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, definendol’ambito in cui tale architettura può essere applicata ed utilizzata. Con il termineEAI è possibile intendere lo sviluppo di una serie di applicazioni software il cuiobiettivo principale è la creazione di un’architettura per l’integrazione dei sistemiinformativi vecchi e nuovi di un’azienda.

Perché è necessario raggiungere un’integrazione? Per capire meglio i motivi chespingono a raggiungere quest’obiettivo è importante fornire una panoramica dellasituazione attuale che si riscontra nella complessa architettura dei sistemi informa-tivi di molte aziende ed organizzazioni. Al giorno d’oggi molte aziende, soprattuttoquelle medio grandi, si ritrovano con tante applicazioni differenti, come ad esempiosistemi CRM, applicazioni di contabilità, gestione vendite ecc., le quali non possonointeragire tra di loro, trovandosi in una evidente assenza di comunicazione. Unaprima causa dell’assenza di tali collegamenti può essere dovuta al fatto che que-ste applicazioni sono state scritte con linguaggi di programmazione differenti perdeterminati sistemi operativi, creando di conseguenza il classico problema di inte-roperabilità. 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 mini-mamente 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, scambiandoinformazioni con i sistemi e le architetture già funzionanti. Utilizzando un approcciodel genere è evidente il rischio di duplicare delle funzionalità già presenti e collaudateche, tramite un intervento di integrazione, potrebbero invece essere riutilizzate, conla conseguente razionalizzazione di tempo e di denaro.In aggiunta a quanto appena descritto, sono presenti, soprattutto in grosse organiz-zazioni come banche ed assicurazioni, applicazioni che funzionano ancora su sistemimainframe che per problemi di costi di porting su nuove piattaforme si preferi-sce mantenere piuttosto che dismettere e riscrivere da zero. Anche in questo casoè necessario prevedere dei meccanismi di comunicazione con le nuove applicazionisviluppate, le quali, molto probabilmente, avranno necessità di attingere ad infor-mazioni memorizzate su tali sistemi mainframe.In questo contesto così eterogeneo è fondamentale studiare ed implementare dellesoluzioni per realizzare architetture di integrazione. Infatti, se alle applicazioni ve-nisse 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 è diavere dell’inefficienze ed anomalie, come ad esempio l’eccessiva ridondanza dei datireplicati sui database delle varie applicazioni e l’impossibilità di creare delle sempliciautomazioni di processo per mezzo di regole di business comuni. Non a caso allesingole applicazioni che non prevedono un’integrazione con l’architettura generaledi un’organizzazione viene attribuito il termine di “isola di automazione”, vista laloro chiusura rispetto all’architettura informativa complessiva.

Una possibile modalità per realizzare l’integrazione tra i sistemi è di adottareun’architettura orientata alle EAI. Dunque è facile capire il ruolo importante chepuò svolgere e le responsabilità che deve assumersi un’architettura EAI, la qualepuò “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 peressere considerata una buona soluzione EAI questa, se implementata, dovrà rispet-tare le caratteristiche di flessibilità e di apertura a possibili future estensioni. Incaso contrario, si potrebbe incorrere in un fallimento dell’architettura stessa, conl’inutile spreco di tempo e denaro.Negli ultimi decenni l’interesse nel ricorrere alle architetture di tipo EAI è statosempre più forte e guidato da diversi fattori, come ad esempio la forte pressionedell’ambiente competitivo del mercato che ha obbligato di fatto ad accorciare sem-pre di più i tempi di sviluppo dell’applicazioni e la prudenza del settore finanziarioche costringe ad utilizzare le applicazioni esistenti piuttosto che crearne di nuove,evitando perciò i rischi di investimenti di lungo periodo. È evidente che la possibili-tà di continuare ad utilizzare le applicazioni già esistenti e funzionanti può portaread un importante risparmio di denaro, un fattore questo che viene tenuto molto inconsiderazione 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 isistemi 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’integra-zione 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 mol-to dalle specificità e criticità della singola organizzazione. È importante effettuareun’analisi precisa per scegliere quali sono i processi ed i dati che richiedono l’integra-zione, perché la scelta di questi elementi implicherà in modo sensibile e determinanteil livello di dove intervenire per realizzare la soluzione EAI.È possibile definire quattro grandi categorie differenti di integrazione:

• il livello dato

• il livello applicazione

13


• il livello metodo

• il livello interfaccia utente

1.2.1 Il livello dato

Si tratta dell’implementazione dei processi, tecniche e tecnologie per spostaredirettamente i dati tra i differenti database presenti, così come indicato nell’esem-pio di figura 1.1. L’integrazione dei dati può essere definita come un’operazione diestrazione di un’informazione da un database, la modifica e aggiornamento se ne-cessari, e la copia di questa su di un altro database. Operando a questo livello lalogica delle applicazioni rimarrà invariata. È probabile che durante il processo ditrasporto 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 icosti 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 sonorelativamente più economiche rispetto alle tecnologie necessarie per implementarearchitetture EAI agli altri livelli.Per contro, il fatto che le applicazioni siano indipendenti rappresenta allo stessotempo uno svantaggio. Per realizzare l’integrazione a livello di dato vengono esclusetutte le logiche delle applicazioni e si effettuano estrazioni e caricamenti dei datiutilizzando l’interfaccia nativa del database. Quest’ultimo aspetto implica diverseproblematiche e richiede di ottenere le autorizzazioni necessarie di accesso ai datidalle persone che li gestiscono. È importante anche considerare come sono stretta-mente accoppiati i dati con la logica dell’applicazioni. Spostare i dati tra i diversidatabase senza comprendere la logica di funzionamento dell’intera architettura po-trebbe risultare un manovra pericolosa, portando a inserire informazioni errate ecausando disallineamenti tra i sistemi.

14


Database

Interfaccia

utente

Logica applicativa

Processi di

trasformazione

-

formattazione

dati

Database

Interfaccia

utente

Logica applicativa

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 controllodella produzione con il proprio applicativo ERP utilizzato per gestire la parte ammi-nistrativa. In una situazione del genere è presente la necessità di comunicare i datidegli ordini registrati sull’applicativo ERP all’applicazione di gestione della produ-zione, in modo che possa essere presa in carico e gestita con strumenti meccanizzatila lavorazione del nuovo ordine. A seguito della conferma di un ordine sul sistemaERP questo dovrà essere inviato, tramite un’applicazione EAI di aggiornamento da-ti, al sistema di produzione. Per realizzare questa esigenza, tramite un’applicazioneEAI che funziona da connettore tra i sistemi, potranno essere prelevati i dati daldatabase del sistema ERP ed inviati sul database dell’applicazione di controllo di

15


produzione, effettuando eventuali variazioni sul contenuto dei dati per rispettarei vincoli del sistema ricevente. L’applicazione di controllo produzione si ritroverànei propri archivi, in maniera automatizzata, le informazioni del nuovo ordine e diconseguenza 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 interfaccecomuni disponibili e richiamabili. Tramite l’utilizzo di queste interfacce sarà pos-sibile mettere insieme più applicazioni, con l’opportunità di condividere la logicadi business e le informazioni. Il problema più grande che bisogna affrontare nellesituazioni reali è proprio la definizione di queste interfacce comuni. Nella figura 1.2

16


è riportato un possibile schema di integrazione EAI a livello applicazione.Questa tipologia di EAI è molto spesso implementata in situazioni in cui sono pre-senti applicazioni come SAP e similari, dove tali sistemi espongono interfacce per iloro processi ed i loro dati. Quindi, per integrare questi sistemi con gli altri, che fan-no parte dell’infrastruttura informativa dell’organizzazione, è necessario utilizzare erichiamare queste interfacce. Così facendo sarà possibile accedere ai processi ed aidati, estrarre le informazioni di cui si ha bisogno, trasformarle in formato compren-sibile al sistema destinatario ed infine inviargliele.Abbiamo parlato di interfacce a livello di applicazione, ma a cosa servono? Sonointerfacce che gli sviluppatori espongono da un’applicazione per fornire l’accesso aidati oppure per l’utilizzo di certi servizi presenti sull’applicazione stessa. Alcuneserviranno per accedere ai processi di business, altre per accedere direttamente aidati, altre ancora che permetteranno di fare entrambe le cose.Perché utilizzarle? Un motivo importante è dato dal fatto che in questo modo vienefornito un accesso ai processi di business ed ai dati utilizzando delle funzionalitàpresenti ed incapsulate all’interno dell’applicazione che le detiene, evitando in que-sto modo l’accesso diretto al database per ottenere l’informazione necessaria, comeaccade in una soluzione di integrazione a livello dato.Per concludere, è possibile dire che questo approccio rappresenta il miglior modo diintegrare le applicazioni consentendo di invocare facilmente logiche di business, conl’intenzione di preservare l’integrità dei dati. Ovviamente questi metodi richiamabilidovranno offrire garanzie di qualità di funzionamento. In alcuni casi, data l’elevatacomplessità nella creazione e manutenzione di queste procedure, la verifica di cor-rettezza dati effettuata tramite un’applicazione di Data Integrity permetterebbe dirilevare eventuali errori di implementazione e di apportare le opportune modifichecorrettive.

Esempio di EAI livello applicazione

Una compagnia assicurativa ha la necessità di integrare due sistemi: un sistemaERP che è stato adottato recentemente per la gestione delle polizze assicurative edun sistema mainframe, presente da più tempo, che permette la gestione delle stesse

17


polizze. Il sistema mainframe invece di essere sostituito dal nuovo applicativo ERPviene mantenuto in parallelo. Questo perché si è deciso che certe funzionalità perla gestione della polizza assicurativa verranno richiamate dal sistema ERP ed altredal sistema mainframe. È evidente che a questo punto sarà necessario mantenereallineate le informazioni condivise tra i due sistemi per non incorrere in errori eproblemi sulle applicazioni.In questo contesto possiamo assumere che una possibile soluzione EAI a livello da-to potrebbe non essere di facile implementazione per via della complessità dei varidatabase coinvolti nel processo di integrazione. Di conseguenza, il punto più natu-rale di integrazione è a livello di interfaccia di applicazione, in modo da utilizzaredei metodi richiamabili esternamente per eseguire l’aggiornamento dei dati. Vistoche di solito i fornitori di soluzioni ERP fornisco delle API specifiche per accedereai metodi ed ai dati dell’applicazione, sarà possibile creare delle applicazioni EAI,che utilizzando tali metodi, magari esposti come Web Services, richiameranno dellefunzionalità di business o permetteranno l’aggiornamento dei dati. In modo analogosarà possibile progettare delle interfacce particolari da esporre alle applicazioni EAIche permetteranno l’accesso ai sistemi mainframe. In questo caso appena descritto,utilizzando l’integrazione a livello di interfaccia di applicazione, si potranno mante-nere allineati i dati tra i sistemi senza dovere conoscere gli aspetti tecnologici dellebasi dati coinvolte.

1.2.3 Il livello metodo

In questo livello lo scopo principale è la condivisione delle logiche di businesspresenti all’interno di un’organizzazione, così come illustrato nella figura 1.3. L’e-sempio classico per descrivere una situazione del genere è l’aggiornamento di unrecord memorizzato negli archivi di un’anagrafica cliente. Quest’operazione potreb-be essere richiesta da più applicazioni le quali potrebbero utilizzare lo stesso metodosenza doversi riscrivere una procedura specifica all’interno di ogni applicazione cheintende effettuare questa operazione.Esistono meccanismi differenti per condividere i metodi: gli oggetti distribuiti, gliapplication servers oppure attraverso la creazione di una nuova applicazione la quale

18


Applicazione 1(es. Gestione contabilità)

Applicazione 2(es. Marketing)

Applicazione n

Frameworks

Oggetto 1(es. Anagrafiche)

Oggetto 2(es. Magazzino)

Oggetto n

….. …..

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 livelloapplicazione. Questo fattore rappresenta una forte limitazione la quale ne riducel’impiego nelle situazioni reali di produzione.

Esempio di EAI livello metodo

Un esempio di EAI a livello metodo può essere rappresentato dall’unione di dueo più applicazioni per integrare funzionalità di business e dati. Supponendo che inun’azienda siano presenti due applicazioni, una che funziona su piattaforma Linuxed un’altra sviluppata per ambiente Windows, per effettuare un intervento EAI alivello di metodo:

19


• è possibile creare una nuova applicazione che comprenda le funzionalità dellevecchie che saranno sostituite;

• utilizzare meccanismi come gli oggetti distribuiti per consentire un facile ac-cesso 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’in-terfaccia utente delle applicazioni. Nonostante questa non sia la soluzione migliorein 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 attinentealla problematica del Data Integrity, questa tipologia è stata riportata solo percompletezza della descrizione dei livelli di integrazione.

1.3 Tecnologie middleware

Dopo avere descritto i possibili vari livelli di integrazione è importante dare unacollocazione dell’EAI all’interno del contesto architetturale di un sistema informati-vo. La domanda che ci si può porre potrebbe essere la seguente: “ma quali sono letecnologie 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 dicomunicazione, deve lavorare come uno strato middleware. Questa caratteristicarappresenta un punto di forza e di debolezza allo stesso tempo. Infatti, se da unlato tutto ciò che viene integrato passa all’interno dell’architettura EAI, tutto ilmeccanismo è centralizzato e si ha la possibilità di semplificarne il monitoraggio.Per contro, se qualcosa non funziona il rischio è di bloccare tutta la comunicazioneinstaurata tra i sistemi. È importante prevedere meccanismi di recupero e ripristinodi 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 da-tabase, di comunicare con un’altra o un gruppo di entità. Realizzare applicazioniEAI significherà analizzare ed implementare soluzioni middleware, che, come abbia-mo detto, rappresentano il modo migliore per muovere informazioni tra applicazionie database.È necessario, però, fare molta attenzione all’implementazione visto che risultano es-sere presenti diverse tecnologie di tipo middleware. Alcune di esse potrebbero nonessere le migliori a risolvere in modo efficace specifiche problematiche delle EAI. Adesempio, i middleware di tipo punto-punto, come possono essere le RPC (remoteprocedure call) possono certamente fornire punti di connessione tra le applicazionied essere impiegate in un’architettura EAI. Attraverso l’utilizzo di questa tecnologia,però, potrebbe diventare ingestibile l’architettura EAI, soprattutto nel caso in cuisi 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 con-cetto di gestore dei messaggi, denominato message broker. L’idea alla base è diridurre il numero di interfacce, posizionando il gestore dei messaggi in mezzo e diconseguenza facilitando il controllo del suo funzionamento. Se un’applicazione dovràcambiare il formato, andrà modificata solo una connessione e questa all’interno delmessage broker. Allo stesso modo, se una nuova applicazione dovrà essere aggiuntaal 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 tipologiadi middleware per risolvere un problema specifico, ma risulta comunque difficile de-finire delle categorie ben distinte. Sicuramente ogni tipologia avrà caratteristicheadatte a risolvere meglio determinati problemi.Nel seguito verranno illustrate, senza scendere nei particolari, alcune tra le principalicategorie di middleware utilizzabili per un’architettura EAI:

• RPC

• Message Oriented Middleware

21


• Oggetti distribuiti

• Database oriented

1.3.1 RPC

Le RPC sono le remote procedure call, le quali rappresentano una possibile mo-dalità di comunicazione con un computer remoto. La parte client ha la facoltà dirichiamare una procedura presente sul server utilizzando una semplice chiamata afunzione. 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 nascon-dere bene le problematiche di rete. Gli svantaggi nell’optare per le RPC consistononel ritrovarsi in una configurazione di tipo punto-punto e nel richiedere una co-municazione sincrona che potrebbe degradare in modo significativo le performancedell’infrastruttura EAI implementata.

1.3.2 Message Oriented Middleware

Una caratteristica importante di questa categoria è data dalla presenza di unacoda di messaggi.I messaggi sono inviati da un’applicazione e messi in una struttura di memorizza-zione di tipo coda (struttura FIFO, first input - first output). Da qui, i messaggipotranno essere prelevati o spediti all’applicazione destinataria in un tempo succes-sivo senza dovere bloccare necessariamente la prima che si è occupata semplicementedi mettere a disposizione i dati sulla coda. Di conseguenza, si capisce che si tratta diuna soluzione di tipo asincrono, ben diversa dall’utilizzo delle RPC che rappresen-tano una modalità sincrona. Questa tipologia di soluzione, chiamata anche MOM(Message Oriented Middleware), è utilizzata, ad esempio, quando i computer su cuisono installate le applicazioni non sono sempre accesi. Saranno presenti dei sistemimittenti che invieranno i dati sulla coda e poi un’applicazione EAI, che potremmochiamare “integratore”, si occuperà di convertirli, se necessario, e di trasferirli alsistema 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 lacreazione 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 inte-grate tramite la condivisione di metodi comuni.Questi metodi possono esistere all’interno di oggetti distribuiti raggiungibili attra-verso la rete. Adottando questo tipo di approccio sarà molto probabile utilizzare unaspecifica tecnologia basata su ORB, basandosi su specifiche come CORBA o DCOM,attenendosi, quindi, a degli standard ben definiti. Una caratteristica importante de-gli oggetti distribuiti è data dal fatto che questo approccio supporta e valorizza glisforzi per il riuso degli oggetti. Uno dei principali svantaggi, invece, è attribuibileal seguente problema: l’utilizzo di queste tecnologie, ovvero degli oggetti distribuiti,richiede forti modifiche alle applicazioni esistenti. In generale, la soluzione offre dispostare i metodi dalle applicazioni agli oggetti distribuiti. Si tratta di un approcciodi impatto sull’architettura esistente e, per questo motivo, di difficile utilizzo in uncontesto operativo reale.

1.3.4 Database oriented

Il middleware orientato ai database è una parte necessaria in tutte le applicazio-ni di integrazione, specialmente per quelle che devono lavorare a livello dato. Nonfornisce solo un’accesso ai dati contenuti nel database, ma si occupa anche di map-pare eventuali differenze di formato. Il middleware in questo contesto può prendereforma di chiamata a livello di interfaccia. Infatti, può tradurre una chiamata nellospecifico dialetto del database di interesse e ritornare la risposta in un formato uni-co. Degli esempi per questa tipologia di middleware sono l’ODBC e JDBC. Il primorappresenta un livello di traduzione per i database relazionali su piattaforme Win-dows, mentre il secondo, JDBC, è anch’esso un livello di traduzione per i database,ma legato al mondo Java.

23


1.4 Metodologie per l’implementazione

Dopo avere brevemente descritto quali sono alcune delle possibili tecnologie perl’implementazione dell’architettura EAI, in questa sezione si discuterà sull’esistenzao meno di una metodologia da seguire per la realizzazione di tali architetture diintegrazione.Possiamo subito dire che una metodologia comune per realizzare architetture EAInon esiste, nonostante da diversi anni si parli di EAI e molti professionisti venganoutilizzati nel loro sviluppo. I processi di integrazione tramite l’EAI si trovano ancorain una situazione poco matura e consolidata. Quanto detto è riconducile alla storiadei modelli e delle architetture dei computer. Infatti, molti software per l’EAI sonoproprietari, ciascun produttore ha creato una particolare metodologia per imple-mentare il proprio prodotto. In più, ogni prodotto non consiste in un’architetturavera e propria di integrazione, ma piuttosto rappresenta solo una parte di essa. Leimplementazioni EAI sono partite con l’intento di arrivare a degli standard, ma imetodi 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 ilprocesso di integrazione e dell’architettura è più vicina all’arte che ad una scienzaesatta. Quindi, molto viene demandato alle capacità ed esperienza delle personeche analizzano ed implementano le procedure di integrazione. Infatti, ci sono diversimetodi che sono utilizzabili per analizzare i dati e flussi dei processi. In base al pro-blema si potrebbero scegliere semplici processi di sincronizzazione dei dati oppureimplementare paradigmi di tipo SOA. Per fare questo, però, non sono presenti delleregole ben definite, dipende da cosa si vuole ottenere come risultato dell’integrazionee da quanto l’azienda è disposta ad investire su questa tematica.Quanto appena detto mette in luce le difficoltà nella scelta di un determinato mo-dello di implementazione delle procedure di integrazione EAI. È molto importantecomprendere 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 ar-chitettura di integrazione è possibile fornire al lettore le linee guida formulate dauno dei massimi esperti di EAI, David S. Linthicum1, il quale ha definito 12 punti

1Autore 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ò occupareanche una lunga parte del periodo necessario all’adozione di un’architettura EAI.Sicuramente è un momento fondamentale ed irrinunciabile. È molto importantecomprendere quali sono i problemi e le esigenze dell’azienda per trovare la soluzionepiù idonea. Sarà necessario collaborare con i responsabili dei vari sistemi informativipresenti per conoscere e comprendere la struttura informativa e ciò che è in essacontenuta. L’interazione con le persone ed i sistemi porterà a determinare qualisono le informazioni che dovrà gestire la soluzione EAI. Inoltre, è fondamentale

25


ricordare che le informazioni ottenute in questo passo influenzeranno direttamentele 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 fattoche molti progetti EAI sono presenti a livello dato e di conseguenza si deve defini-re il significato delle informazioni ed avere una comprensione chiara di come sonostrutturate e memorizzate. Il secondo motivo è legato al fatto che anche i progettisviluppati sugli altri livelli di EAI necessitano molto spesso di comprendere l’orga-nizzazione dei dati sui differenti database.Per implementare un’architettura EAI a livello dato sono presenti tre operazionioperazioni 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 utilizzatocome guida principale per integrare i diversi database che esistono all’internodell’organizzazione.

Dare un significato ai processi

Una volta che si sono compresi i dati è possibile decidere come approcciarsi almodello di business dell’azienda. Tale decisione dipenderà sicuramente dal partico-lare dominio di EAI che si intende raggiungere.In questa attività l’obiettivo è di ottenere una vista dell’azienda a livello di proces-so. Il lavoro principale sarà la comprensione e documentazione di tutti i processi dibusiness presenti all’interno dell’organizzazione.

Identificare le interfacce dell’applicazioni

Una fase da affrontare corrisponde alla raccolta delle informazioni sulle interfac-ce delle applicazioni. Si tratta di un lavoro molto utile per supportare l’integrazione

26


EAI a livello d’interfaccia oppure per implementare l’integrazione dell’interfacciadelle applicazioni con gli altri livelli di EAI.Le interfacce, di solito, non vengono prodotte secondo in modo standard, esse ge-neralmente sono differenti da applicazione ad applicazione, di conseguenza è utileavere un elenco di queste memorizzandole in uno specifico repository facilmenteaccessibile.

Identificare gli eventi di business

L’operazione consiste nell’identificazione di tutti gli eventi di business rilevantiche 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 capirel’esito della azione risultante.Infatti, è fondamentale comprendere chi ha invocato un evento di business, chi hapartecipato all’evento e quali sono stati gli altri eventi che possono essere statiinvocati come conseguenza dell’avvio di uno iniziale.In un’architettura EAI un obiettivo possibile è di automatizzare gli eventi su tutti isistemi eliminando i processi manuali.

Identificare gli scenari di trasformazione dei dati

L’obiettivo di questo punto è di ottenere la conoscenza delle trasformazioni cheavvengono tra i dati scambiati tra i diversi sistemi. È importante realizzare questolavoro perché i dati che esistono in un sistema potrebbero non avere significatosu di un altro senza opportune modifiche al dato stesso. Effettuando le opportunetrasformazioni 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 delleinformazioni da sistema a sistema memorizzando le informazioni che vengono sposta-te e memorizzate. Si dovranno memorizzare gli eventi che limitano gli spostamentidelle informazioni, oppure gli eventi richiesti o le condizioni necessarie per attivarelo spostamento dell’informazione dal sistema sorgente verso il relativo destinatario.

27


Applicare la tecnologia

Una volta terminate tutte le operazioni di catalogazione delle informazioni, siarriva al punto in cui è necessario selezionare e decidere quale tecnologia adottareper risolvere il problema di integrazione EAI. In questo contesto sono presenti moltetecnologie, che abbiamo già descritto in precedenza, come gli oggetti distribuiti, lerpc ed i message brokers. In generale, la scelta della tecnologia da adottare è un mixdi prodotti di fornitori differenti i quali insieme riescono a soddisfare le esigenze diun’architettura EAI. È molto raro che un singolo fornitore sia in grado di risolveretutti i problemi che la soluzione di solito richiede. È evidente che la scelta della tec-nologia sia un processo molto difficile che può richiedere un grande sforzo di tempoe di risorse.In questa fase vengono definiti dei requisiti che una tecnologia e suoi prodotti devonoraggiungere e soddisfare. Con questa attività è possibile comprendere le soluzionidisponibili e scegliere quelle che rispondono meglio alle proprie necessità. Per capirese un requisito potrà essere raggiunto o meno da un prodotto a volte sarà necessa-rio provare con un “progetto pilota”. In questo modo si arriverà a conoscere cometale tecnologia funziona e come questa potrà essere utilizzata nell’architettura EAI.Il tempo per scegliere la giusta tecnologia potrebbe, a volte, essere lungo quan-to lo sviluppo dell’intera soluzione EAI. Un’eventuale scelta errata causerà quasisicuramente il fallimento del progetto EAI.

Fare più test possibili

La parte di test è sempre molto costosa e di solito tende ad occupare moltotempo e molte risorse. Per contro se un’architettura EAI non viene testata in mo-do sufficiente è possibile avere degli effetti collaterali devastanti dal punto di vistadell’integrità di tutto il sistema. Ad esempio, potrebbero essere sovrascritti dei datiimportanti, oppure informazioni errate potrebbero essere inserite all’interno delleapplicazioni. La fase di test è fondamentale per verificare che la soluzione imple-mentata sia scalabile, possa funzionare in modo adeguato ed accettabile nell’usoquotidiano, prevedendo anche carichi di lavoro normalmente non presenti.

28


Utilizzare delle applicazioni di controllo dati può essere uno degli strumenti perverificare 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 attenzio-ne. Generalmente i sistemi su cui non si valutano correttamente le performance sonodestinati a fallire.Con le tecnologie attuali sono presenti molte architetture EAI che non fornisconouna latenza bassa nel rispondere alle operazioni richieste. Gli spostamenti tra si-stemi, l’invocazione di comuni processi di business dovrebbero rispondere con untempo inferiore al secondo. Lo stesso tempo di risposta dovrebbe essere mantenutoa prescindere dall’aumentare del numero di utenti e processi caricati.Come è possibile valutare le performance di un sistema? Innanzitutto possiamoaffermare che le performance non rappresentano un requisito definito all’inizio dellosviluppo e poi, in seguito, ignorato. Le performance sono valutate dall’inizio allafine di tutto il periodo di utilizzo di un’architettura EAI. Quanto appena afferma-to implica che una soluzione EAI deve necessariamente fornire degli strumenti perle verifiche delle performance. Queste verifiche devono essere fatte sotto differenticondizioni. Ad esempio verificando con 100 utenti oppure 1000 utenti, controllandol’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 fareciò è di valutare i soldi che si sono risparmiati utilizzando con successo l’architetturaEAI.Per raggiungere questo obiettivo si devono considerare due fattori:

• il valore dell’architettura EAI intesa come la capacità di eliminare i processicostosi, come i processi manuali, ottenendo di conseguenza una riduzione deglierrori;

29


• il valore fornito dall’incremento della produttività.

Creare delle procedure mantenibili nel tempo

Ultimo punto da considerare, ma non meno importante, è la definizione di comemantenere nel modo migliore un’architettura EAI. In questo caso ci si deve porredelle 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à inmodo da poterle assegnare a persone diverse in caso di necessità. Bisogna ricordarsiche un’architettura EAI rappresenta il cuore di un’azienda perché muove informa-zioni vitali tra i sistemi e quindi un’operazione errata potrebbe compromettere lastabilità e la coerenza tra i sistemi.

1.5 Potenziali criticità

Un’architettura di integrazione EAI deve essere vista come la realizzazione diun obiettivo che porta a migliorare i processi aziendali, necessaria per migliorareil lavoro dell’azienda. Ma ovviamente, come in tutte le scelte, bisogna considerareanche i potenziali aspetti negativi che possono comportare anche delle criticità nonindifferenti.In certe situazioni, nei casi peggiori, si può arrivare addirittura ad un fallimento veroe proprio della architettura EAI. Questo evento porterà con sé tutte le conseguenzelegate all’insuccesso dell’investimento di persone e risorse impiegate per l’implemen-tazione dell’infrastruttura EAI. Per evitare che questo accada, è necessario, primadi procedere a realizzare un’architettura EAI, analizzare i possibili problemi a cui sipotrà andare incontro, valutando le probabilità di incorrere in queste casistiche.La parte che segue vuole illustrare alcuni dei possibili problemi che si possonoincontrare 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 verificaredelle situazioni che creano forti problemi e rallentamenti e che possiamo riassumerenei punti seguenti.

• La reale implementazione risulta essere più complessa e costosa di quella attesae preventivata. A volte capita perché si commettono errori nell’analisi proget-tuale ed in fase di realizzazione si rilevano delle difficoltà tecniche che non siriescono a superare facilmente se non stravolgendo alcune parti del progettoo, nei casi peggiori, ricominciando di nuovo dalla fase di analisi, aumentan-do di conseguenza i costi. Ma i costi possono aumentare anche perché moltifornitori per realizzare architetture EAI tentano di convincere gli sviluppatoriche utilizzando il loro prodotto questo li aiuterà a creare in breve tempo lasoluzione di integrazione. Magari alla fine si scoprirà che avrà solo aumentatoi costi senza portare effettivi miglioramenti.

• Può capitare che le singole business unit2 associate ai sistemi informativi nonvogliano comunicare e cooperare. Prima dell’avvento di un’architettura EAIogni business unit considerava la sola propria applicazione, senza avere neces-sariamente una visione dell’infrastruttura informativa globale. Invece, realiz-zando un’architettura EAI sarà richiesta una collaborazione molto forte tra leunità che si occupano dei vari sistemi ed il gruppo centrale a supporto del-l’EAI. Questo perché i singoli sistemi dovranno condividere con le persone chelavoreranno sulle EAI procedure per richiamare le operazioni sui propri sistemie dovranno comunicare eventuali modifiche e manutenzioni. In caso contrario,il gruppo EAI potrebbe rimanere con informazioni non aggiornate, con tutti irischi di fare operazioni non più coerenti.

• In grosse organizzazioni il gruppo che si occupa di EAI ed i responsabili dei va-ri sistemi possono fare riferimento a capi diversi i quali non voglio incentivarequesto dialogo tra i gruppi; in situazioni del genere eventuali problemi legati

2Parte di un’azienda che rappresenta una specifica funzione di business, chiamata anche areafunzionale o dipartimento.

31


agli eccessivi costi del progetto di integrazione potrebbero diventare cause sca-tenanti di scontro tra il gruppo EAI e gli altri attori dei vari sistemi, rendendola situazione ancora più difficile.

1.5.2 Dati non allineati

Un sistema di memorizzazione di dati per garantire la qualità delle informazionidovrebbe lavorare utilizzando un paradigma di tipo transazionale, modalità questache permetterebbe di essere affidabile. L’utilizzo di un paradigma di questo tipo,ovvero quello transazionale, darebbe la possibilità di semplificare le problematiche diconsistenza, di recupero dati e gestione errori in un sistema di integrazione. Il pro-blema che solitamente si riscontra in un’architettura EAI è di trovare molto spessoprocessi di natura asincrona. Questi processi potenzialmente possono durare anchemolto tempo all’interno di ciascun sistema, quindi difficilmente potrà essere realiz-zato 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 equindi bloccarsi. In caso di errore di una procedura EAI, difficilmente sarà possibilerichiamare una funzione di rollback per annullare le operazioni eseguite, in modoanalogo a quello che avviene su una base dati transazionale. Si potranno ritrovare,perciò, delle informazioni disallineate tra i sistemi, ovvero non ci sarà più garanziadi Data Integrity tra le basi dati delle diverse applicazioni. Questa situazione è il-lustrata nell’esempio della figura 1.4, dove sul sistema di partenza viene modificatal’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 di-sposizione dell’architettura EAI dei meccanismi per accorgersi di queste situazionidi disallineamento dei dati. Questa criticità, ovvero il rischio di avere dei dati nonallineati tra i vari sistemi, è proprio quella che ci porta a giustificare la realizzazio-ne di un sistema di controllo di allineamento effettuando direttamente le verifichesui dati. A questo controllo di coerenza delle informazioni memorizzate nelle basi

32

1.5 – Potenziali criticità

Database1

Tabella Contratti

Applicazione 1

Database3

Tabella Contratti

Applicazione 3

Database2

Tabella Contratti

Applicazione 2

Architettura EAI

Sull’applicazione 1 viene modificato il contratto 1234

1

2

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à

Si verifica un errore nelle operazioni EAI per aggiornare i dati sull’entità contratto degli altri sistemi

3

Si hanno dei dati disallineati sulle tabelle dei contratti!

Utilizzare dei controlli di Data Integrity per riscontrare questi disallineamenti

Figura 1.4. EAI: possibile problema di Data Integrity nell’architettura EAI

33


dati possiamo assegnare il nome di Data Integrity. Quindi, un sistema di controllodi Data Integrity potrà aiutare a rispettare uno dei requisiti più importanti nellosviluppo di processi di integrazione, ovvero il mantenimento della coerenza dei datiscambiati. La correttezza delle informazioni condivise sarà un buon indicatore percapire se l’architettura EAI starà operando in modo corretto o meno.Il prossimo capitolo si occuperà proprio della problematica dell’integrità dei datidistribuiti in un sistema informativo complesso. Sarà illustrato come sia possibiledefinire ed implementare un’applicazione che si occupa di Data Integrity all’internodi 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’ar-chitettura complessa all’interno della quale sono presenti sistemi diversi, è fonda-mentale per garantire la correttezza e la validità delle informazioni scambiate. Lafigura 2.1 riporta un possibile schema di controllo dati tra tre sistemi differenti checondividono l’entità contratti. L’applicazione si occuperà di prelevare i dati da con-trollare ed eseguirà delle procedure di controllo per verificare l’allineamento delleinformazioni.

La presenza di dati disallineati nei back-end potrebbe compromettere le funzio-nalità delle varie applicazioni del sistema informativo o causare malfunzionamentinel richiamare le procedure che usufruiscono di quelle informazioni. Quindi è im-portante 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 contrattodi un’inserzione pubblicitaria dal punto di vista sia amministrativo che editoriale.Questa suddivisione potrebbe fare decidere ai responsabili dei sistemi informativi didefinire l’entità del contratto su entrambi i sistemi. L’entità, intesa come tabella

35

2 – Il Data Integrity in un’architettura EAI

Database

1

Tabella Contratti

Applicazione 1

Database

3

Tabella Contratti

Applicazione 3

Database

2

Tabella Contratti

Applicazione 2

Data IntegrityPreleva le informazioni delle

entità condivise sui vari sistemi e verifica se i dati

sono allineati

Fornisce strumenti per calcolare e visualizzare i

disallineamenti riscontrati tra le entità distribuitesui vari sistemi

Figura 2.1. Data Integrity: esempio di applicazione di controllo dati inun’architettura EAI

36

2.1 – Introduzione

o insieme di tabelle costituite da specifici campi, sarebbe presente in due databasedistinti, i quali dovranno richiedere un processo di integrazione che prevederà deiflussi di allineamento dati per avere gli aggiornamenti delle informazioni in caso dimodifica effettuata in uno dei due sistemi. Se nel processo di aggiornamento tra idue 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’ap-plicazione di Data Integrity, in questo caso, sarà di evidenziare le anomalie tra ledue entità, effettuando i controlli con una cadenza temporale da definire in base allaperiodicità dei flussi che sono presenti nel processo di integrazione. Sarà possibile,in questo modo, predisporre uno strumento con cui fornire delle interfacce utente edei report di dettaglio o aggregati dove riportare le anomalie riscontrate sui dati.Questi strumenti saranno utili per pianificare dei recuperi delle informazioni con lapossibilità di integrare le procedure di riallineamento all’interno dello strumento dicontrollo allineamento dati.Uno dei primi compiti per la realizzazione di una soluzione di Data Integrity è l’i-dentificazione delle entità critiche presenti sui sistemi informativi, definendo cosaesattamente è necessario controllare. L’attività appena citata può essere realizzatadefinendo quali tabelle sono da monitorare e di queste, quali campi è necessariomantenere allineati. Questa considerazione ne fa derivare subito un’altra molto im-portante: bisogna tenere presente che una gestione di Data Integrity ha un costo dianalisi ed implementazione da non sottovalutare e deve essere implementata quan-do la mole di informazioni scambiate è molto grande e di conseguenza il controllomanuale sarebbe impensabile. Generalmente la necessità di utilizzare procedure diData Integrity può essere effettivamente richiesta nei casi in cui sono presenti sistemiinformativi medio grandi, dove i flussi di integrazione sono molteplici e si trovanotante procedure automatizzate. Come già detto, le procedure, anche se automatiz-zate, molto spesso hanno un sistema di monitoraggio che deve essere verificato da ungruppo di utenti il quale ne controllerà il corretto funzionamento. Uno strumentodi segnalazione e monitoraggio aggiuntivo per l’architettura EAI potrebbe arrivareda un’applicazione di Data Integrity, la quale riscontrando o meno disallineamenti,permetterà di capire se qualcosa non sta funzionando nei processi di integrazione.

37


Inoltre, la scelta di ricorrere ad applicazioni di Data Integrity può avvenire ancheper verificare l’allineamento dei dati nel caso in cui un’azienda decida di effettuareoperazioni di migrazioni di alcuni sistemi informativi. Ad esempio, considerandol’azienda su cui ho realizzato il progetto di Data Integrity, all’interno della quale sistanno spostando dati e procedure delle applicazioni CRM e amministrative versoSAP, la fase di migrazione di questi sistemi costituisce un momento molto delicatoper il dato. Risulterà utile verificare, oltre al corretto funzionamento delle nuoveapplicazioni, anche il corretto trasferimento delle informazioni dal sistema vecchioa quello nuovo, controllando eventuali assenze e differenze sui dati. Questo aspettoè importante perché generalmente in casi di spostamento di grosse quantità di datici si affiderà di solito a flussi di integrazione, i quali ovviamente se non sarannoimpostati correttamente genereranno malfunzionamenti che potranno fare perdereinformazioni importanti. Anche per questi motivi implementare una soluzione diData Integrity può essere una strategia vincente per certificare e validare il successodella migrazione dei dati tra i sistemi (vecchio e nuovo).Nello scenario di un’architettura EAI, vista la complessità dello sviluppo e la diffi-coltà di effettuare operazioni di debug in tempo reale, la presenza di uno strumentodi controllo di Data Integrity può rappresentare un ausilio per il successo dell’im-plementazione dell’architettura stessa. Se le informazioni movimentate dai flussi diEAI saranno allineate, questa situazione rappresenterà un segnale positivo di funzio-namento dell’architettura, giustificando di fatto l’investimento e gli sforzi effettuatinella scelta di adottare tale architettura di integrazione. Inoltre, nella fase di nuo-ve implementazioni di procedure di integrazione, il rilevamento di disallineamentinei dati potrà essere utilizzato per comprendere i motivi di queste anomalie. Conuno strumento di controllo dati si avrà la possibilità di definire casistiche di erroree di conseguenza apportare le correzioni sui flussi di integrazione. Quanto appenadetto permette di considerare il Data Integrity come un’attività che collabora conl’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 do-vrà 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. Biso-gna 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 architetturecomplesse. Trattandosi di un ambito in cui sono presenti molti attori sarà necessariopuntare alla collaborazione con i diversi gestori dei sistemi per avere tutti i dettaglipossibili, in modo del tutto analogo alle problematiche EAI già discusse. In caso dimodifiche nelle logiche applicative o di dati sarà importante avere subito le informa-zioni per evitare di effettuare dei controlli con logiche non più coerenti. Un progettodi Data Integrity per essere valido dovrà essere mantenuto nel tempo allineato conle logiche presenti sui sistemi in modo analogo alle altre procedure di integrazione diEAI. Altrimenti, in caso contrario, si correrà il rischio di generare delle segnalazionidefinibili come “falsi positivi”, nel senso che verranno indicati come errori situazionicorrette, oppure non si riscontreranno gli errori quando questi saranno presenti.Le fasi che fanno parte del processo di implementazione di una soluzione di DataIntegrity sono in parte riconducibili alle linee guida per l’implementazione di un’ar-chitettura EAI definite nel primo capitolo, nello specifico possono essere condensatenei 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


• 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 busi-ness” dell’azienda su cui si deve costruire un’applicazione di Data Integrity. Questopassaggio è fondamentale perché l’analisi a questo livello determinerà le scelte del-le fasi successive. Si tratta di un attività molto critica che deve essere fatta con iresponsabili interni dell’azienda per capire e comprendere gli oggetti di business fon-damentali. Ad esempio, oggetti critici di business potrebbero essere i dati dei clientiper un sistema CRM, il documento di vendita per un programma gestionale ecc..L’individuazione a livello logico delle entità da controllare è il passaggio obbligatorioprima di intraprendere qualsiasi altra attività di implementazione. Sarà possibiledecidere, in seguito, di controllare anche altri oggetti di business mentre si starà giàlavorando alle fasi successive, ma queste aggiunte non dovranno comunque stravol-gere il percorso fino a quel momento intrapreso, per evitare di dovere annullare illavoro 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 controllotramite un’applicazione di Data Integrity, sarà molto importante effettuare un’ana-lisi 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 sudi un database, si potrà optare per l’utilizzo di uno strumento compatibile con latecnologia riscontrata ed eventualmente già a disposizione dell’azienda. Si potrannoanche valutare eventuali acquisti di strumenti specifici che permetterebbero miglioriperformance e stabilità.

40


In questa fase di analisi si verrà a conoscenza delle specifiche piattaforme e dei siste-mi informativi presenti. Sarà molto importante ottenere le informazioni di accessoalle basi dati associate ai sistemi. Ad esempio, per un database sarà necessario co-noscere la stringa di connessione e le utenze per accedervi. Se i dati fossero invecesalvati su file, come ad esempio avviene con dei backup, sarà necessario conoscerela cartella dove saranno memorizzati, richiedendo eventualmente i diritti di accessoalmeno in sola lettura.Effettuando l’analisi dell’entità di business e del contesto operativo sarà possibilefare una valutazione di quanti e quali sono i sistemi che richiedono questo moni-toraggio da parte della soluzione di Data Integrity. A questo punto sarà possibileiniziare 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 con-tengono le entità da monitorare, si dovrà scendere di livello andando a verificareed ottenere le informazioni sulle modalità di memorizzazione dei dati. Come giàdetto precedentemente, molto probabilmente, si dovrà accedere ad un database e diquesto sarà necessario ottenere le informazioni circa la modalità di memorizzazionedei dati dell’entità all’interno dei campi della tabella. Infatti, una volta definitel’entità e le informazioni da controllare sarà necessario effettuare un mapping trai dati dell’entità logica e di come questi siano effettivamente presenti all’interno diuna o più tabelle.Questa operazione che può sembrare banale, molto spesso non lo è, perché i cam-pi possono anche essere poco autodescrittivi, ovvero il loro nome non ci fornisceun’informazione esplicita di quale attributo dell’entità si riferisce. Si tratta di unasituazione abbastanza frequente nei casi in cui vengono utilizzate applicazioni com-plesse tipo SAP, nella quale sono presenti migliaia di tabelle e ciascuna di essa ècostituita da una moltitudine di attributi. Inoltre, molto spesso si trovano delletabelle con tanti campi perché l’entità che viene memorizzata su queste strutture

41


deve essere caratterizzata da molte informazioni perché è costituita da tanti attri-buti. Di conseguenza il passaggio dal modello logico dell’entità a quello fisico su unatabella di un database prevederà la creazione di tanti attributi per poter al megliodescrivere 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 moltooneroso dal punto di vista di controllo e di realizzazione, e poi c’è da considerare ilfatto che generalmente quando ci sono tanti attributi non è detto che questi con-tengano valori significativi in tutti i record e soprattutto per tutti i sistemi. Saràfondamentale circoscrivere le informazioni condivise tra i sistemi che necessitano dicontrollo e lavorare solo su quelle. Per raggiungere quest’obiettivo si dovranno con-tattare le persone responsabili dei vari sistemi informativi i quali dovranno fornirele 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, sepresente, mantiene le informazioni associate alla struttura di un database e da cuipossono 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 quanticaratteri), ecc.

Il data dictionary può essere utile per ricercare, con delle interrogazioni SQL speci-fiche, i nomi e gli attributi di campi particolari all’interno della struttura. General-mente si tratta di uno strumento abbastanza comune tra i database. Tuttavia, questidizionari sono stati implementati dai produttori in maniera diversa sia per quantoriguarda la forma che per i contenuti. Per questo motivo, a volte, le informazionida ricercare non sempre si riescono ad ottenere facilmente.

42


Comprendere i vincoli di integrità

Quando si analizza un singolo database, si presentano costantemente problemati-che di integrità sui dati. Per gestire bene queste situazioni è importante comprenderele regole applicate per la costruzione del database. Ad esempio, quando abbiamo unatabella contenente i dati di testata di una fattura ed un’altra contenente i dettaglidi riga collegati alla testata tramite una chiave esterna, l’operazione di inserimentodati corretta prevederà prima il caricamento della testata del documento fattura poil’inserimento di tutte le righe ad essa associata. In caso contrario, se l’integrità nonfosse stata impostata, sarebbe possibile avere delle righe di fattura senza i relatividati di testata e quelle informazioni, molto probabilmente, non sarebbero più rag-giungibili dall’applicazione. Ovviamente per mantenere questi vincoli, le tabelle deidiversi database prevederanno delle chiavi primarie che permetteranno di distingue-re i record in modo univoco.Conoscere questi vincoli di integrità, analizzando chiavi primarie ed indici, sarà diausilio alle politiche di confronto di un’applicazione di Data Integrity per riconoscerela stessa entità presente su database diversi.

Considerare il Data Latency

È una caratteristica associata al dato che definisce quando e come l’informazioneda verificare risulta essere presente e valida. Il Data Latency deve essere conosciutoper determinare il momento in cui l’informazione potrà essere presa in considerazioneda una procedura di controllo allineamento dati come il Data Integrity.Per quanto concerne la parte di controllo delle informazioni possiamo avere trecategorie 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


addirittura latenza nulla rispetto ad una possibile modifica su un altro sistema. Insistemi real time i dati sono aggiornati immediatamente all’interno del database ele 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 inreal time non dovrebbe creare problemi per quanto riguarda il momento in cui pre-levare l’informazione. Nonostante questo converrà accedere ai dati per effettuare iconfronti in momenti in cui ci saranno meno utenti che lavoreranno sui sistemi, inmodo 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 è ag-giornato a determinati intervalli rispetto agli aggiornamenti istantanei come avvieneinvece in real-time. Un esempio può essere il valore all’interno di una tabella cheper essere aggiornato deve aspettare la terminazione di un’operazione molto lungae 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, rispet-to agli aggiornamenti in real-time e near-time. Un tipo esempio di operazione batchtime l’abbiamo quando l’operazione di allineamento tra sistemi avviene con dei jobnotturni, schedulati appositamente per trasportare le informazioni da un sistemaall’altro. Questo significa che durante tutto il giorno si potrà avere un’informazionediversa sulla stessa entità tra i due i sistemi, ma questo non sarà un errore. La situa-zione non sarà risolta finché non arriverà il processo notturno, ovvero un processobatch, ad occuparsi dell’aggiornamento delle informazioni.

Per quanto riguarda l’applicazione di Data Integrity sarà necessario conoscerequeste situazioni per sapere quando prendere i dati su cui effettuare il confronto.

44


2.2.4 Effettuare transcodifiche sui campi

Una volta recuperato tutte le informazioni circa i nomi dei campi e delle tabelleche contengono le entità il processo di analisi dei dati non è ancora terminato.Infatti, quando si integrano applicazioni differenti è facile che queste abbiano neiloro 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 inun sistema, mentre per recuperarla dall’altro sarà necessario concatenare due o piùcampi. Sarà anche possibile trovarsi in situazioni dove il dato per essere confrontatodovrà essere estratto dal valore di un campo, quindi si dovranno utilizzare operazionidi manipolazione di stringhe oppure di conversione da stringa a numero e viceversaPer rappresentare meglio queste casistiche è possibile riportare gli esempi seguenti:

Sistema A

Contratto

ConfermatoROSSI24/06/20091234

Stato contattoClienteDataCodice

Sistema B

Contratto

CROSSI24/06/20091234


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”

Figura 2.2. Data Integrity: esempi di transcodifiche sui dati (1)

45


Sistema A

Contratto



Sistema B

Contratto



Sistema A

Tabella contratto

ConfermatoROSSI1234

Stato contattoClienteCodice

Sistema B

Tabella contratto

ConfermatoROSSI4123

Stato contattoClienteSottocodiceCodice

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)

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.

Figura 2.3. Data Integrity: esempi di transcodifiche sui dati (2)

46


2.2.5 Implementare le politiche di confronto sui dati

Questa è la fase in cui avviene il passaggio dall’analisi alla realizzazione vera epropria. A questo punto sarà necessario definire e realizzare gli algoritmi di carica-mento, aggiornamento e confronto dei dati. Sarà importante considerare il numerodi righe presenti nella diverse tabelle da cui estrapolare i dati su cui effettuare ilconfronto. In particolare, dato che nei grossi sistemi generalmente le entità di busi-ness avranno una cardinalità molto grande, è ragionevole pensare di utilizzare dellestrutture dati di ausilio dove caricare temporaneamente i dati dei sistemi da con-trollare. In queste strutture sarà possibile applicare le logiche di transcodifiche suideterminati campi analizzati nello step precedente in modo da ottenere dei dati con-frontabili. Ovviamente per realizzare queste politiche di confronto sarà necessarioriconoscere ed utilizzare quei campi che rappresentano in modo univoco una deter-minata entità. Sarà necessario definire delle chiavi primarie sulle tabelle temporaneedove saranno memorizzati i dati ed utilizzare queste come chiave di confronto perriconoscere l’assenza o meno del record tra i sistemi. A parità di chiave di confrontoinvece si potranno valutare le differenze sugli altri campi.Aiutandoci con un esempio per rappresentare meglio la situazione, possiamo immagi-nare che una volta prelevato i dati dell’entità contratti dai due sistemi da controllaresi 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 dicampi che renderanno univoco il record all’interno della tabella. Adottando que-sto metodo per entrambe le tabelle sarà possibile ricercare un record dell’entità delprimo sistema all’interno della tabella del secondo sistema, evidenziando di conse-guenza eventuali anomalie.Le possibili anomalie che possiamo riscontrare sono:

• l’assenza del dato

• la differenza su uno o più campi

47


Assenza del dato

Con assenza del dato possiamo intendere un record od un insieme di recordche sono presenti su un sistema, che possiamo chiamare A, e non presenti sull’altrosistema 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.

Sistema A

Contratto

SospesoNERI24/06/20099999



Sistema B

Contratto



Il dato manca sul sistema B

Sistema A

Contratto



Sistema B

Contratto




Il dato manca sul sistema A

Figura 2.4. Data Integrity: esempi di dati assenti

La scelta delle tipologie di assenze da ricercare dipendono in senso stretto dalleapplicazioni di integrazione, quindi, sarà importante conoscere quali sono i dati chevengono aggiornati. In particolare, bisognerà conoscere qual è il sistema che detienela versione del dato corretta, perché tale informazione verrà propagata alle altre

48


applicazioni. In questo modo saremo in grado di valutare se lo stesso dato presentesugli 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 sarannopresenti su entrambi i sistemi. Tale caratteristica è importante perché il calcolo delleassenze potrà essere fatto partendo dall’analisi dei dati presenti sul sistema A e nonsu B o viceversa se necessario, oppure in entrambe le direzioni.Da quanto appena descritto possiamo affermare che quando effettuiamo il controllodi assenza sarà importante verificare l’introduzione o meno di filtri di selezione deidati da confrontare, altrimenti potremmo avere delle segnalazioni di assenza inesatte.Questo serve per giustificare il fatto che non tutti i record presenti nelle tabelleassociate alle entità dovranno essere presi in considerazione. Si tratta di un aspettofondamentale nel processo di realizzazione di una soluzione di Data Integrity, inquanto si dovranno selezionare e mettere a confronto solo i dati che per logiche dibusiness e per impostazioni dell’architettura EAI dovranno trovarsi su entrambi isistemi, eventualmente focalizzandosi solo su quelli assenti su un determinato sistemaoppure 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 riscontrarequando troviamo lo stesso record sui sistemi coinvolti nel confronto e troviamo deivalori 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, tramitela sua chiave primaria univoca, il record sul sistema B ma andando a confrontarei singoli valori riscontriamo delle informazioni diverse per almeno un campo, traquelli che rientrano nelle politiche di confronto. Siamo in una situazione in cui, perqualche motivo da accertare, i dati non sono stati aggiornati correttamente sui varisistemi. Le cause che possono concorrere a questa tipologia di anomalia potrebberoessere le seguenti:

• l’applicazione di integrazione che si occupa di aggiornamento dei dati nonfunziona correttamente, potrebbe essere presente un errore nel mapping tra icampi che deve aggiornare oppure si potrebbe riscontrare un baco nel codice

49


Sistema A

Tabella contratto

ConfermatoBIANCHI9999

ConfermatoROSSI1234


Sistema B

Tabella contratto

ConfermatoNERI9999

ConfermatoROSSI123


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.

Sistema A

Tabella contratto

ConfermatoBIANCHI9999

ConfermatoROSSI1234


Sistema B

Tabella contratto

Confermato9999

ConfermatoROSSI123


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


e l’applicazione di integrazione termina senza effettuare tutte le operazionipreviste;

• si è verificato un errore occasionale sull’applicazione di integrazione e per uncerto periodo il dato rimarrà disallineato; in questo caso si potrebbe essereverificato un problema di funzionamento dell’applicazione EAI dovuto ad errorinella comunicazione. Potrebbero capitare problematiche di rete, ad esempiola rete non funziona oppure una risorsa remota per un po’ di tempo non èraggiungibile. In alternativa, potrebbe capitare di inviare delle informazionigenerate dal sistema mittente contenente dati “sporchi” e di conseguenza questidati sbagliati causeranno un disallineamento sul sistema che li riceverà;

• è intervenuta la modifica sul dato da parte di un operatore tramite l’utilizzodell’applicazione front-end e tale aggiornamento non è stato propagato agli al-tri sistemi. In questa situazione è necessario capire se un’operazione del generepuò avere un senso oppure è presente un problema nella logica applicativa chepermette di fatto la modifica di un dato su cui non avrebbe i diritti di far-lo. Gli utenti, tramite l’applicazione che presenta bug, possono diventare altrifonti di disallineamento sui dati. Inoltre, con un’applicazione che possiede deibug, 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 esserememorizzate in qualche struttura per essere facilmente interrogabili da eventualiapplicazioni per essere esposte a degli utenti. Per questo è ragionevole pensareche tutte le anomalie che vengono riscontrate, passo dopo passo dagli algoritmi diconfronto, vengano memorizzate in tabelle opportunamente create. In questo modosarà possibile creare delle applicazioni le quali espongano in forma aggregata o didettaglio gli esiti dei confronti effettuati sui sistemi.Per tenere traccia delle varie anomalie che si sono succedute sarà possibile prevedereanche delle tabelle di storico degli esiti dei confronti. Queste tabelle potrebberoritornare utili anche per verificare eventuali correlazioni sulle anomalie riscontrate

51


nell’ultima operazione di confronto e quindi capire se, ad esempio, un determinatoerrore si presenta con una cadenza temporale specifica.

2.2.6 Valutare le performance

Le performance, intendendo i tempi per calcolare le anomalie, rappresentanoun aspetto molto delicato, in quanto i caricamenti dei dati e i relativi algoritmi diconfronto devono essere il più possibile veloci in proporzione alle dimensioni delletabelle che contengono gli attributi associati alle entità.Non avrebbe senso che un controllo su una entità contratti ci mettesse qualche gior-no per restituire dei risultati, in quanto coprirebbe un arco temporale troppo lungoe le basi dati non sarebbero le stesse rispetto al momento di partenza del controllo.Questi algoritmi di caricamento devono essere il più possibile veloci prediligendoeventuali funzionalità di caricamento e confronto da svolgere in parallelo per massi-mizzare le performance e ridurre i tempi di attesa.Prima di implementare tutte le politiche di confronto per tutti i sistemi risulta utilescegliere una coppia di sistemi abbastanza significativi come dimensioni per proget-tare gli algoritmi di confronto e verificarne i tempi di risposta. In questo modo sipartirebbe con un confronto su un sotto insieme di entità al fine di utilizzarlo come“progetto pilota” e coglierne eventuali criticità, pensando a come ottenere presta-zioni migliori e come sarebbe possibile rivedere l’algoritmo in termini di velocità diesecuzione.La fase di valutazione di performance è un momento molto importante per il realeutilizzo di una procedura di Data Integrity in un sistema di integrazione. Se l’ap-plicazione fosse troppo lenta per fornire i risultati sarebbe ragionevole pensare chealla fine tale procedura non verrebbe utilizzata proprio a causa di questo difetto. Èbuona norma, quindi, testare se l’approccio implementativo di un singolo algorit-mo fornisce risultati accettabili in termini di prestazioni. Ovviamente è importanteconsiderare anche l’affidabilità in quanto l’algoritmo deve produrre segnalazioni dianomalie corrette.In definitiva un’applicazione di Data Integrity deve essere costituita da un sistema di

52


controllo veloce ed affidabile, altrimenti tutti gli sforzi fatti per la sua realizzazionepotrebbero risultare vani.

2.2.7 Visualizzare i risultati

Tutte le anomalie riscontrate nei processi di controllo devono essere memoriz-zate in qualche struttura. Le anomalie rilevate devono essere organizzate in modotale da essere semplici da consultare. L’obiettivo è di potere creare dell’applicazioniper l’esposizione dei risultati, in forma di riepilogo e di dettaglio, ed eventualmenteintegrare degli strumenti che permettano funzionalità di riallineamento a partire daun elenco di anomalie.Nella fase di studio per la visualizzazione dei risultati sarà possibile pensare di crearedei report per visualizzare delle informazioni di riepilogo. Questi report potrannoessere utili per capire eventuali errori cronici.Inoltre, sarà possibile creare delle applicazioni specifiche le quali permetteranno l’in-terrogazione dell’elenco dei disallineamenti sui dati e si potranno creare delle inter-facce grafiche per esporre questi risultati agli utenti. Si potrà pensare di visualizzarei dettagli delle sole assenze, differenze oppure tutte insieme. Si potranno inseriredelle funzioni di ricerca per verificare se un determinato record risulta disallineatosu qualche sistema, ecc.Sulle applicazioni di visualizzazione degli esiti sarà possibile sviluppare delle proce-dure che consentano il recupero e l’allineamento dei dati per integrare, quindi, lafunzionalità 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 que-sta fase. In particolare con l’ausilio dell’elenco dei risultati delle anomalie sui datisarà necessario effettuare delle operazioni di recupero, in quanto quei dati risultatidisallineati potrebbero compromettere la stabilità delle applicazioni.Per effettuare queste operazioni di riallineamento si potrebbero creare delle estra-zioni dei dati disallineati e utilizzando questi elenchi si potrebbero richiamare le

53


opportune applicazioni di integrazione EAI per effettuarne l’aggiornamento. Unavolta eseguite questi aggiornamenti rieseguendo il controllo con la procedura di Da-ta Integrity si andrebbe a verificare il successo o meno dell’operazione eseguita.È possibile pensare di includere dei processi di allineamento all’interno delle funzio-nalità di visualizzazione delle assenze e differenze sui dati. Ad esempio si potrebbecreare un’applicazione che interrogando la base dati, contenente gli esiti dei con-fronti, permetta un’interazione con l’utente, tramite la quale sarà possibile deciderequali sono i dati da riallineare e qual è il sistema che possiede il dato corretto. Dallevarie impostazioni effettuate dall’utente sarà possibile fare partire delle operazionidi recupero dati in real-time.

2.2.9 Monitoraggio e test continui

L’applicazione analizzata e creata a supporto del Data Integrity, molto proba-bilmente, dovrà essere avviata con strumenti di schedulazione automatici. Questistrumenti consentiranno l’avvio e l’esecuzione in modo tale da impostare i controllidi coerenza dati in periodi e momenti prestabiliti. Questo perché è molto probabileche i controlli debbano essere eseguiti in orari notturni, che, di solito, sono i mo-menti in cui i sistemi hanno già fatto eseguire i loro processi EAI per passaggio datie quindi potenzialmente dovrebbero essere allineati. In più, il vantaggio di operaredi notte è dato dal fatto che ci sarà meno carico applicativo per via del presumibileminor numero di utenti che saranno collegati ai sistemi.Visto la necessità di un’automazione nell’esecuzione, le procedure di Data Integritydevono essere costantemente tenute sotto controllo da sistemi di monitoraggio chedovranno avvisare in caso di errore nell’esecuzione degli algoritmi di caricamento econtrollo dati. Questo è importante per essere certi del successo delle operazionicompiute e quindi poter elaborare i dati prodotti dai confronti e visionarli insiemeai responsabili dei vari sistemi, senza fornire informazioni errate.La parte di monitoraggio servirà anche per il continuo test degli algoritmi di con-fronto. I test rappresentano un’attività che si muoverà di pari passo con l’esecuzionedelle procedure di Data Integrity. Infatti, le basi dati saranno in continuo aggior-namento, 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 nuovidati che non verranno scambiati tra i sistemi. Si tratta di operazioni necessarie perapportare eventuali correzioni sui filtri impostati nei controlli, aggiungendo o elimi-nando delle condizioni sui campi per considerare oppure no determinati record nellepolitiche di confronto. Il Data Integrity deve cercare di non fornire segnalazioni difalsi positivi, in quanto un errore non presente ma segnalato dalla procedura sarebbeun errore dell’algoritmo di confronto.In definitiva, possiamo affermare che l’attività di monitoraggio e l’operazioni di testsaranno necessarie fino a quando il progetto di Data Integrity sarà mantenuto invita ed utilizzato.

2.3 Vantaggi e svantaggi

Progettare una soluzione che certifichi la qualità dei dati possiede dei pro econtro che necessitano di essere analizzati prima di procedere nella realizzazionevera e propria. L’obiettivo di questa sezione è di riassumere i possibili vantaggi esvantaggi 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 requisitofondamentale per fare funzionare le applicazioni correttamente. L’applicazione diData Integrity permetterà di avere il monitoraggio ed il controllo di congruenza deidati sui sistemi che continuamente si scambiano informazioni attraverso proceduredi integrazione. Potremmo ricevere in modo automatico degli avvisi, ad esempiotramite mail, in caso di un’eccessiva presenza di anomalie nei sistemi. Così facendosarà possibile intervenire il più prontamente possibile su problematiche di integra-zione EAI. Il Data Integrity potrà essere utilizzato come supporto alle applicazionidi EAI in quanto fornirà degli strumenti per verificare il corretto passaggio dei datitra un sistema ed un altro.

55


Inoltre, un’applicazione di Data Integrity potrà essere molto utile in caso di migra-zioni di grosse quantità di dati da un sistema ad un altro nei casi in cui l’aziendascelga di cambiare alcune sue applicazioni. In questi casi, i dati è probabile chevengano spostati un po’ per volta. Saranno presenti le applicazioni, quelle vecchiee quelle nuove, che dovranno convivere per un certo periodo. In una situazionecosì 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 sipotrà verificare che il processo di spostamento dati avvenga correttamente, con lapossibilità 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 difatto un costo aggiuntivo oltre a quelli preventivati per la gestione dell’archi-tettura EAI;

2. prevede una manutenzione costante delle procedure, dovuta alle situazioni incui è necessario rivedere le procedure di confronto quando cambiano regoledi business, transcodifica sui campi e vengono introdotti nuovi dati che nondovranno essere propagati sugli altri sistemi;

3. in modo analogo a quanto può capitare per realizzare l’architettura EAI, nellafase di analisi ed interazione con i diversi referenti dei sistemi informativi sipotrebbe avere lo stesso ostruzionismo ad ottenere le informazioni sulle regoledi 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) inun ambiente di integrazione, nel seguito dell’elaborato sarà illustrata un’implemen-tazione reale di un progetto di Data Integrity, realizzato per effettuare il controllodi specifici database di un’azienda del settore pubblicitario.Questa azienda rappresenta uno dei principali operatori a livello mondiale nel set-tore della pubblicità multimediale. Uno dei suoi punti di forza è rappresentato daldisporre di un patrimonio informativo e di una struttura informatica estremamentesofisticata. L’insieme dei database e delle applicazioni sono strutturati per gestireuna quantità di dati estremamente significativa. Il raggiungimento di un sistemainformativo così sofisticato è stato reso possibile anche grazie all’implementazionedi un’infrastruttura EAI che, mediante un reengineering dei sistemi informatici, haconsentito di realizzare un’architettura in grado di supportare e rispecchiare i pro-cessi di business. Per questo tipo di soluzioni è stato adottato il paradigma SOA(Service Oriented Architecture) dove la logica di business è stata realizzata mediantel’implementazione di servizi atomici, indipendenti dalla piattaforma e riutilizzabilinell’intera azienda. Questo tipo di servizi ha consentito di riorganizzare in manie-ra efficiente sia le funzionalità legacy, sia i nuovi sviluppi, secondo una visione perprocessi.La fase che sta attraversando ora l’azienda è molto critica per quanto riguarda l’in-tegrità del dato. È in atto da diversi mesi una migrazione, a passi successivi, versol’applicazione SAP per quanto concerne il sistema informativo CRM e amministrati-vo. Questo ha portato e sta portando a conseguenti modifiche su tutte le applicazioniche si interfacciavano precedentemente al vecchio sistema. Il passaggio che dureràancora diversi mesi potrebbe introdurre un pericoloso rischio di disallineamento suidati che dovrà essere monitorato per evitare malfunzionamenti e disagi sulle appli-cazioni coinvolte. L’operazione di migrazione che sta avvenendo è complessa per viadell’eterogeneità dei sistemi presenti. Tale complessità potrebbe portare al fallimen-to della nuova integrazione nel caso in cui l’interoperabilità non sia garantita dalla

57


consistenza dei dati scambiati. In quest’ottica un sistema di Data Integrity ha lapossibilità di assumere un ruolo fondamentale, il quale potrà consentire di verificarecostantemente l’allineamento sui dati dei sistemi coinvolti nelle modifiche.

Per realizzare la soluzione di Data Integrity sono stati considerati due importan-ti fattori: l’ambiente complesso in cui è stato implementato e la grossa mole di datiche i sistemi possiedono nei loro back-end. Per l’effettiva implementazione è statonecessario adottare uno strumento di ETL (Execute, Transform, Load) adatto perprogetti che implicano una comunicazione tra database eterogenei e che riguardanouna notevole quantità di informazioni. Questo strumento è stato utilizzato per poteraccedere ai diversi database che dovevano essere monitorati e sono state utilizzatedelle procedure, scritte nel linguaggio PL/SQL1 di Oracle, per implementare gli al-goritmi di aggiornamento e confronto dati. Utilizzando queste procedure PL/SQLsi è sfruttato il vantaggio di eseguire direttamente il codice sul server ed ottenerebuoni tempi di esecuzione.I prossimi capitoli saranno dedicati a descrivere il software IBM Datastage ed adillustrare l’implementazione del progetto di Data Integrity in questa azienda dipubblicità.

1Nell’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, latrasformazione ed il trasferimento dei dati da un sistema sorgente ad uno destina-tario, quindi si tratta di un software orientato all’ETL (Extraction, Trasformation,Load). I dati che possono fare parte dei sistemi sorgenti e destinatari rientrano nellecategorie dei file indicizzati, file sequenziali, code di messaggi e soprattutto, per ilnostro caso di studio, database relazionali.Con Datastage è possibile creare differenti progetti e per ognuno di essi si potran-no creare tante applicazioni che in questo contesto di lavoro vengono chiamate job.Ciascun job avrà il compito di eseguire determinate funzioni di estrazioni di in-formazioni da un sistema sorgente, esempio da file Ascii o tabella Oracle, eseguireeventuali trasformazioni sui dati estratti per poi scrivere i risultati su un sistemadestinatario. Ovviamente anche il sistema destinatario potrà essere un file, una ta-bella o comunque una struttura per ricevere dati. Le applicazioni Datastage, ovveroi job, possono essere avviate in modalità real-time su richiesta specifica dell’utente,oppure utilizzando dei particolari processi batch i quali permetteranno di attivarnel’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 sposta-menti e modifiche dei valori di grosse quantità di dati in tempi molto rapidi. Peressere il più possibile efficiente supporta le piattaforme hardware multiprocessoreche permettono di parallelizzare le operazioni di caricamento e trasformazione. Lepeculiarità appena descritte sono risultate fondamentali nella scelta di Datastagecome strumento da adottare nel nostro progetto di controllo dati.Nel seguito saranno illustrati i componenti principali di Datastage. Ci focalizzeremomaggiormente sugli strumenti specifici riguardanti le parti utilizzate nello sviluppodel progetto Data Integrity che sarà descritto nel prossimo capitolo.

3.2 I componenti principali

Datastage è costituito da diversi componenti software le cui funzionalità operanoa livello differente: sono presenti applicazioni per la parte server ed altri per la parteclient.La parte server include tutte le applicazioni di gestione dei servizi, dei repository edelle area di lavoro per lo sviluppo dei progetti di Datastage. In questa categoriaabbiamo tre componenti specifici che svolgono i compiti appena descritti:

• il repository, che rappresenta l’area di memorizzazione contenente le informa-zioni di tutti i progetti Datastage presenti su uno specifico server;

• il server, che costituisce il “motore” di Datastage, di conseguenza è il compo-nente che si occupa eseguire ed interpretare i job definiti nei vari progetti;

• il package installer, si tratta di un’interfaccia utente per installare package eplug-in aggiuntivi.

Tra i componenti client troviamo tutte le applicazioni più operative, ovvero quellenecessarie per la progettazione e la creazione delle applicazioni Datastage, includen-do gli strumenti per la loro esecuzione e schedulazione.L’obiettivo che si pone questo capitolo su Datastage è di introdurre brevemente icomponenti 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 In-tegrity, necessaria per il controllo delle basi dati dell’azienda descritta nel caso distudio.Innanzitutto è necessario effettuare una distinzione tra i componenti client, dovepossiamo definire due categorie importanti:

• client per gli amministratori;

• client per gli sviluppatori.

Entrambe le tipologie di client sono dotate di un’interfaccia Desktop, quindi acces-sibile in modo semplice ed intuitivo.

Client per gli amministratori

Il client per gli amministratori è lo strumento che permette di gestire le areelegate alle tematiche di sicurezza, alla gestione delle licenze, alla gestione delle ope-razioni di log e di scheduling di un singolo progetto di Datastage.In questa categoria è presente un solo applicativo client: si tratta dell’applicazionechiamata Datastage Administrator. Tramite l’Administrator si gestiscono e si man-tengono i progetti sul server di Datastage. Questo client viene anche utilizzato perimpostare le proprietà dei progetti, per impostarne le variabili di sistema e per larisoluzione di alcuni tipi di problemi. Per eseguire questi compiti lo strumento Ad-ministrator, attraverso la sua interfaccia grafica, permette di accedere al repositorydei progetti, su cui è possibile impostare i parametri dei diversi job, i privilegi deivari 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 eprogettare i job. Questi client includono anche tutte le procedure che vengonoutilizzate per le funzionalità di validazione, esecuzione, schedulazione e monitoringdei job stessi.I compiti svolti da questa categoria di client vengono ricoperti sostanzialmente datre applicazioni:

61


1. il Designer, strumento che permette la progettazione e l’implementazione delleapplicazioni che abbiamo già chiamato job. Il Designer rappresenta il moduloprincipale per gli sviluppatori, infatti al suo interno i job creati potrannoessere disegnati e poi compilati, diventando di fatto dei programmi eseguibilie quindi avviabili. Questo client si presenta con un’interfaccia grafica chepermette di visualizzare in modo intuitivo gli oggetti inseribili in un job. Talioggetti rappresentano le operazioni da eseguire sui dati per le funzionalità diestrazione, pulizia, trasformazione ed integrazione delle informazioni;

2. il Manager, che rappresenta un’interfaccia per accedere al repository di unprogetto Datastage consentendone l’esplorazione e la modifica degli oggetticontenuti.

3. il Director, che è lo strumento che permette l’esecuzione in real-time e laschedulazione dei job creati e compilati attraverso il Designer.

3.3 L’applicazione Designer

L’applicazione Designer consente, in modo intuitivo tramite un apposito pul-sante, 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 nellafinestra repository (riportata nella figura 3.1). Esistono differenti tipologie di job chepossiamo creare a seconda della versione di Datastage installata. Per quanto riguar-da l’ambito del nostro progetto di Data Integrity è sufficiente illustrare le seguenticategorie:

• i server job, sono le applicazioni che vengono eseguite sul server di Datastage econsentono di eseguire connessioni, estrazioni e caricamento da e verso le basidati nei formati che abbiamo già definito in precedenza;

• le job sequence, sono le applicazioni che permettono di specificare una sequenzadi server job da eseguire e consentono di definire delle azioni da intraprenderein base a risultati delle elaborazioni dei vari passi precedenti che compongonouna job sequence.

62

3.3 – L’applicazione Designer

Dopo la scelta di creazione di un job o il richiamo di uno già esistente, l’applicazioneDesigner generalmente presenterà nella parte centrale la finestra di progettazione,chiamata Diagram Window (visibile nella figura 3.1), dove sarà possibile inserire glioggetti all’interno dei server job o delle job sequence. In generale, oltre alla Dia-gram Window, saranno visualizzate altre due finestre molto importanti contenentirispettivamente l’elenco degli oggetti presenti nel repository del progetto e l’elencodegli oggetti inseribili nei differenti job (anche queste due finestre sono presenti nellafigura 3.1). Attraverso la visualizzazione del contenuto del repository del progettocorrente sarà possibile richiamare gli altri job già definiti, mentre con la finestra dielenco oggetti saremo in grado di selezionare e trascinare nella Diagram Window glielementi da aggiungere nel job corrente.Un’applicazione di Datastage, nell’esempio specifico un server job, consiste sostan-zialmente in una serie di oggetti uniti tra loro attraverso degli elementi di collega-mento chiamati link. L’insieme risultante descriverà il flusso di spostamento delleinformazioni da una base dati di input ad una di output. In generale, gli oggettiinseribili in un server job possiedono un link di input e/o un link di output. Ciò nonesclude di avere anche degli oggetti specifici che possono ricevere più link di inputed 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’appli-cazione. 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 ilink su cui sarà possibile definire dei trigger per attivare o meno tali activity.

63


Repository Diagram Window

Lista oggetti

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

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 Server job

3.4.1 Stage

L’applicazione Designer offre differenti tipi di stage precostruiti da adoperare neiserver job. Questi elementi vengono di solito utilizzati per rappresentare basi di datisorgenti e destinatari. Sono presenti anche degli oggetti dedicati per le operazionispecifiche di conversione di formato e contenuto sui dati.Gli stage possono essere suddivisi in due tipologie: attivi o passivi. Quelli attivimodellano il flusso delle informazioni fornendo dei meccanismi per operazioni dipassaggio, aggregazione, e conversione tra formati dei dati. Al contrario la tipolo-gia passiva consente di accedere ai database o ai file per realizzare le operazioni diestrazione o di scrittura dei dati. Da quanto detto ne consegue che sono gli stagedi tipo passivo che si occupano dell’effettiva lettura o scrittura di informazioni da overso una base dati. I riferimenti sui dettagli di connessione alla base dati e sulle ef-fettive informazioni da prelevare od inserire sono definibili all’interno delle proprietàdel singolo stage specifico, il quale presenta una serie di opzioni configurabili dallosviluppatore.Gli oggetti inseribili in un server job sono organizzati in differenti gruppi a secondadelle 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 que-sto dettaglio: nel progetto Data Integrity realizzato si è sempre utilizzato lo stageappartenente al gruppo di Database, in particolare quello chiamato Oracle OCI (ri-ferimento figura 3.2). Questa tipologia di stage ci ha permesso di collegarci ai diversi

65


back-end di tipo Oracle presenti nell’azienda su cui abbiamo impostato le operazionidi estrazione dati. Nello specifico per ogni entità da monitorare di ciascun sistemaabbiamo 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 stagepresenti in un server job. Servono, quindi, per specificare come i dati si dovrannomuovere nel momento in cui il server job sarà mandato in esecuzione. Un collega-mento è rappresentato da un oggetto di tipo freccia che è costituito da un verso dipartenza ed uno di arrivo. Il verso di partenza rappresenta la parte chiamata outputlink, 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 diricevere i dati prelevati da uno stage di lettura. Lo stage di scrittura ricevendoquesti dati, tramite il link di input, si occuperà di scriverli in determinate strutturedestinatarie. Al contrario, un output link si occuperà di inviare i dati letti tramiteun opportuno stage di selezione ed estrazione di informazioni, ovvero uno stage dilettura. I dati selezionati da uno stage di lettura saranno inviati sullo specifico linkdi output e tali informazioni prelevate saranno ricevute da uno stage di scritturaattraverso 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 devo-no essere mappati tra i due stage. In particolare, la definizione delle colonne sullostage di scrittura collegato all’input link permetterà di definire i campi che dovrannoessere scritti sulla base dati ricevente. Mentre la definizione delle colonne dello stagedi lettura collegato all’output link servirà per definire i campi che dovranno essereletti 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 è ilprincipale tipo di link e viene utilizzato per gli stage sia di tipo attivo chepassivo;

• reference, si tratta di un link che viene utilizzato solo per gli stage di tipo attivoper fornire informazioni su come i dati devono essere cambiati nel passaggioda una base dati mittente ad una destinataria, hanno una funzione similarealle tabelle di lookup.

Le due tipologie di link sono rappresentate nell’applicazione Designer in modo dif-ferente: gli stream link sono rappresentati da frecce continue, mentre i link di tiporeference 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 ditipo Database (uno di lettura ed uno di scrittura) per estrazione ed inserimento datisu database Oracle, collegati mediante uno stream link per definire la direzione deglispostamenti dei dati.

67


Stage di lettura

con cui estrarre i dati dal sistema sorgente

Stage di scrittura

con cui scrivere i dati sul sistema ricevente

Link (parte di output)

dove transitano i dati prelevati dallo stage di lettura

Link (parte di input)

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 inesecuzione. Una sequenza può contenere informazioni di controllo, in particolare èpossibile prendere determinate decisioni se un job all’interno della sequenza è statoeseguito 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 unae-mail di segnalazione, il lancio di un’eccezione, ecc.La progettazione di una sequence è molto simile alla creazione di un server job. Ladifferenza principale che si riscontra è la seguente: al posto degli stage abbiamo leactivity le quali sono collegate una con l’altra attraverso dei link. Sui link è possibiledefinire delle condizioni di trigger, necessarie per attivare o meno una determinataactivity. Ogni activity possiede delle proprietà che possono essere testate comeespressioni in trigger per decidere se andare avanti nella sequenza o meno. Alleactivity 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.5.2 Trigger

Il flusso di controllo della job sequence dipende da come sono interconnesse leactivity dai vari link e come sono state impostate le condizioni sui trigger. Sonopresenti tre tipologie di trigger:

• conditional, una condizione di trigger viene attivata per passare alla prossimaactivity collegata se le condizioni impostate per il trigger sono state soddisfatte;

• unconditional, non viene controllata alcuna condizione e si passa alla prossimaactivity, ovvero quella destinataria, appena termina l’activity precedente;

• otherwise, quest’ultima viene utilizzata come default quando una activitysorgente possiede più output trigger, ma nessuno dei trigger condizionali èscattato.

Nella figura figura 3.4 viene riportato un esempio di job sequence dove so-no state evidenziate alcune activity e per una di queste, nello specifico l’activityControllo_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.6 L’applicazione Manager

Nell’applicazione Manager abbiamo la visibilità di tutti gli oggetti facenti partedel progetto a cui siamo collegati. In particolare sono visibili i job, le sequence, ladefinizione delle tabelle di input / output e le eventuali routine create.Questa applicazione permetterà di effettuare le classiche operazioni di gestione deglioggetti all’interno dei progetti Datastage, come le operazioni di copia, di rinomina,di eliminazione degli oggetti, ecc. Facendo riferimento al progetto di Data Integrityimplementato, l’applicativo Manager è stato utilizzato soprattutto per le operazionidi backup di tutti gli oggetti del progetto su file in modo da salvaguardare il lavorofino a quel momento realizzato.Il Manager, oltre alla gestione degli oggetti di un progetto, può ritornare utile perspecificare le proprietà sui server job e le job sequence. Tali proprietà possono es-sere definite anche all’interno dell’applicazione Designer ma attraverso l’utilizzo nelManager è possibile accedere in modo più rapido su queste proprietà per tutti glioggetti del progetto.Per concludere, è utile ricordare che in questo specifico client è presente una proce-dura chiamata Usage Analysis con cui è possibile verificare le relazioni di un oggettocon tutti gli altri presenti nel progetto. In particolare, tale strumento è risultatomolto comodo per capire, in modo rapido, se un determinato server job è statoincluso o meno in una job sequence.

3.7 L’applicazione Director

Questa applicazione permette di avviare, manualmente o tramite l’utilizzo difunzioni di schedulazione, i job e le sequence di un progetto di Datastage. Con ilclient Director è possibile anche accedere e visionare le informazioni di tutti i logregistrati sulle diverse applicazioni.La finestra del client Director consente di visualizzare l’elenco dei server job e dellejob sequence di uno specifico progetto Datastage. In particolare è possibile sceglieretra tre tipologie di viste differenti:

72

3.7 – L’applicazione Director

• job status, che rappresenta la vista di default in cui vengono visualizzati glistati di tutti i job;

• job schedule, per visualizzare un riepilogo dei job su cui è stata impostata unaschedulazione automatica;

• job log, che rappresenta la visualizzazione del dettaglio del log di uno specificojob selezionato.

Attraverso la vista job status è possibile, come abbiamo detto, visualizzare gli statidei vari job, in particolare quelli di nostro interesse sono i seguenti:

• compiled, il job è stato compilato ma non è stato più eseguito dopo la compi-lazione;

• 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 checonverebbe controllare;

• stopped, il job è stato fermato dall’utente;

• aborted, il job è andato in errore;

• has been reset, il job è stato reinizializzato, operazione da fare necessariamentedopo una situazione di aborted.

Quindi, per concludere, attraverso l’utilizzo dell’applicazione Director abbiamo lapossibilità:

• di mandare in esecuzione un job che si trova in una stato avviabile comecompiled, finished o has been reset;

• di interrompere un job che si trova in stato di running;

73


• di effettuare un’operazione di reset su un job che si trova in stato di stoppedo aborted.

Tutte le operazioni appena citate sono facilmente eseguibili attraverso dei pulsantiintuitivi 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 di-sposizione dei meccanismi di verifica di allineamento sui dati presenti nei sistemiinformativi, ed in parte coinvolti nella migrazione verso SAP, all’interno dell’azien-da pubblicitaria oggetto di questo caso di studio. Il progetto è stato realizzatoall’interno del gruppo di Reply che si occupa delle problematiche di integrazioneEAI per tale azienda. La collaborazione con il gruppo EAI è stata di fondamentaleimportanza sia per la fase di analisi che di sviluppo. Infatti, lavorando a stretto con-tatto con chi si occupa direttamente dell’integrazione dei sistemi è stato possibiledefinire in modo puntuale le entità da monitorare, risolvendo in modo rapido anchele problematiche di accesso ai vari sistemi back-end.La finalità principale di questa soluzione di Data Integrity è di fornire un supportoper mantenere la congruenza dei dati distribuiti sui vari back-end, in modo tale chele applicazioni front-end eroghino i servizi e le funzionalità previste senza errori odisfunzioni. La segnalazione degli errori presenti sui dati distribuiti sui vari sistemideve essere utilizzata come ausilio per intervenire e prevedere delle opere di corre-zione sui diversi back-end, cercando di anticipare i possibili problemi che potrebberoessere evidenziati dagli utenti delle applicazioni in caso di disallineamenti. Quindi, sel’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 recuperie le operazioni di riallineamento solo dopo le segnalazioni di malfunzionamento daparte degli utenti, migliorando di conseguenza il servizio offerto dall’intera strutturainformativa. Inoltre, gli utenti avranno la sensazione di una migliore affidabilità deisistemi dovuta alla probabile diminuzione degli errori applicativi.Un’applicazione di Data Integrity in una grossa azienda, dove generalmente sono pre-senti molti sistemi informativi, permette di salvaguardare, con strumenti di controlloe segnalazione, la qualità e validità delle informazioni possedute. Più i dati sottomonitoraggio 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 diverifica allineamento dei dati, giustificandone la presenza all’interno del complessosistema informativo aziendale:

• SAP è il sistema amministrativo preposto alla gestione del ciclo attivo/pas-sivo (emissione richieste di acquisto, ordini, contratti), della contabilità, delmagazzino, dei dipendenti e delle strutture organizzative;

• SEM è il sistema che permette una produzione editoriale multimediale integra-ta e flessibile per tutte le esigenze pubblicitarie del cliente, indipendentementedal media utilizzato;

• TCC serve per la gestione particolare dei contratti cartacei: si tratta di unsistema per garantire che oltre al contratto in formato digitale, sia inviatadagli 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 suobusiness particolare: contiene informazioni di dettaglio sui clienti per fornirepiù 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, annun-ci, anagrafiche, ecc., che devono essere mantenute allineate per garantire il funzio-namento dell’architettura informativa. Ad esempio, l’entità relativa ai contratti èpresente sia sul sistema SAP che su SEM: sarà molto importante mantenerla corret-tamente allineata per non incorrere in errori delle applicazioni front-end che farannorichiesta dei dati di un contratto presente su entrambi i sistemi.Riporto nella Tabella 4.1 tutti i controlli sulle entità che sono stati implementati trai differenti back-end. È importante sottolineare che le verifiche eseguite sono staterealizzate tra coppie di sistemi, ovvero confrontando i dati, a livello di record, di unback-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 diReply che si occupano dell’architettura EAI di quest’azienda e le figure responsabilidei vari sistemi informativi coinvolti in questo progetto di Data Integrity. Nell’elencoriportato nella tabella 4.1 il sistema citato per primo, in generale, è quello detentoredel dato mentre il secondo è quello ricevente. Con la coppia SAP-SEM si intendeche SAP possiede i dati aggiornati dei contratti, degli annunci e delle sigle, mentreSEM, tramite flussi di integrazione EAI, riceve gli aggiornamenti da SAP.

79


Nel seguito riporto, per ciascuna coppia di sistemi, le tipologie di controlli effettuatisulle entità condivise. In particolare, il controllo di assenza è associato alla mancanzadel record su uno dei due sistemi, mentre per ricerca di disallineamenti dovuti adifferenza è inteso la presenza di valori diversi (considerando le opportune variazioniper le transcodifiche) di almeno un campo di un record oggetto di controllo.

Entità Controllo assenza Controllo differenzaContratti Sì SìAnnunci Sì SìSigle No Sì

Tabella 4.2. Tipologia di controlli entità per la coppia di sistemi SAP-SEM

Entità Controllo assenza Controllo differenzaContratti Sì SìAnnunci Sì SìCampagne pubblicitarie Sì No

Tabella 4.3. Tipologia di controlli entità per la coppia di sistemi CLIC-SAP

Entità Controllo assenza Controllo differenzaContratti Sì SìAnnunci Sì Sì

Tabella 4.4. Tipologia di controlli entità per la coppia di sistemi SAP-TCC

80

4.1 – I sistemi controllati

Entità Controllo assenza Controllo differenzaContratti Sì SìAnnunci Sì SìCampagne pubblicitarie Sì No

Tabella 4.5. Tipologia di controlli entità per la coppia di sistemi SAP-DBLocal

Entità Controllo assenza Controllo differenzaAnagrafiche Sì SìSedi Sì Sì

Tabella 4.6. Tipologia di controlli entità per la coppia di sistemi CDB-SAP

Entità Controllo assenza Controllo differenzaContratti Sì SìAnnunci Sì SìSigle No Sì

Tabella 4.7. Tipologia di controlli entità per la coppia di sistemi CLIC-SEM

81


4.2 Descrizione del progetto

Per la realizzazione del progetto è stato scelto di caricare periodicamente, inmodo massivo, tutte le basi dati, che si è deciso di tenere sotto controllo e di cuiabbiamo già parlato, su una struttura di appoggio, così come è mostrato nella figura4.1. I dati estratti dai vari sistemi vengono memorizzati in un database Oracle,che per standard aziendali è stato chiamato DBADI1DATAINT. Questo archivioconterrà, in apposite tabelle di replica, le entità dei vari sistemi sui cui dovremocontrollare la coerenza delle informazioni. Infatti, proprio su queste tabelle, caricatecon applicazioni Datastage e script specifici, che avverranno tutte le operazioni diaggiornamento e confronto di congruenza dei dati, così come è illustrato nella figura4.2.Per la realizzazione della parte che abbiamo appena descritto, ovvero il caricamentoe controllo dati, sono stati utilizzati i seguenti componenti:

• una base dati grande e affidabile per memorizzare le informazioni associatea determinate entità prelevate dai sistemi, in particolare, come abbiamo giàdetto, si utilizza un database Oracle su cui vengono effettuate quotidianamentele operazioni di caricamento. Questo database, chiamato DBADI1DATAINT,oltre a contenere le repliche delle tabelle dei diversi sistemi, conterrà le tabelledegli esiti relativi ai vari confronti effettuati, includendo anche delle tabelle distorico esiti per mantenere traccia dei disallineamenti risolti;

• stored procedure e funzioni create nel linguaggio PL/SQL. Queste procedure efunzioni, tramite l’utilizzo dei cursori, sono state utilizzate per la realizzazionedegli algoritmi di aggiornamento dati sulle tabelle di replica e per l’imple-mentazione degli algoritmi di confronto; tali stored procedure e funzioni sonomemorizzate in opportuni package presenti sul database DBADI1DATAINT;

• job sequence e server job di Datastage. Mediante il loro utilizzo sono statirealizzati la maggiore parte dei connettori specifici per l’estrapolazione deidati dai vari sistemi da controllare. I job di Datastage permettono l’accesso alback-end specifico di un sistema e tramite la definizione di opportune query di

82

4.2 – Descrizione del progetto

SEM

CLIC CDB

TCC

DBL

SAP

DB

di replica dei sistemi -

esiti sui controlli

di allineamento

DBADI1DATAINT

LOAD_TABELLE_SEM

LOAD_TABELLE_SAP

LOAD_TABELLE_TCC

LOAD_TABELLE_CDB

LOAD_TABELLE_CLC

LOAD_TABELLE_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


DB di replica dei

sistemi -esiti sui controllidi allineamento

DBADI1DATAINT

Aggiornamento dati sulleentità da controllare

(aggiornamento transcodifiche -calcolo codice hash)

Calcolo disallineamentiricerca record assenti e

differenti tra le entità controllate -archiviazione delle anomalie

non più presenti

1

2

3

4

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

Procedure PL/SQL

Procedure PL/SQL

CHECK_SYSA_SYSB

AGGIORNA_DATI

ESEGUI_CONTROLLI

Evento

esterno

Figura 4.2. Progetto Data Integrity: esecuzione degli algoritmi di aggior-namento - controllo dati

84


selezione permettono di prelevare i soli dati di interesse che saranno caricatigiornalmente sulle tabelle di replica del database Oracle DBADI1DATAINT(riferimento figura 4.1). I job di Datastage sono stati impiegati anche perrichiamare le procedure e funzioni PL/SQL utilizzate per l’aggiornamento edil confronto dei dati prelevati dai vari sistemi e memorizzati sulle tabelle direplica 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 delleeccezioni, in particolare per due basi dati non Oracle (CLIC e DBLocal), per cuisono state realizzate delle procedure di estrazione ad hoc. Sono state create dellefunzioni che consentono di effettuate degli scarichi massivi dei valori di interessedalle tabelle su file. Da questi file, tramite opportune procedure SQL*Loader1, sonostate realizzate le operazioni di caricamento sul database DBADI1DATAINT.

È stato scelto di prelevare i dati dalle tabelle dei sistemi da monitorare, repli-candoli su di un database centralizzato (DBADI1DATAINT), perché si è cercatodi 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 diintegrazione. Per impattare il meno possibile su questi back-end è stato deciso diimpostare i caricamenti massivi sul database DBADI1DATAINT, sia tramite Data-stage che con le procedure ad hoc, in orari notturni. Infatti, in quella fascia orariai back-end sono meno sollecitati dalle applicazioni front-end e non prevedono par-ticolari applicazioni di integrazione. In tale periodo abbiamo il momento miglioreper prelevare delle “fotografie” dai sistemi su cui andare ad effettuare i controlli diallineamento dati.Lo scopo della fase di controllo dati è di generare dei risultati contenenti le anomalieriscontrate, considerando i casi di assenza dei record di un’entità e di differenza suuno o più campi dell’entità stessa. Visto che i caricamenti avvengono negli orarinotturni, le anomalie riscontrate potranno essere disponibili in tarda mattinata o al

1Utilità per caricare velocemente dati memorizzati in file di testo su database Oracle.

85


più nel primo pomeriggio del giorno in cui è stato avviato il controllo di coerenza. Inquesto modo, appena terminato il confronto ed ottenute le anomalie, sarà possibileprendere eventuali contromisure in caso di presenza di particolari errori e differenzesui dati. L’utilizzo di questi risultati servirà per effettuare le opportune segnalazioniai diretti responsabili dei sistemi informativi e decidere le possibili mosse correttive.Per realizzare la parte di monitoraggio delle anomalie riscontrate, dagli algoritmi dicontrollo, vengono utilizzati i seguenti strumenti:

1. dei report di riepilogo, dove i dati delle anomalie vengono estratti dalle tabelledegli esiti ed aggregati in questi specifici report, creati in modo automatico,tramite il richiamo di un servizio custom aziendale2, dopo la fase di controllodi allineamento per una coppia di sistemi;

2. un’applicazione WEB, che rappresenta l’interfaccia con cui sono sempre frui-bili i disallineamenti sui dati dei sistemi controllati, memorizzati nel databaseDBADI1DATAINT. Le informazioni visualizzabili tramite l’interfaccia WEBsono dei riepiloghi aggregati e delle informazioni di dettaglio sui disallinea-menti. Lo scopo dell’applicazione WEB è, quindi, di fornire una visualizza-zione degli esiti dei controlli sui disallineamenti in modo sia riepilogativo chedettagliato.

La figura 4.3 riporta i due strumenti appena descritti, ovvero un esempio di reporte l’applicazione WEB, utilizzati per il controllo dei risultati prodotti dalle verifichedi allineamento dei dati.

2Servizio a cui è possibile passare un template di report e genererà in output un documentoExcel.

86


DB di replica dei

sistemi -esiti dei controllidi allineamento

DBADI1DATAINT

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

Figura 4.3. Progetto Data Integrity: strumenti di monitoraggio

87


4.3 Il database delle repliche e degli esiti

DB

di replica dei

sistemi -

esiti sui controlli

di allineamento

DBADI1DATAINT

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

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)

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

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.

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, utiliz-zato come parte di repository dell’applicazione di Data Integrity, è stato realizzatocon lo scopo di:

• ospitare le tabelle di replica delle entità presenti sui sistemi che sono oggettodi controllo;

• ospitare le tabelle contenenti i risultati dei controlli di allineamento dati, ov-vero quelle contenenti gli esiti relativi alle verifiche effettuate sui dati prelevatidai diversi sistemi;

• ospitare le tabelle di storico esiti per memorizzare le anomalie che risultanoessere state risolte e che possiamo definire chiuse.

In aggiunta alle tabelle appena descritte, questo database contiene anche i packageOracle dove sono presenti le stored procedure e le funzioni PL/SQL utilizzate perle operazioni di aggiornamento e controllo allineamento dei dati prelevati dai varisistemi.

Le tabelle di replica possiedono tutti i campi necessari per memorizzare i recordprelevati dalle basi dati sorgenti che saranno oggetto di confronto. Per questo motivoi 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 datooriginale presente sul sistema di partenza.Per quanto riguarda le tabelle predisposte alla memorizzazione degli esiti questesono state progettate per memorizzare le anomalie rilevate di un’entità tra duesistemi. Ad esempio, il controllo di coerenza delle informazioni dei contratti tra ilsistema SAP e SEM ha una tabella specifica per memorizzare le anomalie riscontrate.Nella tabella verranno memorizzati i dati assenti e differenti risultanti dal confrontoSAP-SEM. È presente anche una tabella, molto simile nelle caratteristiche a quelladegli esiti dei contratti tra SAP e SEM, che viene utilizzata per memorizzare leinformazioni di storico dove si manterranno le anomalie risolte.In ogni tabella contenente gli esiti, considerando anche quelle di storico, sono presenti

89


dei campi che ci forniscono informazioni sull’anomalia riscontrata. In particolareabbiamo:

• un campo specifico (chiamato [prefisso_tabella]3_tipo_anom_cod) per de-terminare il tipo di anomalia rilevata; in particolare tale campo assumerà iseguenti valori: ’A’ per un’anomalia dovuta all’assenza del dato e ’D’ perl’anomalia dovuta alla differenza su uno o più campi oggetto di controllo;

• un campo per specificare il sistema possessore del dato (chiamato [prefis-so_tabella]_SYS_A) da cui si prelevano i valori e si controllano con l’altrosistema, quello che dovrebbe possedere l’informazione congruente;

• un campo per specificare il sistema (chiamato [prefisso_tabella]_SYS_B) chedovrebbe 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 prefissotabella), sono importanti perché consentono di capire dove si è riscontrata l’ano-malia. Ad esempio, se sull’entità contratti tra SAP-SEM sono presenti le seguentiinformazioni:

• tipo_anom_cod=’A’, SYS_A =’SAP’, SYS_B =’SEM’, si tratta di un’ano-malia assenza che rappresenta la mancanza di un contratto su SEM;

• tipo_anom_cod=’D’, SYS_A =’SAP’, SYS_B =’SEM’, si tratta di un’ano-malia differenza che rappresenta la differenza su uno o più campi del contrattomemorizzato su SEM;

3Tutti i campi delle tabelle del database DBADI1DATAINT devono iniziare con 4 caratteri fissiassociati al nome della tabella di appartenenza. È lo standard aziendale.

90

4.4 – Le procedure e funzioni PL/SQL

4.4 Le procedure e funzioni PL/SQL

4.4.1 Introduzione

Nel linguaggio PL/SQL è presente un meccanismo per elaborare i risultati dellequery orientato alle tuple. Per realizzare questo meccanismo vengono utilizzati icursori. Nello specifico, un cursore è una sorta di puntatore al risultato di una querye questo viene impiegato per scorrere e leggere i valori dei campi associate alle righeselezionate.La presenza dei cursori all’interno del linguaggio PL/SQL mi ha permesso, in modoagevole, di creare le procedure di aggiornamento e di controllo dei dati associatealle entità da monitorare con l’applicazione di Data Integrity. Ad esempio, perquanto riguarda l’aggiornamento dei dati, per la problematica delle transcodifiche,viene utilizzato un cursore sulla tabella associata all’entità prelevata dal sistema dipartenza. Questo cursore permette di scorrere in modo rapido tutto l’insieme deidati memorizzati e per tutti i campi che necessitano di essere aggiornati è possibilerichiamare delle funzioni di transcodifica specifiche a seconda del tipo confronto.Inoltre, utilizzando sempre i cursori, ho implementato con opportune proceduregli algoritmi di confronto necessari per la ricerca di anomalie dovute all’assenza edifferenza sui dati. Questi algoritmi, creati nel linguaggio PL/SQL, sono richiamatidai 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 esserecontrollati non appena terminata l’operazione di caricamento. Sui dati memorizzatinelle tabelle di replica devono essere prima eseguite delle funzioni/procedure di ag-giornamento che hanno compiti ben specifici: aggiornare le transcodifiche sui campie calcolare un codice hash per la rilevazione delle differenze.

91


Aggiornamento transcodifiche

Si tratta delle funzioni che si occupano di aggiornare i dati per quanto riguardale transcodifiche sui campi in modo che la semantica presente sulle informazionida confrontare sia congruente. L’obiettivo di questo tipo di funzioni è di fare inmodo che il valore di uno specifico campo tra i due sistemi da controllare sia lostesso, a meno ovviamente di errori in uno dei due. Le funzioni di transcodificadei campi sono state realizzate in base ai confronti sulle coppie dei sistemi. Adesempio, sul sistema SAP le entità contratti ed annunci devono essere confrontatecon i sistemi SEM, TCC, DBLocal e CLIC. Di conseguenza, sono presenti dellefunzioni di aggiornamento transcodifiche per i campi delle entità contratti ed annuncidi SAP per il confronto con SEM, altre funzioni per il confronto SAP-TCC, altreancora 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 politichedi confronto tra i sistemi. Attraverso l’utilizzo di questo accorgimento è stato possibi-le semplificare gli algoritmi di confronto, controllando nella fase di ricerca differenzesolo 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 degliesiti per evidenziare la presenza di una differenza di due valori diversi sullo stessocampo questi saranno concatenati e memorizzati all’interno della tabella degli esitiseparandoli con il carattere ’|’. Dalla scelta effettuata ne consegue che la presen-za del carattere ’|’ all’interno dei campi delle tabelle degli esiti rappresenterà, inmodo immediato ed anche di facile ricerca, tramite l’utilizzo dell’operatore SQL LI-KE(’%|%’), l’esistenza di una differenza tra i valori dei due sistemi confrontati.Il funzionamento della procedura è abbastanza semplice: tramite l’utilizzo di un

92


cursore associato alla tabella contenente l’entità di un sistema, si leggeranno i varirecord e per ciascuno sarà effettuato il calcolo del codice hash, utilizzando come basedi input della funzione hash i campi da controllare. Inoltre sarà possibile chiamarecontestualmente alla funzione di hash anche le funzioni di transcodifica, descritte inprecedenza, sui campi coinvolti. Il vantaggio di operare in questo modo sta nel fattodi condensare in un’unica procedura le operazioni di aggiornamento dati e calcolocodice 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 quelloche dovrebbe avere la stessa informazione, ovvero verso il ricevente, il quale vieneaggiornato tramite applicazioni di integrazione EAI. Di conseguenza, si controllerà sel’informazione, sotto forma di record, contenuta sul sistema possessore è presente omeno sul ricevente. Nel caso in cui l’informazione venga trovata sul sistema riceventesi verificherà se i campi, oggetto di controllo, saranno uguali oppure no. Nella tabelladegli esiti si memorizzeranno le assenze dei dati dati del sistema ricevente rispettoa quello possessore e le differenze riscontrate sui dati presenti in entrambi.Per fare quanto appena descritto, superata la fase di aggiornamento transcodifiche evalorizzazioni dei codici hash sulle varie entità, sarà necessario avviare gli algoritmiche hanno il compito di svolgere le funzioni di quadratura dei dati, inteso comeallineamento dati. Questi algoritmi si occupano di rilevare i disallineamenti di unaspecifica entità (contratti, annunci, ecc) tra due sistemi per volta. In base alle regoledi business e di integrazione è stato definito il sistema possessore e ricevente dei datiper ciascuna entità. Quindi, saranno effettuati i confronti tra i sistemi possessoricon i diversi riceventi, come abbiamo già illustrato in precedenza.È importante precisare che non tutti i dati devono essere presenti su entrambi isistemi per una specifica entità, in quanto per regole di business esistenti certeinformazioni non devono arrivare o per via delle tempistiche di adozione di un sistemarispetto ad un altro è possibile che certi dati non siano stati mai inviati. Ad esempio,esistono contratti, aventi determinate caratteristiche, presenti sul sistema SAP chenon vengono passati a SEM per logiche di business. Quanto detto ha il seguente

93


effetto: nella fase di controllo di ricerca assenze si dovranno escludere dal confrontotali record, altrimenti si forniranno dei falsi disallineamenti, che possiamo chiamarefalsi positivi. È importante definire in modo accurato quali sono i filtri da adottarenella selezione dei record da confrontare per la ricerca delle assenze.

Una volta che si sono sistemate correttamente le logiche di confronto, i disal-lineamenti individuati vengono registrati periodicamente in queste tabelle di esiti,create in modo specifico per coppia di sistemi ed entità. Contestualmente all’opera-zione di controllo, vengono eseguiti dei movimenti di storicizzazione delle anomalienon 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’algo-ritmo di confronto. Per ogni entità controllata sulla coppia di sistemi è stata creatauna 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 esitidell’entità da controllare;

• una cancellazione dei dati presenti nella tabella degli esiti dell’entità da con-trollare;

2. Selezione ed inserimento nella tabella degli esiti dei disallineamenti dovuti adassenza di record sull’entità, riscontrati nel confronto tra due sistemi.

94



• una selezione dei dati, con gli opportuni filtri, presenti sul sistema possessoreed 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 recuperatoquesto sarà inserito nella tabella degli esiti opportuna, indicando, oltre aidati 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 dif-ferenza sui campi di un record di un’entità, riscontrati nel confronto tra due sistemi.


• una selezione dei dati, con gli opportuni filtri, presenti sia sul sistema possesso-re che quello ricevente, dove però viene riscontrato un codice hash differente;nella selezione dei campi si utilizza una funzione particolare che si aspettain input i due campi relativi alla stessa informazione prelevata dai sistemi eritorna 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 recuperatoquesto sarà inserito nella tabella degli esiti opportuna, indicando, oltre ai datidell’entità, il sistema possessore, quello ricevente, stato esito ’APERTO’ ecome tipo anomalia il valore ’D’;

95


4. Eliminazione dalla tabella di storico dei disallineamenti ancora presenti nellatabella 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 ancorapresenti all’interno della corrispondente tabella degli esiti, in modo tale dalasciare nello storico solo i disallineamenti non più presenti per poterli definirechiusi.

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 irecord che sono rimasti nello storico con l’indicazione di disallineamento ’A-PERTO’, dopo l’operazione di cancellazione, saranno da considerare come di-sallineamenti chiusi, ovvero non più esistenti, perché non aventi più riscontronella 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

SERVERDATASTAGE

ProgettoDATA_INTEGRITY

CDB

SAP

SEM

TCC

CDB

SAP

SEM

TCC

CDB-SAP

CLC-SAP

CLC-SEM

SAP-DBL

SAP-SEM

SAP-TCC

CDB-SAP

CLC-SAP

CLC-SEM

SAP-DBL

SAP-SEM

SAP-TCC

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

JOB SEQUENCE

SERVER JOB

LOAD CHECK

JOB SEQUENCE

SERVER JOB

Figura 4.5. Progetto Data Integrity: la parte di progetto sviluppata su Datastage

97


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 attraversostrutture di controllo più complesse in differenti job sequence. I server job e le jobsequence sono state memorizzate all’interno del progetto di Datastage secondo lastruttura 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 leprocedure di aggiornamento dati e calcolo hash sulle tabelle di replica primadel confronto di allineamento;

3. i job, che richiamando le stored procedure e le funzioni PL/SQL, avviano leprocedure di confronto di allineamento dati, dopo l’operazione di aggiorna-mento.

98


Job di caricamento dei dati dai sistemi da monitorare

Lettura dati dalsistema sorgente

1. Scrittura sulla tabella di replica dei dati letti2. Memorizzazione logLink di ouput

Link di input

Stage Oracle Stage Oracle

Job per l’esecuzione degli aggiornamenti sui dati

Preparazione log1. Avvio stored procedureper aggiornamento dati2. Memorizzazione logLink di ouput

Link di input


Job per l’avvio degli algoritmi di confronto

Preparazione log1. Avvio stored procedureper il confronto dati2. Memorizzazione logLink di ouput

Link di input


Figura 4.6. Progetto Data Integrity: tipologie job Datastage

99


Come già anticipato, i server job che appartengono ad una specifica operazionesono stati collegati uno con l’altro attraverso l’utilizzo delle job sequence. Que-st’ultime, ovvero le job sequence, hanno consentito di indicare l’ordine con cuiattivare i singoli server job in funzione del compito svolto. Procedendo in que-sto modo è più semplice richiamare le operazioni di caricamento, aggiornamentoe confronto. Ad esempio, per il caricamento dei dati delle tabelle appartenenti alsistema SAP è sufficiente richiamare solo una job sequence, nello specifico chiamataLOAD_TABELLE_SAP, che a sua volta richiamerà tutte le job sequence ed i ser-ver 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 unospecifico link, come è possibile osservare nella parte 1 della figura 4.7. Uno stageviene utilizzato per la selezione dei dati, mentre l’altro per la memorizzazione delleinformazioni estratte nelle tabelle di replica del database DBADI1DATAINT. Tra-mite lo stage di caricamento Oracle si effettua la selezione ed il prelievo dei dati daldatabase di un sistema da controllare. I dati risultanti dalla selezione sul sistemadi partenza vengono trasferiti sul link. Sulla relativa parte di input di questo linkè collegato lo stage di scrittura dati per la memorizzazione delle informazioni nellatabella di replica presente nel database DBADI1DATAINT. La tabella di replicariceverà tutti i record prelevati dalla selezione del primo stage.Terminata l’operazione di caricamento sarà scritto un record di “successo” in unastruttura di log. Questa struttura è sostanzialmente una tabella utilizzata per teneretraccia delle varie operazioni eseguite nel processo di controllo. Anche la tabella dilog è memorizzata sul database DBADI1DATAINT.I nomi dei server job che ricoprono il compito di caricamento sono stati definiti se-condo lo standard seguente:LOAD_[nome entità abbreviata]_[sistema]ad esempio, LOAD_ANN_SAP è il nome del server job di caricamento degli an-nunci di SAP, come è anche riportato nella parte 1 della figura 4.7.

100


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

JOB SEQUENCE LOAD_CON_ANN_SIGLE_SAP

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

2

1

3

Figura 4.7. Progetto Data Integrity: server job / job sequence per il caricamento dati

101


I diversi server job di caricamento sono stati collegati e sono richiamabili utilizzandodelle job sequence che permettono di avviare i singoli server job in parallelo. Unesempio di questa tipologia di job è riportata nella parte 2 della figura 4.7 che con-sente di caricare le entità dei contratti, annunci e sigle del sistema SAP.Inoltre, sono state create delle job sequence particolari che ne richiamano altre. Illoro compito è di richiamare tutti job (sia job sequence che server job) per attivarele funzionalità di caricamento di uno specifico sistema. Queste job sequence sonostate chiamate secondo il seguente standard:LOAD_TABELLE_[nome sistema]La job sequence LOAD_TABELLE_SAP richiama tutti i job utilizzati per il cari-camento del sistema SAP, come è mostrato nella parte 3 della figura 4.7. Tramiteuna sola chiamata ad una job sequence siamo in grado di attivare i caricamenti ditutte 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 proce-dure e funzioni per eseguire l’aggiornamento dei dati per le transcodifiche ed per ilcalcolo del codice hash, prima dell’esecuzione degli algoritmi di confronto. In questafase si renderanno uguali le codifiche di campi e contestualmente saranno calcolatii codici hash utilizzati come campi di confronto nella fase di verifica dei disallinea-menti dovuti a differenze sui dati.I server job di questa categoria sono costituiti da due stage Oracle in modo analogoa quelli utilizzati per il caricamento. Nella figura 4.8 è riportato il server job peril richiamo della stored procedure utilizzata per l’aggiornamento dati dell’entità an-nunci 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’outputlink metterà solo un record di log che sarà memorizzato dallo stage ricevente l’inputlink. Lo stage Oracle ricevente scriverà il record nella opportuna tabella di log solose la specifica procedura PL/SQL di aggiornamento dati, configurata sullo stagericevente, avrà eseguito il suo compito correttamente senza restituire errori. In de-finitiva, tutte le stored procedure PL/SQL di aggiornamento dati sono richiamate

102


SERVER JOB AGGIORNA_ANN_SAP_PER_SAP_SEM_1

Definizione della stored procedure da richiamare all’interno delle proprietà dello stage WRITE_TDI07_LOG (la stored procedure è memorizzata all’interno del database DBADI1DATAINT)

Carica log Scrivi log

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 se-guente 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 pro-cedure PL/SQL che si occupa di aggiornare i dati sulle transcodifiche e sul codicehash 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 è presentenel nome del server job il suffisso “PER_SAP_SEM”.

103


4.5.3 I job per richiamare gli algoritmi di confronto

Definizione della stored procedure da richiamare all’interno delle proprietà dello stage WRITE_TDI07_LOG (la stored procedure è memorizzata all’interno del database DBADI1DATAINT)

Carica log Scrivi log

SERVER JOB CONTROLLA_ANN_SAP_SEM_2

Figura 4.9. Progetto Data Integrity: server job per richiamare il confrontodi un’entità tra due sistemi

In questa categoria appartengono i server job che richiamano le stored proce-dure PL/SQL incaricate di effettuare il calcolo delle anomalie sulle entità oggettodi confronto. I job sono strutturati in maniera simile a quelli utilizzati per il cari-camento e l’aggiornamento dei dati nelle tabelle di replica, come è possibile vederenella figura 4.9. Anche questi server job consentono la memorizzazione di un log pertenere traccia dei risultati delle diverse operazioni.I job appartenenti a questa categoria sono stati chiamati secondo il seguente stan-dard:CONTROLLA_[Entita]_[SYS_A]_[SYS_B]_2ad 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 eSEM (come riportato in figura 4.9).

Per richiamare in modo coordinato tutti i server job necessari per realizzare l’in-tera procedura di confronto tra due sistemi sono state impiegate delle job sequenceche permettono di sincronizzare prima tutte le rispettive operazioni di aggiornamen-to dei dati e poi, in seguito, di avviare quelle di confronto. Tali job sequence sonopredisposte a richiamare, in parallelo per ottimizzare i tempi, prima tutti i serverjob di aggiornamento dei dati e poi, previa verifica di successo delle operazioni pre-cedenti, di avviare tutti i server job che hanno il compito di attivare le proceduredi confronto su tutte le entità di una coppia di sistemi. Una volta terminate leoperazioni appena descritte, le job sequence permetteranno di inviare delle e-mail dinotifica del successo o dell’insuccesso delle operazioni di aggiornamento e controllodati.Le job sequence appartenenti alla categoria appena descritta sono state chiamatesecondo 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 specifichesulle tabelle del database DBADI1DATAINT contenenti i risultati dei controlli didisallineamento sui vari sistemi/entità. Per rendere l’applicazione facilmente fruibileè stata realizzata come una interfaccia WEB con cui è possibile interrogare le basidati degli esiti e visualizzare rapidamente l’elenco dei disallineamenti suddivisi persistema / entità. Tale interfaccia è costituita da un menù con cui selezionare ilsistema di cui richiedere gli esiti (parte 1 della figura 4.10). Per il sistema selezionatosarà visualizzato l’insieme delle entità che vengono monitorate e di cui disponiamo

105


gli esiti (parte 2 della figura 4.10). Nella pagina di visualizzazione delle entità persistema sarà possibile scaricare dei report contenenti i dati aggregati e di dettagliosull’ultimo controllo effettuato (parte 2 della figura 4.10 - pulsante “download”). Perogni entità controllata saranno riportate anche le informazioni relative al numerodi disallineamenti, suddividendo per assenze e differenze (parte 2 della figura 4.10).Sempre dalla pagina di visualizzazione entità per sistema, sarà possibile accedere aduna pagina di dettaglio (riportate nella parte 3 della figura 4.10) per vedere tuttele anomalie visualizzando un determinato numero di esiti per ogni pagina risultato,evitando liste dati troppo lunghe, che potrebbero influenzare i tempi di rispostadella pagina WEB stessa.

106

4.6 – Interfaccia utente

1

2

3

Figura 4.10. Progetto Data Integrity: applicazione WEB per la visua-lizzazione degli esiti

107


4.7 Generazione report

I report sono creati nel formato XML contenente i tag di un file XLS, quindisono stati realizzati per essere aperti con un programma di elaborazione di fogli dicalcolo come Microsoft Excel. I report contengono delle informazioni di riepilogosui 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. Inognuno di essi saranno presenti i riepiloghi di tutte le entità confrontate (contratti,annunci, ecc). Per ogni riepilogo saranno indicate le informazioni numeriche sui di-sallineamenti dovute alle assenze e alle differenze. Per i disallineamenti dovuti alledifferenze verranno riportate i dati numerici relativi ai campi che hanno prodottoqueste anomalie durante la fase di confronto.Nella figura 4.11 è riportato un esempio di report contenente i dati numerici deidisallineamenti riscontrati dai controlli sui sistemi SAP-SEM. In questa visualizza-zione avremo un riscontro numerico immediato sulle quantità dei disallineamentirilevati dall’ultima esecuzione dell’algoritmo. Tramite questi report si potrà deci-dere se operare o meno con interventi di urgenza per il riallineamento dei dati. Inalternativa, si potranno utilizzare tali informazioni per effettuare delle analisi piùprecise per capire le cause di questi disallineamenti. In questi report, oltre ai datidi riepilogo, sono riportati anche degli elenchi con i primi 10.000 record disallineatiper ciascuna entità controllata, suddividendo per disallineamenti dovuti ad assenzae differenza.

108

4.7 – Generazione report

Figura 4.11. Progetto Data Integrity: esempio di report contenente gli esiti dei controlli

109


4.8 Interazione con l’ambiente di schedulazione

Tutti i job di Datastage precedentemente descritti devono essere richiamati inmodo automatico per evitare di lasciare il compito di attivazione delle applicazioneall’utente. Per questo è stato necessario valutare come poter attivare in manieraautomatica questi job, sia di caricamento che di richiamo delle procedure PL/SQL.Come abbiamo visto nel capitolo di introduzione a Datastage è presente il program-ma Director che permette di impostare l’avvio dei server job e delle job sequence inorari prestabiliti. L’utilizzo di tale strumento poteva essere una soluzione, ma datoche 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 modoavanzato e flessibile la schedulazione, in date e orari precisi e configurabili, per av-viare processi e programmi presenti su diverse macchine della rete, creando di fattouna piattaforma di automatizzazione di processo. In più, questo schedulatore puòlavorare, senza problemi, su piattaforme diverse. In particolare può essere installatosu ambienti Unix/Linux, Windows, ecc. Quindi, i programmi e processi che neces-sitano di operazioni di schedulazione possono essere realizzati su piattaforme anchemolto differenti tra loro.Ritornando al contesto del progetto descritto, per avviare i job di Datastage ab-biamo utilizzato degli script Unix da far richiamare da questo schedulatore dSeries.Gli script Unix hanno il compito di invocare gli specifici job direttamente sullamacchina su cui è stato installato il server di Datastage. Inoltre, attraverso lo sche-dulatore dSeries è stato possibile prevedere l’attivazione di un programma customper la creazione dei report di riepilogo una volta terminate le operazioni di controlloallineamento dati. Attraverso l’infrastruttura creata l’applicazione WEB avrà ac-cesso sempre ai dati degli esiti aggiornati e permetterà di scaricare gli ultimi reportgenerati.

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 illustratonel precedente capitolo, di effettuare il caricamento dei dati, prelevati dai vari si-stemi, in tabelle di replica su cui vengono eseguiti i controlli di allineamento dati.Una volta constatato le cardinalità relative alle tabelle da controllare presenti suisistemi, che risultano essere dell’ordine di milioni di record per ciascuna entità, sonoriuscito, con l’ausilio del gruppo EAI, ad impostare dei controlli quotidiani fino a trecoppie di sistemi differenti. Per ogni coppia di sistemi vengono controllate le entitàcondivise che abbiamo definito precedentemente. Nella tabella 5.1 sono riportatii giorni in cui vengono eseguiti i controlli su queste coppie di sistemi. È possibileosservare che in alcuni casi le operazioni di controllo allineamento vengono eseguiteogni giorno, nello specifico questo è vero per i controlli SAP-SEM e CDB-SAP. Ilmotivo è dovuto al fatto questi sistemi condividono dati critici per le finalità di pro-duzione ed è molto importante avere un riscontro sulla quantità di disallineamentipresenti e, di conseguenza, avere delle situazioni giornaliere sulla qualità dei daticondivisi. Per gli altri sistemi, invece, è sufficiente avere una situazione settimanalesui disallineamenti, perché meno critici dal punto di vista della produzione.

111

5 – Valutazioni del progetto di Data Integrity realizzato in azienda

XXVenerdì

XXXGiovedì

XXXMercoledì

XXXMartedì

XXXLunedì

CDB - SAPCLC - SAPSAP - DBLSAP - TCCCLIC - SEMSAP - SEM

Figura 5.1. Progetto Data Integrity: calendario controlli

Per ricevere in modo immediato un riscontro sui controlli eseguiti, al termine delleprocedure di verifica allineamento sono richiamate delle funzioni di creazione report,di cui abbiamo già parlato nel capitolo precedente, in cui vengono riportati i datinumerici relativi all’assenze ed alle differenze rilevate sui dati. Questi report vengo-no mandati, in modo automatico, al gruppo EAI ed ai vari responsabili dei sistemicoinvolti nelle operazioni di controllo. In questo modo è stato impostato un sistemadi avviso immediato: le persone che riceveranno questi report potranno verificare idati numerici relativi ai disallineamenti riscontrati ed in base ai confronti precedentipotrà valutare l’aumento o la diminuzione di questi, decidendo eventualmente diricorrere ad operazioni correttive sui dati.

5.2 Riscontri numerici

I dati numerici relativi alle quantità di disallineamenti rilevati nei vari confrontieffettuati, 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 del-le modalità di migrazione ed operando correttive sulle applicazioni di integrazione,che dal punto di vista dei singoli dati, operando con delle procedure di riallinea-mento specifiche. I report generati dopo ogni confronto offrono costantemente unavisualizzazione dei disallineamenti:

• dal punto di vista aggregato, visualizzando numeriche relative alle quantità didati disallineati per assenza del dato e per differenza;

• dal punto di vista dettagliato, riportando i primi 10000 record disallineati perproblemi di assenza e differenza.

Le visualizzazioni aggregate sui disallineamenti permettono di avere una situazionerapida di quali campi risultano essere maggiormente interessati dal problema delledifferenze. Allo stesso tempo, la visualizzazione dei dati di dettaglio permette diavere il riferimento puntuale su un singolo record disallineato.

I dati dei confronti che vengono maggiormente utilizzati sono quelli relativi alleverifiche di allineamento tra i sistemi SAP-SEM, CLIC-SEM, SAP-TCC e CDB-SAP. I report contenenti questi dati disallineati hanno permesso di individuare dellecriticità e, in seguito, di rimuoverle nei flussi di integrazione.Per quanto riguarda le procedure di riallineamento sono state adottate tre tipologiedi operazioni:

1. l’utilizzo di applicazioni, già esistenti, di integrazione, opportunamente man-date in esecuzione con parametri specifici, con l’intento di riprovare ad inviareal sistema l’informazione che doveva essere già aggiornata, ma che per problemidi 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 alcunidati disallineati tra i sistemi SAP-TCC si è ricorso a questa tipologia, ovverosono stati creati dei nuovi flussi di integrazione per correggere i dati.

Nel seguito riporto le informazioni riguardanti alle anomalie più evidenti che sonostate corrette:

113


• tramite i risultati dei confronti SAP-TCC e SAP-SEM sono stati recuperaticirca 20 mila record di dati assenti nei sistemi TCC e SEM;

• il confronto SAP-SEM sull’entità annunci ha permesso di scoprire un bug suun’applicazione di integrazione esistente tra SAP e SEM. Questa applicazioneinviava un’informazione errata: nello specifico veniva passata la località incui era pubblicato l’annuncio, mentre il sistema ricevente aveva bisogno dellalocalità in cui era stato venduto l’annuncio, di conseguenza una volta scopertal’anomalia si è operato un bug fixing sul processo di integrazione;

• sono stati riallineati migliaia di codici contratto presenti sul sistema SEM cheper problemi di integrazione non erano stati aggiornati;

• sono stati riallineati migliaia di codici categoria sugli annunci che risultavanoessere differenti tra i sistemi SAP-SEM;

• è stato scoperto un errore sull’applicazione front-end di SEM che, dopo un’o-perazione particolare di modifica dell’annuncio, perdeva il valore di un camporelativo alla prenotazione annuncio, risultando, di conseguenza, disallineatocon il sistema SAP.

Allo stato attuale i controlli continuano ad essere eseguiti secondo il calendarioriportato nella tabella 5.1. Contestualmente a queste operazioni di controllo i re-port vengono generati di pari passo, creando di conseguenza un archivio storico deidisallineamenti riscontrati nei vari giorni.Inoltre, c’è un ultimo aspetto da considerare nella fase di analisi dei dati prodottidagli algoritmi: è ancora presente buon un numero di anomalie che l’azienda hadeciso 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 4.181.433

# record SEM 4.217.407

Disallineamenti totali 74.373

Record assenti su SEM 70.771

Record differenti su SEM 3.602

Campi su cui è stata riscontrata la differenza

Codice interno SAP 3.106

Codice offerta 497

Entità annunci


# record SEM 9.636.913


Record assenti su SEM 189.935

Record differenti su SEM 139.773


Prodotto 1

Tipo pubblicazione 440

Volume 2.256

Edizione 1.589

Localita 29.141

Categoria 128.893

Flag prenotazione 4.958

Figura 5.2. Progetto Data Integrity: riepiloghi controlli contratti - annunci SAP-SEM

115


Controllo SAP-TCC effettuato in data 17/06/2009

Entità contratti


# record TCC 5.406.511


Record assenti su TCC 133.946

Record differenti su TCC 67.636


Stato contratto 67.636

Entità annunci


# record TCC 13.151.216


Record assenti su TCC 207.333

Record differenti su TCC 50


Prodotto 36

Tipo pubblicazione 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 esitiperché l’azienda vuole tenere traccia di tali disallineamenti. Di conseguenza, si do-vranno 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 questocaso di studio, ha richiesto molti sforzi di analisi ed il coinvolgimento di diverse per-sone responsabili dei sistemi informativi. È stato speso diverso tempo per decidere leentità 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 deisuoi sistemi più importanti, da un’applicazione custom (CLIC) verso una di tipopackage (ovvero SAP). Il passaggio verso SAP sta coinvolgendo tutte le applicazioniche precedentemente si interfacciavano con il sistema vecchio, ovvero CLIC. In ag-giunta ai problemi di controllo delle funzionalità EAI, si è creata l’esigenza di averela verifica di allineamento dei dati migrati tra i sistemi CLIC - SAP, considerandotutti i problemi di conversione alle strutture del nuovo sistema adottato.Un fattore, che ho dovuto tenere molto in considerazione nell’implementazione delleprocedure di caricamento e controllo, è relativo alle performance dell’applicazionedi Data Integrity. Questo strumento di controllo allineamento dati per essere effet-tivamente utilizzato deve produrre i risultati dei confronti in tempi ragionevoli. Secosì non fosse non sarebbe possibile prendere le opportune contromisure in caso diun numero elevato di disallineamenti.È stato compiuto uno sforzo importante per realizzare delle procedure di caricamen-to, aggiornamento e calcolo disallineamenti il più veloci possibili. Quanto detto èfondamentale per via delle cardinalità notevoli presenti nelle tabelle dei sistemi dacontrollare. Per rendere l’applicazione Data Integrity più efficiente sono state predi-sposte in parallelo, dove è stato possibile e compatibilmente con le potenzialità dellemacchine a disposizione, tutte le funzionalità di caricamento e controllo dei vari si-stemi da monitorare. È stato scelto come momento di esecuzione delle operazioni di

117


caricamento e confronto dati l’orario notturno. Infatti, nelle ore notturne abbiamoil momento migliore per questo tipo di operazioni: i sistemi sono più scarichi dalpunto di vista computazionale e di conseguenza anche le macchine su cui verrannoeseguite le diverse operazioni saranno più veloci.

Nel capitolo precedente ho descritto che il caricamento dei dati, prelevati dai varisistemi 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 riferi-menti espliciti alla data di ultima modifica del record, di conseguenza, senzatale informazione non abbiamo un discriminante agevole per effettuare del-le operazioni aggiornamento sulla tabella di replica, presente sul databaseDBADI1DATAINT, associata ad un entità di un sistema da controllare;

• risulta essere un’operazione molto lunga individuare i record cancellati sulsistema di produzione, per aggiornare in modo congruente le informazioni sullatabella di replica; sarebbe necessario scorrere tutto l’insieme dei record dellatabella di replica e verificare o meno la presenza sul sistema di produzione equesto costituisce un’operazione molto lenta.

Considerati questi due aspetti, si è scelto di svuotare e caricare di continuo le tabel-le di replica presenti sul database Oracle DBADI1DATAINT. Sono riuscito, comegià affermato in precedenza, a velocizzare le fasi di caricamento dei dati tramitel’utilizzo di procedure eseguite, il più possibile, in parallelo. Tutte le entità dei siste-mi coinvolti nel controllo di Data Integrity sono replicate sulle tabelle del databaseDBADI1DATAINT in quattro ore al massimo. Considerato il caricamento massivodei dati ne consegue che le procedure di aggiornamento e confronto disallineamentieffettueranno le loro operazioni sulla maggior parte dei dati presenti nelle tabelle direplica: non possiamo limitarci ad un sottoinsieme, perché caricando i dati ogni voltaquesti devono essere aggiornati, sia per le operazioni di transcodifica che per quel-le relative al calcolo del codice hash. Ovviamente anche gli algoritmi di confrontoutilizzeranno 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 ancoradi monitorare l’allineamento dei dati condivisi tra i sistemi. Posso affermare che lostrumento 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 con-cesso per l’analisi e lo sviluppo dell’applicazione Data Integrity, abbiamo deciso, conl’ausilio del gruppo EAI di Reply, di focalizzarci sui sistemi che presentavano le cri-ticità più urgenti, ovvero quelli coinvolti maggiormente dalla migrazione verso SAP.Quanto detto non esclude il fatto di potere aggiungere altre procedure di controllosu entità e sistemi differenti. Una volta deciso ed impostato un modello di procedi-mento questo è possibile ripeterlo anche per gli altri. In particolare, le operazioniche 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 sonoi 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 tabelledegli esiti, aggregando i dati diversamente;

• visualizzare, in modo differente, sui report e sull’applicazione WEB i dati chel’azienda ha deciso di non correggere;

119


• velocizzare maggiormente le funzionalità di caricamento, aggiornamento e con-trollo 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 è possibilesuddividere l’archivio centralizzato in più sottoarchivi dove caricare le tabelledi replica e degli esiti; in modo opportuno saranno da spostare anche le storedprocedure e funzioni PL/SQL che faranno riferimento a tali tabelle;

• integrare le funzionalità di ripristino dati e di riallineamento all’interno del-l’interfaccia WEB già presente.

Quest’ultimo punto, ovvero le funzionalità di ripristino da inserire nell’interfacciaWEB, permetterebbe di velocizzare il riallineamento dei dati sulle anomalie riscon-trate. Con questa funzionalità aggiuntiva sarebbe possibile sistemare in tempo realei dati differenti, anziché ricorrere a flussi batch che di solito vengono lanciati la not-te e sono time consuming, ovvero ci mettono molto tempo per completare la loroesecuzione. Intervenendo in tempo reale, invece, sarebbe possibile risolvere alcunesegnalazioni di errore, dovute a problemi sui dati, provenienti dagli utenti dell’appli-cazioni. Si fornirebbe in questo modo un servizio di assistenza migliore e gli utentipercepirebbero un incremento di affidabilità dei sistemi utilizzati, migliorando di fat-to la qualità del sistema. Maggiore sarà la qualità dei dati condivisi, di conseguenzaci saranno meno errori e potrà aumentare la produttività complessiva dell’azienda.

120

Conclusioni

Il problema dell’integrità dei dati distribuiti è un aspetto molto importante nellearchitetture di integrazione EAI ed un’applicazione di Data Integrity deve essereconsiderata come un supporto per gestire questo problema. Un’applicazione di DataIntegrity permette, come ampiamente illustrato, di verificare il funzionamento delsistema di integrazione partendo dal punto di vista dei dati, ovvero si occupa diverificare l’allineamento delle informazioni distribuite e condivise tra i vari sistemidella struttura informativa di un’azienda, fornendo degli strumenti per visualizzarei disallineamenti riscontrati. In questo modo si potrà decidere tempestivamente leeventuali contromisure in caso di disallineamenti che potrebbero rendere instabili lefunzionalità presenti nei sistemi e creare dei disservizi.

Il lavoro per mantenere il più possibile allineati i dati distribuiti rappresenta unrequisito fondamentale nello sviluppo di applicazioni di integrazione di sistemi. In-fatti, se i dati condivisi fossero continuamente disallineati, il patrimonio informativolegato alle informazioni memorizzate rischierebbe di essere compromesso seriamente.In un contesto del genere, molto probabilmente, l’integrazione realizzata ricadrebbein un fallimento, causando danni economici a tutti gli attori coinvolti nel processodi integrazione: dall’azienda su cui è stata realizzata l’integrazione a quelle di con-sulenza che hanno partecipato alla sua messa in funzione.Quanto appena detto ci porta a dire che è molto importante tenere sotto controllo idati relativi alle entità di business condivise e che rappresentano gli “oggetti critici”per un’azienda. L’obiettivo è di realizzare delle soluzioni di integrazione che possanoessere il più facilmente gestibili, mantenendo allineate tali informazioni distribuitesui 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 malfun-zionamenti 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 leoperazioni più critiche; in questo caso l’obiettivo da perseguire è di avere menosistemi da integrare, accorpando basi dati ed applicazioni;

• altrimenti, oltre allo sviluppo dell’integrazione sui sistemi presenti, prevederedei meccanismi automatici per valutare la qualità dei dati condivisi, ovverorealizzare un’applicazione di Data Integrity.

La prima casistica, relativa ad una semplificazione delle procedure, è difficile da rea-lizzare perché in molte situazioni reali rivedere le funzionalità delle applicazioni giàesistenti, riscrivendo dall’inizio o riutilizzando in parte codice esistente, rappresentadi solito “l’ultima scelta” che i vari responsabili IT vogliono perseguire. Cambiare leapplicazioni, che funzionano e danno garanzia di affidabilità, generalmente è una re-sponsabilità che nessuno vuole prendersi e costituisce un investimento a medio lungotermine che non da certezza di successo, visto tutti i rischi legati all’implementazionee test. Anche se in prospettiva si potrebbe optare per l’adozione di nuove soluzionie applicazioni, che sulla carta potrebbero dare maggiore vantaggi in termini di in-tegrazione, il rischio di intraprendere a volte è troppo grande e ci si accontenta dimettere in comunicazione, con strumenti di integrazione come le EAI, i sistemi che sihanno a disposizione. Quindi, pochi investimenti nel cambiare le applicazioni, anchequando obsolete, ma molti nel creare infrastrutture di comunicazione, cercando dicondividere informazioni tra sistemi anche molto diversi tra loro, come ad esempioapplicazioni mainframe con architettura .Net o Java.Da quanto detto, la seconda ipotesi, ovvero utilizzare degli strumenti di control-lo dati, potrebbe essere la strada da perseguire per verificare se le architetture di

122

Conclusioni

integrazione realizzate stanno funzionando o meno. Realizzare strumenti di con-trollo sui dati, di solito, non prevedono la modifica delle applicazioni già esistenti egeneralmente hanno un costo inferiore rispetto alle modifiche delle applicazioni del-l’infrastruttura informativa. È possibile affermare che la verifica della correttezzadei dati distribuiti sui sistemi rappresenta un fattore di successo per la soluzione diintegrazione 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 po-trebbe porre è la seguente: ma quali sono le metodologie da utilizzare per realizzareun’applicazione di Data Integrity? La risposta purtroppo non è immediata per viadei seguenti problemi:

• dalle ricerche che ho effettuato per svolgere questa tesi ho constatato che nonesiste una bibliografia importante sull’argomento Data Integrity in un con-testo di integrazione software e, quindi, non esistono standard specifici. Pergiustificare questo aspetto c’è da considerare che è difficile avere dei paradigmiben definiti per implementare dell’applicazioni di Data Integrity consideratala varietà dei sistemi tra di loro molto differenti presenti nell’architettura in-formativa di un’azienda. Molto spesso è necessario una valutazione caso percaso e risulta difficile proporre degli standard;

• le difficoltà, non indifferenti, nella creazione del processo di controllo conside-rate le notevoli cardinalità delle tabelle e la corretta definizione degli outputche deve restituirci un’applicazione di Data Integrity. Questo secondo aspettoè molto importante e se viene analizzato bene può permetterci di sopperirealla 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 sistemiper avere più informazioni possibili. In questo modo si avranno dei riscontri im-mediati sulle ipotesi di implementazione e si potrà discutere costruttivamente perdecidere 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 DataIntegrity deve essere inteso come l’utilizzo di una serie di contromisure e di segna-lazioni per avere delle garanzie di qualità dei dati in contesti eterogenei e complessidal punto di vista informativo. In queste realtà abbiamo di solito la presenza dimolti 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 possonorappresentare una situazione critica perché con l’aumentare del numero di personeè probabile che aumentino anche le possibilità di avere errori nelle procedure. Infat-ti, quando ci sono tanti gruppi di persone che lavorano su un’architettura comune,uno degli aspetti più difficili da affrontare è legato al corretto coordinamento deglisviluppi e messa in produzione delle modifiche. Infatti, se un gruppo, che lavorasu una specifica applicazione, sviluppa delle modifiche che impattano sul sistema diintegrazione e queste non vengono comunicate per tempo agli altri gruppi, si cor-rerà il rischio, portando in produzione tali modifiche, di creare malfunzionamentinelle applicazioni di integrazione. I sistemi potrebbero non funzionare, creando undisservizio, ed i dati potrebbero non essere più allineati. Nel caso appena descrittoun’applicazione di Data Integrity fornirebbe una modalità per rilevare questi disal-lineamenti e ricorrere il prima possibile ad operazioni correttive.Una soluzione di Data Integrity, implementata come applicazione di verifica sullaqualità di integrazione, si pone l’obiettivo di aiutare ad individuare i disallineamentianalizzando i dati. Se quest’ultimi saranno allineati tale situazione potrà rappresen-tare un sintomo di buon funzionamento complessivo dell’architettura di integrazione.Al contrario, riscontrare degli errori sui dati farà pensare subito ad un possibile pro-blema di integrazione o comunque evidenzierà una situazione non allineata che dovràessere presa in considerazione.

È importante sottolineare che un’applicazione di Data Integrity presumibilmentepotrà essere gestita dalle persone del gruppo di integrazione, le quali possiederan-no già le conoscenze e competenze necessarie per sapere come intervenire e comeattivarsi in caso di problemi. In generale, riscontrando errori nei dati, dopo avereffettuato le opportune analisi, si potrà pensare di attivare i meccanismi specifici diaggiornamento per effettuare le cosiddette “operazioni di allineamento”. In seguito

124

Conclusioni

a queste operazioni di allineamento, sarà ragionevole verificarne il successo avvian-do nuovamente lo strumento di controllo di Data Integrity per aver evidenza dellabuona riuscita dei meccanismi di ripristino.

125

Allegato A

Linguaggio PL/SQL

Introduzione

Lo scopo di questa sezione è di illustrare i principali costrutti specifici del linguaggioPL/SQL utilizzati per la realizzazione delle procedure di aggiornamento dati e con-trollo presenti nel progetto di Data Integrity descritto nel caso di studio del quartocapitolo. Non saranno trattate, in dettaglio, le istruzioni del linguaggio SQL base dicui fanno parte le operazioni di SELECT, INSERT, UPDATE, DELETE, CREATE,ecc, considerando che il lettore abbia già questa conoscenza. La mia intenzione, inquesta breve descrizione, è di focalizzarmi sulle peculiarità del PL/SQL rispetto allecaratteristiche del linguaggio SQL base.Il PL/SQL è un linguaggio procedurale, strutturato e a blocchi. Questo tipo dilinguaggio permette l’interrogazione delle basi dati Oracle con la possibilità di effet-tuare 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 secon-do sequenze logiche i comandi SQL in unità. In un blocco si possono dichiararecostanti e variabili e quest’ultime possono essere utilizzate per memorizzare i risul-tati di una query. Le istruzioni che possiamo ritrovare in un blocco PL/SQL sonoistruzioni 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, peruna questione di organizzazione, essere raggruppati in pacchetti denominati pac-kages. Ciascuno di essi è costituito da una parte di interfaccia ed una parte diimplementazione.

Costrutti fondamentali

Declare-Begin-End

La scrittura del codice PL/SQL deve rispettare uno schema ben definito. Infattiuna procedura o una funzione deve seguire questa struttura:

• DECLARE, è opzionale, permette di indicare una sezione dove dichiarare edefinire le variabili, i cursori e le eccezioni dell’utente che saranno usate nelblocco di codice.

• BEGIN serve per indicare l’inizio di un blocco di codice, da lì in poi segui-ranno tutte le istruzioni PL/SQL della procedura o funzione, fino ad arrivareall’istruzione END.

• EXCEPTION, è opzionale, specifica l’azione da intraprendere quando occorreuna particolare eccezione, ovvero cattura l’errore e ne permette la sua gestione.

• END; è l’istruzione per determinare la fine del blocco, bisogna notare che ilpunto 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 dialcune 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 TRUEe FALSE;

• %TYPE è un attributo particolare che può essere utilizzato per definire va-riabili il cui tipo è associato allo stesso di una colonna di una tabella presentenel database;

• %ROWTYPE specifica un record adatto a memorizzare tutti i valori degli at-tributi di una riga di una tabella o risultato di una query. Ad esempio se nel da-tabase fosse presente la tabella PIPPO la dichiarazione PIPPO%ROWTYPEservirebbe per specificare un record formattato per contenere tutti i campi ditale tabella.

Dichiarazioni cursore

La dichiarazione di un cursore serve per specificare un insieme di righe che possonoappartenere ad una tabella oppure ad un risultato di una query attraverso un’ope-razione 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 dalcarattere ’,’. 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. Questiparametri servono per assegnare valori alle variabili che sono indicate nell’istruzioneselect.

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 cursoreda aprire sarà necessario specificare anche l’eventuale lista dei parametri da passarein input.

1 open <nome cursore> [(<lista di parametri>)];

Una volta richiamata l’istruzione open l’operazione di select associata al cursoresarà processata e il cursore stesso punterà alla prima riga selezionata. Per poter scor-rere le righe seguenti si utilizzerà il comando fetch, il quale permetterà di proseguirenell’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 selezionatidalla 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 presentenell’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. Unavolta 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 edisabilitato:

1 close <nome cursore>;

Riportiamo un esempio per riepilogare le operazioni da eseguire per l’utilizzo diun 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 riferimentoalla 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 unariga recuperata da un cursore e questa sarà accessibile utilizzando l’oggetto <nomerecord>.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 inmodo automatico senza utilizzare l’istruzione exit.In alternativa al nome del cursore è possibile specificare una query di selezione diret-tamente, sostituendo il nome del cursore con l’istruzione SQL, perciò sarà possibilescrivere:


(<istruzione select>)

3 loop

...


...

7 end loop;

132

Allegato A

Nella situazione appena descritta il cursore non dovrà essere specificato primadell’ingresso del ciclo ma sarà definito nell’istruzione select.Ad esempio, per definire velocemente un cursore che punti ad una tabella possiamoscrivere:

1 for record_tabella in

(select ∗ from tabella)

3 loop

...

5 end loop;

Inoltre, sull’istruzione loop possiamo specificare il numero di iterazioni facendo usodi due interi, uno per il limite inferiore ed uno per quello superiore. Quanto appenadescritto non è possibile ottenerlo con l’istruzione loop while perché il numero diiterazioni è sconosciuto.Quindi con il costrutto loop for possiamo scrivere:


<estremo inferiore>..<estremo superiore>

3 loop

...


...

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 nellaforma:

1 if <condizione> then

...


...

5 [elsif] <condizione> then

...


...

9 [else]

...


...

13 end if;

Il comportamento è analogo alle istruzioni if-then-else dei linguaggi di programma-zione classici.

Procedure e funzioni

Il linguaggio PL/SQL fornisce sofisticati costrutti di linguaggio per programmareprocedure e funzioni come blocchi PL/SQL separati. Questi possono essere richia-mati da altri blocchi PL/SQL, altre funzioni e procedure, anche in questo caso inmodo 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ò essereusata nella definizione di procedure/funzioni.Alle procedure e funzioni è possibile passare dei parametri. Ciascuno è specificatocome 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 cuiutilizzare il parametro. Se non viene specificato nulla il default è IN.

• IN significa che al parametro si può fare riferimento all’interno del corpo dellaprocedura o funzione, ma non può essere modificato;

1Blocchi 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 dellaprocedura o funzione, ma non si può fare riferimento al valore del parametro;

• IN OUT permette sia di far riferimento al parametro che l’assegnazione divalori.

Come abbiamo visto le funzioni hanno la stessa struttura delle procedure, l’uni-ca differenza sta nel fatto che le funzioni restituiscono un valore il cui tipo di datodeve 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 programmatoridi 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 delleeccezioni. Ogni errore o avviso durante l’esecuzione di un blocco PL/SQL causa unaeccezione. Si può distinguere tra due tipi di eccezioni: eccezioni definite dal sistemaed eccezioni definite dall’utente (che devono essere dichiarate dall’utente nella partedi dichiarazione di un blocco dove l’eccezione è utilizzata/implementata).Il sistema definisce eccezioni che vengono automaticamente attivate quando i corri-spondenti errori o avvisi vengono incontrati. Le eccezioni definite dall’utente, con-trariamente, devono essere attivate esplicitamente in una sequenza di istruzioni uti-lizzando l’istruzione raise <nome eccezione>.Alla fine di un blocco, dopo la parola chiave exception, le routines di gestione delleeccezioni definite dall’utente vengono implementate. Un’implementazione di unagestione 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/SQLsono 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 presentenella gestione dell’eccezioni può contenere il nome others, la quale rappresenterà laroutine 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 pro-grammatore, raggruppate per formare degli strumenti specifici necessari alla risolu-zione di un determinato compito.

CORBA: Common Object Request Broker Architecture, meccanismo software perla gestione delle chiamate a procedura con oggetti di invocazione che risiedono inuno 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’applicazioneCRM serve a tenersi in contatto con la clientela, memorizzando le informazioni inappositi database e fornendo delle modalità per analizzare le interazioni con il clien-te.

DCOM: Distributed Component Object Model, tecnologia informatica di Microsoftche usa gli stessi paradigmi di CORBA.

ERP: Enterprise Resource Planning, sistema di gestione che integra i vari aspetti delbusiness 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), trasfor-mazione (Trasformation) e caricamento (Load) dei dati in un sistema di sintesi comeun Data Warehouse.

JDBC: Java DataBase Connectivity, si tratta di un connettore per database chepermette ad un programma scritto in Java di accedere a qualsiasi base dati.

ODBC: Open Database Connectivity, si tratta una API standard utilizzata per laconnessione ai database; si tratta di un’interfaccia indipendente dai linguaggi diprogrammazione, dai sistemi di database e dai sistemi operativi.

ORB: Object Request Broker, parte di software middleware che permette ai pro-grammatori di effettuare chiamate di programma tra computer differenti in una rete.

SAP: insieme di applicazioni ERP per integrare tutti gli aspetti del business, inclusala pianificazione, la realizzazione del prodotto, la logistica di magazzino, le gestionedelle vendite e degli acquisti.

SOA: Service Oriented Architecture, fornisce dei metodi per i sistemi di sviluppo edi integrazione dove le funzionalità sono esposte come servizi richiamabili in modoindipendente dal sistema operativo e linguaggio di programmazione utilizzato.

140

Bibliografia

[1] David Cronin Alan Cooper, Robert Reimann. About Face 3: The Essentials ofInteraction 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. Top10 reasons why eai fails, Di-cembre 2002. 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 percorsouniversitario, in particolar modo ringrazio Stefania per il supporto nei momenti piùdifficili.Ovviamente ringrazio il relatore, prof. Fulvio Corno, per tutti i consigli fornitidurante la stesura della tesi.Ringrazio l’azienda Blue Reply S.r.l., ed in particolar modo, Alessandro Ponte eFederico Stentella per il supporto durante l’attività svolta.

145

EnterpriseApplicationIntegration -...

Documents

Transcript of EnterpriseApplicationIntegration -...