Download code from GitHub
Fans of the Oracle BI suite of products will find Oracle Business Intelligence (Oracle BI) 12c a refreshing software version, both from its visual advancements and its technical foundation changes. This version of Oracle BI brings Oracle's flagship analytics system to the next level while maintaining its core enterprise-architecture concepts. The updated architecture allows for easier scalability of the solution across multiple servers, brings departmental BI and data visualization concepts into the mix, and strengthens its deployment processes with its new lifecycle-management tools. This chapter focuses on an overview of the Oracle BI 12c architecture, with occasional references to its predecessor to give some perspective as to how far the Oracle BI 12 release has come in terms of a more straightforward implementation process and increased functionality.
Going right for the guts of the platform, it is best to understand how the Oracle BI 12c system is laid out by looking at the logical interoperability of the architectural components. Oracle BI 12c is a combination of several core technologies, which reside as common software components within the Oracle Fusion Middleware (FMW) stack inside the Oracle software eco-system.
The following illustration shows some of Oracle BI 12c's logical architecture components. Users of Oracle BI 11g will find some of this topology familiar, yet clearly different in many ways:
Oracle BI Domain: This is the core architecture of Oracle BI 12c
WebLogic Server: This is the chosen application server for Oracle BI 12c
Service Instance: The structural housing for all critical Oracle BI artifacts (metadata) that would allow delineated movement from one environment to another (also multi-tenancy in future releases)
Java components: These are the components which have been written in Java for Oracle BI 12c. They are deployed to the application server and WebLogic Server
BI System Components: These are the components which have been written mainly in C++ for Oracle BI 12c
Oracle BI relational repository: This is a set of database schemas (BIPLATFORM and MDS) that store metadata related to a specific Oracle BI 12c instance
Oracle BI filesystem: This is the instructional set of physical files and directories containing configuration, logs, and metadata concerning the Oracle BI 12c instance
Similar to the Oracle BI 11g environment, once the software has been installed, all of the components in the architecture topology shown will exist. These components are transparent to the end users (that is, users in the organization who will view dashboards, reports, receive alerts, and so on). However, for the Oracle BI 12c administrators, and those that need to work with the technical aspect of the system, each of these areas of the Oracle BI 12c architecture is very important.
There are a few noticeable changes in architecture terminology when comparing Oracle BI 11g to Oracle BI 12c. Let's call out a few of these key differences, as they are relevant to the language used throughout the book.
The first is that Fusion Middleware Home, as it relates to the installation of Oracle BI and the location of files in the file system, is now called ORACLE HOME. In Oracle BI 11g, Fusion Middleware Home was the base install folder for your Oracle BI 11g installation. The same concept is used in Oracle BI 12c; it is now rather more appropriately called the ORACLE HOME. This makes sense as traditionally, in an n-tier server architecture, the Oracle BI system is installed on its own application server. Therefore, it would be the only core Oracle technology application on a machine, not conflicting with any other Oracle home install locations from other applications.
The second is that the Oracle Process Management and Notification Server (OPMN) is no longer used to manage the Oracle BI System Components. This has been replaced by a more integrated process, which still allows start, stop, and status of Oracle BI to be controlled by the command line or through Enterprise Manager. These components, previously managed by the OPMN, are still referred to as the BI System Components (that is, BI Server, BI Presentation Server, and so on). This also means that the idea of instances is now replaced by Service Instances.
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 it to a position of having excellent software. 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 figure illustrates the main categories of products making up the current Oracle product stack:
The 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, Oracle Hyperion Oracle Web Center, and so on.
Similar to the previous Oracle BI version, Oracle BI 12c requires a relational database repository schema to hold metadata concerning the installation, report scheduling, usage tracking, auditing, and other aspects of the environment. As an initial set of steps in the installation process, these very necessary repositories are created using the Repository Creation Utility (RCU) against the selected database server. Chapter 2, Installing the Pre-requisite Software, goes into greater detail about this crucial repository structure. In Oracle BI 11g, two database schemas were installed with the RCU-Metadata Services (MDS) and BIPLATFORM. However, in Oracle BI 12c there can be up to nine database repository schemas for Oracle BI 12c that can be installed via the Oracle BI 12c RCU. There are now even more repository schemas that must be installed for Oracle BI 12c to be correctly installed and configured. The additional required schemas will have the suffixes WLS, WLS_RUNTIME, STB, and OPSS. Other schemas available are for auditing purposes, if optionally chosen for the implementation.
Note
Another interesting fact is that the Oracle BI Metadata Repository (RPD) is still a file, typically prefixed as RPD (that is, .rpd extension) and even in the latest version of Oracle BI the metadata is not stored in any database repository.
The Oracle BI Metadata Repository 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 end users.
The term Oracle BI Domain, as noted previously and shown in the illustration, is used as a way to group all Oracle BI 12c components within the Fusion Middleware (that is, WebLogic Server) architecture. This should not be confused with the WebLogic Application Server Domain, which is given the default name bi when following the default Oracle BI 12c 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 to the WebLogic Application Server, this is good to keep in mind from a technical perspective.
Note
When learning about the overall component composition, a very important detail to keep in mind is the manner 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. The Oracle BI System Components are now managed by the WebLogic Management Framework (WMF) which is the same system that manages the WebLogic Scripting Tool (WLST) functionality.
There are many components that comprise Oracle BI 12c. Oracle BI 12c can categorize these components by the class of programming languages in which they were developed. This is mainly either Java or C++. In comparison to previous versions of Oracle BI, where it seemed to be a somewhat compact environment, Oracle BI 12c is much more integrated into the larger platform of Fusion Middleware, which adds both value and complexity. Some of the same legacy component names persist; however, it should not be taken lightly that most legacy components have been renamed, removed, or placed under new management processes.
The following figure 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 comprise the Oracle BI Domain:
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.
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 EJBs.
New to Oracle BI 12c, this JEE deployment provides the Visual Analyzer (VA) analytical graphics system, which allows for data visualizations.
Java Management Extensions Managed Beans (JMX MBeans) allow dynamic API functionality for managing, configuring, and administering Oracle BI 12c.
SOA Web Service provides a web service interface to the contents of the Oracle BI Presentation Catalog. The tree of objects in the Oracle BI Presentation Catalog is exposed as a tree of web services, defined by a WSIL tree with WSDL leaves. An organization could use these services for Business Process Execution Language (BPEL) integration.
Oracle Real-Time Decisions (RTD) provides a decision-making rules engine that enables real-time business intelligence predictions and outcome analysis.
Presentation Services runs as a deployed JEE process, not as a web server, and does not communicate using any web server plug-in API. The Oracle BI Presentation Services Plug-in forwards HTTP requests to Oracle BI Presentation Services System Component to handle requests from HTTP traffic, such as browser-based user interfaces or SOAP requests.
The enterprise reporting solution for authoring and delivering highly formatted documents.
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.
This is a C++ process that does the data access and aggregates data from data sources. You can configure multiple BI Server processes, which share the load. No session replication takes place between the BI Server processes. This is the core of OBIEE, and provides the services for accessing and managing the RPD.
The BI Server does not maintain user session state. For high-availability deployments, query results are cached in the global cache.
This is a C++ process that generates the user interface pages and renders result sets on behalf of the Oracle BI Scheduler. You can configure multiple Presentation Services processes, which share the load. No session replication takes place between the Presentation Services processes.
Presentation Services is almost stateless. The only significant state is the client authentication. If Oracle Business Intelligence is configured to use single sign on for authentication purposes, then users do not have to re-authenticate after a failover. For all other authentication schemes, when failover occurs, clients will have to re-authenticate. The client sees an interruption of service and is redirected to a login page.
This is a C++ process that runs jobs according to a configurable frequency. Jobs may be agents created in the Oracle BI Presentation Catalog, or jobs created by the job manager. This scheduler differs from the Quartz scheduler that BI Publisher leverages. When scaled, only a maximum of two instances (one active, one passive) can be configured.
This is a Java process that includes resource-intensive graph and PDF rendering. It also allows BI Presentation Services to support BI Publisher and Java tasks within BI Scheduler. You can configure multiple JavaHost processes, which share the load. No session replication takes place between the JavaHost processes. The JavaHost is a stateless process. In Oracle BI 12c, JavaHost enables query access between Hyperion Financial Management (HFM) and Hyperion planning data sources integrated in the OBIEE RPD.
This is a C++ process that manages the population of BI Servers and Oracle BI Schedulers. It also distributes requests to the BI Server and ensures that requests are evenly load-balanced across scaled-out BI Servers in the domain. When scaled, only a maximum of two instances (one active, one passive) can be configured.
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:
Let's talk a little more in detail about the enterprise application server that is at the core of Oracle Fusion Middleware, WebLogic. 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 architecture (SOA). You can already see why BEA was a perfect acquisition for Oracle years ago. Or, more to the point, a perfect core for Fusion Middleware.
The WebLogic Server is a robust application in itself. In Oracle BI 12c, the WebLogic Server is crucial to the overall implementation, not just from installation but throughout the Oracle BI 12c lifecycle, which now takes advantage of the WebLogic Management Framework. Learning the management components of WebLogic Server that ultimately control the Oracle BI components is critical to the success of an implementation. These management areas within the WebLogic Server are referred to as the WebLogic Administration Server, WebLogic Manager Server(s) , and the WebLogic Node Manager.
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:
Clustered from the installation: The WebLogic Server license provided with out-of-the-box Oracle BI 12c does not allow for horizontal scale-out. An enterprise WebLogic Server license needs be obtained for this advanced functionality.
Contains an Embedded Web/HTTP Server, not Oracle HTTP Server (OHS): WebLogic Server does not contain a separate HTTP server with the installation. The Oracle BI Enterprise Deployment Guide (available on https://www.oracle.com/index.html) discusses separating the Application tier from the Web/HTTP tier, suggesting Oracle HTTP Server.
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.
Note
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 the same port as the Admin Server. It is not necessarily a native application deployment to the core WebLogic Server, but gets deployed and configured during the Oracle BI installation and configuration process automatically. In the deployments page within the Administration Console, you will find a deployment namedem.
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:
We 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 that provides control of the deployed Oracle BI application ancillary deployments, libraries, and several other configurations, is called the Enterprise Manager Fusion Middleware Control.
Tip
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 warrants an entire book devoted to the subject. For further reading, we recommend the Packt Publishing Advanced WebLogic Cookbook.
It would be difficult to discuss the overall architecture of Oracle BI without at least giving some mention to how the basics of security, authentication, and authorization are applied. By default, installing 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. Integration of secondary LDAP providers, such as Oracle Internet Directory (OID) or Microsoft Active Directory (MSAD), is crucial to leveraging most organizations' identity-management systems. The combination of multiple authentication providers is possible; in fact, it is commonplace. 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. Potentially, users may want another set of users to be stored in a relational database repository, or have a set of relational database tables control the authorization that users have in relation to the Oracle BI system. WebLogic Server provides configuration opportunities for each of these scenarios.
Oracle BI security incorporates the Fusion Middleware Security model, Oracle Platform Security Services (OPSS). This has a positive influence over managing all aspects of Oracle BI, 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 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, such as the Security Assertion Markup Language (SAML) 2.0. Other well-known single-sign-on mechanisms such as SiteMinder and Oracle Access Manager already have pre-configured integration points within Oracle BI Fusion Control. A later chapter will go into an exercise for creating new users and groups, and assigning application roles, but for now, here are a few key concepts to know about security:
Oracle BI 12c and Oracle BI 11g security is managed differently from the legacy Oracle BI 10g versions. Oracle BI 12c no longer has backward compatibility for the legacy version of Oracle BI 10g, and focus should be to follow the new security configuration best practices of Oracle BI 12c.
An Oracle BI 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.
As of Oracle BI 12c, the OPSS metadata is now stored in a relational repository, which is installed as part of the RCU-schemas installation process that takes place prior to executing the Oracle BI 12c installation on the application server.
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 on with the remainder of the book; however, once you complete the book and are ready to engage in more advanced discovery, you will want to research and understand these items to be more versed in managing Oracle BI security.
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.
Identity Store is the authentication provider, which may also provide authorization metadata. 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 Oracle Internet Directory or Microsoft Active Directory to reference users within an organization. These LDAP configurations are referred to as Authentication Providers.
The Credential Store is ultimately for advanced Oracle configurations. You may touch upon this when establishing an enterprise Oracle BI deployment, but not much thereafter, unless integrating the Oracle BI Action Framework or something equally as 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 at a later time without having to re-enter said credentials. An example of this would be integrating Oracle BI with the Oracle Enterprise Management (EPM) suite. In this example, let's pretend 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 not all users accessing the Oracle BI dashboard have credentials to access to the Oracle EPM environment directly, how could they open and view the report without being prompted for credentials? The answer is that the Credential Store is 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 presto, access!
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).
The first thing to recognize with infrastructure requirements prior to deploying Oracle BI 12c is that its memory and processor requirements have increased since previous versions. The Java Application server WebLogic Server installs 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. Be prepared for a recommended minimum 8 to 16 GB Read Access Memory (RAM) requirement for an Enterprise deployment, and a 6 to 8 GB RAM minimum requirement for a workstation deployment.
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.
Note
In Oracle BI 12c, a 64-bit Windows OS is a requirement for installing the Oracle BI Development Client tools. It has been observed that with some initial releases of Oracle BI 12c client tools, the ODBC DSN connectivity does not work in Windows Server 2012. Therefore, utilizing Windows Server 2012 as a development environment will be ineffective if attempting to open the Administration Tool and connecting to the OBIEE Server in online mode.
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:
How do we get our developers the best environment suitable for developing our metadata?
Do we need to procure new hardware?
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.
Note
The certification matrix for Oracle BI 12c can be found on the Oracle website at the following locations: http://www.oracle.com/technetwork/middleware/fusion-middleware/documentation/fmw-1221certmatrix-2739738.xlsx andhttp://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html.
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.
There are several reasons why an organization may wish to expand their Oracle BI 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 deployment, there are several crucial decisions to be made. These decisions can be greatly assisted by preparing properly, using Oracle's recommended guides for clustering and deploying Oracle BI on an enterprise scale.
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.
We would be remiss not to highlight one of the most important concepts of scaling out Oracle BI, 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 need to be shared across the nodes. If these common elements were not shared, if one node were to fail, there is a potential loss of data. Most importantly is that in a highly available Oracle BI environment, there can be only one WebLogic Administration Server running for that environment at any one time. A HA configuration makes one Administration Server active while the other is passive. If the appropriate pre-configuration 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 their environment.
OBIEE 12c requires you to modify the Singleton Data Directory (SDD) for your Oracle BI configuration found at ORACLE_HOME/user_projects/domains/bi/data, so that the files within that path are moved to a shared storage location that would be mounted to the scaled-out servers on which a HA configuration would be implemented. To change this, one would need to modify the ORACLE_HOME/user_projects/domains/bi/config/fmwconfig/bienv/core/bi-environment.xml file to set the path of the bi:singleton-data-directory element to the full path of the shared mounted file location that contains a copy of the bi data folder, which will be referenced by one ore more scaled-out HA Oracle 12c servers.
For example, change the XML file element:
<bi:singleton-data-directory>/oraclehome/user_projects/domains/bi/bidata/</bi:singleton-data-directory>
To reflect a shared NAS or SAN mount whose folder names and structure are inline with the IT team's standard naming conventions, where the /bidata folder is the folder from the main Oracle BI 12c instance that gets copied to the shared directory:
<bi:singleton-data-directory>/mount02/obiee_shared_settings/bidata/</bi:singleton-data-directory>
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.
In respect to the enterprise architecture and infrastructure of the Oracle BI environment, a clustered environment can be expanded in one of two ways: horizontally (scale-out) and vertically (scale-up). 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. A horizontally expanded system can then, additionally, be vertically expanded.
There are benefits to both scaling options. The decision to scale the system one way or the other is usually predicated on the cost of additional physical servers, server limitations, peripherals such as memory or processors, or an increase in usage activity by end users. Some considerations that 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
Need for failover or high availability
Costs for processor and memory enhancements versus the cost of new servers
Anticipated increase in concurrent user queries
Realized decrease in performance due to increase in user activity
When discussing scaling out the Oracle BI Server cluster, it is a common mistake to confuse the WebLogic Server application clustering with the Oracle BI Server Cluster Controller. Currently, Oracle BI 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 exists when the environment is scaled. In an Oracle BI scaled-out clustered environment, a secondary node, which has an instance of Oracle BI installed, will contain 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 gets 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 to say that when the main Oracle BI server engine instance fails, the secondary, or passive, Oracle BI Server engine then becomes active to route requests and field queries.
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.
In an effort to relay best practices and strategic deployment of large-scale enterprise Oracle BI deployment, Oracle lends a big helping hand and provides a topology referred to as the Enterprise Deployment Guide (EDG). This guide is not to be taken lightly. When deciding on the major factors of a full-scale, enterprise-wide Oracle BI deployment, this topology is what 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 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 12c in the subsequent chapters, you will see several references to files inside of the Oracle Home (for those familiar with Oracle BI 12c, this is the same concept as the Fusion Middleware home location, which is now redefined as Oracle Home) folder structure. It is recommended that, as you progress in your learning of Oracle BI 12c, you take note of which folders contain files pertinent to modifying the environment or assisting with troubleshooting efforts. The following figure illustrates the standard logical deployment structure for Oracle BI 12c:
Here are a few key directories that are worth remembering as, during an Oracle BI 12c implementation, you will reference them frequently:
ORACLE_BASE: This is the directory where you have chosen to install Oracle BI on the server as the base directory from which you have access. Typically, you will install into the main folder off one of the drive letters in Windows, or a sub-folder of a mounted directory in Linux, following some standard or best practice, for example:C:oracleor/mount01/apps/oracle/. Obviously, for maintenance purposes, create a base directory folder that is not too far from the main mount or drive letter.ORACLE_HOME: This is the location where Oracle BI 12c is installed from the installation process. There should only be oneORACLE_HOMEfor Oracle BI 12c on each physical server installation. For example:C:/oracle/obiee12c/, where child folders under this areuser_projects,wlserver,oracle_common, and so on.DOMAIN_HOME(BI_DOMAIN): This is the location of the established Oracle BI 12c WebLogic Server domain created to house the managed server information and BI System Components.Singleton Data Directory (SDD) is the location of the metadata for the Oracle BI 12c domain. It also holds information regarding clustering across multiple host servers.
BI_CONFIG_HOME: This is the location for all central configuration files related to the Oracle BI 12c. Such files found in all legacy versions of Oracle BI such asinstanceconfig.xml,NQSConfig.INIand so on are located within sub-directories of this folderDOMAIN_HOME/config/fmwconfig/biconfig/.BI Tools is the directory location which has the main lifecycle-management tools and options for deploying, migrating, starting, and stopping the Oracle BI 12c system. The lifecycle-management-tool executables are located in the folder
DOMAIN_HOME/bitools/bin/.
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/
|
Log name ( |
Location |
|
NQQuery ( |
|
|
NQServer ( |
|
|
NQSUDMLGen |
|
|
RPD Migration Utility |
|
|
SAW Log |
|
|
Java Host ( |
|
|
NQScheduler |
|
|
NQCluster |
|
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:
OBICCSccslogconfig.xmlOBIJHlogging_config.xmlOBIPSinstanceconfig.xmlOBISCHschedulerconfig.xmlOBISNQSConfig.xmlOBISlogconfig.xmlessbasecluster.properties
The download files for Oracle BI 12c can be found at the Oracle Technology Network (OTN), http://www.oracle.com/technetwork/index.html or on http://edelivery.oracle.com , both of which require a login with an Oracle account, which is free to create for anyone with a valid e-mail address:
Once you have downloaded these files, unzip them using either the Windows native zip utility or a utility such as 7-zip (http://www.7-zip.org/).
Make sure you have enough space to store, unzip the files, and install the software, as follows:
Recommended free disk space: Minimum 50 GB
For a full list of system requirements, hardware, software, operating systems, and so on, see the following guide: http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html.
Here's a quick checklist of items before you get started installing and configuring OBIEE:
Has the RCU been run to create the OBIEE 12c required database repositories?
Is the database running?
Do you have sufficient privileges to install the software (such as administrator privileges on the machine)?
Have you downloaded the correct operating-system binary files for OBIEE 12c?
Is your machine using DHCP or does it have a static IP address?
Note
The instructions in this chapter are for a static IP. If you are using DHCP, you'll need to install a Loopback Adapter. For instructions on installing the Loopback Adapter, see http://technet.microsoft.com/en-us/library/cc708322(WS.10).aspx.
During installation on a Windows OS, it is best practice to use the command prompt to access the folder structure and executable files for each part of the installation and configuration. Be sure to use the right-click function to execute the executable files using the Run as administrator option.
There are a few terms used in this chapter we believe every reader should research at their leisure after you've gone through the content in this book. Here are the ones we think are worth learning more about:
Weblogic Management Framework: http://www.oracle.com/pls/topic/lookup?ctx=fmw121400&id=ASCON11260
In this chapter, we reviewed the key areas of the Oracle BI system and its Fusion Middleware architecture, with WebLogic at the core of the system. You'll find that it is equally important to understand the infrastructure and architecture of both WebLogic Server and Oracle BI 12c for where they intersect, and where the additional power of WebLogic may be leveraged for more advanced technology operations such as lifecycle management and programmability.
In the next few chapters, you will install the Oracle BI 12c software. It might seem like a lot to digest at first, but in the end you'll have your own private sandbox, free to play with, and occasionally break, at your own discretion.
