Nella figura 7.10 è rappresentata l’architettura dell’applicativo Hyperion Cash Flow Ma- nagement. Questo sistema si suddivide in due fasi distinte. Una prima riguarda il processo "Flusso CBI" che si occupa di elaborare giornalmente i dati di consolidato che giungono da una banca. Al termine di questo processo i dati vengono caricati nell’am- biente di raccolta dati come mostrato in figura 7.2 . Questo sistema, a differenza del
Figura 7.9: Frammento del Batch di importazione all’interno di BP dei dati di contabilità
precedente, non prevede l’inserimento di dati di input da parte dell’utente che invece può soltanto effettuare analisi sui dati di output.
Il processo del Flusso CBI viene eseguito con un file batch schedulato. Al suo interno il batch presenta nel seguente ordine:
• L’esecuzione del flusso SSIS Load Process; • L’esecuzione del flusso SSIS Output Process; • L’esecuzione del flusso SSIS Hyperion upload. Successivamente sono dettagliate le tre esecuzioni.
Figura 7.10: Architettura applicativo Cash Flow Management
Il Flusso CBI è stato realizzato utilizzando l’applicativo SSIS di SQL Management Studio. In figura 7.11 si possono visualizzare tutte le fasi del processo. Il primo oggetto utilizzato si occupa di ricercare in una determinata cartella i file che contengono il nome "*CBI*.*" e importarli in una tabella del database. Se il flusso all’interno dell’oggetto termina correttamente, si prosegue con l’oggetto "Execute SQL Task" che prende in in-
put una procedura e manipola i dati caricati precedentemente al fine di ordinarli secondo determinate impostazioni. Nella figura 7.12 è visualizzabile la procedura in cui vengono
Figura 7.12: Execute SQL Task con il File Procedure
convertiti i dati presenti nel file CBI e impostati suddividendo le informazioni tra: Ti- pologia di operazione, conto corrente, data, saldo, ecc. L’oggetto LoadHB si occupa di ricreare delle tabelle di staging e calcolare i valori presenti all’interno del file inputato inizialmente e viene generata una tabella nel database con all’interno tutti i dati da ca- ricare.
CustomHB si occupa della gestione degli scarti prima che i dati vengano inseriti all’inter- no della tabella di output. Infatti i dati necessitano di una verifica di consistenza prima del termine del processo in quanto può capitare che un conto corrente possa essere stato inserito in modo non corretto o che una banca o causale nuova possano essere stati inse- riti all’interno del file. In tal caso, i dati non conformi vengono scartati e nella fact-table sono inseriti solo i rimanenti.
L’ultimo oggetto SSIS di questa procedura è After Import Banca. Se non sono stati generati scarti di dati non corretti nel processo precedente, allora anche quest’ultimo oggetto avrà esito positivo.
Nella figura 7.13 è possibile visualizzare il processo interno all’oggetto After import banca. All’interno è presente una query che effettua un count nella tabella degli scarti e verifica se il risultato è maggiore di zero. In caso affermativo, il file CBI non viene spostato nella cartella di fine processo ma viene inviato al reparto IT del cliente che si occuperà di sistemare l’anagrafica al fine di poter procedere nuovamente al caricamento il giorno
Figura 7.13: Oggetto finale di verifica correttezza dati
successivo. In figura 7.14 è mostrato il processo che si occupa di estrarre le informazioni
Figura 7.14: Estrazione dei dati dal Flusso CBI per il caricamento su Hyperion
dalle viste create sul DB SQL Reply e importarle successivamente nell’applicativo Oracle. Per questo processo è stato utilizzato diverse volte l’oggetto extract file che ha permesso di definire le colonne utili e la codifica di esse e di scrivere i dati su file txt. Il processo inizia dall’estrazione dei dati di anagrafica di società, conti corrente e causali; terminata l’anagrafica si procede estraendo per ogni singolo conto il totale dei movimenti nel mese
e il totale dei saldi. Le ultime due estrazioni riguardano gli ultimi dieci saldi e i dati scartati.
Figura 7.15: Caricamento dei dati su Hyperion Cash Flow Management
In figura 7.15 è rappresentata l’ultima esecuzione del file batch. Al termine dell’e- strazione dei dati, l’ultimo step prevede che essi vengano caricati sui sistemi Oracle per permettere successivamente all’utente di effettuare delle analisi e stilare dei report. Non essendo connessa l’anagrafica presente nel DB SQL e quella sul DB Essbase di Hy- perion, il processo necessita di un ulteriore controllo di consistenza dei dati. Per definire i possibili errori che potrebbero verificarsi durante il caricamento, è stato deciso di suddi- vidire il caricamento dei dati in quattro differenti step. Ognuno ha due percorsi possibili. Se il caricamento giunge a buon fine allora si procede con lo step successivo, altrimenti il sistema si blocca e l’oggetto error invia una mail predefinita all’utente coinvolto nel- l’errore.
Seguendo il processo in figura si parte con il caricamento dei dati di anagrafica per poi proseguire con il caricamento del file dei movimenti, saldi e ultimi dieci saldi. Se tutto il caricamento è andato a buon fine, una mail di conferma è inviata al reparto IT.
In figura 7.16 è rappresentata un’estrazione di batch che è all’interno dell’oggetto Carica- mento Anagrafiche. Primo step riguarda l’eliminazione dei precedenti file di anagrafica a
cui segue l’upload dei nuovi file e quindi il caricamento dei soli dati mancanti. Al termine viene eseguito un deploy del cubo ed il processo termina.
Figura 7.16: Flusso batch per upload dati di consolidato
L’output del sistema è la realizzazione del report dei saldi che viene inviato ogni mattina al termine del processo al controller di riferimento. Questo file ingloba al suo interno tutte le informazioni che sono state processate nel sistema appena analizzato. Mostra nella prima colonna i dati del fondo immobiliare di riferimento, nella seconda i conti correnti connessi ad ogni singolo fondo e nelle successive il saldo giornaliero per ogni conto corrente.