OBIEE 11g Architecture: What You Need to Know

obiee 11g architectureOBIEE is an acronym for Oracle Business Intelligence Enterprise Edition. Business intelligence refers to the various activities that a firm does to collect information about their market or their competitors. Oracle Business Intelligence Enterprise Edition refers to Oracle Corporation’s set of business intelligence tools comprising of former Siebel Systems business intelligence and Hyperion Solutions business intelligence products/services. In this intermediate level tutorial we walk you through the OBIEE Architecture. We assume that you know the basics of databases, if not, you can learn database concepts and design with this course. 

OBIEE Architecture

The entire system architecture is known as BI Domain. The BI domain consists of Java components and non-Java components. Note that Java components are Weblogic server domain components. Non-java components are Oracle BI system components.

  • Weblogic Server Domain

It consists of Managed server module and Admin server module. These services have the Java modules to trigger the Java services.

  • Admin Server

This module contains Java components for administering the system. It is responsible to trigger the start, stop kind of admin activity for the peer Manager server processes.

  • Managed Server

This module provides the run-time environment for the Java-based services and applications within the system. The services include SOA, Security, Publisher, BI office services, BI plugin and more.

  • Node Manager

It is a distinct and separate Java utility. The node manager is responsible for providing processes management services to the Admin server and Managed server. This module triggers the auto start, stop and restart activities.

  • OPMN( Oracle Process Manager and Notification server).

It is used to start and stop all system components of BI.

  • Oracle Weblogic Server

This is a Java EE application server which provides support for the deployment of Oracle BI Java components.

  • Fusion Middleware Control

This is a browser based tool used to monitor, manage and configure Oracle Business Intelligence components.

  • Java Components

They are deployed as Java EE applications.

  • Administrative components

JMX MBeans and Enterprise management applications manage all configurations and run time settings for Oracle BI.

  • Oracle BI Publisher

This helps author, manage and deliver all types of highly formatted documents to employees, customers and suppliers.

  • Oracle BI Office

This helps integrate Oracle BI and MS Office products.

  • Oracle BI Action Services

This helps the Action framework and aids an administrator to manually configure which Web service directories can be browsed by users upon their creation of actions.

  • Oracle RTD(Real Time Decisions)

This component helps companies to make better decisions in real time with its enterprise analytics software solutions.

  • Oracle BI security services

This helps the integration of the Oracle BI server with the Oracle fusion middleware security platform.

  • Oracle BI SOA Services

These enable objects in the Oracle BI presentation catalog to invoke analysis, agents and conditions. Also facilitates the process to invoke Orcale BI functionality from BPEL(Business Process Execution Language) processes.

  • Oracle BI Plugin

This routes HTTP and SOAP(Simple Object Access Protocol) requests to Oracle BI presentation services.

  • System Components

These are deployed as non-JEE components such as processes and services created in C++ and J2SE.

  • Oracle BI Server

It provides significant query and data access capabilities. Also provides support to access and manage the enterprise semantic model.

  • Oracle BI Presentation Services

This is responsible to provide the framework and interface in order to present business intelligence data to web clients.

  • Oracle BI Scheduler

It supports extensible scheduling for analysis to be delivered to users at specific times.

  • Oracle BI JavaHost

It helps Oracle BI presentation services to support Java tasks for Oracle BI scheduler, Oracle BI publisher and graph generation.

  • Oracle BI cluster controller

It distributes requests to the BI server which results in requests to be evenly load-balanced across all BI Server process instances in the BI domain. You can get a better understanding of how OBIEE works with this basic course.

Guidelines for Repository Design in OBIEE

We’ll go through the details of how to design your OBIEE repository. Before you proceed, we would recommend you take this introductory course on Oracle Database administration to get a feel of Oracle DB. We recommend that you create aliases for all the physical tables, ideally prefixed with either “Dim_”, “Fact_” or “Fact_Agg_.” Whenever possible you should configure the connection pools to use a “native driver” instead of ODBC (Open Database Connectivity) to connect to the physical databases. Ensure that the Max Connections parameter in your connection pools is neither too high nor too low. To give the value you can use the formula given below. Note that the formula assumes that the maximum number of users logged on and running a report at any point of time would be 4%.

Max Connections = Total Users * 0.04 * Max Reports on a Dashboard

All logical tables should be prefixed with either “Dim-“, “Fact-” or “Fact Compound-“.   Physical primary keys or Surrogate keys should not exist on the Business Model layer. The column names on the Business Model layer should be suggestive of business rather than any physical entity. For instance, use “$Profit” rather than “DOLLARS”. A Logical Key must always be assigned to dimension logical tables. Note that the Logical Key should be suggestive of business. For instance use “Employer Login” instead of “EMPLOYER_PK”. Only dimension attributes should be contained in dimension logical tables. Note that logical key should never be assigned to fact logical tables.

An aggregation rule should be assigned to every logical column within a fact logical table. The Business model should be restricted to logical star-schemas. Every Dimension Table must have a corresponding Dimension Hierarchy. Also each level of a dimension hierarchy should have appropriately set “Number of Elements.” Whenever there is no existing logical relationship, the “Content Level” is not set for a particular dimension. You should not merge all your measures into a single Fact Logical Table. For instance, split “Actual Sales” and “Forecasted Sales” into two Logical Tables e.g – “Stats-Sales” and “Stats-Forecasted”.

In case of multiple subject areas list the common dimensions in the same order across all the Subject Areas. A user should not be able to select objects from a Subject Area that have no logical relationship.Within each Subject Area, presentation Table names must not begin with “Dim-“, or “Fact-” or “Fact Compound-“.

Do remember that OBIEE is a vast topic. We’ve just covered the basics here. If you’d like to get a more in depth understanding of OBIEE you can take this advanced course on OBIEE 11g.