Data Flow

Di seguito verranno presentati i principali data flow utilizzati per realizzare le diverse fasi dell’ETL.

Estrazione

Per poter estrarre i dati da SAP `e necessario utilizzare l’ABAP DataFlow il quale genera codice ABAP (Advanced Business Application Programming) che interroga le strutture sorgenti definite nel flusso.

Nella Figura 5.4 viene mostrato un esempio di flusso ABAP Data

Flow. Il flusso estrae i dati dalle tabelle SAP VBRP e VBRK che

contengono i dati di fatturazione, effettua una Inner Join tra le tabelle e il risultato viene salvato in un file. Il file prodotto dal flusso verr`a usato durante la fase di primo caricamento nella base di dati.

Trasformazione

Figura 5.4: Esempio di ABAP Data Flow

operazioni di pivot o reverse pivot (rotazione da colonne a righe e viceversa), inserimento di nuovi campi, conversioni di tipi di dati, etc.

Di seguito alcune trasformazioni e controlli che vengono spesso applicati ai dati.

• I campi di tipo stringa, provenienti dalle sorgenti, potrebbero avere spazi prima e dopo il valore, per eliminarli viene utilizzata la funzione trim() che provvede ad eliminarli.

• Alcuni valori delle misure e delle dimensioni potrebbero avere valori nulli creando problemi in fase di analisi e caricamento. Tramite la funzione nvl() vengono assegnati dei valori di default, definiti nelle variabili globali, per le date, per i campi numerici e per le stringhe.

• Il valore di alcuni attributi dimensionali, in genere le descrizioni, vengono ottenuti tramite la concatenazione di pi `u attributi.

In Figura 5.5 viene mostrato un flusso che trasforma i dati della fatturazione e li carica nella tabella dei fatti.

Figura 5.5: Esempio di un Data Flow

L’azienda committente ha varie sedi sparse nel mondo, quindi i

documenti di fatturazione hanno valute diverse fra loro. Per

permettere analisi locali e globali si `e deciso di arricchire il documento di fatturazione con due nuovi campi che esprimono gli importi nella valuta locale, quella del paese dove ha sede l’azienda che ha emesso la fattura e che pu `o essere diversa da quella del documento, e in quella globale. La valuta globale `e quella dell’azienda capogruppo, ovvero l’euro.

Nella progettazione e realizzazione del flusso si `e dovuto tener conto di questa esigenza.

Il flusso ha inizio con i dati precedentemente salvati tramite il flusso

ABAP data flow (R3 BillingFact). I dati vengono estratti tramite un

oggetto Query che non fa altro che mappare i campi da estrarre. Dopo l’estrazione `e stato inserito un punto di controllo, Data Transfer, il quale salva i dati caricati in una tabella per eventuali ispezioni future.

Il flusso prosegue con il primo arricchimento di informazioni tramite l’oggetto LookupPartner che aggiunge il nuovo campo ottenuto

dal prodotto tra l’importo (es. importo netto) nel documento con il valore del tasso di cambio locale. Un esempio `e mostrato nella Figura 5.6.

Figura 5.6: Esempio di passaggio da valuta del documento a valuta locale

Il passo successivo `e l’arricchimento con l’importo espresso nella valuta globale. Nel flusso si controlla se la valuta locale `e uguale a quella globale, in caso affermativo non sono necessarie modifiche altrimenti si moltiplica l’importo per il tasso globale valido in quel

momento. Questi passaggi vengono effettuati dagli oggetti

ExchgRateLookup, LookupQuery, NOLookupQuery e GlobalCurrencyAmts e rappresentati nelle Figure 5.7 e 5.8.

Caricamento

Il caricamento `e l’ultima fase del processo di ETL e corrisponde al caricamento dei dati sul data warehouse.

Quando questa fase viene eseguita per la prima volta `e in generale necessario progettare fisicamente il database creando lo schema del data warehouse con i relativi indici. Lo strumento utilizzato non richiede la definizione dello schema che invece viene ricavato automaticamente dal flusso di caricamento.

Figura 5.7: Esempio di controllo di uguaglianza tra valuta locale e globale

Nella Figura 5.6 viene sottolineata questa fase con un rettangolo rosso; consiste semplicemente nel mappare tutti i campi, trasformati precedentemente, nella tabella dei fatti BILLING FACT con l’opzione di

caricamento TRUNCATE attiva. In tal modo tutti i dati vengono

caricati nella tabella del DWH finale solo dopo che `e stata svuotata. Nella fase di caricamento `e stato necessario gestire un problema di fuso orario dovuto al fatto che le sedi dell’azienda sono sparse nel mondo e hanno orari di utilizzo dei database operazionali differenti. Questa differenza di fuso orario impedisce di utilizzare un’unica finestra temporale per caricare il DW. Per risolvere il problema le sedi sono state suddivise in due gruppi: uno che comprende le aziende presenti nei paesi europei ed asiatici, uno che comprende le filiali americane. I dati provenienti dai due gruppi vengono quindi caricati da due job (J SalesFact G1 e J SalesFact G2) ad orari differenti.

Gestione errori

Quando un Job ETL viene eseguito `e possibile che vengano segnalati dei warnings, essi rappresentano dei problemi che non pregiudicano

l’esecuzione del job. Un esempio di warning `e quello segnalato a

seguito di un mapping tra tipi di dato compatibili ma che possono determinare la perdita di informazioni, come ad esempio tra un campo di tipo varchar(50) e un campo di tipo varchar(30), dove eventuali stringhe con pi `u di 30 caratteri vengono troncate.

In caso di errore invece il flusso viene terminato. Esempi tipici di errore sono quelli dovuti a problemi di connettivit`a verso i DB, conversioni tra tipi di dati incompatibili (ad esempio da stringa a valore numerico), o ancora una divisione con divisore uguale a zero o la violazione di una chiave primaria.

cui si dovesse verificare un errore, il flusso salta direttamente al nodo Catch in cui `e stato inserito uno script che si occupa di inviare un’email con il messaggio di errore che `e stato rilevato.

Durante l’esecuzione del flusso vengono prodotti anche dei file di log sia per monitorare l’esecuzione che per esaminare i dettagli di un eventuale errore.

Schedulazione automatica del job

Dopo che i job sono stati completati e verificati nell’ambiente di sviluppo questi vengono installati nell’ambiente di produzione e schedulati per l’esecuzione.

La gestione della schedulazione dei job e il monitoraggio della loro esecuzione avviene tramite il servizio Data Services Management Console

accessibile tramite browser. In Figura 5.9 `e visibile un esempio di

schedulazione di job.

5.4

Conclusioni

In questo capitolo si `e discusso brevemente del processo di estrazione, trasformazione e caricamento dei dati.

Successivamente sono stati presentati lo strumento della suite SAP (Data Services) utilizzato per il presente progetto di tesi e i pacchetti predefiniti SAP detti Rapid Mart soffermandosi principalmente sul pacchetto delle vendite.

Si `e discusso del processo di ETL relativo al progetto mostrando e spiegando le varie fasi di estrazione, trasformazione e caricamento dei dati nel data warehouse e soffermandosi nell’illustrazione di uno dei flussi creati.

AMBIENTE DI SVILUPPO

DELLA REPORTISTICA

Una volta definita la struttura del data warehouse e dopo averlo popolato con i dati richiesti dal cliente `e necessario generare i modelli per presentare tali dati all’utente finale. In questo capitolo verranno descritti gli strumenti utilizzati per la creazione dei modelli di analisi.

6.1

Introduzione

Negli ultimi anni le analisi multidimensionali sono oggetto di particolare interesse nella business intelligence, infatti l’uso di alcuni strumenti interattivi permettono di estrarre dati di sintesi, esplorarli da diversi punti di vista e permettono di determinare situazioni anomale o tendenze interessanti nella gestione dei processi aziendali. [Albano 12]

Esistono diversi tipi di analisi di dati:

• Generazione di rapporti: consiste nel produrre dei rapporti sintetici che presentano in maniera efficace informazioni

• Analisi multidimensionale: in genere i dirigenti, per prendere

decisioni, hanno bisogno di effettuare analisi storiche

relativamente alle attivit`a dell’azienda. Tali rapporti hanno una struttura complessa ma consente di effettuare analisi da vari punti di vista e scoprire situazioni anomale o tendenze interessanti.

• Analisi esplorative: si cerca di scoprire in modo automatico un qualche modello interessante da un insieme di dati utilizzando tecniche di Data Mining. Ad esempio “Qual `e il profilo generale dei possessori di carta di credito che traggono profitto dalle promozioni offerte con il resoconto mensile?”. Un modello quindi `e una rappresentazione concettuale che evidenzia l’informazione presente nei dati.

Il sistema di reportistica `e lo strumento con il quale gli utenti finali possono interagire con il data warehouse senza la necessit`a di avere alcuna informazione su come esso sia strutturato.

Esso ha l’obiettivo di fornire la documentazione analitica sulle attivit`a di rilievo dell’organizzazione all’interno della quale `e sviluppato. Il documento prodotto viene chiamato “report”, esso si presenta come una combinazione di tabelle e/o grafici e mette in evidenza gli indicatori rilevanti per un determinato fenomeno aziendale.

Possiamo avere due categorie di utenti della reportistica: gli

sviluppatori e gli utenti finali. Il primo rappresenta colui che crea i report, l’utente finale `e colui che ha richiesto, consulta e modifica i report in base alle esigenze dell’azienda.

In questo capitolo verranno presentate le principali caratteristiche del software utilizzato per lo sviluppo della reportistica, SAP Business

Object BI 4.0 e lo Universe Design Tool, inoltre ne verr`a mostrato il suo utilizzo.