In relation to Oracle BI 12c, the Java components are those which have been developed in the Java programming language. These components are similar to Oracle BI 11g, with a few differences. The main Java for Oracle BI 12c components, in no particular order of importance, are described in the following sections.

There are many components that comprise Oracle BI 12c. These mainly need to be all in a running state in order for Oracle BI 12c to be considered in running condition - the only exception being the Essbase component. The Oracle BI System Components are those which are developed in a non-Java programming language. Most have been developed in the C++ programming language, as mentioned previously. The following sections cover a list of those components.

Essbase

This is the Essbase server, which provides Oracle/Hyperion Essbase capabilities for the Oracle BI implementation.

It is important to understand how all of the components interact within the Oracle BI environment. Understanding such general concepts as which port numbers are defined to communicate within the default Oracle BI architecture, or how the Oracle BI Administration Tool communicates with the Oracle BI repository, will be quite helpful in your journey to becoming an Oracle BI professional. The following figure shows each of the components comprising the core Oracle BI architecture, the communication ports, and the communication direction:

Before we move on to a description for each of those areas within WebLogic, it is also important to understand that the WebLogic Server software that is used for the installation of the Oracle BI product suite carries a limited license. Although the software itself is the full enterprise version and carries full functionality, the license that ships with Oracle BI 12c is not a full enterprise license for WebLogic Server for your organization to spin off other siloed JEE deployments on other non-OBIEE servers. This book is hardly a guide to software licensing, but following are a few of those differences one should keep in mind when beginning or continuing an Oracle BI 12c implementation:

These items are simply a few nuances of the product suite in relation to Oracle BI 12c. Most software products contain a short list such as this one. However, once you understand the nuances, the easier it will be to ensure that you have a more successful implementation. It also allows your team to be as prepared in advance as possible. Be sure to consult your Oracle sales representative to assist with licensing concerns.

Despite these nuances, we highly recommend that in order to learn more about the installation features, configuration options, administration, and maintenance of WebLogic, you not only research it in relation to Oracle BI, but also in relation to its standalone form. That is to say that there is much more information (books, blogs, and so on) at large on the topic of WebLogic Server itself than WebLogic Server as it relates to Oracle BI. Understanding this approach to self-educating or web searching 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.

Upon installing and configuring Oracle BI 12c, the domain bi is established within the WebLogic Server. This domain is the recommended name for each Oracle BI 12c implementation and should not be modified.

The domain path for the bi domain may appear as ORACLE_HOME/user_projects/domains/bi .

This directory for the bi domain is also referred to as the DOMAIN_HOME or BI_DOMAIN folder.

The WebLogic Server is an enterprise software suite that manages a myriad of application server components, mainly focusing on Java technology. It is also comprised of many ancillary components, which 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 WebLogic Server is WebLogic Administration Server. When installing the WebLogic Server software, the 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 such aspects as authentication-provider security (for example, LDAP) and other application-server-related configurations.

WebLogic Server installs 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 WebLogic Administration Console, or via a command line using the WebLogic Scripting Tool (WLST). You access the Administration Console from any networked machine using a web-based client (that is, a web browser) that can communicate with the 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.

Web applications, Enterprise Java Beans (EJB), and other resources are deployed onto one or more Managed Servers in a WebLogic Server Domain. A 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 Administration Server just discussed. One administration server per domain must exist, but one or more managed servers may exist in the WebLogic Server Domain.

In a production deployment, Oracle BI is deployed into its own managed server. The Oracle BI installer installs two WebLogic server instances, the Admin Server and a managed server, bi_server1. Oracle BI is deployed into the managed server bi_server1, and is configured by default to resolve to port 9502; the Admin Server resolves to port 9500. Historically, this has been port 9704 for the Oracle BI managed server, and port 7001 for the Admin Server.

When administering the WebLogic Server via the Administration Console, the WebLogic Administration Server instance appears in the same list of servers, which also includes any managed servers. As a best practice, the WebLogic Administration Server should be used for configuration and management of the WebLogic Server only, and not contain any additionally deployed applications, EJBs, and so on.

The general idea behind 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 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. It is very necessary and, as part of any of your ultimate start-up and shutdown scripts for Oracle BI, the Node Manager lifecycle management will have to be a part of that process. Node Manager's real power comes into play when Oracle BI 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 figure shows how machines A, B, and C are physically separated, each containing a Node Manager. You can see that the Administration Server communicates to the Node Manager, and not the Managed Server, directly:

In Oracle BI 11g, the default security model is the Oracle Fusion Middleware security model, which has a very broad scope. A universal 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, and even 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 can be managed in the Oracle Enterprise Manager Fusion Middleware Control interface. They can also be scripted using the WLST command-line 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 and the application at large is extremely important as it relates to security management. Oracle BI uses three main repositories for accessing authentication and authorization information, all of which are explained in the following sections.

Policy Store

The Policy Store is quite unique to Fusion Middleware security and leverages a security standard referred to as 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 Roles that are assigned policies defining access to information within Oracle BI. Stated another way, the application privileges, such as the ability to administer the Oracle BI RPD, are assigned to a particular application role, and these associations are defined in the Policy Store. The following figure shows how each area of security management is controlled:

These three types of security providers within Oracle Fusion Middleware are integral to Oracle BI architecture. A chapter or more could be written on each provider, but that is beyond 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).

Oracle BI 12c has a separate client tools installation that requires Microsoft Windows XP or a more recent version of the Windows Operating System (OS). The Oracle BI 12c client tools provide the majority of client-to-server management capabilities required for normal day-to-day maintenance of the Oracle BI repository and related artefacts. The client-tools installation is usually reserved for Oracle BI developers who architect and maintain the Oracle BI metadata repository, better known as the RPD, which stems from its binary file extension (.rpd).

The Oracle BI 12c 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 when developing with Oracle BI is the ability for multiple metadata developers to develop simultaneously. Although the use of the term simultaneously can vary among the technical communities, the use of concurrent development within the Oracle BI suite requires Oracle BI's Multi-User Development Environment (MUDE) configuration, or some other process developed by third-party Oracle partners. The MUD 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 developer. 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 12c require a significant amount of processor and RAM capacity in order to perform development efforts on a standard-issue workstation or laptop.

If an organization currently leverages the Oracle BI Multi-User Development Environment, or plans to with the current release, this raises a couple of questions:

Microsoft Windows is a requirement for Oracle BI client tools. However, the Oracle BI client tool does not include the server component of the Oracle BI environment. It only allows for connecting from the developer's workstation to the Oracle BI server instance. In a Multi-User Development Environment, this poses a serious problem as only one metadata repository (RPD) 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 other's in real-time.

To resolve the 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. 16GB+ RAM and a dual-core processor are recommended. A 64-bit operating system kernel is required. Without an upgraded workstation from which to work, Oracle BI metadata developers will be at a disadvantage for general iterative metadata development, and will especially be disenfranchised if interfacing within a Multi-User Development Environment.

The second solution is one that takes advantage of virtual machines (VM) capacity within the organization. Virtual machines have become a staple within most information technology departments, as they are versatile and allow for the speedy proposition of server environments. For this scenario, it is recommended to create a virtual-machine template of an Oracle BI environment from which to duplicate and stand up individual virtual machine images for each metadata developer on the Oracle BI development team. This effectively provides each metadata developer with their own Oracle BI development environment server, which contains the fully deployed Oracle BI server environment. Each developer then has 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 figure illustrates how an Oracle BI MUD environment can leverage either upgraded developer-workstation hardware or VM images, to facilitate development:

Oracle BI 12c largely complies 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 that are compliant. Oracle does a good job of updating a certification matrix for each Fusion Middleware application suite per respective product release.

The certification matrix document is usually provided in Microsoft Excel format and should be referenced before any project or deployment of Oracle BI begins. 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.

Configuring the Oracle BI product suite, specifically when involving scaling out or setting up high-availability (HA), takes preparation. Proactively taking steps to understand what it takes to correctly establish or pre-configure 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 deployment hasn't been made, if the potential exists, proper planning is recommended.

A major benefit of Oracle BI's ability to leverage WebLogic Server as the Java application server tier is that, per the 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 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. Additional clustered nodes of Oracle BI can then be configured to establish and expand the server, either horizontally or vertically.

High-availability of the Oracle BI system can be difficult to achieve, but may be necessary based on increased system demands on concurrent usage or other factors. Providing a 24x7 up-time of server operations for some organizations is a must. High Availability is the type of architecture associated with an environment when attempting to maintain a high-level of application availability and minimal downtime.

Failover is the process that takes place when a server node in a cluster fails, and application traffic otherwise intended for the downed server flows to the other active clustered server nodes. Failover also requires some level of load balancing, and the concept can vary depending on 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. Step-by-step configuration instructions for a high-availability or failover environment are an advanced infrastructure topic and beyond the scope of this book. However, it is important to note that because Oracle BI is part of the Fusion Middleware stack, it has the ability to capitalize on all fault-tolerance features offered by that common architecture.

As you begin developing and deploying your Oracle BI 12c solutions, you will eventually run into some issues down the road. Face it: you are implementing technology! Issues, no matter how minor, are bound to arise. No one plans for them. But here is a list of log file locations where best to begin troubleshooting in Oracle BI 12c. If you have experience with a previous version of Oracle BI, you'll notice how some of the file names have changed to better reflect the new approach to functionality in Oracle BI 12c, although the general content of the log files is similar:

<OBI_LOGS> = DOMAIN_HOME/servers/

Those who are familiar with previous versions of Oracle BI might be surprised that several legacy-named physical-configuration files still reside in the Oracle BI 12c architecture. These files can still be manually manipulated to configure the Oracle BI 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, Installing and Configuring Client Tools. If there is a need to locate these configuration files, they can be found at DOMAIN_HOME/config/fmwconfig/biconfig/bi_component_name, where the bi_component_name could be OBIS, OBIPS, and so on.

Here is a list of the main Oracle BI configuration files based on the central Oracle BI 12c instance path of the BI_CONFIG_HOME path: