Il Power Cube “CAPPISA_Power_Cube”Il Power Cube “CAPPISA_Power_Cube” 6

(1)

6

Il Power Cube “CAPPISA_Power_Cube”

Affrontiamo in questo capitolo, i principali aspetti che sono stati indagati relativamente al processo di creazione del Power Cube relativo al modello Transformer discusso nel capitolo precedente. Tali aspetti riguardano la scelta di opportune configurazioni con l'obbiettivo di garantire buone prestazioni del processo di creazione che abbiamo,in parte, dovutamente già affrontato per modellare il nostro cubo. Nel seguito di questo capitolo, verrà mostrato il modello Transformer del secondo Power cube creato, “CAPPISA_Classi_fatturato”, che è stato disegnato perseguendo le stesse linee guida precedenti e pertanto non verrà ulteriormente approfondito. In maniera analoga, trattandosi di un modello che ricalca, se pur parzialmente, il modello “CAPPISA_Power_Cube”, le considerazioni fatte riguardo il processo di creazione ed ottimizzazione del cubo sono equivalenti.

6.1 Che cosa è un Power Cube

Un Power Cube è una particolare struttura contenente due principali gruppi di valori: metadati e dati. I metadati rappresentano informazioni sui dati di carattere strutturale come dimensioni, categorie, drill down path, descrizioni testuali, ed informazioni sulle proprietà delle misure. I dati rappresentano invece valori numerici associati alle misure oppure espressioni di testo, come i nomi (labels)

(2)

associate alle categorie. Nel gruppo relativo ai dati sono contenti gli indici, alcuni dei quali collegano i valori delle misure con le categorie. Il Power cube è creato attraverso una complessa strategia di compressione dati che si avvale dell'utilizzo di sofisticati indici (bitmap index) che permettono di ottimizzare la performance nel recupero dei dati. Nei tradizionali modelli OLAP, un cubo contiene valori pre- aggregati per tutte le categorie del modello e ciò comporta un aumento significativo delle dimensioni rispetto ai dati di input; inoltre, i tempi di creazione della struttura multidimensionale sono molto più lunghi poiché l'aggregazione dei valori è calcolata a build time, cioè durante il processo di creazione del cubo stesso. La dimensione finale del Power Cube invece è notevolmente ridotta rispetto alla dimensione dei dati sorgenti grazie ad una efficiente tecnologia di compressione, unita ad una architettura che consente il calcolo dei valori aggregati (rollups) a run time; in questo modo, non prevedendo il calcolo di valori pre-aggregati a build time, il tempo di creazione del cubo risulta decisamente più rapido.

6.2 Query Timing Control

La fase di lettura dei records relativi ai file sorgenti (data read) è, come abbiamo detto in precedenza, una fase critica dell'intero processo di creazione del cubo, e la prima scelta implementativa condotta per ridurre il volume dei dati di input è stata quella di creare sorgenti dati distinte per ognuna delle dimensioni del modello, mantenendo una separazione tra i dati sorgenti strutturali e transazionali. Transformer permette di controllare il processing dei dati agendo su una delle proprietà delle file IQD sorgenti (timing). La finestra relativa a questo controllo è raffigurata in Figura 6.1 e la prendiamo in considerazione solo ora perché più consona, secondo il nostro punto di vista, all'argomento che stiamo trattando.

(3)

Questo controllo permette di includere od escludere, un determinato file sorgente dai processi di generazione delle categorie (Generate Categories) e creazione del Power cube (Power Cube Creation).

Figura 6.1 Timing control relativo al file sorgente Magazzini.iqd

La generazione delle categorie è un processo svolto nell'ambito del processo di creazione del cubo, in particolare nella fase di update dei metadati; questo comportamento di default può essere modificato riservando ad esempio un subset di file sorgenti esclusivamente per il processo di generazione delle categorie, escludendolo dall'intero processo di creazione del cubo. Il timing control dei file strutturali del nostro modello è stato settato per il popolamento iniziale delle categorie: le informazioni contenute in questi file non hanno quella caratteristica di “volatilità” tipica dei valori numerici, bensì sono informazioni pressoché statiche,

(4)

quindi utilizzabili per la costruzione dell'infrastruttura multidimensionale del modello. A questo punto, il modello Transformer popolato con le categorie risulta privo solo esclusivamente delle misure, i cui valori sono contenuti nelle colonne del file transazionale. Questi valori sono altamente dinamici ed in continuo cambiamento e quindi necessitano di essere aggiornati ogni volta che il Power cube viene costruito. Per questo, il timing control del nostro file transazionale (Figura 6.2) è stato settato per essere elaborato durante il processo di creazione del cubo.

Figura 6.2 Timing control relativo al file Vendite_Acquisti.iqd

L'impiego di questo controllo permette nella pratica di isolare il processo di generazione delle categorie dal processo di creazione de cubo, evitando quindi l'elaborazione dei file strutturali che risulterebbe ridondante e costosa in termini di tempo. Il Power Cube è quindi generato da Transformer con tempi più rapidi ed è sempre possibile agire sui controlli dei file sorgenti per impostare il comportamento del programma nei loro confronti; qualora alcune informazioni strutturali del

(5)

modello siano soggette a cambiamenti per un certo periodo di tempo, è necessario che le categorie relative a questi dati vengano aggiornate durante il processo di creazione del cubo impostando il timing control nella configurazione di default.

Riportiamo in Figura 6.3 il diagramma relativo alla struttura gerarchica delle categorie della dimensione Periodo; attraverso questo preview è stato possibile valutare la correttezza del risultato del processo di generazione delle categorie ancor prima di creare il Power Cube. Questo tool infine permette di modificare la struttura ottenuta attraverso l'eliminazione di categorie esistenti o l'inserimento manuale di nuove categorie; nel nostro lavoro, abbiamo mantenuto la struttura integralmente così come generata da Transformer poiché non sono state riscontrate anomalie.

.

Figura 6.3 Diagramma delle categorie per la dimensione Periodo

Root category

Drill category

Category

(6)

Per completezza, riportiamo nelle Figure 6.4 e 6.5 il diagramma delle categorie generate per le dimensioni Gruppi Merceologici ed Agenzia.

Figura 6.4 Diagramma delle categorie per la dimensione Gruppi Merceologici

Figura 6.5 Diagramma delle categorie per la dimensione Agenzia

Primary Drill Down Path

(7)

Prima di parlare dei metodi di ottimizzazione che mette a disposizione Transformer per il processo di creazione del cubo, descriviamo, se pur brevemente, il secondo modello Transformer di Power Cube sviluppato ed un report Impromptu che verranno utilizzati per mostrare l'utilizzo nella funzionalità di Drill Through offerta da Transformer.

6.3 Drill Through cube-to-cube:

Il modello Transformer “CAPPISA_Classi_Fatturato”

L'interfaccia del modello Trasformer “CAPPISA_Classi_fatturato” è riportato qui di seguito in Figura 6.6. La Mappa delle Dimensioni si compone di 3 dimensioni regolari e di una dimensione temporale, aventi caratteristiche simili a quelle già in

(8)

precedenza analizzate per il modello “CAPPISA_Power_Cube”. La dimensione

Periodo presenta un livello intermedio Quadrimestre generato automaticamente da

Transformer e che abbiamo scelto di mantenere per permettere analisi OLAP su scenari temporali diversi. Per questo livello di aggregazione, che avevamo soppresso nel modello precedente poiché non ritenuto particolarmente utile, abbiamo provveduto a rinominare opportunamente le categorie generate dal programma (scegliendo degli identificativi più intuitivi), agendo direttamente sul diagramma della struttura gerarchica al termine del processo di generazione delle categorie stesse (Figura 6.7).

Figura 6.7 Diagramma delle categorie della dimensione Periodo del modello

CAPPISA_Classi_fatturato

Le categorie circondate in rosso sono quelle che sono state rinominate; le altre categorie evidenziate in verde non sono state modificate, ma potrebbero essere oggetto di future personalizzazioni per i report OLAP che l'utente può generare attraverso Power Paly in ambiente Windows. Per le categorie dei livelli Nome

(9)

articolo e Classi sono state definite, in ambiente Impromptu, opportune espressioni

condizionali per le colonne sorgenti che riportiamo nelle figure seguenti (Figura 6.8 e Figura 6.9) unitamente ai rispettivi diagrammi ottenuti dal processo di generazione delle categorie. Anche in questo modello, siamo ricorsi al timing

control dei file sorgenti in modo del tutto analogo a quanto discusso in precedenza,

per popolare la struttura multidimensionale con i valori estratti dai file strutturali per poi completare, con il file transazionale Performance_vendite.iqd, la creazione successiva del cubo.

Figura 6.8 Diagramma delle categorie per la dimensione Gruppi Merceologici

del modello CAPPISA_Classi_fatturato

Primary Drill Down Path

(10)

Figura 6.9 Diagramma delle categorie per la dimensione Classi del modello

CAPPISA_Classi_fatturato

L'ultimo particolare che prendiamo in esame per questo modello, è la misura

Numero clienti: si tratta del valore numerico relativo al numero dei soci clienti che

effettuano un particolare acquisto; le tipologie di acquisto sono suddivise in classi di fatturato per le quali abbiamo definito i range di valori mostrati in Figura 6.9. Per definire correttamente questa misura, abbiamo definito colonne aggiuntive nel report Impromptu iniziale per il conteggio dei records relativi ai clienti, successivamente, alla luce dei scarsi risultati ottenuti, abbiamo tentato l'utilizzo di particolari funzioni di raggruppamento che hanno portato agli stessi risultati deludenti a causa dell'estrema pesantezza dell'interrogazione formulata che hanno

(11)

comportato tempi di attesa intollerabili. Questa scelta è stata propriamente abbandonata poiché è stato sufficiente definire questa misura come una Category

Count Measure dal pannello delle proprietà delle misure, vale a dire una misura

attraverso la quale Transformer effettua il conteggio delle categorie del livello selezionato. In Figura 6.10, riportiamo la definizione di questa tipologia di misura che non avevamo previsto, per scopi diversi, nel modello di Power Cube trattato in precedenza.

Figura 6.10 La Category Count Measure Numero Clienti

Come vedremo nel prossimo capitolo, il percorso di navigazione dei dati multidimensionali di un Power Cube può essere intrapreso dall'utente in una sessione OLAP distinta, oppure “passando” attraverso i dati di un altro Power cube, mantenendo attiva la sessione OLAP corrente in Power Play. Si tratta di una funzionalità aggiuntiva (Drill Through) a cui abbiamo fatto ricorso nel nostro lavoro per sincronizzare i modelli di Power Cubes creati, con lo scopo di offrire all'utente la possibilità di aumentare la visibilità dei dati che sta esplorando. Power

(12)

Play utilizza particolati filtri in grado di estrapolare il contenuto informativo della stessa categoria che stiamo esaminando dall'altro Power Cube, visualizzandolo contestualmente in un nuovo report. Per compiere questa operazione, è necessario che i codici delle categorie delle dimensioni siano univoci (corrispondono ai valori numerici che abbiamo estratto dal Database aziendale attraverso i file IQD e che rappresentano univocamente le singole entità nel contesto aziendale). In ogni caso, la sovrapposizione tra l'insieme delle dimensioni non deve essere necessariamente totale (come nel nostro caso) in modo tale che attraverso il drill through si possa estendere sia il panorama di esplorazione dei dati (lo stesso dato può essere analizzato sotto le altre prospettive relative all'altro Power Cube), che quello relativo alle misure. La funzionalità di Drill Through è stata impostata dal pannello delle proprietà del Power Cube “CAPPISA_Power_Cube” come mostrato in Figura 6.11.

(13)

6.4 Drill Through to Impromptu: i

6.4 Drill Through to Impromptu: il report “Omaggi”

l report “Omaggi”

Abbiamo creato in ambiente Impromptu un report per l'estrazione dei dati relativi agli omaggi offerti ai soci del Consorzio Agrario nel triennio 2005-2006-2007. Il report Omaggi è stato impiegato per abilitare la funzionalità di drill through nel Power Cube “CAPPISA_Classi_fatturato” (Figura 6.12), in modo tale da poter disporre contestualmente dei dati relativi agli acquisti effettuati dai soci clienti per classi e di quelli relativi agli eventuali omaggi di cui ha usufruito.

Figura 6.12 Drill Through to Impromptu in Transformer

A differenza del caso precedente, il drill through verso un report Impromptu consente di ottenere dettagli aggiornati in tempo reale con i dati residenti nel Database, che possono essere presi in esame con i dati storici memorizzati all'interno del cubo. Il report Omaggi è stato creato con l'obbiettivo principale di

(14)

mettere in luce una funzionalità drill through alternativa offerta da Transformer, con un lieve occhio di riguardo alla presentazione del report se pur non strettamente necessaria. In Figura 6.13, è riportato l'output del report generato e l'espressione del filtro impostato; il filtro relativo all'importo dell'omaggio (forma circolare verde in figura) è stato necessario secondo il nostro punto di vista per escludere l'estrazione di valori nulli che il Database aziendale contiene al suo interno. Questo particolare è stato oggetto di indagini successive per i responsabili del CED.

(15)

Il Drill Through to Impromptu completa la descrizione dei due modelli di Power Cube che abbiamo trattato; dal prossimo paragrafo prenderemo in esame i principali metodi di ottimizzazione del processo di creazione del cubo.

6.5 L'ottimizzazione del processo di creazione

del Power Cube

In questo lavoro, abbiamo cercato di mettere in evidenza come la fase di modellizzazione del cubo abbia rappresentato un passo molto importante dell'intero processo di creazione, ed i fattori legati alla performance di Transformer nella generazione del nostro cubo sono stati il punto di riferimento di tutta la nostra trattazione. Le scelte implementative condotte fino a questo momento hanno permesso una sensibile riduzione delle dimensioni dei dati sorgenti: l'utilizzo di molteplici sorgenti di dati nelle modalità che abbiamo trattato è stata la prima scelta significativa che abbiamo affrontato per il contenimento dei tempi del processo di creazione del cubo. Infine, il Drill through to Impromptu, funzionalità nativa di Transformer, ha condotto la nostra attenzione sulla tipologia Impromptu Query

Definition per i file sorgenti dei modelli; le caratteristiche della strategia di join

implementata per le relazioni tra le tabelle del Catalogo “Statistiche Magazzino” hanno avuto un impatto positivo sia per l'elaborazione delle query SQL da parte di Transformer relativamente ai singoli file sorgenti IQD generati, sia per l'ultimo report Impromptu che abbiamo discusso (Omaggi). Le prestazioni del processo di creazione del cubo possono essere ulteriormente migliorate studiando i principali metodi di ottimizzazione offerti da Transformer. In Figura 6.14, riportiamo la finestra relativa alle proprietà del Power cube “CAPPISA_Power_Cube”, ed in particolare ai metodi di ottimizzazione disponibili (Processing tab). In generale, le

(16)

tecniche di ottimizzazione utilizzate da Transformer si basano su un particolare processo di frammentazione dei dati attraverso il quale un cubo dalle dimensioni importanti viene “partizionato” in una serie di sotto-cubi opportunamente collegati tra loro aventi dimensioni più contenute. Questo metodo, detto Partitioning in ambito Transformer, prevede quindi che i dati all'interno del Power cube vengano pre-aggregati e raggruppati successivamente in sezioni subordinate, dette appunto partizioni, in modo da ottimizzare la performance di Power Play nell'estrazione dei dati condotta a run time.

Figura 6.14 Metodi di ottimizzazione di Transformer

La strategia di partizione operata di default da Transformer (Auto-Partitioning) è quella che generalmente offre le migliori prestazioni raggiungendo un buon compromesso tra la riduzione del tempo di creazione del Power cube e l'incremento del tempo di accesso dei dati in Power Play. E' possibile comunque settare

(17)

diversamente i parametri relativi ai 3 controlli su cui si basa questa tecnica di partizione di default (Figura 6.15) per implementare una strategia personalizzata.

Figura 6.15 Auto-Partitioning di Transformer

Il primo controllo (Estimated number of consolidated records) specifica la stima del numero di records consolidati contenuti all'interno del cubo. Transformer opera un processo di consolidamento dei dati, combinando (aggregando) records he contengono valori identici (non numerici), riducendo la dimensione del cubo e permettendo un miglioramento dell'estrazione dei dati a run time. Il valore di default di questo controllo è di 10.000.000 records. Il secondo controllo (Desired

partition size) può essere utilizzato per settare la dimensione desiderata che si

intende riservare a ciascuna partizione all'interno del cubo; Transformer utilizza questo valore per selezionare le categorie del modello che soddisfano la dimensione specificata e che premettono di ottimizzare la performance delle query. La dimensione di default impostata da Transformer è pari al 5% del valore stimato

Slider Control Massima dimensione partizione 10.000.000 recors Minima dimensione partizione 100.000 records

(18)

relativo al primo controllo, e può essere incrementato fino al raggiungimento della soglia massima, pari al 100% del numero di righe stimato in precedenza, quindi coincidente con esso, o decrementato fino ad una valore minimo corrispondente all'1% del numero di records consolidati. Il valore numerico relativo alla dimensione desiderata può essere settato manualmente oppure agendo attraverso lo

Slider Control le cui estremità indicano la direzione verso la quale è orientata la

performance. Si tratta di due contesti diametralmente opposti: portando il controllo sull'estrema sinistra (massima dimensione della partizione), si ottiene un incremento nella performance del processo di creazione del cubo, a scapito di quella relativa all'accesso dei dati a run time in Power Play; viceversa l'estremo opposto (minima dimensione possibile per la partizione desiderata) massimizza la performance dell'applicazione Power play client degradando quella relativa al processo di costruzione del cubo. Per chiudere la panoramica di questi controlli, il terzo ed ultimo controllo del metodo Auto-Partitioning è quello relativo al massimo numero di livelli riservati al processo di partizione (Maximum number of passes). In pratica, il valore intero che può essere settato manualmente rappresenta il numero di volte che Transformer esegue la lettura dei dati sorgenti per il cubo durante il processo di partizione. Un aumento del numero di livelli di partizione comporta l'aggiunta di ulteriori passi per la lettura dei dati; generalmente, questo controllo può essere utilizzato per evitare che Transformer esegua un numero eccessivo di passi nel caso in cui la dimensione della partizione desiderata sia notevolmente inferiore rispetto al numero di records consolidati aggiunti al Power cube. Attraverso il metodo di ottimizzazione che stiamo esaminando, Transformer esegue il processo di creazione del cubo attraverso un algoritmo dinamico che si basa sull'utilizzo di particolari pesi (weight) per la scelta delle dimensioni candidate per il processo di partizione. Le dimensioni del modello che sono privilegiate sono quelle con più livelli e caratterizzate da un indice di parent/child ratio consistente nell'ambito dell'intera dimensione. Il parent/child ratio esprime il rapporto tra il numero di categorie di un livello e quello del livello parentale immediatamente

(19)

superiore. Successivamente, l'algoritmo assegna dinamicamente le categorie delle dimensioni scelte alle partizioni in modo che la loro dimensione equivalente si avvicini il più possibile a quella della partizione desiderata. Nel nostro lavoro, si è scelto di mantenere la strategia di partizione di default pur consapevoli della possibilità di settare i parametri discussi in precedenza per una strategia personalizzata. Come abbiamo detto, Transformer opera una strategia di partizione che generalmente offre il miglior compromesso in termini di performance; tuttavia, per cubi che hanno un numero di records superiore a 300.000, è possibile implementare una strategia manuale assegnando un determinato livello di partizione alla categorie del modello privilegiando quelle con un parent/child ratio elevato. In questo caso, è comunque buona norma valutare i benefici della strategia manuale rispetto a quella implementata di default da Transformer. Il numero complessivo di records del nostro primo Power Cube è circa 250.000,per cui, pur valutando interessante la possibilità di una partizione manuale, si è scelto di mantenere la strategia di default anche successivamente il processo di creazione del cubo. L'ottimizzazione dei dati sorgenti ha consentito ai nostri modelli il raggiungimento di performance soddisfacenti che ci hanno indotto a tralasciate una strategia di partizione manuale che potrebbe essere oggetto di indagini future prevedendo un possibile aumento significativo della dimensione del Power Cube.

Un altro metodo che abbiamo preso in considerazione è quello che permette di ottimizzare la produzione del Power Cube attraverso l'aggiunta esclusiva dei dati più aggiornati al cubo esistente evitando la ricostruzione totale del cubo. Questa tecnica, detta Incremental Update, permette notevoli miglioramenti nelle prestazioni poiché Transformer esegue l'aggiornamento dei dati in tempi molto più rapidi. Tuttavia, l'impiego di questo metodo non può essere considerato valido per tutto il ciclo di vita del Power Cube: le modifiche strutturali apportate al modello (nuove dimensioni, categorie,ecc..) invalidano l'update incrementale; Transformer viola la possibilità di utilizzo di questo metodo ogni volta che la struttura del

(20)

modello viene modificata segnalando un errore. In Figura 6.16, riportiamo la finestra delle proprietà del Power Cube relativamente alla tecnica Incremental

Update e le tipologie di dati valide per il suo utilizzo.

Figura 6.16 Incremental Update in Transformer

Per i nostri modelli di Power Cube, abbiamo settato l'aggiornamento incrementale solo successivamente ai processi di generazione delle categorie e di costruzione del cubo. Abbiamo mantenuto questo metodo non prevedendo modifiche strutturali importanti per i modelli sviluppati; tuttavia, si è tenuto conto dell'esistenza di un limite al numero di update che possono essere effettuati su di un cubo. Infatti, all'aumentare del numero di update eseguiti, le prestazioni della strategia di dell'auto-partitioning operata da Transformer tendono a degradare fino a raggiungere un costo pari a quello sostenuto per la costruzione iniziale del cubo

(21)

(Tabella 6.1). La tabella mostra il piano di attività (scheduling) che abbiamo preso come punto di riferimento; dopo il quarto update incrementale eseguito è opportuno ricostruire integralmente il cubo in modo da consentire un refreshing della strategia di partizione.

Step Attività

1 Costruzione iniziale del Power Cube

2 Incremental Update 1 sul passo 1

5 Incremental Update 4

6 Incremental Update 5

Tabella 6.1 Scheduling delle attività di Incremental Update

6.6 Scheduling Power Cube build process

L'aspetto più critico che abbiamo dovuto affrontare riguarda la scelta del periodo di tempo opportuno da dedicare al processo di creazione del Power Cube. Il traffico di dati sulla rete LAN aziendale ha raggiunto livelli in taluni casi talmente importanti da compromettere l'elaborazione in corso di Transformer. Transformer infatti deve estrarre i dati relativamente ai file sorgenti del modello attraverso l'esecuzione della query corrispondente ed accedendo al Database relazionale residente sul server aziendale, che registra quotidianamente un numero elevato di richieste provenienti sia dagli clients della rete interna che da hosts esterni (agenzie periferiche). Le

(22)

metodologie discusse per l'ottimizzazione del processo di costruzione del cubo hanno richiesto fasi di test per verificare l'effettivo beneficio in termini di riduzione del tempo impiegato per l'elaborazione complessiva. Tali prove sono state condotte schedulando il processo di creazione nelle ore notturne dove il traffico sulla rete aziendale è risultato notevolmente ridotto. A tal proposito, è stata realizzata una semplice macro utilizzando il linguaggio Visual-Basic like offerto dalla piattaforma COGNOS, e cioè il COGNOS Script language. In questo modo abbiamo potuto usufruire di un ulteriore strumento attraverso il quale è possibile automatizzare le proprie applicazioni di business intelligence. La macro (BUILD.mac) è stata scritta attracerso l'editor di COGNOS (COGNOS Script editor) e successivamente inserita nell'insieme dei task da eseguire richiamando l'interfaccia dello scheduler Transformer direttamente dal menù del modello del Power Cube, e programmando la sua esecuzione a partire dalle ore notturne (tipicamente 2.00 am, talvolta 23.00 pm). Riportiamo qui di seguito integralmente il codice della macro implementata.

'***Percorso file di log

Const LogFilePath = "C:\Cubi\log\" Const LogFileId= "creazione_cubo" Global LogFile as Integer

Global LogMsg as String

'***Dichiarazione sub-routine per i file di log Declare Sub OpenLogFile()

Declare Sub WriteLogFile() Declare Sub CloseLogFile()

'***** Creazione del file log con aggiunta della data Sub OpenLogFile()

LogFile = FreeFile

Open LogFilePath & LogFileId& "_" & Format$( Now,"dmmmyy_hhmmss" ) & ".log" For Output as LogFile

(23)

'**** Scrittura del file di log Sub WriteLogFile()

Print #LogFile, Format(Now, "dmmmyy hh:mm:ss") & " " & LogMsg End Sub

'***Chiusura file di log Sub CloseLogFile() Close LogFile End Sub

'*** Programma principale Sub Main ()

On Error Goto Error_Routine Dim objTrans as Object Dim objModello as Object Dim objCubo as Object Dim strNomeModello as String Dim strMdlPath as String Dim strMdcPath as String Dim strMdcBuildPath as String Dim strBackupPath as String Dim strLogPath as String Dim strModello as String Dim strCubo as String Dim strCuboExt as String Dim strCuboNome as String Dim Data as Variant

Dim Nome_Macro as String

'***Nome della macro che appare nel file di log Nome_Macro= "BUILD"

OpenLogFile

LogMsg = "Inizio esecuzione di " & Nome_Macro& "." WriteLogFile

(24)

'***Dichiarazione dei path *** strMdlPath = "C:\Cubi\" strMdcPath = "C:\Cubi\" strMdcBuildPath = "C:\Cubi\temp" strBackupPath = "C:\Cubi\backup\" strLogPath = "C:\Cubi\log\" strNomeModello = "CAPPISA_Power_Cube" strCuboExt = ".mdl" strCubo = "CAPPISA_Power_Cube"

strModello = strMdlPath & strNomeModello & strCuboExt

LogMsg = "Inizio del processo di creazione del cubo " & strNomeModello & "." WriteLogFile

'***Apertura modello con PowerPlay Transformer... ***

Set objTrans = CreateObject ("CognosTransformer.Application") With objTrans

.LogFilesPath = strLogPath

.PowerCubesPath = strMdcBuildPath .ModelsPath = strMdlPath

End With

Set objModello = objTrans.OpenModel(strModello) Set objCubo = objModello.Cubes.Item(1)

'*** Creazione del cubo *** objCubo.CreateMDCFile objModello.Close Set objCubo = Nothing Set objModello = Nothing Set objTrans = Nothing

(25)

creazione del modello." WriteLogFile

Data = CVar(Date)

strCuboNome = strCubo & "_" & Format(Data,"Medium Date") & ".mdc"

LogMsg = "Copia del cubo esistente nella cartella di backup con la data appesa al nome.." WriteLogFile

FileCopy strMdcPath & strCuboExt, strBackupPath & strCuboNome

LogMsg = "Copia del cubo esistente eseguita nella cartella di backup con la data appesa al nome."

WriteLogFile Goto Finish Error_Routine:

LogMsg = "ERRORE RILEVATO: '" & Err & "-" & Error & "' durante l'esecuzione del processo." WriteLogFile

CloseLogFile Exit Sub Finish: End Sub