L’applicazione realizzata ha richiesto l’approvvigionamento dei dati di partenza da diverse sorgenti. Il modello dati realizzato è costituito da una serie di strutture di staging, organizzate su livelli differenti, destinate a contenere le diverse tipologie di variabili utilizzate per l’inizializzazione dell’applicazione.
Il modello realizzato è rappresentato nella figura 4.1. Per ragioni di leggibilità le strutture di staging sono identificate in figura tramite i loro nomi tecnici definiti a sistema. Le rispettive associazioni funzionali e la relativa descrizione dei dati contenuti al loro interno verrà data nel seguito del paragrafo.
Osservando lo strato di estrazione presente alla base del modello, si può vedere come esso si interfacci con altre strutture dati già presenti all’interno dell’azienda e legate ad altri contesti applicativi.
Il modello dati qui illustrato può essere idealmente diviso in due parti: nella parte sinistra del modello sono presenti i flussi che eseguono il caricamento delle componenti relative ai costi per veicolo; nella parte destra si possono invece osservare i quattro flussi relativi al caricamento dei volumi di vendita pianificati e consuntivi. Queste due sezioni saranno trattate in maniera separata nei paragrafi successivi.
33
Warranties Accrual Planning
ZO_WAP04 ZO_WAP01 ZO_WAP21 ZO_WAP22 ZO_WAP23 ZO_WAP31 ZO_WAP32
ZO_WA_01A ZO_WA_21A ZO_WA_22A ZO_WA_23A ZO_WA_31A ZO_WA_32A ZO_WA_04A
Bex query CV Data delibera APD Bex query CV Data vendita APD Bex query Costi per data effettuazione APD
Bex Query Distribuzione costi per data effettuazione APD Bex query CV Data vendita APD Bex query CV Data vendita APD Bex query Costi per data effettuazione APD
ZO_WAP05 ZO_WAP06 ZO_WAP07
Data Source ZO_WAP08 File CSV BFP Standard margin Reporting commerciale Area Sales Sellout
Figura 4. 1: Modello approvvigionamento dati dell'applicazione
Verranno ora illustrate le tipologie delle strutture dati rappresentate in figura. Per la scrittura dei punti elencati nel seguito sono stati consultati i testi alle voci [3] e [4] e i portali ufficiali alle voci [6] e [7] della bibliografia.
• Query BEx: Una query BEx è una query costruita tramite lo strumento BEx Query designer. Al suo interno è possibile indicare le dimensioni e le misure da rappresentare, l’ordine di visualizzazione dei dati, nonché impostare le varie opzioni di navigabilità dei report. È inoltre possibile specificare delle variabili che consentono, mediante un prompt visualizzato al momento dell’esecuzione, di parametrizzare l’estrazione dei dati in base ai valori inseriti. Normalmente le query vengono eseguite tramite appositi strumenti front-end di analisi ma nel caso analizzato vengono utilizzate solamente come sorgente dati per il modello.
• Variante query BEx: Una variante di una query BEx è costituita da una prevalorizzazione delle variabili definite all’interno della query stessa. Per ogni query è possibile specificare una serie di varianti che contengono un insieme di
34
valori relativi alle variabili create al fine di parametrizzare l’estrazione dei dati da parte della query stessa.
• Infocubo real time: In cima al modello è presente quella che è la destinazione del processo di ETL, ovvero il data mart utilizzato per la gestione dei dati elaborati in fase di pianificazione. I data mart su SAP sono comunemente chiamati “infocubi”. Gli infocubi standard sono ottimizzati in maniera tale che vengano velocizzate le operazioni di lettura a discapito di quelle di scrittura; ciò è utile nel caso di utilizzo degli stessi da parte di strumenti di reportistica ma può creare dei problemi in presenza di strumenti di pianificazione. Le applicazioni BPC utilizzano una tipologia particolare di infocubi detta real time. Un infocubo real time rende possibile la lettura e la scrittura simultanea di dati da parte di utenti diversi. Proprio questa peculiarità lo rende particolarmente adatto per l’utilizzo all’interno di contesti di pianificazione in cui i vari utenti possono avere la necessità di scrivere i dati di propria competenza in maniera simultanea sul cubo di pianificazione. Gli infocubi rappresentati nella parte in basso a destra della figura sono invece di tipo standard, e vengono utilizzati per la reportistica di altre aree aziendali.
• Data store object (DSO): Le strutture di staging dedicate all’applicazione, rappresentate in figura da dei cilindri azzurri, sono state implementate utilizzando dei Data store objects (convenzionalmente identificati tramite l’acronimo DSO). Un DSO è una struttura dati sulla quale è possibile eseguire delle query bex e specificare dei campi chiave. Nella sua versione standard consente di immagazzinare i dati all’interno di due tabelle distinte: una tabella contiene i dati attivi, che sono disponibili per il reporting; la seconda tabella contiene i record pervenuti per mezzo di trasferimenti dati ma che non sono ancora stati inclusi nel processo di attivazione. Eseguendo il comando di attivazione dei dati, i record selezionati vengono eliminati dalla tabella dei dati appena caricati e vengono inclusi nella tabella dei dati attivi. I DSO presenti nel livello superiore illustrato in figura sono di questa tipologia.
Una seconda tipologia di DSO, utilizzata nel livello inferiore delle strutture illustrate in figura, è detta Data store object for direct update. I DSO di questa
35
tipologia contengono la sola tabella dei dati attivi e dunque non è necessario eseguire alcun comando di attivazione prima di poter usufruire dei dati trasferiti. La scelta di questa tipologia di DSO per il primo livello di immagazzinamento dei dati è dovuta ad un vincolo tecnico: lo strumento utilizzato per l’estrazione dei dati (APD), che sarà descritto in seguito, consente di scrivere le informazioni solamente su DSO appartenenti alla seconda tipologia illustrata.
• Transformation: I simboli a forma di clessidra rovesciata di colore verde rappresentati in figura rappresentano quelle che su SAP BW vengono chiamate transformation. Le transformation, collocate tra una sorgente e una destinazione dati, consentono di effettuare operazioni di consolidamento, pulizia ed integrazione delle informazioni.
Esse sono costituite da una serie di transformation rules che permettono di trattare i dati in diversi modi. È possibile effettuare delle mappature dirette tra i campi della sorgente e quelli della destinazione lasciando inalterati i valori, applicare ai dati delle formule standard (che possono essere, ad esempio, formule matematiche o di manipolazione di stringhe). Si ha anche la possibilità di utilizzare delle routine scritte in codice ABAP, il linguaggio proprietario di SAP, in modo da eseguire operazioni più complesse che necessitano di un livello più elevato di personalizzazione.
Ad una transformation vengono associati uno o più Data transfer process (DTP). Un DTP determina come i dati vengono trasferiti da un oggetto all’altro. È possibile definire dei filtri sulle informazioni da trasferire ed ipotizzare una schedulazione del processo di trasferimento con cadenza, ad esempio, giornaliera o settimanale.
Il processo può essere inoltre impostato per essere eseguito in qualsiasi momento tramite la semplice esecuzione del comando di avvio.
• Analysis process designer (APD): Un analysis process designer (solitamente abbreviato in APD) è un workbench che consente di creare, eseguire e monitorare dei processi di analisi. È possibile reperire dati da diverse sorgenti, eventualmente combinandole, eseguire operazioni di trasformazione del dato, presentare i
36
risultati tramite strumenti di reporting o scrivere l’output direttamente su delle strutture dati o su dei file.
• Data source: Un data source è un insieme di campi dati, con tipo e lunghezza accuratamente definiti, utilizzato per alimentare una struttura BW a partire da una sorgente dati esterna. Nel caso rappresentato in figura la sorgente esterna è costituita da un file di tipo CSV.
• Process Chain: Una process chain è un insieme di processi che attende in background l’esecuzione di un evento. Esse contengono un processo di start che consente di dare il via all’esecuzione di una serie di altri processi relativi alle varie categorie di operazioni effettuabili sul data warehouse. Lo start della catena può essere azionato in maniera manuale o essere schedulato per un determinato orario e secondo una determinata cadenza temporale.