Architettura di OBIEE 11g

Per capire cosa sta alla base dell’architettura di Oracle BI, è necessario con- siderare brevemente l’architettura generale in cui Oracle inquadra i propri prodotti. Come esplicitato in [Khan et al., 2012], negli ultimi anni la socie- tà ha acquisito numerose altre aziende produttrici di software ottenendo il controllo di molteplici sistemi per la gestione di dati. Tuttavia, al fine di garantire l’interoperabilità tra le diverse tecnologie e permettere che queste interagiscano in modo efficiente tra loro e con il DBMS (ancora prodotto principale e originario della società), sono stati fatti sforzi volti alla defini- zione di un livello intermedio che si inserisce tra quello dei database e quello applicativo (Fig. 5.6).

Figura 5.6: Stack dei prodotti Oracle

Il principale risultato di questo proposito è la creazione di Fusion Midd- leware, un framework destinato a realizzare il livello per l’interoperabilità suddetto e facilitare l’interfacciamento anche con prodotti di altri venditori. Non ci si sofferma su dettagli relativi a Fusion Middleware, in quanto non interessanti per i nostri scopi, se non per introdurne un componente impor- tante: WebLogic, un server per applicazioni Java EE, fondamentale per il funzionamento di OBIEE ed altre applicazioni.

Nella Figura 5.7 sono mostrati i componenti che compongono l’architet- tura complessiva della piattaforma di business intelligence, all’interno della quale si distinguono:

• Dominio WebLogic Server. È l’insieme dei componenti Java EE distribuiti come applicazioni ed eseguiti su server WebLogic. Tali componenti sono suddivisi tra differenti istanze di WebLogic:

– l’Admin Server, istanza che contiene i componenti indispensabili per il funzionamento del dominio e di OBIEE all’interno di esso,

Figura 5.7: Architettura di Oracle BI

cioè l’Admin Console, destinata alla configurazione del sistema, alla gestione di tutte le applicazioni distribuite e di aspetti le- gati alla sicurezza, e il Fusion Middleware Control (anche noto come Enterprise Manager ), che consente di gestire i componenti di sistema, citati più avanti;

– i Managed Server, di fatto istanze contenitori per le applicazioni non amministrative, ognuno raggiungibile dall’esterno attraverso una specifica porta;

– Node Manager, non una vera e propria istanza ma un modulo del dominio il cui ruolo diventa fondamentale nel momento in cui si scala orizzontalmente il sistema su più server fisici, ad esempio con un nodo master contenente l’istanza amministrativa e altri nodi destinati alla distribuzione delle applicazioni.

• Istanza BI. Racchiude i componenti di sistema, prevalentemente svi- luppati in C++, che costituiscono il vero core della piattaforma, realiz- zandone le funzionalità caratteristiche; i più interessanti sono descritti più dettagliatamente nei paragrafi successivi.

• Strutture di archiviazione. Si tratta di file e database contenenti informazioni necessarie al funzionamento di OBIEE o generate dalla piattaforma stessa. Tra i componenti più importanti si introducono l’RPD, destinato a contenere la definizione del modello dei dati, e il Presentation Catalog che contiene i dashboard creati e, in generale, tut- ti gli oggetti prodotti per la rappresentazione grafica dei risultati. La

maggior parte dei metadati necessari al funzionamento dell’istanza BI è contenuta in due schema di database (non necessariamente Oracle), MDS e BIPLATFORM, creati automaticamente tramite una utility al momento dell’installazione.

Figura 5.8: Interazione tra i componenti di Oracle BI

Per comprendere più facilmente i ruoli svolti dai diversi componenti è possibile osservare nella Figura 5.8 come avviene una tipica interazione con il sistema e tra i diversi moduli:

1. L’utente interagisce con il sistema attraverso un’interfaccia grafica ba- sata sul web, il client è pertanto rappresentato da un web browser e le interazioni hanno l’effetto di invocare richieste HTTP[S] verso un web server.

2. Il web server redireziona le richieste a webLogic che individua l’applica- zione destinataria, in questo caso il plugin Java di BI che serve ad espor-

re i componenti di sistema (NB: il server web può essere rappresentato da WebLogic stesso, in tal caso il primo passaggio è evitato).

3. Il plugin comunica la richiesta, utilizzando un protocollo proprietario basato su XML, al componente di sistema BI Presentation Services im- plementato in C++; ci si riferisce al componente con il temine services, in quanto è prevista la possibilità che le sue funzioni siano svolte da più istanze che condividono il carico di lavoro. Tali funzioni sono generare le pagine per l’interfaccia utente, invocare le necessarie interrogazioni sui dati e, viceversa, tradurre graficamente i risultati ottenuti. Per assolvere questo compito il modulo comunica principalmente con:

• il Presentation Catalog, una struttura che memorizza su disco, tramite file XML, la struttura di dashboard, analisi, filtri, prompt ed altri oggetti precedentemente realizzati e salvati dagli utenti; • il BI Server, a cui sono inviate le interrogazioni sui dati, per le

analisi in tempo reale o derivanti dalla richiesta di caricamento degli oggetti suddetti.

4. Il BI Server si occupa della manipolazione e aggregazione dei dati pro- venienti dalle sorgenti di dato ed espone un’interfaccia per richieste formulate in un linguaggio di livello più alto rispetto all’SQL, deno- minato SQL logico. Una volta ricevuta una query dal componente di presentazione, la traduce in una o più interrogazioni da inviare al- le sorgenti coinvolte (query SQL nel caso di database relazionali) ed esegue alcune manipolazioni aggiuntive, ad esempio quelle necessarie a connettere le diverse fonti.

Il modo in cui svolgere queste operazioni è definito dal modello dei dati specificato dall’amministratore e memorizzato nel repository dei metadati (RPD). Il BI Server può inoltre fare uso di una memoria cache per riciclare i risultati ottenuti dalle query e migliorare le prestazioni.