As with good software suite, a solid architectural foundation is required. In today's marketplace the ability for software to scale well, meet the growing needs of an enterprise, and integrate with an organization's existing Information Technology (IT) investments is expected. Having the software be transparent enough for the average IT professional to implement it is definitely a plus. Being simple enough for an end-user to use or consume the product is a must. Oracle Business Intelligence (Oracle BI) 11g fits within all of these paradigms.
This chapter provides an overview of the Oracle BI architecture and its place in the Oracle Fusion Middleware (FMW) stack.
Oracle BI has a history forged by acquisition and brilliant advances in both technology and market share (refer to the document called Magic Quadrants for Business Intelligence Platforms on Gartner's site at http://www.gartner.com/id=1531017). Without going into much historical detail about the early beginnings of the software suite, as a reader, you are either new to Oracle BI or have experienced the tool in one of its former versions. Those versions can be Siebel Analytics or Oracle BI 10g.
The old adage of knowing where you've been to know where you are going doesn't much apply to understanding most of Oracle BI 11g. From architecture of the Graphical User Interface (GUI) the majority of the tool has been rewritten. Although, the principal of the tool remains the same; to provide an end-to-end enterprise analytics solution; the core components of Oracle BI have changed substantially enough for it to feel like a brand new tool to those familiar with its previous versions. With that being said, let's talk about Oracle BI 11g's architecture.
The following illustration shows some of Oracle BI 11g's infrastructure components from a core architecture perspective:
Oracle BI Domain: It is the core architecture of Oracle BI 11g.
WebLogic Server: It is the chosen application server for Oracle BI 11g.
Java components: These are the components which have been written in Java for Oracle BI 11g. They are deployed to the application server and WebLogic Server.
System components: These are the components which have been written mainly in C++ for Oracle BI 11g. They are managed by the Oracle Process Management and Notification Server.
Oracle BI relational repository: It is a set of database schemas (BIPLATFORM and MDS) that store metadata related to a specific Oracle BI 11g instance.
Oracle BI filesystem: It is the instructional set of physical files and directories containing configuration, logs, and metadata concerning the Oracle BI 11g instance:
Once Oracle BI 11g is installed and configured, the architecture seen in the preceding illustration will exist. The components, pointed out in the preceding illustration, will be the areas where most of the backend, or day-to-day platform maintenance, and troubleshooting takes place. Some IT resources may already have insight into maintaining some of these components if they have experience in working with other Oracle products in the FMW stacks such as WebLogic, WebCenter, SOA, and so on. However, to most Oracle BI aficionados, this environment will be new.
Oracle Fusion Middleware is taking on the enterprise challenge of bringing together the Oracle database and Oracle applications stacks. It is the middle-tier between them. Fusion Middleware is Oracle's go-forward foundation for the fusion of products between the database and application stack. Oracle has acquired many companies over the last decade for their technology or market share. This has taken them to a position of having excellent software. Oracle didn't communicate effectively before that. To achieve interoperability, a common layer had to be formed to fuse together the existing technologies, create efficiencies, and provide consistent delivery of software applications. The following image illustrates the main categories of products, making up the current Oracle product stack:
The Fusion Middleware product category contains Oracle Fusion Middleware (FMW), which forms the core of Oracle's Application Integration Architecture (AIA). It is the foundation for Oracle's fusion applications and software suites, such as Oracle BI 11g, Oracle Hyperion EPM, and so on.
In previous versions of Oracle BI, the default application server delivered with the product suite was Oracle Container for Java (OC4J). This Java application server was actually a slimmed-down version of the better-known Oracle Application Server (OAS). However, with the release of Oracle BI 11g—as with the mass majority of the Oracle Fusion Middleware applications—Oracle WebLogic Server (WLS) became the core application server. Previously, it was known as BEA WebLogic.
The WLS is a robust and scalable Java application server and it has been ranked as one of the top application servers in the market. Oracle has made a strong investment in WebLogic Server's atlas-like position as the foundation to which its Fusion Middleware stack is raised. With the current Oracle BI 184.108.40.206 release, the consideration to leverage IBM WebSphere as an alternate application server is under review. However, no guidance has been provided by Oracle on this topic. For prior releases of Oracle BI 11g, no other Java application server has been certified. So, an application server by any other name just won't do.
Oracle BI 11g is a system that has evolved—and continues to evolve—based on expansive user requests, a market that dictates stronger integration points, and more powerful BI tools. As such, Oracle BI 11g now incorporates, or better yet, requires a relational database repository to hold metadata concerning the installation, report scheduling, usage tracking, auditing, and other aspects of the environment.
Actually, the Oracle BI 11g installation process cannot begin until these repositories are created by the Repository Creation Utility (RCU) and accessible on a database server. Chapter 2, Installing the Metadata Repository, goes into greater detail about this crucial repository structure, better known by two database schemas—Metadata Services (MDS) and BIPLATFORM. The installation and configuration of these two repositories are required primarily for integration of Oracle BI 11g with the Oracle Fusion Middleware stack.
One interesting fact to note, however, is that the Oracle metadata repository (RPD) is still file based.
The RPD is the metadata storage mechanism in which Oracle BI developers model and map physical data sources to logical business representations in order for the resulting analytics to be easily consumed by the end users.
There are a lot of components that comprise Oracle BI 11g. Oracle BI 11g can categorize these components by classifying them based on the programming languages in which they were developed. The programming languages are mainly either Java or C++. In comparison with previous versions of Oracle BI, where it seemed to be a somewhat compact environment, Oracle BI 11g is much more integrated into the larger platform of Fusion Middleware, which adds both value and complexity. Some of the similar legacy components' names persist. However, it should not be taken lightly because most of the legacy components have been renamed, removed, or placed under new management processes.
The following diagram provides a high-level overview of the main components that comprise the Oracle BI 11g architecture. The components are clearly segmented by the processes in which they are managed, each of which ultimately comprises the Oracle BI Domain:
The term Oracle BI Domain, as noted previously and shown in the illustration, is used as a way to group all Oracle BI 11g components within the Fusion Middleware architecture. This should not be confused with the WebLogic Application Server domain which is given the default name,
bifoundation_domain, while following the default Oracle BI 11g installation options. The latter is a WebLogic Java Application Server term. The former is a Fusion Middleware term. Since Fusion Middleware is so closely related with the WebLogic Application Server, it is good to keep it in mind from a technical perspective.
When learning about the overall component composition, a very important detail to keep in mind is the matter in which the components are managed. Since WebLogic Server is a Java application server, it manages all of the Oracle BI components developed in the Java programming language. Another management system, the Oracle Process Management and Notification (OPMN) system, handles the other components, which are referred to as the System Components.
In relation to Oracle BI 11g, the Java components are those which have been developed in the Java programming language. Those components are as follows:
Action service: Primarily used by the Action Framework it executes actions on behalf of Presentation Services and Oracle BI Scheduler. Actions may be invocations of third party web services, or invocations of user supplied Java code executed as Enterprise JavaBeans (EJB).
Administrative components: Java Management Extensions (JMX) and Managed Beans (MBean) allow dynamic Application Programming Interface (API) functionality for managing, configuring, and administering Oracle BI 11g.
Web Service SOA: This provide a web service interface to the contents of the Oracle BI Presentation Catalog. The tree of objects in Oracle BI Presentation Catalog is exposed as a tree of web services, defined by a Web Services Inspection Language (WSIL) tree with Web Service Definition Language (WSDL) leaves.
Oracle BI Presentation Service plugin: Presentation Services run as a process, not as a web server, and does not communicate using any web server plugin API. The Oracle BI Presentation Services plugin forwards HTTP requests to Presentation Services. The HTTP requests are the requests from the browser-based user interface, or SOAP requests. This is ultimately just a servlet.
Security Services: It provides standards-based authentication and population services. It enables the Oracle BI server to integrate with the Fusion Middleware security platform which includes the Credential Store Framework and the Identity Store.
In relation to Oracle BI 11g, the system components are those which are developed in a non-Java programming language. Most of the system components have been developed in the C++ programming language as mentioned in the previous section. Here is a list of those components:
Oracle BI Server: This is a C++ process that performs the data manipulation and aggregates data from data sources. You can configure multiple Oracle BI Server processes, which share the load. No session replication takes place between the Oracle BI Server processes.
The Oracle BI Server does not maintain a user session state. For high availability deployments, query results are cached in the global cache.
Oracle BI Presentation Server: This is a C++ process that generates the user interface pages and renders results sets on behalf of the Oracle BI Scheduler. You can configure multiple Presentation Services, which share the load. No session replication takes place between the Presentation Services.
Presentation Services are almost stateless. The only significant state is the client authentication. If Oracle BI is configured to use a single sign-on for authentication purposes, users do not have to reauthenticate after a failover. For all other authentication schemas, when failover occurs, clients will have to reauthenticate. The client will see an interruption of service and will be redirected to a login page.
Oracle BI has some very basic capabilities, which can store the state or current session activity for a user logged in to the system. This is referred to as Session Management. Since the BI Presentation Server maintains the authentication state, the users do not have to log in on each subsequent dashboard that they visit. If a system is stateless, the application cannot easily remember the information about the user or actions performed previously.
Oracle BI Scheduler: It is a C++ process that runs the jobs according to a configurable frequency. Jobs can be created by agents in Oracle BI Presentation Catalog, or jobs can be created by the Job Manager. The Oracle BI Scheduler differs from the Quartz Scheduler that the Oracle BI Publisher leverages.
Oracle BI JavaHost: It is a Java process that includes resource-intensive graphs and PDF rendering. It also allows Oracle BI Presentation Services to support Oracle BI Publisher and Java tasks within the Oracle BI Scheduler. You can configure multiple JavaHost processes, which share the load. No session replication takes place between the JavaHost processes. JavaHost is a stateless process.
Oracle BI Server Cluster Controller: It is a C++ process, which manages the population of Oracle BI Servers and Oracle BI Schedulers. It also distributes the requests to the Oracle BI Server and ensures that requests are evenly load balanced across scaled-out Oracle BI Servers in the domain.
In general, it is important to understand how all of the components interact within the Oracle BI environment. Understanding some general concepts, such as "which port numbers are defined to communicate within the default Oracle BI architecture", "how the Oracle BI Administration Tool communicates with the Oracle BI database repository" will be quite helpful in your journey for becoming an Oracle BI professional. The following illustration shows each of the components comprising the core Oracle BI architecture, the communication ports, and the communication direction:
Let's talk a little more in detail about the enterprise application server that is at the core of Oracle Fusion Middleware—WebLogic. The Oracle WebLogic Server is a scalable, enterprise-ready Java Platform Enterprise Edition (Java EE) application server. Its infrastructure supports the deployment of many types of distributed applications. It is also an ideal foundation for building service-oriented applications.
The WebLogic Server is a robust application in itself. In previous versions of Oracle BI, the Oracle BI administrator and other developers took less effort to modify, configure, or otherwise maintain the Java application server. In Oracle BI 11g, the WebLogic Server is more crucial to the overall implementation, not only for installation but also throughout the Oracle BI 11g life-cycle. Learning the management components of the WebLogic Server, which ultimately controls the Oracle BI components, is critical for the success of an implementation. These management areas within the WebLogic Server are referred to as the WebLogic Administration Server, WebLogic Manager Server(Servers), and WebLogic Node Manager.
Before we move on to the description of each of the management areas within WebLogic, it is important to understand that the WebLogic Server software, which is used for the installation of the Oracle BI product suite, carries a limited license. Although the software itself is the full enterprise version—logically containing 100 percent of the product's functionality—the license that ships with Oracle BI 11g is not a full enterprise license for the WebLogic Server. This book hardly deals with software licensing, but here are a few nuances that one should keep in mind as they go about an Oracle BI 11g implementation:
The WebLogic Server license, which is provided with Oracle BI 11g, does not grant horizontal scale-out. An enterprise WebLogic Server license needs to be obtained for this advanced functionality.
The WebLogic Server does not provide a separate HTTP server with the installation. The Oracle BI Enterprise Deployment Guide (http://docs.oracle.com/cd/E21764_01/doc.1111/e15722/toc.htm) discusses the separation of the application tier from the web/HTTP tier and suggests Oracle HTTP Server (OHS). OHS is part of the Oracle FMW web tier and must be downloaded separately (http://www.oracle.com/technetwork/java/webtier/downloads/index.html). The other web/HTTP servers that can be used are Apache and Windows IIS, which we will discuss in the Chapter 4, Installation Options.
These items are simply a few nuances of the product suite in relation to Oracle BI 11g. Most software products have a very short list of nuances like the preceding one. However, once you understand the nuances, it will be easier to ensure that you have a more successful implementation. It also allows your team to be prepared for implementations. Be sure to consult your Oracle sales representative to assist you with the licensing concerns.
In order to learn more about the installation features, configuration options, administration, and maintenance of the WebLogic Server, we recommend that you reference the documentation of the WebLogic Server itself and not just the material on how it relates to Oracle BI 11g. The core of the WebLogic Server doesn't change just because Oracle BI 11g integrates into it. Understanding this approach should provide you with more efficient results.
The highest unit of management for controlling the WebLogic Server installation is called a domain. A domain is a logically related group of WebLogic Server resources that you manage as a unit. A domain always includes, and is centrally managed by, one Administration Server. Additional WebLogic Server instances which are controlled by the Administration Server for the domain are called Managed Servers. The configuration for all the servers in the domain is stored in the configuration repository, the
config.xml file, which resides on the machine hosting the Administration Server. The
config.xml files, by default, are stored in the path
<FMW_HOME> is the path on the server to which you have installed Oracle BI 11g.
Upon installing and configuring Oracle BI 11g, the domain named
bifoundation_domain is established within the WebLogic Server. This domain is the recommended name for each Oracle BI 11g implementation and should not be modified.
The WebLogic Server is an enterprise software suite that manages a myriad of application server components mainly focused on Java technology. It is also comprised of many ancillary components that enable the software to scale well, and also make it a good choice for distributed environments and high availability.
Clearly, it is good enough to be at the core of Oracle Fusion Middleware. One of the most crucial components of the WebLogic Server is the WebLogic Administration Server. When installing the WebLogic Server software, the WebLogic Administration Server is automatically installed with it. It is the Administration Server that not only controls all subsequent WebLogic Server instances called Managed Servers, but also controls aspects such as security, Persistence Stores, and other application server-related configurations.
The WebLogic Server gets installed on the operating system and ultimately runs as a service on that machine. The WebLogic Server can be managed in several ways. The two main methods are via the Graphical User Interface (GUI) web application called the WebLogic Administration Console or via the command line using the WebLogic Scripting Tool (WLST). You can access the WebLogic Administration Console from any machine using a web-based client (that is, web browser) that can communicate with the WebLogic Administration Server through the network and/or firewall.
The WebLogic Administration Server and the WebLogic Server are basically synonymous. If the WebLogic Server is not running, the WebLogic Administration Console will be unavailable as well. If the WebLogic AdminServer is not running, no administrative tasks can be made to the system, although concessions are made for a High Availability configuration.
Web applications, Enterprise Java Beans (EJB), and other resources are deployed on to one or more WebLogic Managed Servers in a WebLogic Domain. A WebLogic Managed Server is an instance of a WebLogic Server in a WebLogic Server domain. Each WebLogic Server domain has at least one instance which acts as the WebLogic Administration Server which we have just discussed. Only one Administration Server per domain must exist, but one or more Managed Servers may exist in the WebLogic Server domain. Having one or more managed servers, allow for deployed JEE applications to be logically delineated. They also provide a means to independently configure application server port numbers and they provide a barrier for runtime issues such as a server crash. You can deploy applications, EJBs, and other resources on the WebLogic Managed Servers and use the WebLogic Administration Server only for configuration and management purposes.
In a production deployment, Oracle BI 11g is deployed into its own Managed Server. The Oracle BI 11g installer comes with three installation types—simple, enterprise, and software. The latter two installation types configure two WebLogic Server instances, the Administration Server and another Managed Server called
bi_server1. Oracle BI 11g is deployed into the Managed Server called
bi_server1 and is configured by default to resolve to port 9704. The simple installation type configures only the administration server, deploys Oracle BI 11g into it, and resolves to port 7001. For the simple installation type, only one WebLogic Server instance exists.
The simple installation type is not recommended for anything more than sandbox, test environment development, or demonstrations.
When administering the WebLogic Server via the Administration Console, the WebLogic Administration Server instance appears in the same list of servers that also includes the Managed Servers. The WebLogic Administration Server should be used only for configuration and management of the WebLogic Server and should not contain any additionally deployed applications, EJBs, and so on.
One thing to note is that the Enterprise Manager Fusion Control is actually a JEE application deployed to the Administration Server instance, which is why its web client is accessible under port 7001. It is not necessarily a native application deployment to the core WebLogic Server, but gets deployed and configured during the Oracle BI 11g configuration. In the deployment's page within the Administration Console, you will find a deployment named
The general idea behind the Node Manager is that it takes on somewhat of a middle-man role. That is to say, the Node Manager provides a communication tunnel between the WebLogic Administration Server and any WebLogic Managed Servers configured within the WebLogic Domain. When the WebLogic Server environment is contained on a single physical server, it may be difficult to recognize the need for a Node Manager. However, its real power comes into play when Oracle BI 11g is scaled out horizontally on one or more physical servers. Each scaled-out deployment of WebLogic Server will contain a Node Manager. If the Node Manager is not running on the server on which the Managed Server is deployed, then the core Administration Server will not be able to issue start or stop commands to that server. As such, if the Node Manager is down, communication with the overall cluster will be affected.
The following diagram shows how machines A, B, and C are physically separated—each of them contains a Node Manager. You can see that the Administration Server communicates with the Node Managers and not directly to the Managed Servers:
We have briefly discussed the WebLogic Administration Console which controls the administrative configuration of the WebLogic Server Domain. This includes the components managed within it such as security, deployed applications, and so on. The other management tool which provides control on the deployed Oracle BI application ancillary deployments, libraries, and several other configurations is called the Enterprise Manager Fusion Middleware Control.
This seems to be a long name for a single web-based tool. As such, the name is often shortened to Fusion Control or Enterprise Manager. Reference to either abbreviated title in the context of Oracle BI should ensure fellow Oracle BI teammates understand what you mean.
To discuss the vast amount of individual configuration points contained within the WebLogic Administration Console and Fusion Control, you can warrant an entire chapter devoted to this subject. In fact, a subsequent chapter, Chapter 5,Understanding the Systems Management Tools is dedicated to it.
The Oracle Process Management and Notification (OPMN) system is not a new concept or tool within the Oracle product line. It has acted as a management service in many other Oracle products for years and is now a fitting utility for the cross-platform deployment architecture that Oracle BI 11g allows. The OPMN controls the Oracle BI 11g system components. Those are the components primarily developed in the C++ programming language. The OPMN not only allows each of the five system components to be started and stopped by calling a single command, it will also monitor those system component processes at runtime. It can even attempt to restart a component if it detects a failure. To start and stop the system components, you can use the Oracle Enterprise Manager Fusion Middleware Control or a command-line interface. The following screenshots represent the status retrieval of the System Components using the Fusion Middleware Control GUI and command-line interface, respectively:
The command-line executable is deployed with the Oracle BI 11g installation. It resides in the default filesystem directory locations—
The Enterprise Manger Fusion Middleware Control, as per the default Oracle BI 11g installation, is accessible via the URL –
Either approach used for stopping, starting, or checking the status of the system components is valid. Either approach will work properly, however it is recommended—whenever possible—to leverage the Fusion Control interface for these actions in order to achieve the most consistent results.
It would be difficult to discuss the overall architecture of Oracle BI 11g without at least giving some mention to how the basics of security, authentication, and authorization are applied. By default, installing the Oracle WebLogic Server provides a default Lightweight Directory Access Protocol (LDAP) server referred to as the WebLogic Server Embedded LDAP server.
This is a standards-compliant LDAP system which acts as the default authentication method for out-of-the-box Oracle BI 11g. Integration of secondary LDAP providers, such as Oracle Internet Directory (OID) or Microsoft Active Directory (MSAD) is crucial in order to leverage most organizations' identity management systems.
The combination of multiple authentication providers is possible, it is in fact common. For example, a configuration may wish to have users that exist in both the Embedded LDAP server and MSAD to authenticate and have access to Oracle BI 11g.
Oracle BI 11g security incorporates the Fusion Middleware Security model—Oracle Platform Security Services (OPSS). This is a positive influence over managing all aspects of Oracle BI 11g as it provides a very granular level of authorization and a large number of authentication and authorization integration mechanisms. OPSS also introduces, to Oracle BI 11g, the concept of managing privileges by application role instead of directly by user or group. It abides by open standards to integrate with security mechanisms that are growing in popularity. Those security mechanisms are Security Assertion Markup Language (SAML) 2.0 and so on. Other well known single sign-on mechanisms such as SiteMinder and Oracle Access Manager have already preconfigured integration points within the Oracle BI 11g Fusion Control.
Chapter 5, Understanding the Systems Management Tools will go into an exercise for creating new users, groups, and assigning application roles, but for now, here are a few key concepts to know about security:
Oracle BI 11g security is managed completely in a different way from the previous versions, although the Oracle BI 10g security model is still allowed for backwards compatibility.
An Oracle BI 11g best practice is to manage security by Application Roles.
Understanding the differences between the Identity Store, Credential Store, and Policy Store is critical for advanced security configuration and maintenance.
The following sections discuss these few key concepts at a high level. Understanding these concepts is not critical at this moment for you to continue with the remainder of the book, however, once you complete the book and are ready to engage in more advanced discovery, you will need to research and understand these items to be more versed in managing Oracle BI 11g security.
Let's first disclaim that the best practice for Oracle BI 11g security is to use the default Oracle Fusion Middleware security model. However, the legacy approach to manage security via the Oracle BI metadata repository (RPD) is still allowed. This backwards compatibility for security allows environments running on previous versions of Oracle BI (for example, Oracle BI 10g) to leverage the investments in complicated metadata repository architectures or unique identity solutions while still taking advantage of Oracle BI 11g's new functions and features.
This backwards compatibility can potentially provide a false sense of comfort. However, since the official Oracle BI roadmap is only to support the Fusion Middleware security model, backwards compatibility merely bridges a gap in migrating to Oracle BI 11g where rearchitecture of security would otherwise delay, or prevent, some organizations from taking advantage of the new offering. There are certain requirements to leverage this backwards compatible security architecture. The Oracle BI 11g product documentation discusses the right way to incorporate this technique in a section called Alternative Security Administration Options (http://docs.oracle.com/cd/E21764_01/bi.1111/e10543/legacy.htm#CHDCEFBC).
In previous releases of Oracle BI security, groups and the relationship of a managed Identity Store's (that is LDAP or custom relational table) users with an Oracle BI group was managed within the RPD. A group was the highest level of organization for specific sets of users. This goes for both the metadata repository and the Web Catalog. This legacy approach was limited to a single software solution, Oracle BI.
In Oracle BI 11g, the default security model is the Oracle Fusion Middleware security model which has a much broader vision and scope. General Information Technology security administration best practice is to set permissions or privileges to a specific point of access on a group and not individual users. The same idea applies here except there is another enterprise level of user/group aggregation called an Application Role. Application roles can contain other application roles, groups, or individual users. Access privileges to a certain object such as a folder, web page, or column should always be assigned to an application role. Application roles for Oracle BI 11g can be managed in the Oracle Enterprise Manager Fusion Middleware Control interface.
Fusion Middleware security can seem complex at first, but knowing the correct terminology and understanding how the most important components communicate with each other it becomes easier. The application at large is extremely important as it relates to security management. Oracle BI 11g uses three main repositories for accessing authentication and authorization information, all of which are explained in the next sections.
This is the authentication provider. A simple mnemonic here is that this store tells Oracle BI how to identify any users attempting to access the system. An example of creating an Identity Store would be to configure an LDAP system such as the Oracle Internet Directory or Microsoft Active Directory to reference users within an organization.
The credential store is ultimately for advanced Oracle configurations. You may touch upon this while establishing an enterprise Oracle BI 11g deployment, but not much thereafter unless integrating with the Oracle BI 11g Action Framework, or something equally complex. Ultimately, the Credential Store does exactly what its name implies—it stores credentials.
Specifically, it is used to store credentials of other applications, which the core application (that is, Oracle BI) may access later without having to re-enter said credentials. An example of this would be integrating Oracle BI 11g with the Oracle Enterprise Management (EPM) suite. In this example, let's pretend that there is an internal requirement at Company XYZ for users to access an Oracle BI dashboard. Upon viewing said dashboard if a report with discrepancies is viewed, the user requires the ability to click on a link which opens an Oracle EPM Financial Report containing more details about the concern. If all users accessing the Oracle BI dashboard do not have credentials to access the Oracle EPM environment directly, how could they open and view the report without being prompted for credentials? The answer would be that the credential store would be configured with the credentials of a central user having access to the Oracle EPM environment. This central user's credentials (encrypted, of course) are passed along with the dashboard viewer's request and hey presto, access!
The policy store is unique to Fusion Middleware security and leverages a security standard referred to as eXtensible Access Control Markup Language (XACML), which ultimately provides granular access and privilege control for an enterprise application. This is one of the reasons why managing by application roles becomes so important. It is the individual application role to which assigned policies are defining access for the information within Oracle BI. Stated another way, the application privileges, such as the ability to administer the Oracle BI 11g RPD, are assigned to a particular application role, and these associations are defined in the policy store. The following illustration shows from where each area of security management is controlled:
These three types of security providers within Oracle Fusion Middleware are integral to the Oracle BI 11g architecture. A chapter or more could be written on each provider but that is outside the scope of this book. Further recommended research on this topic would be to look at Oracle Fusion Middleware Security, OPSS, and the Application Development Framework (ADF).
The first thing to recognize with infrastructure requirements prior to deploying Oracle BI 11g is that its memory and processor requirements have been increased since previous versions. The Java application server, WebLogic Server, gets installed with the full version of its software (though under a limited/restricted license as already discussed). A multitude of additional Java libraries and applications are also deployed. Ultimately, the authentication Application Development Framework (ADF) used to develop much of the platform accounts for a larger overall footprint. Be prepared for a recommended minimum 8 GB Read Access Memory (RAM) requirement for an enterprise deployment and a 4 GB minimum requirement for a developer workstation deployment. Other system requirement information can be found within the Oracle documentation at http://docs.oracle.com/cd/E23943_01/doc.1111/e15722/overview.htm#CJAHADHD.
Since release 220.127.116.11, Oracle BI 11g has a separate Client Tools installation that requires Microsoft Windows XP or a more recent version of the Windows OS. The Oracle BI 11g Client Tools provides the majority of client to server management capabilities required for normal day-to-day maintenance of the Oracle BI repository and related artifacts. The Client Tools installation is usually reserved for Oracle BI developers who design and maintain the Oracle BI metadata repository, better known as RPD, which stems from its binary file extension (
.rpd). Compared to previous versions of the product, there are two tools now, which have been removed from the Client Tools installation:
Oracle BI ODBC Manager
Oracle BI Catalog Manager (available with version 18.104.22.168)
The Oracle BI 11g Client Tools installation provides each workstation with the Administration Tool, Job Manager, and all command-line Application Programming Interface (API) executables.
One of the key features of Oracle BI development is the ability for multiple metadata developers to develop simultaneously. Although the use of the term "simultaneously" can vary amongst the technical communities, the use of concurrent development within the Oracle BI suite requires Oracle BI's Multiuser Development (MUD) environment configuration.
The configuration itself is fairly straightforward and ultimately relies on the Oracle BI administrator's ability to divide metadata modeling responsibilities into projects. Projects—which are usually defined and delineated by logical fact table definitions—can be assigned to one or more metadata developers.
In previous versions of Oracle BI, a metadata developer could install the entire Oracle BI product suite on an up-to-date laptop or commodity desktop workstation and successfully develop, test, and deploy an Oracle BI metadata model. The system requirements of Oracle BI 11g prevent developers from installing the full Oracle BI 11g server suite on a legacy workstation as the minimum memory requirement is 4 GB. Most of the 32-bit workstations operate with 3 GB or less requirement.
If an organization currently leverages the Oracle BI MUD environment, or plans to leverage with the current release, this raises several questions:
How do we get our developers to the best environment suitable for developing our metadata?
Do we need to procure new hardware?
Most of the developers' desktop workstations or laptops run 32-bit Microsoft Windows XP or Windows Vista. Microsoft Windows is a requirement for the Oracle BI Client Tools. However, the Oracle BI Client Tools does not include the server component of the Oracle BI 11g environment. It only allows for connecting from the developer's workstation to the Oracle BI server instance. In a multiuser development environment, this poses a serious problem as only one metadata repository can exist on any one Oracle BI server instance at any given time. If two developers are working from their respective workstations at the same time and wish to see their latest modifications published in a rapid application development (RAD) cycle, this type of iterative effort fails as one developer's published changes will overwrite the others in real time.
To resolve the above issue there are two recommended solutions. The first is an obvious localized solution. This solution merely upgrades the Oracle BI developers' workstations or laptops to comply with the minimum requirements for installing the full Oracle BI environment on said machines. This upgrade should be both memory (RAM) and processor (MHz) centric. A dual-core processor and a 4 GB plus RAM are recommended.
However, in order for a Windows operating system to acknowledge and use more than 4 GB memory, a 64-bit operating system kernel is required. Without an upgraded workstation, from which to work, Oracle BI 11g metadata developers will sit at a disadvantage for general iterative metadata development and especially be disenfranchised if interfacing within a multiuser development environment.
The second solution is one that takes advantage of virtual machines (VM). The virtual machines have become a staple within most IT departments as they are versatile and allow speedy proposition of server environments. For this scenario, it is recommended to create a virtual machine template of an Oracle BI 11g environment, from which individual virtual machine images for each metadata developer on the Oracle BI development team can be duplicated or stood up. This solution effectively provides each metadata developer with their own Oracle BI development environment server which contains the fully deployed Oracle BI server environment. Then, developers have the ability to develop and test iteratively by connecting to their assigned virtual server without fear that their efforts will conflict with another developer's. The following diagram illustrates how an Oracle BI 11g MUD environment can leverage either upgraded developer workstation hardware or VM images to facilitate development:
This book does not cover the installation, configuration, or best practices for developing in a MUD environment. However, the Oracle BI development team deserves a lot of credit for documenting these processes in unprecedented detail. The Oracle BI 11g MUD environment documentation provides a case study (http://docs.oracle.com/cd/E21764_01/bi.1111/e10540/case_study.htm#CHDGIBBD), which conveys best practices for managing a complex Oracle BI development lifecycle. When you are ready to deploy a MUD environment, it is highly recommended to peruse this documentation first.
The information in this section seeks to convey these best practices in facilitating a developer's workstation when using a MUD environment, but the mentioned resources will delve further into this.
Now that the Oracle BI 11g is part of the larger enterprise Fusion Middleware stack, the Oracle BI tool suite complies largely with the overall Fusion Middleware infrastructure. This common foundation allows for a centralized model to communicate with operating systems, web servers, and other ancillary components which are compliant. The certification matrix for Oracle BI 11g can be found on the Oracle website at http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html.
The certification matrix document is usually provided in a Microsoft Excel format and should be referenced before you begin any project or deployment of Oracle BI 11g. This will ensure that infrastructure components such as the selected operating system, web server, web browsers, LDAP server, and so on will actually work when integrated with the product suite.
There are several reasons why an organization may wish to expand their Oracle BI 11g footprint. This can range anywhere from requiring a highly available environment to achieving high levels of concurrent usage over time. The number of total end users, the number of total concurrent end users, the volume of queries, the size of the underlying data warehouse, and cross-network latency are even more factors to consider.
Scaling out an environment has the potential to solve performance issues and stabilize the environment. When scoping out the infrastructure for an Oracle BI 11g deployment, there are several crucial decisions to be made. These decisions can be greatly assisted by preparing and properly using Oracle's recommended guides for clustering and deploying Oracle BI 11g on an enterprise scale.
Configuring the Oracle BI 11g product suite, specifically while involving scaling out or setting up high availability (HA), needs preparation. Proactively taking steps to understand what it takes to correctly establish or preconfigure the infrastructure required to support any level of fault tolerance and high availability is critical. Even if the decision to scale out from the initial Oracle BI 11g deployment has not been made and if the potential exists, proper planning is recommended. Proper planning for HA can be achieved by following the Oracle Enterprise Deployment Guide for Oracle BI at http://docs.oracle.com/cd/E23943_01/doc.1111/e15722/toc.htm.
We would remiss the most important concepts of scaling out Oracle BI 11g if we do not highlight it, specifically for high availability—shared storage. The idea of shared storage, is that in a fault tolerance environment there are binary files and other configuration metadata that needs to be shared across the nodes. If these common elements are not shared, then if one node is to fail there is a potential loss of data.
Most importantly, in a highly available Oracle BI 11g environment, there can be only one WebLogic Administration Server running for that environment at any instance in time. An HA configuration makes one Administration Server active while the other is made passive. If the appropriate preconfiguration steps for shared storage (as well as other items in the high availability guide) are not properly completed, one should not expect accurate results from his/her environment.
A major benefit of Oracle BI 11g's ability to leverage the WebLogic Server as the Java application server tier, is that for every default installation, Oracle BI gets established in a clustered architecture. There is no additional configuration necessary to set this architecture in motion. Clearly, installing Oracle BI 11g on a single server only provides a single server with which to interface, however, upon doing so Oracle BI is installed into a single node clustered application server environment. Then, additional clustered nodes of Oracle BI 11g can be configured to establish and expand the server either horizontally or vertically.
With respect to the enterprise architecture and infrastructure of the Oracle BI 11g environment, a clustered environment can really expand in one of the two ways—horizontally and vertically. A horizontal expansion is the typical expansion type when clustering. It is represented by installing and configuring the application on a separate physical server with reference to the main server application. A vertical expansion is usually represented by expanding the application on the same physical server under which the main server application resides.
There are benefits to both scaling options. A vertical scale out can provide an advantage of a single machine's processor or memory power and save the cost of a separate physical machine. Horizontal scale out provides the advantages of failover, multiple machines, and redundancy. The decision to scale out in one way or the other is usually predicated on cost of additional physical servers, server limitations, and peripherals such as memory, processors, or an increase in usage activity by the end users. Some considerations, which may be used to assess which approach is the best for your specific implementation, might be as follows:
Load balancing capabilities and need for an Active-Active versus Active-Passive architecture (suggests horizontal scaling)
Need for a failover or high availability (suggests horizontal scaling)
Cost for processor and memory enhancements versus cost of new servers (suggests vertical scaling)
Anticipated increase in concurrent user queries (horizontal or vertical scaling)
Realized decrease in performance due to an increase in user activity (horizontal or vertical scaling)
When discussing scaling out of the Oracle BI server cluster, it is a common mistake to confuse the WebLogic Server application clustering with the Oracle BI Server Cluster Controller. In an attempt to clarify, it helps to remember that the Oracle BI Server System Component is the service or server engine controlled by the OPMN. There is also an Oracle BI Managed Server which is controlled by the WebLogic Server. Currently, Oracle BI 11g can only have a single metadata repository (RPD) reference associated with an Oracle BI server deployment instance at any single point in time. Because of this, the Oracle BI server engine leverages a failover concept to ensure some level of high availability that exists when the environment is scaled out.
In an Oracle BI scaled out and clustered environment, a secondary node, which has an instance of Oracle BI 11g installed, contains a secondary Oracle BI Server engine. From the main Oracle BI Managed Server containing the primary Oracle BI server instance, the secondary Oracle BI server instance is established as the failover server engine, using the Oracle BI Server Cluster Controller. This configuration takes place in the Enterprise Manager Fusion Control console. Based on this configuration, the scaled-out Oracle BI Server engine acts in an Active-Passive mode. That is, when the main Oracle BI 11g server engine instance fails, the secondary or passive Oracle BI server engine then becomes active to route requests and field queries.
With high availability, it is often very hard to achieve multiples of nine (that is, 99.999 percent) for uptime of any server or application server environment. High availability is the type of architecture associated with an environment when attempting to maintain a high level of application availability and minimize downtime.
Failover is the process that takes place when a server node in a cluster fails and application traffic, otherwise intended for the down server, flows to the other active clustered server nodes. Failover also requires some level of load balancing and the concept can vary depending on the desired architecture within an organization, but the general concept should be roughly the same in most topologies.
As part of an enterprise deployment strategy, taking failover and high availability into consideration is usually part of the architecture planning process. A step-by-step configuration for HA or a failover environment is an advanced infrastructure topic and is beyond the scope of this book. However, it is important to note that because Oracle BI 11g is part of the Fusion Middleware stack, it has the ability to capitalize on all fault tolerance features offered by that common architecture.
In an effort to relay best practices and strategic deployment of a large-scale enterprise, Oracle BI deployment, Oracle lends a big helpful hand and provides a topology referred to as the Enterprise Deployment Guide (EDG). This guide should not be taken lightly. When deciding on major factors of a full-scale enterprise wide Oracle BI deployment, this topology is the one that should be referenced first. Use the EDG to plan for required resource skills, procurement of hardware, and as a gauge to estimate the effort involved in achieving the architecture that your requirements demand. The topology includes pertinent information regarding load balancing, virtual IP addresses, separation of HTTP servers from application servers, and other fully vetted infrastructure recommendations. It is especially recommended to view this guide before embarking on any deployment involving extranet access to your Oracle BI implementation or a large user base of an internal deployment.
As you get started with installing, configuring, and deploying Oracle BI 11g in the subsequent chapters, you will see several references to files inside the Fusion Middleware folder structure and the Oracle BI home folder structure. Again, taking advantage of a common architecture, Oracle BI 11g leverages the Fusion Middleware foundation to organize the filesystem structure. This consistency is a benefit for all implementers and administrators that will eventually maintain the platform. It is recommended that, as you progress in your learning of Oracle BI 11g, you should note the folders which contain files pertinent for modifying the environment, or assisting with troubleshooting efforts. The following diagram illustrates the standard logical deployment structure for Oracle BI 11g:
As you begin developing and deploying your Oracle BI 11g solutions, you will eventually run into some issues down the road. Face them, you are implementing a technology! Issues, no matter how minor, are bound to arise. No one plans for them. But here is a list of log files' locations where it is best to begin troubleshooting in Oracle BI 11g:
<OBI_LOGS> = /u01/fmw/instances/instance1/diagnostics/logs=
Log Name (
RPD migration utility
All logs regarding the OPMN system can be found at the following centralized location:
Those who are familiar with the previous versions of Oracle BI might be surprised that several legacy named physical configuration files still reside in the Oracle BI 11g architecture. These files can still be manually manipulated to configure the Oracle BI 11g environment. However, much of the basic configuration is handled via the Oracle BI Enterprise Manager which will be discussed in more detail in Chapter 5, Understanding the Systems Management Tools. If there is a need to locate these configuration files, they can be found at the following location:
The following is a list of configuration files based on the central Oracle BI 11g instance path of
For a self review and recap of this chapter, here are a few questions based on important topics covered in this chapter. There is no answer key. These questions are for your own reflection on the chapter material.
What is Oracle Fusion Middleware?
What are some of the reasons to scale out an Oracle BI deployment?
List each of the Oracle BI system components. How many are there?
What is the name of the guide that should be referenced while planning an enterprise deployment of Oracle BI 11g?
What is the purpose of the Identity Store?
The following list would help you to continue your learning:
Oracle BI 11g Enterprise Deployment Guide: http://download.oracle.com/docs/cd/E21764_01/doc.1111/e15722/toc.htm
Multiuser Development Environment: http://download.oracle.com/docs/cd/E21764_01/bi.1111/e10540/lifecycle.htm#CIAFAFGE
This chapter provided a high-level overview of the Oracle BI 11g architecture. Oracle BI 11g is an overhaul to prior versions of the tool. This chapter discussed how Oracle Fusion Middleware has made Oracle BI 11g an extremely robust tool incorporating open standards and best practices where possible. An effort was made to discuss topics, which are high on the priority list for most organizations, such as security and scaling out the architecture. Recommendations were provided around these topics where possible. Although there is a lot more detail that could be written into each subject section of this chapter, the chapter conveyed enough information to capture the bulk of the Oracle BI 11g architecture, so that you can speak intelligently about the subject after reading this chapter.
The architecture described in this chapter discussed the core foundation of Oracle BI 11g and did not discuss Oracle Real-time Decisions (RTD), the Oracle decision making engine, nor will the remainder of this book discuss it (an entire book could be devoted merely to this subject; so, we chose to leave it out of this).
The next several chapters take you on a journey through setting up Oracle BI 11g, prepping data sources, modeling a custom analytics solution, and getting to know Oracle BI intimately. Keep the momentum going and just know that by the end of this book, you'll be well on your way to becoming an Oracle BI aficionado.