Skip Headers
Oracle® Fusion Middleware High Availability Guide
11g Release 1 (11.1.1)

Part Number E10106-15
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

14 Configuring High Availability for Oracle Portal, Forms, Reports, and Discoverer

This chapter describes high availability concepts and configuration procedures for Oracle Portals, Forms, Reports, and Discoverer. This chapter includes the following topics:

14.1 Overview of Oracle Portal, Forms, Reports, and Discoverer

Oracle Portal offers a complete portal framework for building, deploying, and managing portals that are tightly integrated with Oracle Fusion Middleware. Oracle Portal provides a rich, declarative environment for creating a portal Web interface and accessing dynamic data with an extensible framework for Java EE-based enterprise application access.

With Oracle Portal, you can enhance your deployments with enterprise content management capabilities through Oracle Universal Content Management. In addition, you can add Enterprise 2.0 capabilities to existing portals using Oracle WebCenter Services. Oracle Portal has certified interoperability with both of these complementary solutions, as well as with Oracle enterprise applications and other Oracle Fusion Middleware components.

When Oracle Portal is implemented, it often becomes the entry point into an organization internet or intranet, and as such, it is crucial that it is as highly available as possible.

Oracle Forms is Oracle's long established technology to design and build enterprise applications quickly and efficiently.

Oracle Reports Services is the reports publishing component of Oracle Fusion Middleware. It is an enterprise reporting service for producing high quality production reports that dynamically retrieve, format, and distribute any data, in any format, anywhere. You can use Oracle Reports Services to publish in both Web-based and non-Web-based environments.

Oracle Discoverer is a business intelligence tool for analyzing data. It is a key component of Oracle Fusion Middleware. Discoverer provides an integrated business intelligence solution that comprises intuitive ad-hoc query, reporting, analysis, and Web publishing functionality. These tools enable non-technical users to gain immediate access to information from data marts, data warehouses, multidimensional (OLAP) data sources, and online transaction processing systems. Discoverer integrates seamlessly with Oracle Portal and Oracle WebCenter, enabling rapid deployment of Discoverer workbooks and worksheets to Web portals.

Oracle Portal, Forms, Reports and Discoverer can be installed individually or collectively.

14.1.1 Oracle Portal, Forms, Reports, and Discoverer Architecture

Figure 14-1 Illustrates a single-instance Oracle Portal, Forms, Reports, and Discoverer deployment.

Figure 14-1 Oracle Portal, Forms, Reports, and Discoverer Architecture

Oracle Portal, Forms, Reports, and Discoverer Architecture
Description of "Figure 14-1 Oracle Portal, Forms, Reports, and Discoverer Architecture"

Oracle Portal, Forms, Reports, and Discoverer Common Components

Figure 14-1 includes the following common components:

  • Oracle Web Cache performs two functions. Its primary function is to serve static Web content from its cache, much faster than could be achieved by the Oracle HTTP Server alone. If Oracle Web Cache does not have a cacheable page in its cache, or that page is not current, it requests the page from the attached Oracle HTTP Servers.

    The second function of Oracle Web Cache is used in high availability environments. It receives a request, and if it cannot service that request from its own cache, it can load balance it between several Oracle HTTP Servers.

    Oracle Web Cache is optional, but can be used in conjunction with Oracle Forms, Reports and Discoverer.

  • Oracle HTTP Server is responsible for assembling requested pages. Page assembly is not always straightforward. Depending on how the page is made up, the Oracle HTTP Server performs one of the following:

    • If the page is a simple HTML document, then the Web tier finds and returns the document.

    • If the Web page needs to be assembled by executing a Java EE application, the Oracle Web Tier routes the request to Oracle WebLogic Server, which, after processing the request, sends the result back to the user through the Oracle Web Tier.

    • If the Web page needs to be assembled by executing some other application such as PLSQL or CGI, the Oracle Web Tier routes the request to the appropriate application, and once that application has processed the request, it sends the result back to the user through the Oracle Web Tier.

    • If the requested page is security controlled, the Oracle Web Server invokes Oracle Identity Management to ensure that the user is authorized to view the page.

    The Oracle HTTP server can be used as stand-alone or in conjunction with Oracle Web Cache.

    In Oracle Portal, Forms, Reports and Discoverer deployments, the Oracle HTTP Server uses an Apache module called mod_wl_ohs to route requests to the Oracle WebLogic Managed Servers. When WebLogic Managed Servers are clustered together, mod_wl_ohs load balances requests among all Managed Servers in a given cluster.

  • Oracle WebLogic Managed Servers are the Java EE runtime containers for Oracle Portal, Forms, Reports and Discoverer Applications.

  • Oracle Process Manager and Notification Server (OPMN) is used to start, stop, and monitor Oracle Web Cache and Oracle HTTP Server. It periodically polls Oracle Web Cache and the Oracle HTTP Server to ensure that they are functioning. If they are not functioning, OPMN takes appropriate action to restart the failed component to ensure that service is maintained.

  • Oracle Node Manager is used to start, stop, and monitor Oracle WebLogic Managed Servers including the Administration Server. It periodically polls the WebLogic Managed Servers to ensure that they are functioning. If they are not functioning, the Oracle Node Manager takes appropriate action to restart the failed component to ensure that service is maintained.

  • The Oracle WebLogic Administration Server contains both the WebLogic Administration Console and the Oracle Fusion Middleware Enterprise Manager. It is active only once within a WebLogic domain. If the server hosting the Administration Server fails, it must be manually restarted elsewhere.

  • Oracle Single Sign-On is Oracle's Enterprise authentication mechanism. Oracle Single Sign-On is integrated into Oracle HTTP Server for each of the product components. When a request which requires authentication comes in to the Oracle HTTP Server, it determines whether the user has been authenticated through the Oracle Single Sign-On server. If the user has been authenticated, the request is processed. If however, the user has not been authenticated, the Oracle Single Sign-On server is contacted to gain authorization.

14.1.2 Common Log Files

The following table lists, describes, and provides the location for generic log files used by Oracle Portal, Forms, Reports, and Discoverer:

File Location Description
access_log ORACLE_INSTANCE/diagnostics/logs/OHS/ohs1 Lists each access to the Oracle HTTP Server and the HTTP Return code
ohs1.log ORACLE_INSTANCE/diagnostics/logs/OHS/ohs1 HTTP Server error log
access_log ORACLE_INSTANCE/diagnostics/logs/WebCache/web1 Lists each access to Oracle WebCache and the HTTP Return code
access_log DOMAIN_HOME/servers/WLS_PORTAL/logs Lists access requests being received by the WebLogic Managed Server
opmn.log ORACLE_INSTANCE/diagnostics/logs/OPMN OPMN log files

14.1.3 Common Component Failures and Expected Behaviors

This section describes high availability concepts that apply to Oracle Portal, Forms, Reports, and Discoverer.

14.1.3.1 Oracle Web Cache and Oracle HTTP Server Process Failures

Oracle HTTP Server, Oracle Web Cache, and Oracle Discoverer preference server processes are protected by the Oracle Process Manager and Notification system (OPMN). If one of these processes fails, OPMN automatically restarts the process.

Oracle WebLogic Managed Servers are started and monitored by Oracle Node Manager. If an Oracle WebLogic Managed Server fails, Oracle Node Manager restarts the process.

14.1.3.2 Common Component Node Failures

If a node that is not fronted by Oracle Web Cache fails, the Load balancer automatically reroutes requests to a surviving node.

If Oracle Web Cache fails, the Load Balancer automatically reroutes requests to a surviving web cache node.

If a node with Oracle HTTP Server fronted by Oracle Web Cache fails, Oracle Web Cache reroutes the request to a surviving Oracle HTTP Server.

If Oracle WebLogic Server fails, Oracle HTTP Server reroutes requests to another WebLogic cluster member.

Oracle Portal, Forms, Reports and Discoverer requests being processed by the failed node must be restarted.

14.1.3.3 Common Component WebLogic Managed Server Failures

In a high availability configuration, Oracle WebLogic Managed Servers are clustered together. If one of the managed servers fails, mod_wl_ohs automatically redirects requests to one of the surviving cluster members. If the application stores state, state replication is enabled within the cluster, which allows redirected requests access to the same state information.

14.1.3.4 Common Component Database Failures

Databases are recommended to be implemented using high availability technologies such as Oracle Real Application Clusters. If one of the database nodes fails, the database as a whole remains available. In some cases you may have to resubmit the request.

In a multi database node environment, if a user session is connected to the database node that fails, the following occurs:

  • Oracle Portal: The user is required to resubmit the request.

  • Oracle Forms: The user is required to resubmit the request.

  • Oracle Reports: If the database connect string is configured using Oracle Transparent Application Failover, no action is required (unless the report writes to a database during its execution).

    If the database containing the reports queue loses a node, then the user is required to resubmit the report request.

  • Oracle Discoverer: The user is required to resubmit the request.

14.1.4 Oracle Portal, Forms, Reports, and Discoverer Cluster-Wide Configuration Changes

Oracle Web Cache instances are clustered. Once a configuration change is made through the Oracle Fusion Middleware Console or through the Oracle Web Cache Administration utility, these changes are propagated to other cluster members. Propagation is done manually using these tools.

Oracle HTTP Servers are not clustered. The Oracle HTTP server configuration is file-based. As a result, changes made to one Oracle HTTP Server must be manually copied to other Oracle HTTP Servers in the configuration. This also applies to static HTML files stored in the htdocs directory.

Configure Oracle Portal, Forms, Reports and Discoverer using a series of configuration files. Any changes to these files must be manually applied to all members in the architecture.

WebLogic Managed Servers are clustered and share resources at the cluster level. Changes to these resources can be made once without the need for propagation. These resources include:

  • Data sources

  • Application redeployments

  • State replication

14.1.5 Common Component Log File Information

Cluster wide log consolidation is not offered for Oracle Web Cache, Oracle HTTP Server, OPMN, and WebLogic Managed Servers. For information about the status of an Oracle HTTP Server application, refer to the log files on each Oracle HTTP Server node. To For information about the status of an failed application, refer to the log files on each Server node.

14.2 Oracle Portal and High Availability Concepts

This section describes single-instance information, as well as high availability concepts specific to Oracle Portal. This section guides you through the concepts and considerations necessary for creating a successful high availability Oracle Portal deployment.

14.2.1 Oracle Portal Single-Instance Characteristics

For information about the single-instance architecture of Oracle Portal, see the following sections in the Oracle Fusion Middleware Administrator's Guide for Oracle Portal.

14.2.1.1 Oracle Portal Request Flow

For information about request flow in Oracle Portal, see the following sections in the Oracle Fusion Middleware Administrator's Guide for Portal Guide:

14.2.1.2 Oracle Portal Component Characteristics

The following lists the characteristics of Oracle Portal components:

  • Oracle Portal application runs inside a WebLogic container (WLS_PORTAL).

  • Oracle Portal repository stores metadata, documents, customizations, and personalizations.

  • Oracle Portal has a strong dependency on Oracle Web Cache to process and cache content.

  • Oracle Portal depends on Oracle HTTP server to route traffic to WebLogic Server, service product images, and rewrite URLs.

14.2.1.3 Oracle Portal Startup and Shutdown of Processes and Lifecycle

Oracle Portal does not have any process of its own. It relies on standard Oracle tools and utilities to manage Oracle Web Cache, Oracle HTTP Server, WebLogic Managed Server WLS_PORTAL, and the database.

The following lists the configuration and monitoring interfaces for Oracle Portal components:

  • Enterprise Manager for managing Oracle Web Cache, Oracle HTTP Server, Oracle Portal, and WLS_PORTAL

  • Oracle WebLogic Administration Console for managing WLS_PORTAL

  • Oracle WebLogic Scripting Tool (WLST) for adding or editing Portal-specific configuration parameters

  • The opmnctl command line interface for managing Oracle Web Cache and Oracle HTTP Server

14.2.1.4 Oracle Portal Deployment Artifacts

The Portal application is deployed as a staged application (portal.ear) to WebLogic Server (WLS_PORTAL). The configuration files are available in DOMAIN_HOME/servers/WLS_PORTAL/stage/portal/portal/configuration

14.2.1.5 Oracle Portal Configuration Information

Some of the Portal configuration is stored in the Portal repository. This information includes site details (site host and port), Web Cache details (webcache host, invalidation port, and invalidation password), and Oracle Internet Directory details (Oracle Internet Directory host and port). Such information can be changed by accessing Enterprise Manager or by using WLST commands for any of the containers.

The remaining Portal configuration is available in configuration files that are located inside the staged location of the Portal application. Such configuration files are located in DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/. In the HA environment, if a configuration file is modified, the same change must be repeated on each WLS_PORTAL instance either by repeating the action on each node or by copying over the configuration files from one node to another.

Table 14-1 Portal Configuration Files

Configuration File Description

appConfig.xml

Portal Page Engine configuration

portal_dads.conf

Portal Database Access Descriptor (DAD) configuration

This file contains properties related to High Availability (HA). It contains connect string information to the database. If Oracle RAC nodes are added or removed, this file must be updated to reflect the final set of nodes. The file contains a configuration property, which can be enabled to test a pooled database connection before using it. At a minimal cost, this property can be enabled to ensure better results when a database node goes down.

portal_cache.conf

Portal Cache configuration

portal_plsql.conf

Portal global settings


14.2.1.6 Oracle Portal Logging and Log Configuration

Portal log files are generated in the DOMAIN_HOME/servers/WLS_PORTAL/logs directory. The log file is named WLS_PORTAL-diagnostic.log. Log rotation ensures that older logs are archived with a similar name. The configuration of log files in Portal is controlled by the logging.xml file, which is located in DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL.

14.2.1.6.1 Oracle Portal Log Files

The following table lists and describes log files used by Oracle Portal:

File Location Description
WLS_PORTAL.log DOMAIN_HOME/servers/WLS_PORTAL/logs Log file for the WebLogic Managed Server
WLS_PORTAL.out DOMAIN_HOME/servers/WLS_PORTAL/logs Supplemental log file for the WebLogic Managed Server. This is generally the first place to look for WebLogic issues.

14.2.1.7 Oracle Portal External Dependencies

Oracle Portal requires an Oracle HTTP Server to service requests. Optionally these requests may be cached by Oracle Web Cache, in which case it also acts in the capacity of a load balancer.

Oracle Portal requires a database to store information. This database is pre-seeded with schemas using the Oracle Repository Creation Assistant.

14.2.2 Oracle Portal Protection from Failures and Expected Behavior

Figure 14-2 illustrates a high availability configuration for Oracle Portal.

Figure 14-2 Oracle Portal High Availability Deployment

Oracle Portal High Availability Deployment
Description of "Figure 14-2 Oracle Portal High Availability Deployment"

The Oracle Portal high availability setup includes two or more Oracle Web Cache instances. These Oracle Web Cache instances are clustered together to provide cache consistency and failover. Each Oracle Web Cache is configured to route traffic to two or more Oracle HTTP servers, and these servers load balance incoming requests.

Each Oracle HTTP Server is configured to route Oracle Portal requests to two or more Oracle WebLogic managed servers, which host the Oracle Portal application. Oracle HTTP Server is a web server provided by Oracle Fusion Middleware. It incorporates an OpenSSL module to support Secure Sockets Layer (SSL) and HTTP Secure Sockets Layer (HTTPS). Oracle HTTP Server also provides a mod connector to route traffic to Oracle WebLogic Server, which runs Java servlets and J2EE applications. Oracle Portal relies on Oracle HTTP Server to service product images and rewrite URLs rewriting, in some scenarios.

WLS_PORTAL is the WebLogic Server that runs the Oracle Portal application. WebLogic Server provides a complete Java EE environment that includes a JSP translator, a JSP servlet engine (OJSP), and an Enterprise JavaBeans (EJB) container. It provides a fast, lightweight, highly scalable, easy-to-use, complete Java EE environment. It is written entirely in Java and executes on the standard Java Development Kit (JDK) Virtual Machine (JVM).

The Portal application running inside WLS_PORTAL works closely with Oracle Web Cache, using its Edge Side Includes (ESI) processing, to service dynamic Portal pages in a secure fashion. Oracle Portal uses ESI to securely cache various pieces of metadata and content in Oracle Web Cache. As content changes, Oracle Portal invalidates any cached copies in Oracle Web Cache. Such content is regenerated in a subsequent request. ESI allows content to be cached at a more granular level, thereby increasing the cache hit ratio and enabling a more granular invalidation of Portal content. For most content/metadata, Oracle Portal also backs up the in-memory content in Web Cache into the Portal Cache, which is based on file system.

Oracle Portal stores its content and metadata information in a database. To ensure that the database is not a single point of failure, the database is built using Oracle Real Application Clusters.

Finally, a load balancer front ends the Oracle Web Cache instances to provide a single virtual access point to Oracle Portal. Besides load balancing external traffic coming from the browser, the load balancer also provides load balancing for internal traffic generated by Oracle Portal (referred to as Portal Loopback Requests). The load balancer also provides load balancing of invalidation messages generated from the Portal metadata repository. Such invalidation requests are sent to Oracle Web Cache to invalidate any stale content cached in Oracle Web Cache. The clustering feature in Oracle Web Cache ensures cache consistency across the Oracle Web Cache instances.

Note:

If you are deploying your own producers, ensure that there is redundancy for the Producers and the producers are front-ended by a load balancer. This step ensures that there is no single-point of failure in the system.

14.2.2.1 Oracle Portal Process Failures

Due to redundancy in each component, if a particular process goes down, Oracle Portal continues to work. Note that Oracle Portal does not attempt to retry a request. Therefore, if a failure occurs while processing a particular request, that request fails.

14.2.2.2 Oracle Portal Node Failures

For information about Oracle Portal Node failure, see Section 14.1.3.2, "Common Component Node Failures."

14.2.2.3 Oracle Portal WebLogic Managed Server Failures

For information about Oracle Portal WebLogic Managed Server failure, see Section 14.1.3.3, "Common Component WebLogic Managed Server Failures."

14.2.2.4 Oracle Portal Protection from Database Failures

For information about Oracle Portal database failure, see Section 14.1.3.4, "Common Component Database Failures."

14.3 Oracle Reports and High Availability Concepts

This section describes single-instance information, as well as high availability concepts specific to Oracle Reports. This section guides you through the concepts and considerations necessary for creating a successful high availability Oracle Reports deployment.

14.3.1 Oracle Reports Single-Instance Characteristics

Oracle Reports Services is the reports publishing component for Oracle Fusion Middleware. It is an enterprise reporting service for producing high quality production reports that dynamically retrieve, format, and distribute any data, in any format, anywhere. Oracle Reports Services can be used to publish in both Web-based and non-Web-based environments.

The following components are specific to Oracle Reports:

Oracle Reports Server

The Reports Server (rwserver) processes client requests, including ushering them through its various services, such as authentication and authorization checking, scheduling, caching, and distribution (including distribution to custom-or pluggable-output destinations). The Reports Server also spawns runtime engines for generating requested reports, fetches completed reports from the Reports Server cache, and notifies the client that the job is ready.

The reports server can be run stand-alone or in-process.

Oracle Reports Engine

The Reports Engine includes components for running SQL-based and pluggable data source-based reports, fetches requested data from the data source, formats the report, sends the output to cache, and notifies the Reports Server that the job is complete.

Oracle Reports Cache

The Reports Cache is used to store the output of reports, which have been successfully run. By using the reports cache it is not necessary to generate the same report repeatedly.

Oracle Reports Queue

The Reports Queue contains a list of the report requests. When processing capacity becomes available, the next report in the queue is executed.

Oracle Reports Customer Databases

Typically, reports are compiled using information stored in a variety of databases. These are referred to as customer databases.

Oracle Single Sign On

Although advisable it is not a mandatory requirement to restrict access to Oracle Reports using Oracle Single Sign-On (SSO).

14.3.1.1 Oracle Reports State Information

Oracle Reports only state information is job metadata. For example, which reports are to be run, and the parameters with which they are run. This is often referred to as the reports queue. This information is stored in operating system files servername.dat, or alternatively in a database.

14.3.1.2 Oracle Reports External Dependencies

Oracle Reports requires Oracle HTTP Server to service requests. Optionally these requests may be cached by Oracle Web Cache, in which case it also acts in the capacity of a load balancer.

14.3.1.3 Oracle Reports Specific Configuration Files

The following table lists and locates configuration files used by Oracle Reports:

File APPHOST1 Location APPPHOST2 Location
rwserver.conf DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_11.1.1.2.0/configuration/ DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_11.1.1.2.0/configuration/
reports_ohs.conf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

14.3.1.4 Oracle Reports Connection Retry

This section describes the following connection retries:

  • Oracle Portal Database Connection Retry:

    If the connection from the Reports Server to the Oracle Portal database schema is dropped, the Reports Server tries to reestablish the connection before generating an error. If reconnection is successful, there is no need to restart the Reports Server.

  • Oracle Internet Directory Connection Retry:

    If the Oracle Internet Directory connection becomes stale, the Reports servlet and the Reports Server try to reestablish the connection before generating errors. If reconnection is successful, there is no need to restart the Reports Server.

  • Oracle Metadata Repository and Oracle Identity Management Outage:

    The outage of the Oracle Metadata Repository (which stores security metadata) does not bring down the Reports Server. If the Oracle Metadata Repository is unavailable, the Reports Server rejects new requests as a result of the component being unavailable. When the Oracle Metadata Repository is brought back on-line, the Reports Server recovers itself and begins to receive and process new requests.

    If Oracle Identity Management components become unavailable, the Reports Server also reject new requests, much like the outage of the Oracle Metadata Repository.

  • Reports Server Timeout:

    The Reports Server has a configurable timeout for waiting for requests to be returned from the database. This timeout must be set to a high enough value to allow valid reports to run but not so high as to cause excessively long waits.

14.3.1.5 Oracle Reports Process Flow

The various components of Oracle Reports Services contribute to the process of running a report as follows:

  1. The client requests a report by contacting a server through a URL (Web)

  2. The Reports Server processes the request as follows:

    If the request includes a TOLERANCE option, the Reports Server checks its cache to determine whether it already has output that satisfies the request. If it finds acceptable output in its cache, then it immediately returns that output rather than rerunning the report.

    If the request is the same as a currently running job, it reuses the output from the current job rather than rerunning the report.

    If neither of these conditions is met:

    • If Oracle Reports Servlet (rwservlet) is SSO-enabled, it checks for authentication. A secure Reports Server then authorizes the user using Oracle Internet Directory. If Oracle Reports Servlet (rwservlet) is not SSO-enabled, a secure Reports Server authorizes and authenticates the user.

    • If the report is scheduled, the Reports Server stores the request in the scheduled job queue, and the report is run according to schedule. If the report is not scheduled, it is queued in the current job queue for execution when a Reports Engine becomes available.

  3. At runtime, the Reports Server spawns a Reports Engine and sends the request to that engine to be run.

  4. The Reports Engine retrieves and formats the data.

  5. The Reports Engine populates the Reports Server cache.

  6. The Reports Engine notifies the Reports Server that the report is ready.

  7. The Reports Server accesses the cache and sends the report to output according to the runtime parameters specified in either the URL, the command line, or the keyword section in the cgicmd.dat file (URL requests only).

If a report server dies while running a request the request must be resubmitted. Once resubmitted, one of the surviving reports servers processes the request.

14.3.1.6 Oracle Reports Log Files

The following table shows log files used by Oracle Reports:

File Location Description
WLS_REPORTS.log DOMAIN_HOME/servers/WLS_REPORTS/logs Log file for the WebLogic Managed Server
WLS_REPORTS.out DOMAIN_HOME/servers/WLS_REPORTS/logs Supplemental log file for the WebLogic Managed Server. This is generally the first place to look for WebLogic issues.
rwservlet_diagnostic.log DOMAIN_HOME/servers/WLS_REPORTS/logs Log information relating to the Reports servlet.
rwserver_diagnostic.log DOMAIN_HOME/servers/WLS_REPORTS/logs Log information relating to the Reports server

14.3.2 Oracle Reports Protection from Failure and Expected Behavior

Figure 14-3 illustrates an example Oracle Reports high availability deployment.

Figure 14-3 Oracle Reports High Availability Deployment

Oracle Reports High Availability Deployment
Description of "Figure 14-3 Oracle Reports High Availability Deployment"

As shown in Figure 14-3, the Oracle Real Application Clusters database provides a high availability repository for the reports queue. In high availability configurations, each Reports server has access to the same reports queue. A shared reports queue ensures that any request is only processed once, but it can be processed by any Reports server in the deployment.

Typically, reports are compiled using information stored in a variety of databases, the diagram above refers to these databases as customer databases.

In order to make full use of the Reports cache, the cache should be available to any of the Reports servers in the implementation. This way reports generated by one Reports server can be reused or served by any Reports server. In Figure 14-3, the Reports cache is made available using a shared directory.

Single Sign-On (SSO) is not required to restrict access to Oracle Reports, however, many organizations do restrict access to Oracle Reports using Oracle Single Sign-on. This chapter includes the steps required to protect the deployment using Oracle Single Sign On.

The in-process Reports server is recommended for high availability reports deployments. The in-process reports server runs inside Oracle WebLogic Server and the Reports servers themselves can be clustered to ensure that high availability is maintained.

When using Web Cache in a highly available distributed configuration, it is important that contents of all of the distributed caches are consistent. For example, the same cached copy of a given report is available from any Oracle Web Cache instance. When cached content becomes invalid, it is essential that it becomes invalid in all of the web caches. To achieve this goal web cache clustering is used.

The Diagram above includes the Web Logic Administration Server and shows how it can be positioned on APPHOST2. To determine how to do this refer to the appropriate chapter elsewhere in this guide.

14.3.2.1 Oracle Reports Process Failures

If the Reports Server hangs or fails to respond, but the WebLogic Managed Server does not, the WebLogic Managed Server must be restarted manually.

14.3.2.2 Oracle Reports Node Failures

For information about Oracle Reports Node failure, see Section 14.1.3.2, "Common Component Node Failures."

14.3.2.3 Oracle Reports WebLogic Managed Server Failures

For information about Oracle Reports WebLogic Managed Server failure, see Section 14.1.3.3, "Common Component WebLogic Managed Server Failures."

14.3.2.4 Oracle Reports Database Failures

For information about Oracle Reports database failure, see Section 14.1.3.4, "Common Component Database Failures."

14.4 Oracle Forms and High Availability Concepts

This section describes single-instance information, as well as high availability concepts specific to Oracle Forms. This section guides you through the concepts and considerations necessary for creating a successful high availability Oracle Forms deployment.

14.4.1 Oracle Forms Single-Instance Component Characteristics

In the Oracle Fusion Middleware Forms Services architecture there is only one connection between the client and the HTTP Listener, much like any Web-based application. The HTTP Listener routes the request to the Forms Listener Servlet, which controls routing the requests from the Forms client to the Forms runtime.

The communication between the Forms client and the Forms runtime always goes through the HTTP Listener, leaving the application with only one port open to the network.

The client sends HTTP requests and receives HTTP responses from the HTTP Listener process. With the HTTP Listener acting as the network endpoint for the client, the other server machines and ports are not exposed at the firewall.

14.4.1.1 Oracle Forms State Information

Oracle Forms employs a stateful architecture. Each Runtime process keeps the state for the client it serves in working memory. No state is ever, or can ever be, serialized or shared between runtime processes

14.4.1.2 Oracle Forms Database Requirements

Oracle Forms only requires access to the databases with which it will interact. There are no special requirements for Oracle Forms itself.

14.4.1.3 Oracle Forms Request Flow

The Oracle Forms request flow is as follows:

  1. The user chooses a Link from a Web page, or types a URL directly in the Browser.

  2. The HTTP Listener interprets the URL that is passed and displays an HTML page containing an <EMBED> or <OBJECT> tag (depending on which browser is used) that describes the Forms Java Client to the Browser. The URL that is passed calls the Forms Servlet to create an HTML page dynamically based on the base.html files located on the web server.

  3. The Client receives the HTML file served by the HTTP Listener. The tag in the HTML file supples the information required to locate the Java Class files that make up the Forms Java Client. Within the tag in the HTML file you supply information about the Form that should run, and any other parameters that you want to pass to your Forms session, such as the Login information. The tag definition also contains instructions on what Forms Services to run and many parameters which help to customize aspects of the Java Client, including the look-and-feel, and color schemes.

    The HTML file might also contain other HTML attributes such as those to tell the browser to run this particular applet using a particular version of the JRE on the client.

  4. The Browser then asks the HTTP Listener for the Java Class files from the location specified in the HTML file. The CODEBASE parameter in the HTML file is used to define this. The files may be downloaded individually or as an "Archive". This archive has an extension of .JAR and can be best thought of as a .ZIP file containing all of individual CLASS files required by the applet. The use of a JAR file speeds up the download of the Java Client and enables caching on the client for subsequent calls. The ARCHIVE parameter defines which (if any) .JAR file should be used. The JRE plug-in carries out the additional step of checking the version of the Forms Client Java code available on the HTTP Listener and only downloads it if it turns out to be newer that any version that the plug-in currently has cached.

  5. The CLASS or JAR files are downloaded (if not already present) to the Browser and the Java applet starts.

  6. The Java Client applet sends a request to start a Forms session through the HTTP Listener to the Forms Listener Servlet. The Forms Listener Servlet is defined by the serverURL parameter in the HTML file's tag.

  7. After receiving the connection request from the Java Client, the Forms Listener Servlet starts a new Forms Runtime process for this client. You can define user specific environments for each runtime process by setting the Servlet initialization envFile parameter in the formsweb.cfg configuration file to a specific environment file.

  8. The Forms Runtime process allocated to this client, loads the module specified in the HTML file and any libraries and menus that are required by that form. All communication between the Forms Client and the Forms Runtime process is passed through the Forms Listener Servlet.

  9. The user is prompted for database login information, if this had not already been supplied, and the connection to the database server is established.

  10. The user is now ready to work.

14.4.1.4 Oracle Forms Configuration Persistence

Oracle Forms uses several files for startup configuration:

  • formsweb.cfg holds the Forms specific startup parameters for the runtime process that used to be expressed on the command line. It consists of a default section that is used if no specific section is used and one or more user sections that holds parameters specific to that section. These sections correspond to what is referred to as an application, a set of forms that belong to the same logical unit.

    formsweb.cfg is located in the following directory:

    DOMAIN_HOME/config/fmwconfig/servers/<FORMS_MANAGED_SERVER>/applications/formsapp_11.1.1/config
    
  • default.env holds startup parameters that used to be expressed in environment variables. On Windows these variables can also be put in the system registry.

    This file is located in the same directory as formsweb.cfg:

    DOMAIN_HOME/config/fmwconfig/servers/<FORMS_MANAGED_SERVER>/applications/formsapp_11.1.1/config
    

    It is possible to create customized .env files with different names. If such files exist, they are specified in the formsweb.cfg and are thus discoverable.

  • base.html and basejpi.htm or a customized version of either, holds the template structure for the HTML code that launches the Forms client applet.

    These files are located in the following directory:

    ORACLE_INSTANCE/config/FormsComponent/forms/server
    
  • Registry.dat holds the default location and search paths for fonts, icons, and images. Find this file in:

    DOMAIN_HOME/config/fmwconfig/servers/<FORMS_MANAGED_SERVER>/applications/formsapp_11.1.1/config/forms/registry/oracle/forms/registry
    
  • frmweb.res holds key binding definitions for the Forms client. The bindings define the relationships between keyboard keys and the internal Forms functions they can trigger. For UNIX this bindings file is located at:

    ORACLE_INSTANCE/config/FormsComponent/forms/admin/resource/<language>
    

    Where <language> is a two character language denominator. For Windows this file is available at:

    ORACLE_INSTANCE/config/FormsComponent/forms
    

    On Windows, the language is defined by putting the language abbreviation at the end of the file name: frmwebf.res for French for example.

  • jvmcontroller.cfg is the file for configuring JVM Controller(s). Any controllers configured for the system will have been defined in this file. This file is located in the following directory:

    ORACLE_INSTANCE/config/FRComponent/frcommon/tools/jvm/
    

14.4.1.5 Oracle Forms Runtime Considerations

The Oracle Fusion Middleware Forms Services is made up of three components: a Forms Client that is downloaded automatically to the end user's client machine and cached, the Forms Listener Servlet, and the Forms Runtime, on the middle tier.

Oracle Forms Client (Java Applet)

When a user runs a Forms session, the Forms Client, a thin 100 percent Java Applet, dynamically downloads from the Oracle Fusion Middleware Application Server. This generic Java Applet provides the classes for rendering the user interface for the associated Forms Runtime process on the middle tier, and handles user interaction and visual feedback, such as that generated by navigating between items or checking a checkbox. The same Java applet is used for all Forms application, therefore it is downloaded only once and cached on the client and so is available for subsequent Forms applications.

In order to run a Java applet in a browser, it is necessary to have a Java Runtime Engine (JRE) installed. The JRE is installed on the client and is platform dependent.

Oracle Forms Runtime Process

The Forms Runtime process is the process that maintains a connection to the database on behalf of the Forms Client. The process is created when a user accesses a page containing a Forms application. The process is automatically stopped when the user closes the Forms application or terminates the browser window.

Oracle Forms Listener Servlet

The Forms Listener Servlet manages:

  • The creation of a Forms runtime process for each client when a user requests to run a Forms application.

  • The Forms Listener Servlet is also in charge of stopping the runtime process as the user closes the Forms application or terminates the browser window.

  • Network communications between the client and its associated Forms runtime process

14.4.1.6 Oracle Forms Process Flow

The various components of Oracle Forms Services contribute to the process of running and Oracle Form as follows:

  1. Client requests a form by contacting a server through a URL.

  2. Oracle HTTP Server routes the request to Oracle WebLogic Server

  3. Oracle WebLogic Server creates a forms Runtime process to run the form.

If a middle tier server crashes or a servlet session is interrupted, recover from either failure by restarting the application. A new Forms Runtime is created by doing so and any unsaved data can be reentered. The unsaved data does not cause database corruption since Forms uses atomic transactions which guarantees that database saves happen in an orderly and defined manner.

14.4.1.7 Oracle Forms Configuration Files

The following table shows configuration files used by Oracle Forms:

File APPHOST1 Location APPHOST2 Location
formsweb.cfg DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config
default.env DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config
base(jpi).htm DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config
Registry.dat DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config/forms/registry/oracle/forms/registry DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config/forms/registry/oracle/forms/registry
frmweb.res UNIX:

ORACLE_INSTANCE/config/FormsComponent/forms/admin/resource/<language>

Windows:

ORACLE_INSTANCE/config/FormsComponent/forms

UNIX:

ORACLE_INSTANCE/config/FormsComponent/forms/admin/resource/<language>

Windows:

ORACLE_INSTANCE/config/FormsComponent/forms

jvmcontroller.cfg ORACLE_INSTANCE/config/FRComponent/frcommon/tools/jvm/ ORACLE_INSTANCE/config/FRComponent/frcommon/tools/jvm/
forms.conf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

14.4.1.8 Oracle Forms External Dependencies

Oracle Forms requires an Oracle HTTP Server to service requests. Optionally these requests may be cached by Oracle Web Cache, in which case it also acts as a load balancer.

Oracle Forms uses Sun's Java plug-in (JRE) on the client to run the Forms Java Client.

14.4.1.9 Oracle Forms Log Files

The following table shows log files used by Oracle Forms:

File Location Description
WLS_FORMS.log DOMAIN_HOME/servers/WLS_FORMS/logs Log file for the WebLogic Managed Server
WLS_FORMS.out DOMAIN_HOME/servers/WLS_FORMS/logs Supplemental log file for the WebLogic Managed Server. This is generally the first place to look for WebLogic issues.
Various ORACLE_INSTANCE/FormsComponent/forms/trace Forms trace files, generated if a Forms runtime process fails.

The filename has the format:

<forms_runtime_process>_dump_<process_id>

Forms runtime process does not write to a log file under normal operation

Various DOMAIN_HOME/servers/WLS_FORMS/logs Listener Servlet logs

14.4.2 Oracle Forms Protection from Failover and Expected Behavior

Oracle Forms has no serializable state, which means that transparent failover is not possible. If a runtime process fails, the client process served by that server process also fails. Oracle Forms employs atomic database transactions. With atomic transactions, a set of data, a record, or set of records, is either fully saved or not saved at all. As a result, the failure causes data not yet saved to be lost in a defined and precise manner. The data must be re-entered by the user when the application is restarted. If the process failed as a result of the machine it ran on failing, a substantial part, or all of the existing capacity to service the user base may be unavailable. In this scenario the application as a whole may be unavailable. To ensure continuity one option is to have redundant capacity either in an active-active or active-passive configuration.

Figure 14-4 Oracle Forms High Availability Deployment

Oracle Forms High Availability Deployment
Description of "Figure 14-4 Oracle Forms High Availability Deployment"

14.4.2.1 Oracle Forms N+1 Redundancy

N+1 refers to an approach to redundant capacity that is based on the idea that hardware tends to break in units rather than in groups, meaning that a network of computers is more likely to lose one of its components rather than lose several at the same time. The principal of N+1 is to have as many machines as needed to service the entire user base at peak load plus one additional unit of equal capacity as the machine with the largest capacity in the set. This is often referred to as active-passive failover, since the failover happens on the machine level.

If you had six servers in your deployment that can handle the entire user base and are identically configured, they all have an HTTP Server and a Java Runtime and the Forms Runtime installed. There is a hardware (or software) load balancer to ensure that no single server is over utilized. The load balancer is aware of one machine labeled Standby, which has the same capacity as the machine with the largest capacity among the rest of the set, and is identically configured to all of them, but does not route to it. In an active-passive scenario, the standby machine doesn't have to be running. In an active-active scenario it could be an active part of the set, and provide spare capacity in an ongoing basis.

Now let's assume one of the machines fails:

If one of the machines fails, the standby machine is brought online and the load balancer has been reconfigured to route new requests to that machine as well, and to ignore the failed machine (some hardware load balancers do these two steps automatically). If the standby machine was already running and serving the user base in an active-active deployment, the downtime may be as small as the time it takes to restart the browser on the client. If the Standby machine was not running in an active-passive deployment, and was required to be started, and the load balancer had to be reconfigured manually, the downtime would be longer.

14.4.2.2 Oracle Forms N+M Redundancy

For added failover capacity more than one standby machine can be used. That is usually referred to as N+M. The chance of more than one machine failing at the same time (or close to the same time) is significantly smaller, but if there is a requirement to be able to handle that situation, a N+M setup is possible and perhaps called for.

For redundancy in the case of a condition that affects all the machines in the deployment, perhaps a natural disaster that destroys all machines in one location, this deployment can be duplicated in two different geographical locations.

14.4.2.3 Oracle Forms Virtual Machines

In a datacenter that uses virtual machines, the standby machine can be brought online using any spare hardware and thus be implemented very cheaply.

14.4.2.4 Oracle Forms Configuration Cloning

The significance of cloning the environment becomes apparent when studying the scenarios described in the previous sections. All changes done to one machine's environment must also be present on all other machines, including the standby machine. This can present a practical problem, especially if the spare machine is virtual. The image that is the virtual machine must be kept in sync with the changes made to the other machines.

14.4.2.5 Oracle Forms Process Failures

For information about Oracle Forms process failure, see Section 14.1.3.1, "Oracle Web Cache and Oracle HTTP Server Process Failures."

14.4.2.6 Oracle Forms Node Failures

For information about Oracle Forms Node failure, see Section 14.1.3.2, "Common Component Node Failures."

14.4.2.7 Oracle Forms WebLogic Managed Server Failures

For information about Oracle Forms WebLogic Managed Server failure, see Section 14.1.3.3, "Common Component WebLogic Managed Server Failures."

14.4.2.8 Oracle Forms Database Failures

For information about Oracle Forms database failure, see Section 14.1.3.4, "Common Component Database Failures."

14.5 Oracle Discoverer and High Availability Concepts

This section describes single-instance information, as well as high availability concepts specific to Oracle Discoverer. This section guides you through the concepts and considerations necessary for creating a successful high availability Oracle Discoverer deployment.

14.5.1 Oracle Discoverer Single-Instance Characteristics

When you install Discoverer, you create a Discoverer topology within a single instance, as shown in Figure 14-5. After installation, you can configure other types of topologies for Discoverer.

Figure 14-5 Discoverer Topology for a Single Instance

Description of Figure 14-5 follows
Description of "Figure 14-5 Discoverer Topology for a Single Instance"

14.5.1.1 Oracle Discoverer Runtime Considerations

Figure 14-6 illustrates the runtime interaction between Discoverer components.

Figure 14-6 Runtime Interaction Between Discoverer Components

Description of Figure 14-6 follows
Description of "Figure 14-6 Runtime Interaction Between Discoverer Components"

The Discoverer Servlet is a Java EE application that is deployed on a managed server, which can be started and shutdown through the Oracle WebLogic Server administration console and by using the Oracle Enterprise Manager Fusion Middleware Control. The Discoverer Servlet is a stateless process.

The Discoverer Session Server is an OPMN-managed CORBA component that performs Discoverer operations such as connecting to the database or opening a workbook. The Session Server provides the link between the Discoverer Servlet and the database. There is one Session Server component per active user login session. The Discoverer Session Server is a stateful process; the state is stored only in memory.

The Discoverer Preference Server is an OPMN-managed component that provides preference settings (both default and user-defined) for all Discoverer users. These preferences control the Discoverer behavior. For information about starting and stopping the Preference Server, see the Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer.

The Discoverer Services Status is a dummy process managed by OPMN. This process must be running for the Session Server to be spawned.

Note:

The Discoverer Servlet and Session Server must run on the same machine.

Oracle Discoverer External Dependencies

Discoverer requires an Oracle HTTP Server and Enterprise Manager Fusion Middleware Control.

The database schema for Discoverer and the portlet schema must be loaded (before installing Discoverer) by using the Repository Creation Utility (RCU).

Discoverer interacts with customer databases that contain Discoverer workbooks and the Discoverer End User Layer and other data sources. For more information, see the "About the Discoverer database tier" section in the Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer.

Oracle Web Cache can be used to configure load balancing for Discoverer.

The Portlet Provider component of Discoverer can provide portlets to Oracle Portal and Oracle Web Center.

The Web Services component of Discoverer can be used by external clients (such as Oracle BI Publisher and Oracle BI Enterprise Edition) to obtain Discoverer connections and workbooks.

It is recommended (but not mandatory) to restrict access to Oracle Discoverer by using Oracle Single Sign-On (SSO).

Discoverer Process Flow

See the "How does Discoverer work?" section in the Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer.

Connection Protocols

Client browsers send HTTP requests to the Discoverer Java EE application.

The Discoverer Java EE application accesses the database schema by using WebLogic Server data sources.

The Discoverer Session Server (non-Java EE component) uses the OCI layer to connect to data sources.

The Discoverer Java EE application and the Discoverer Session Server processes communicate by using CORBA.

14.5.1.2 Oracle Discoverer Viewer and Web Cache

You can improve Discoverer Viewer performance and availability by using Oracle Web Cache. For information about when and how to use Web Cache, see the "Using Discoverer Viewer with Oracle Web Cache" chapter in the Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer.

14.5.1.3 Oracle Discoverer Configuration Considerations

The environment and behavior of Oracle Discoverer are controlled by Discoverer preferences and configuration parameters.

For information about the location of the files in which preferences and configuration parameters are stored, see the "Discoverer Configuration Files" section in the Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer.

14.5.1.4 Oracle Discoverer Deployment Considerations

The Discoverer Java EE application deployment and contains basic deployment descriptors.

  • The discoverer.ear file consists of the following files: application.xml, jazn-data.xml, and weblogic-application.xml.

    These files are located in the DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/ directory, where DOMAIN_HOME is the name of the domain directory.

  • The discoverer.war file contains the following files: custom-laf.xml, plus_versions.properties, uix-config.xml, portlet.xml, weblogic.xml, struts-config.xml, and web.xml.

    These files are located in the DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/ directory, where DOMAIN_HOME is the name of the domain directory.

14.5.1.5 Oracle Discoverer Log File Locations

You can search for and view Discoverer log files in the Enterprise Manager Fusion Middleware Control.

For more information, see the Enterprise Manager Fusion Middleware Control online help.

14.5.1.6 Discoverer Log Files

The following table shows log files used by Oracle Discoverer:

File Location Description
WLS_DISCO.log DOMAIN_HOME/servers/WLS_DISCO/logs Log file for the WebLogic Managed Server
WLS_DISCO.out DOMAIN_HOME/servers/WLS_DISCO/logs Supplemental log file for the WebLogic Managed Server. This is generally the first place to look for WebLogic issues.
Various ORACLE_INSTANCE/diagnostics/logs/Discoverer/Discoverer_Instance Supplemental Discoverer log files including Preference store.

14.5.2 Oracle Discoverer Protection from Failures and Expected Behavior

Figure 14-7 shows a Discoverer topology that consists of two Discoverer instances.

The Discoverer Java EE application in each managed server communicates with a single Preference Server. Therefore, the same preferences are applied to both the Discoverer instances. The Discoverer instances can exist either on the same machine or on different machines.

Figure 14-7 Discoverer Topology for Multiple Instances

Description of Figure 14-7 follows
Description of "Figure 14-7 Discoverer Topology for Multiple Instances"

The following sections discuss specific high-availability considerations relevant for Discoverer. After making configuration changes to provide high availability, you must restart the Oracle HTTP Server and the managed servers in which the Discoverer Java EE applications are deployed.

14.5.2.1 Preference Server Failover

Failure detection and restart of the Discoverer Java EE application in a cluster is managed by WebLogic Server.

The Preference Server is a singleton process and runs only one instance in the entire cluster.

If the Preference Server process goes down, OPMN brings it up again automatically. If OPMN too is down, the administrator must either start the Preference Server manually or move the files containing the preferences (reg_key.dc and pref.txt) to another machine where the Preference Server is configured and then start the Preference Server on that machine.

If the Preference Server is started in another node in the cluster, the Discoverer Java EE application must be configured to recognize the new Preference Server.

14.5.2.2 Session State Replication and Failover

When a server or machine that is handling requests pertaining to a particular Discoverer HTTP session is down, subsequent request are diverted to other managed servers in the cluster. The session state can be replicated in the new server. The necessary information to achieve this replication is available in the HTTP request (as GET/POST).

Note:

Discoverer requires a Session Server (C++ process) to be available to complete any request. Therefore, in a failover situation, the response time would be marginally higher because a C++ process must be spawned and brought to the required state.

14.5.2.3 Performance Recommendation

The Discoverer Java EE Servlet spawns a Session Server process for each HTTP request that it receives. If multiple Discoverer instances (managed server and the associated oracle instance) exist in a single machine, the load on the CPU might become very high because all Discoverer instances might spawn C++ processes simultaneously. Adding Discoverer instances on different machines yields better performance than adding them on the same machine.

14.5.2.4 Propagation of Configuration Changes Across the Cluster

Any configuration change must be implemented individually in each managed server in the cluster. You can achieve this by copying the configuration.xml file to all the managed servers.

For information about the location of the configuration files, see the "Discoverer Configuration Files" section in the Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer.

14.5.2.5 Cluster-Wide Application Deployment

Each Discoverer Java EE application instance (managed server) should be associated with an Oracle instance that contains Discoverer components. These components are created during the configuration phase of the installation process. So adding managed servers to a cluster and deploying the Discoverer Java EE application from the WebLogic Server administration console are not supported.

All the managed servers defined in the cluster are targets for deployment of the Discoverer Java EE application.

14.5.2.6 Online Application Deployment

Most of the Discoverer Java EE application-dependent jar files are available through shared libraries. Patching these shared libraries does not require the Discoverer Java EE application to be restarted.

Changes to the following jar files, which are available through the system classpath, require the Discoverer Java EE application to be restarted.


WL_HOME/server/lib/weblogic.jar
ORACLE_HOME/modules/oracle.jrf_11.1.1/jrf.jar
ORACLE_HOME/opmn/lib/nonj2eembeans.jar
ORACLE_HOME/server/lib/ojdbc6.jar
ORACLE_HOME/opmn/lib/optic.jar
ORACLE_HOME/opmn/lib/iasprovision.jar
ORACLE_HOME/opmn/lib/ons.jar
ORACLE_HOME/modules/oracle.adf.share_11.1.1/oracle-el.jar
ORACLE_HOME/jlib/share.jar
ORACLE_HOME/jlib/jewt4.jar

14.5.2.7 Oracle Discoverer Process Failures

For the Discoverer Java EE application to access databases, an entry for each database must be created in the ORACLE_INSTANCE/config/tnsnames.ora file. For more information, see the "About configuring the tnsnames.ora file" section in the Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer.

14.5.2.8 Oracle Discoverer Node Failures

For information about Oracle Discoverer Node failure, see Section 14.1.3.2, "Common Component Node Failures."

14.5.2.9 Oracle Discoverer WebLogic Managed Server Failures

For information about Oracle Discoverer WebLogic Managed Server failure, see Section 14.1.3.3, "Common Component WebLogic Managed Server Failures."

14.5.2.10 Oracle Discoverer Database Failures

For information about Oracle Discoverer database failure, see Section 14.1.3.4, "Common Component Database Failures."

14.6 Configuring Oracle Portal, Forms, Reports, and Discoverer for High Availability

This section describes procedures for configuring Oracle Portal, Forms, Reports, and Discoverer for a high availability deployment. This section contains information on the following topics

Note:

Oracle strongly recommends reading the release notes for any additional installation and deployment considerations prior to starting the setup process.

Note:

The hostnames and ports listed in these sections are, for illustrating this example deployment. When configuring your actual deployment, you can specify your own hostnames and ports.

14.6.1 Prerequisites

Before installing Oracle Portal, Forms, Reports and Discoverer, review the prerequisites described in this section.

14.6.1.1 Dependencies

If you are using Oracle Single Sign-On, it is assumed that a high availability Identity Management Framework is available. Oracle Portal, Forms, Reports, and Discoverer uses Single Sign-On, which is available in Oracle Identity Management 10g.

14.6.1.2 Network Requirements

This section describes network requirements.

14.6.1.2.1 Load Balancer

In order to distribute requests across the Oracle Web servers, a load balancer is required. This external load balancer should have the following features:

  • Virtual server name and port configuration

  • Process failure detection

  • Monitoring of ports (HTTP, HTTPS) for Oracle HTTP and HTTPS

  • SSL Translation (if required)

14.6.1.2.2 Load Balancer Configuration - Virtual Server Names and Ports

If you are using a load balancing router, it must be configured to enable the following:

If using SSL traffic terminated at the load balancer

A virtual IP address (VIP1) that listens for requests to mysite.mycompany.com on port 443 (an HTTPS listening port), and balances them to the application tier Oracle Web Cache, running on WEBHOST1 and WEBHOST2, port 7777 (an HTTP listening port). You must configure the Load Balancing Router to perform protocol conversion.

If using site SSL

A virtual IP address (VIP1) that listens for requests to mysite.mycompany.com on port 443 (an HTTPS listening port), and balances them to the application tier, Oracle Web Caches running on WEBHOST1 and WEBHOST2 port 443 (an HTTPS listening port).

If using HTTP traffic terminated at the load balancer

A virtual IP address (VIP1) that listens for requests to mysite.mycompany.com on port 80 (an HTTP listening port), and balances them to the application tier, Oracle Web Caches running on WEBHOST1 and WEBHOST2 port 7777 (an HTTP listening port).

Web Cache

  • The virtual IP address VIP1 listens for requests to mysite.mycompany.com on port 9401 (an HTTP listening port), and balances them to the application tier Oracle Web Cache on WEBHOST1 and WEBHOST2 port 9401 (an HTTP listening port).

    Note:

    For security reasons, ports 9401, 9402 and 9403 on the load balancing router should not be visible to external users.
  • HTTP/HTTPS monitoring of Oracle Web Cache: The Load Balancing Router must be configured to detect an inoperative computer and stop routing requests to it until it is functioning again. Two Oracle Web Cache ports must be monitored: the HTTP request port and the invalidation port.

    To monitor port 7777, use the following URL in the Load Balancing Router configuration:

    hostname:port/_oracle_http_server_webcache_static_.html
    

    For example:

    http://webhost1.mycompany.com:7777/_oracle_http_server_webcache_static_.html
    

    If the Load Balancing Router receives a response from this URL, then the Oracle Web Cache instance is running. If it does not receive a response, the process or the server is down, and the load balancing router forwards all requests to the active computer.

    To monitor port 9401, use the following URL in the Load Balancing Router configuration:

    http://hostname.domain.com:9401/x-oracle-cache-invalidate-ping
    

    For example:

    http://apphost1.mycompany.com:9401/x-oracle-cache-invalidate-ping
    

    The load balancing router sends an HTTP request to this URL; the response header resembles the following:

    HTTP/1.0
    

    The load balancing router must be configured to detect the string HTTP in the first line of the response header. Therefore, when the load balancing router detects HTTP in the first line of the response header, the invalidation port is available. If it does not, all invalidation requests are routed to the active computer.

    Note:

    The sqlnet.ora file must be updated to prevent connection timeouts related to the load balancing router and firewall.

    To summarize, the load balancer requires the following configuration:

    Virtual Host Virtual Port Server Pool Server Port Comments
    mysite.mycompany.com 443/80 UserRequest WEBHOST1 7777 Protocol conversion required if terminating SSL at the load balancer
    mysite.mycompany.com 443/80 UserRequest WEBHOST2 7777 Protocol conversion required if terminating SSL at the load balancer
    mysite.mycompany.com   Cache Invalidation WEBHOST1 9401 Invisible to the external clients
    mysite.mycompany.com   Cache Invalidation WEBHOST2 9401 Invisible to the external clients

14.6.1.3 Databases

Different products use databases in different ways. Below is a summary of the database requirements for Oracle Portal, Forms, Reports and Discoverer:

Oracle Portal

Oracle Portal stores both its own metadata and user content in a database. The majority of the Portal application logic is also placed into this database in the form of PLSQL. Using a combination of the metadata, user content, and PLSQL, Portal generates Web pages.

Oracle Portal requires a high availability database, which has been pre-seeded with database objects required by the Portal application. For information about creating the Metadata Repository, see Section 14.6.3, "Creating the Metadata Repository."

Oracle Forms

Oracle Forms interacts with the database and therefore requires access to it. There are no special database requirements of Oracle Forms itself.

Oracle Reports

Oracle Reports requires a highly available database, which contains the reports queue. It also requires access to various customer databases, which it uses to compile report content.

Oracle Discoverer

Oracle Discoverer requires a database for portlets. This should be a high availability database, and should be seeded using the Oracle Repository Creation Utility (RCU).

In addition, Oracle Discoverer interacts with a number of customer databases. These databases are used to store Discoverer End User Layers, and work books as well as the data on which it reports.

14.6.1.4 Shared Directories

Shared directory requirements vary depending on the product. These requirements are described in the following table:

Product Shared Directory Requirement
Oracle Portal None
Oracle Forms Not mandatory, but useful to have a shared directory for Oracle Forms executables.
Oracle Reports Reports Cache
Oracle Discoverer Portlet Preference Store

14.6.1.5 Managed Port Numbers

Many Oracle Fusion Middleware components and services use ports. As an administrator, it is important to know the port numbers used by these services, and to ensure that the same port number is not used by two services on the same host.

Port numbers can either be automatically or manually assigned at installation time.

14.6.1.6 Site Names

In order to configure a Web site a site name is required. This site name, for example mysite.mycompany.com, must be defined in DNS and be associated with the Virtual IP address assigned to the load balancer.

A site name is also required for the Single Sign-On server, which is set up as part of the high availability Single Sign-On installation.

14.6.2 Assumptions

For the example high availability configuration described in this chapter, consider the following assumptions:

14.6.2.1 Ports

The following table lists the typical ports required by an Oracle Portal, Forms, Reports, and Discoverer implementation.

Purpose Host(s) Port Comment
mysite.mycompany.com Load balancer 80 HTTP port on the load balancer
Web Cache HTTP APPHOST1

APPHOST2

7777 Web Cache HTTP port
Web Cache HTTPS APPHOST1

APPHOST2

4443 Web Cache HTTPS port
Web Cache Invalidation APPHOST1

APPHOST2

9401 Web Cache invalidation port
Web Cache Admin APPHOST1

APPHOST2

9400 Web Cache Administration port
HTTP Server (OHS) - HTTP APPHOST1

APPHOST2

7778 OHS HTTP listening port
HTTP Server (OHS) - HTTPS APPHOST1

APPHOST2

4444 OHS HTTPS listening port
WebLogic Admin port APPHOST1 7001 WebLogic Administration Server port
WLS_PORTAL APPHOST1 7050 WebLogic Managed Server port
WLS_PORTAL1 APPHOST2 7050 WebLogic Managed Server port
WLS_REPORTS APPHOST1 7051 WebLogic Managed Server port
WLS_REPORTS1 APPHOST2 7051 WebLogic Managed Server port
WLS_DISCO APPHOST1 7052 WebLogic Managed Server port
WLS_DISCO1 APPHOST2 7052 WebLogic Managed Server port
WLS_FORMS APPHOST1 7053 WebLogic Managed Server port
WLS_FORMS1 APPHOST2 7053 WebLogic Managed Server port
Internet Directory SSOHOST 389 Oracle Internet Directory HTTP port
Single Sign On SSOHOST 7777 Single Sign On listening port

14.6.3 Creating the Metadata Repository

Before installing Oracle Portal and Oracle Discoverer, create and "seed" a repository with metadata that these applications require to function, by running the Repository Creation Utility (RCU).

Note:

A metadata repository is not required for Oracle Forms and Reports.

14.6.3.1 Install the Repository Creation Utility (RCU)

Install the latest version of the Repository Creation Utility, as described in the Oracle Fusion Middleware Repository Creation Utility User's Guide.

14.6.3.2 Run Repository Creation Utility

After installing RCU, use it to populate the database. Start the Repository Creation Utility using the following commands:

For UNIX:

rcu

For Windows:

rcu.exe

These commands are located in the RCU ORACLE_HOME/bin directory.

  1. In the Create Repository screen, select Create and then click Next.

  2. In the Database Connection Details screen, specify the following values:

    • Database Type: Oracle Database

    • Host Name: Enter one of the Oracle RAC nodes (use the VIP name), if using Oracle RAC.

    • Port: Enter the listener port.

    • Service Name: Enter the service name of the Oracle Real Application Clusters database.

    • User Name: Enter sys.

    • Password: Enter the sys user password.

    • Role: Select SYSDBA.

  3. In the Check Prerequisites screen, click OK when the prerequisites have been validated.

  4. In the Select Components screen, specify the following values:

    • Create New Prefix: Enter a prefix to be added to database schemas, for example: MYS

    • Components: Portal and BI > Portal and Discoverer

    Click Next.

  5. In the Check Prerequisites screen, click OK when the prerequisites have been validated.

  6. In the Schema Passwords screen, enter passwords for each of the portal schemas or use the same password for all schemas.

    Click Next.

  7. In the Map Tablespaces screen, click Next to accept the defaults.

  8. In the Create Tablespaces screen, click Yes to allow RCU to create any missing tablespaces.

  9. In the Creating Tablespaces screen, click OK to acknowledge tablespace creation.

  10. In the Summary screen, click Create to begin the creation process.

14.6.4 Install and Configure Application Tier on APPHOST1

The following steps are applicable for Oracle Portal, Forms, Reports and Discoverer installations.

14.6.4.1 Install Oracle WebLogic Server

To install Oracle WebLogic Server binaries, see the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

See "Understanding Your Installation Starting Point" in Oracle Fusion Middleware Installation Planning Guide for the version of Oracle WebLogic Server to use with the latest version of Oracle Fusion Middleware.

14.6.4.2 Install Oracle Portal, Forms, Reports, and Discoverer

To install the Oracle Portal, Forms, Reports, and Discoverer binaries, see Oracle Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer.

Note:

Before you run the Configuration Wizard by following the instructions in Section 14.6.4.3, "Configure Oracle Portal, Forms, Reports, and Discoverer Software," ensure that you applied the latest Oracle Fusion Middleware patch set and other known patches to your Middleware Home so that you have the latest version of Oracle Fusion Middleware.

See "Understanding Your Installation Starting Point" in Oracle Fusion Middleware Installation Planning Guide for the steps you must perform to get the latest version of Oracle Fusion Middleware.

14.6.4.3 Configure Oracle Portal, Forms, Reports, and Discoverer Software

Start the Oracle Fusion Middleware Configuration Wizard by running this command:

ORACLE_HOME/bin/config.sh

Note:

Before starting the configuration, ensure that the following environment variables (UNIX) are not set:
  • LD_ASSUME_KERNEL

  • ORACLE_BASE

  • LD_LIBRARY_PATH

Continue with the following steps:

  1. In the Welcome screen, click Next.

  2. In the Prerequisite Checks screen, once all the prerequisites have been validated, click Next.

  3. In the Create Domain screen, select Create New Domain and enter these values:

    • User Name: Name of the user to log into the WebLogic domain.

    • User Password: Password for the domain.

    • Confirm Password: Type the same password again.

    • Domain Name: Name for the domain. For example: MyDomain

    Click Next.

  4. In the Specify Security Updates screen, if required, enter a username and password to receive Oracle Security updates for Oracle Support.

  5. In the Specify Installation Location screen, enter these values:

    • WebLogic Server Location: Enter the installation directory for Oracle WebLogic Server. This directory should be MW_HOME/wlserver_10.3, for example:

      /u01/app/oracle/product/FMW/wlserver_10.3
      
    • Oracle Instance Location: Enter the directory where the Oracle configuration files are to be placed. This should be outside of the Oracle home directory. This directory will be known as the ORACLE_INSTANCE. For example:

      /u01/app/oracle/admin/fmw1
      
    • Oracle Instance Name: fmw1

    Click Next.

  6. In the Configure Components screen, choose which products to install and configure.

    Ensure that Management Components - Enterprise Manager is also selected.

    Select Clustered.

    Click Next.

  7. In high availability implementations, it is not mandatory for all of the ports used by the various components to be are synchronized across hosts, but Oracle strongly recommends it. Oracle Allows the bypassing of Automatic Port Configuration by specifying ports to be used in a file.

    Create a file with the ports you wish to assign by Select a file name, and click View/Edit.

    You can find a sample staticports.ini file on installation Disk1 in the stage/Response directory.

    This file should have entries for the following:

    [Domain Port No = 7001
    Oracle HTTP Server Port No = 7778
    WebCache Port No = 7777
    WebCache Administration Port No = 9400
    WebCache Statistics Port No = 9402
    Web Cache Invalidation Port = 9401
    Portal Managed Server Port = 7050
    Reports Managed Server Port = 7051
    Discoverer Managed Server Port = 7052
    Forms Managed Server Port = 7053]
    

    Save the file and click Next.

  8. In the Specify Proxy Details screen (Reports only), if a proxy server is in use, enter the details in this screen.

    Otherwise, click Next.

  9. In the Specify Schema screen (Portal and Discoverer only), specify the following values:

    • Database Connect String in the format:

      For an Oracle RAC database:

      racnode1-vip:ListenerPort:racnode2-vip:ListenerPort@mydb.mycompany.com
      

      For other databases:

      host:port:mydb.mycompany.com
      
    • Portal Schema Name: MYS_PORTAL

    • Portal Schema Password: Enter password entered in RCU.

    • Discoverer Schema Name: MYS_DISCOVERER

    • Discoverer Schema Password: Enter password entered in RCU.

    Click Next.

  10. In the Specify Portlet Schema screen (Portal and Discoverer only), specify the following values:

    • Portlet Schema Name: MYS_PORTLET

    • Portlet Schema Password: Enter password entered in RCU.

    Click Next.

  11. In the Specify Application Identity Store screen, specify the following values:

    • Hostname: Name of the Oracle Internet Directory server, for example: myoid.mycompany.com

    • Port: Oracle Internet Directory port, for example: 389

    • User Name: cn=orcladmin

    • Password: Password for Oracle Internet Directory's orcladmin account

  12. In the Summary screen, click Install to begin the creation process.

14.6.4.4 Validation

Validate the initial installation by performing the following tests:

Test URL Result
Portal http://apphost1.mycompany.com:7777/portal/pls/portal Portal Home page opens
Forms http://apphost1.mycompany.com:7777/forms/frmservlet Forms Servlet Home page opens
Reports http://apphost1.mycompany.com:7777/reports/rwservlet/showjobs Job Queue opens
Discoverer http://apphost1.mycompany.com:7777/discoverer/viewer Discoverer Viewer Home page opens

14.6.4.5 Generic Configuration

The following steps are required regardless of the product being configured:

14.6.4.5.1 Set Admin Server Listen Address

In servers where multiple network cards exist, it is important to bind the Administration Server to the network card that you wish to use.

To do this:

  1. Log in to the WebLogic Console using the URL

    http://apphost1.mycompany.com:7001/console

  2. In the Domain Structure menu, select Environment, and then Servers.

  3. Click AdminServer (admin)

  4. In the Change Center, click Lock & Edit.

  5. Set the listen address to the DNS name referring to the network card you wish to use. This is generally the public server name.

  6. Click Save.

  7. Click Activate Changes from the change center.

  8. Stop the Administration Server using the stopWebLogic.sh script, located in the DOMAIN_HOME/bin directory. Start the Administration Server using the startWebLogic.sh script, also located in DOMAIN_HOME/bin directory.

14.6.4.5.2 Configure Virtual Hosts

For the site to function properly with the load balancer, you must add two virtual hosts. You can configure the virtual hosts using Oracle Enterprise Manager Fusion Middleware Control, or you can edit the file ORACLE_INSTANCE/config/OHS/ohs1/httpd.conf or create a file called virtual_hosts.conf in the directory ORACLE_INSTANCE/config/OHS/ohs1/moduleconf.

To add two virtual hosts to the virtual_hosts.conf file, in a text editor, add the following entries to the file:

NameVirtualHost *:7778
<VirtualHost *:7778>
    ServerName http://mysite.mycompany.com:80
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>
 
<VirtualHost *:7778>
    ServerName apphost1.mycompany.com:7777
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>

Note:

Where:

7778 is the Oracle HTTP Server Listening Port

80 is the Load Balancer Listening Port

7777 is the Web Cache Listening Port.

Name of the server on which the Oracle HTTP server resides: apphost1

Use ServerName HTTP if your site works only in the http protocol.

Restart the Web Tier using these commands:

opmnctl stopall
opmnctl startall
14.6.4.5.3 Create boot.properties File

Create a boot.properties file for the Administration Server on APPHOST1. The boot.properties file enables the Administration Server to start without prompting you for the administrator username and password.

In a text editor, create a file called boot.properties in the directory DOM_HOME/servers/AdminServer/security, and enter the following lines in the file:

username=adminuser
password=password

Restarting the Administration Server encrypts the values in this file, for that reason it is recommended that the Administration Server is restarted on each node that can host it.

Stop the Administration Server using the script stopWebLogic.sh, which is located in DOMAIN_HOME/bin, or by using the script startWebLogic, also located in DOMAIN_HOME/bin.

14.6.4.5.4 Configure sqlnet.ora

Create a file called sqlnet.ora in the directory ORACLE_INSTANCE/config/ and add the following entry to the file:

TCP.CONNECT_TIMEOUT=10

This ensures that database connections time out after a reasonable time.

14.6.4.5.5 Configure Web Cache

Web Cache is optional for Oracle Forms, Reports and Discoverer, but mandatory for Oracle Portal. If the environment being configured does not use Web Cache, ignore the following Web Cache configuration steps:

Log Into Enterprise Manager Console

Log into the Oracle Fusion Middleware Enterprise Manager Console using the following URL:

http://apphost1.mycompany.com:7001/em

The default User Name and Password are the same as the WebLogic domain username and password entered during the installation.

Create Site

  1. In the Navigator window, expand the Web Tier tree.

  2. Click on the component wc1.

  3. From the list at the top of the page, select Administration - Sites.

  4. Select Create Site.

  5. Enter the following information to add a site.

    Field Value
    Host Name mysite.mycompany.com
    Port Specify the port number on the load balancer where requests are received, for example, 80 for HTTP requests and 443 for HTTPS request.

    If using a load balancer, this is the listening port on the load balancer.

    Default site Yes
    Site Wide Compression Yes
    Site Alias - Host Name mysite.mycompany.com
    Site Alias - Port 7777
    Site Alias - Host Name mysite.mycompany.com
    Site Alias - Port 80 Foot 1 

    Footnote 1 Required when the load balancer can send requests to port 80 as well as port 443.

  6. Do not change any other defaults.

  7. Select Submit.

  8. Select OK to save each entry.

Create Site-to-Server Mapping

  1. On the same page, select Create in the Site-to-Server Mapping section.

  2. Enter the following information to add the site:

    Field Value
    Host Pattern mysite.mycompany.com
    Port Pattern 80
    Selected Origin Servers apphost1.mycompany.com:7778

  3. Click OK to store the site.

  4. Ensure that the site mysite.mycompany.com:443/80 appears first in the list of site-to-server mappings.

  5. Click Apply to save the changes.

Enable Session Binding

The session binding feature in Oracle Web Cache is used to bind user sessions to a given origin server to maintain state for a period of time. Although almost all components running in a default Oracle Fusion Middleware mid-tier are stateless, session binding is required for Oracle Portal.

Enabling session binding forces all the user requests to go to a specific Oracle Portal middle tier, resulting in a better cache hit ratio for the portal cache.

Follow these steps to enable session binding:

  1. Select Administration - Session Configuration at the top of the page.

  2. Select the site mysite.mycompany.com:443/80 from the drop down list.

  3. In the Session Binding section, select Cookie based Session Binding with any Set Cookie.

  4. Click Apply to save the changes.

14.6.4.5.6 Change the Web Cache Passwords

Web Cache passwords are randomly generated, however they are required in later stages. It is therefore recommended that the Web Cache passwords be changed from the default value to a new known value.

To change the default password, follow these steps:

  1. In the Navigator window, expand the Web Tier tree.

  2. Click on the component wc1.

  3. From the drop down list at the top of the page, select Administration - Passwords.

  4. Enter new invalidation and administration passwords, confirm them, and click Apply.

14.6.4.5.7 Restart Web Tier (Oracle HTTP Server and Web Cache)

After making the previous changes, restart the Web Tier components using these commands:

opmnctl stopall 
opmnctl startall
14.6.4.5.8 Register with Single Sign-On Server

Perform these steps from the Single Sign-On server:

  1. Set the ORACLE_HOME variable to the Single Sign-On Server ORACLE_HOME location.

  2. Execute ORACLE_HOME/sso/bin/ssoreg.sh (ssoreg.bat on Windows) with the following parameters:

    -site_name mysite.mycompany.com
    -mod_osso_url http://mysite.mycompany.com
    -config_mod_osso TRUE
    -oracle_home_path ORACLE_HOME
    -config_file /tmp/osso.conf
    -admin_info cn=orcladmin
    -virtualhost
    -remote_midtier
    
  3. Copy /tmp/osso.conf to the mid-tier home location, which is:

    ORACLE_INSTANCE/config/OHS/ohs1
    
  4. Restart Oracle HTTP server on APPHOST1 using the following command:

    opmnctl restartproc process-type=OHS
    
  5. Log into the Single Sign-On Server using the following URL:

    http://login.mycompany.com/pls/orasso
    
  6. Go to the Administration page and then Administer Partner applications. Delete the entry for apphost1.mycompany.com.

14.6.4.5.9 Enabling the WebLogic Plug-in

For security purposes, turn on the WebLogic plug-in enabled flag for the domain. To do this, follow these steps:

The Oracle web tier sits in front of the Oracle WebLogic server, routing requests from the Oracle HTTP Servers to the Oracle WebLogic managed servers. In this scenario, you must tell WebLogic that the Oracle WebLogic plug-in is being used. To do this:

  1. Log on to the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, click on the domain name.

  3. Click on the Web Applications tab.

  4. Click Lock & Edit.

  5. Select the WebLogic Plugin Enabled box.

  6. Save and activate the changes.

  7. Restart the Administration Server.

14.6.4.5.10 Change Host Assertion in WebLogic

Because the Oracle HTTP server acts as a proxy for WebLogic, by default certain CGI environment variables are not passed through to WebLogic. These include the host and port. WebLogic must be told that it is using a virtual site name and port so that it can generate internal URLs appropriately.

  1. Log into the Oracle WebLogic Server Administration Console using the following URL:

    http://apphost1.mycompany.com:7001/console
    
  2. Select Clusters from the home page or choose Environment -> Clusters from the Domain structure menu.

  3. In the Change Center, click Lock & Edit.

  4. Click on the Cluster Name (cluster_portal, cluster_forms, cluster_reports, cluster_disco).

  5. Select HTTP and enter the following values:

    Parameter Value
    Frontend Host mysite.mycompany.com
    Frontend HTTP Port 80
    Frontend HTTPS Port 443

    This ensures that any HTTPS URLs created from within WebLogic are directed to port 443 or 80 on the load balancer.

  6. Click Activate Changes in the Change Center window to save the changes.

  7. Restart the WLS_PORTAL, WLS_FORMS, WLS_REPORTS, WLS_DISCO Managed Servers using the following steps:

    1. Select Servers from the Home page or Environment > Servers from the Domain structure menu.

    2. Select the Control tab.

    3. Select the box next to each Managed Server.

    4. Choose Shutdown > Force Shutdown Now.

    5. Click Yes to shut down the Managed Server.

    6. Once the Managed Server is shut down, select the box next to the Managed Server.

    7. Click Start.

    8. Click Yes to start the Managed Server.

14.6.4.6 Configure Oracle Portal for High Availability

The following steps are required to configure Oracle Portal only.

14.6.4.6.1 Rewire Portal Repository

Follow these steps to rewire the Oracle Portal repository:

  1. Log into the domain using Oracle Fusion Middleware Enterprise Manager using the following URL:

    http://apphost1.us.oracle.com:7001/em
    
  2. Expand the Fusion Middleware menu on the left hand side.

  3. Expand the Portal menu (under Fusion Middleware menu).

  4. Click Portal.

  5. Right-click Portal and select settings Wire Configuration.

  6. Enter the following information for Portal midtier:

    Parameter Value
    Host Enter the DNS name of the load balancer. For example: mysite.mycompany.com
    Port Enter the port that the load balancer is listening on. For example, 443 for SSL Termination/Site Enabled SLL or 80 for HTTP
    SSL Protocol Select this if SSL Termination/Site Enabled SSL is being used.

  7. Enter the following information for Web Cache:

    Parameter Value
    Host Enter the DNS name of the load balancer. For example: mysite.mycompany.com
    Invalidation Port Enter the Portal Invalidation port as configured at the load balancer, for example: 9401
    Invalidation User Name Enter the user name to be used for Portal invalidations, for example: invalidator
    Invalidation Password Password for the above account.

    If you do not know the value of this password, it can be changed in Enterprise Manager as described above.


  8. Click Apply to start the rewire.

  9. After the rewire completes, click the Portal menu option again.

  10. Ensure that the Portal URL now shows:

    http://mysite.mycompany.com:80/portal/pls/portal
    
14.6.4.6.2 Configure Parallel Page Engine Loop-Back with Load Balancer

The purpose of the Parallel Page Engine (PPE Servlet) is to construct pages that have been requested by users. It does this by receiving the page request from a user, making its own new requests to fetch all the pieces of the page "in parallel", assembling these pieces into a single page file and then sending the page content back to the end user (or back to the client browser).

These internal requests should be kept inside of the organization, and be served using the HTTP protocol.

The following steps are required only if you are using a load balancer.

  1. Log into the Oracle Fusion Middleware Enterprise Manager using this URL:

    http://apphost1.us.oracle.com:7001/em
    
  2. Select Fusion Middleware > Classic -> Portal from the object browser on the left.

  3. Right-click Portal, and select Settings > Page Engine.

  4. In the Advanced Properties section, add the following information:

    Parameter Value
    UsePort Select the internal loopback port number, for example: 7777. This port will have been configured at the load balancer for internal requests.
    Use Scheme Change to the value of HTTP

  5. Click Apply to save the settings.

  6. Restart the WebLogic Managed Server from the Oracle WebLogic Administration Console as follows:

    1. Select Servers from the Home page or Environment > Servers from the Domain structure menu.

    2. Select the Control tab.

    3. Select the box next to the WLS_PORTAL Managed Server.

    4. Choose Shutdown > Force Shutdown Now.

    5. Click Yes to shut down the Managed Server.

    6. Once the Managed Server is shut down, select the box next to the Managed Server.

    7. Click Start.

    8. Click Yes to start the Managed Server.

14.6.4.6.3 Database Wallets and Portal

If you are using SSL, Oracle Portal requires that the database in which the portal schema resides has a wallet. In this wallet is stored the certificate of the load balancer or the site. Once the wallet has been created, Oracle Portal must be informed of its location.

Note:

This step is required only if you are using SSL Termination or Site SSL.

Create a Database Wallet

Before starting this process, copy the certificate to the database servers.

Each browser does this in a slightly different way. For Firefox browsers:

  1. Use a browser to access the URL https://mysite.mycompany.com.

  2. Go to Firefox > Preferences > Advanced > Encryption > view certificates.

  3. Highlight the certificate for mysite.mycompany.com select export and give the file a name.

  4. Copy this file to the database server.

  5. Save the certificate if requested.

  6. Now that you have obtained a copy of the certificate, create a wallet on each of the database servers, and import this certificate using the Oracle Wallet Manager from the database server. This must be done for all of the Oracle RAC nodes by following these steps:

    1. Type owm to invoke the Oracle Wallet Manager.

    2. Select Wallet > New.

    3. Select No so that you do not create the wallet in the default location.

    4. Enter a password for the wallet (remember this password - it is needed later)

    5. Set the Wallet Type to Standard.

    6. Select No to the question Do you want to create a certificate at this time?.

    7. In Oracle Wallet Manager, select Operations > Import Trusted certificate.

    8. Select Select a file that contains the certificate and click OK.

    9. Select the certificate file selected above and click Import.

    10. Select Wallet and Save As.

    11. Select a location for the wallet. For example:

      ORACLE_BASE/admin/DB_NAME/wallet
      
    12. Repeat this procedure for other Oracle RAC database nodes.

      You must use the same directory paths on all database nodes.

Identify the Wallet to Portal

Now that the certificate is stored inside the database wallet, store the location of the wallet within the portal repository by following these steps:

  1. Run the SQL*Plus script secwc.sql, which is located in the following directory

    ORACLE_HOME/portal/admin/plsql/wwc
    

    It may be necessary to create a database entry in the file tnsnames.ora located in ORACLE_HOME/network/admin:

    SQL> @secwc 'file:$ORACLE_BASE/admin/DB_NAME/wallet' 'walletpassword'
    

    In the command above:

    • Use the absolute path to the wallet. Do not use environment variables.

    • walletpassword is the password for the wallet.

    • Use the path to the wallet directory, not the wallet file itself. The keyword file is required.

14.6.4.6.4 Restart All Components

After making the changes in previous sections, the Web tier components must be restarted. This section describes the procedure for restarting the components.

Restart Web Components

Restart the Oracle HTTP Server using these commands:

opmnctl stopall 
opmnctl startall

Restart WLS_Portal

Restart the Managed Server WLS_PORTAL by logging into the WebLogic Administration Console and following these steps:

  1. Select Servers from the Home page or Environment > Servers from the Domain structure menu.

  2. Select the Control tab.

  3. Select the box next to the WLS_PORTAL Managed Server.

  4. Choose Shutdown > Force Shutdown Now.

  5. Click Yes to shut down the Managed Server.

  6. Once the Managed Server is shut down, select the box next to the WLS_PORTAL Managed Server.

  7. Click Start.

  8. Click Yes to start the Managed Server.

14.6.4.6.5 Post-installation Step for Portal Installation with Oracle RAC

Oracle recommends setting initial-capacity for individual data sources created for Portal and Portlet components to 0. Please use Administration Console to set initial-capacity to 0 for these data sources.

14.6.4.6.6 Validate Configuration

To validate the configuration, perform the following tests:

Test URL Result
Test Portal using the load balancer http://mysite.mycompany.com/portal/pls/portal Portal Home page opens.

Troubleshooting Single Sign-On Errors

If a Single Sign-On error message appears on the Portal front screen at this stage in the configuration, the database wallet may not have been created properly, or Oracle Portal may not have been notified of its correct location.

If this error appears, repeat the steps to create the database wallet and the subsequent identification to portal.

14.6.4.7 Configure Oracle Forms for High Availability

Use the following steps to configure Oracle Forms only.

14.6.4.7.1 Create TNSNAMES Entries for Customer Databases

If the application will access one or more databases, an entry for each database being accessed must be placed into the file tnsnames.ora.

to place an entry for each database into the file, follow these steps:

  1. Edit the file ORACLE_INSTANCE/config/tnsnames.ora and add an entry similar to this:

    mydb.mycompany.com =
      (DESCRIPTION =
        (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
        (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
        (LOAD_BALANCE = yes)
        (CONNECT_DATA =
          (SERVER = DEDICATED)
          (SERVICE_NAME = mydb.mycompany.com)
        )
      )
    

    Note:

    This is an Oracle RAC database connect string.
  2. Save the file and test that the database connection is configured correctly using the command:

    tnsping mydb.mycompany.com
    

    Note:

    Set the environment variable TNS_ADMIN before issuing the tnsping command above.
14.6.4.7.2 Restart WLS_FORMS

Restart the Managed Server WLS_FORMS by logging into the WebLogic Administration Console and following these steps:

  1. Select Servers from the Home page or Environment > Servers from the Domain structure menu.

  2. Select the Control tab.

  3. Select the box next to the WLS_FORMS Managed Server.

  4. Choose Shutdown > Force Shutdown Now.

  5. Click Yes to shut down the Managed Server.

  6. Once the Managed Server is shut down, select the box next to the WLS_FORMS Managed Server.

  7. Click Start.

  8. Click Yes to start the Managed Server.

14.6.4.7.3 Validate Configuration

To validate the configuration, the following tests should be performed:

Test URL Result
Test load balancer http://mysite.mycompany.com/ Home page opens
Forms http://mysite.mycompany.com/forms/frmservlet Forms Servlet Home page opens

14.6.4.8 Configure Oracle Reports for High Availability

The following steps are required to configure Oracle Reports only.

14.6.4.8.1 Create Reports Queue in Database

To maintain a consistent reports queue across multiple Reports server instances and to be resilient to the failure of a reports server, create the reports queue in a high availability Real Application Clusters database.

To create the Reports queue, run the SQL*Plus script rw_server.sql against the database.

The script is located in this directory:

ORACLE_HOME/reports/admin/sql

Follow these steps:

  1. Create a user to hold the report queue in the database using the following commands:

    sql> create user report_queue identified by MYSpassword;
    sql> grant connect, resource,create view to report_queue;
    
  2. Connect to the Reports user and execute the following script:

    sqlplus report_queue/MYSpasswd
    sql> @ORACLE_HOME/reports/admin/sql/rw_server.sql
    
14.6.4.8.2 Create a TNSNAMES Entry for Reports Queue

Oracle Reports uses entries in the tnsnames.ora file to determine database connection information. Place an entry in this file for the reports queue database by following these steps:

  1. Edit the file ORACLE_INSTANCE/config/tnsnames.ora file and add an entry similar to this:

    myrepq.mycompany.com =
      (DESCRIPTION =
        (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
        (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
        (LOAD_BALANCE = yes)
        (CONNECT_DATA =
          (SERVER = DEDICATED)
          (SERVICE_NAME = myrepq.mycompany.com)
        )
      )
    

    Note:

    This is an Oracle RAC database connect string.
  2. Save the file and test that the database connection is configured correctly using the following command:

    tnsping myrepq.mycompany.com
    

    Note:

    Set the environment variable TNS_ADMIN before using the tnsping command.
14.6.4.8.3 Create a Security Key for the Reports Queue

Oracle Reports security is performed using an indirect model. Before the reports server can be configured to use the database reports queue, make an entry in WebLogic to hold the reports queue password by following these steps:

  1. Log into Oracle Fusion Middleware Enterprise Manager using the following URL, entering the WebLogic administrator user and password when prompted:

    http://apphost1.mycompany.com:7001/em
    
  2. In the navigation tree on the left hand side, expand WebLogicDomain, and click on the name of the domain, for example: ReportsDomain.

    The ReportsDomain overview page appears.

  3. From the drop-down menu at the top of the page select Security > Credentials.

  4. Click Create Key.

  5. Provide the following information:

    Parameter Value
    Select Map reports
    Key queuePassword
    Type Password
    User Name report_queue
    Password Password for the reports queue account
    Description Description for the reports queue account

  6. Click OK when finished.

14.6.4.8.4 Configure the Database Job Repository for In-Process Reports Servers

After the reports queue has been placed into the database, the reports server needs to be told how to access it.

To do this, edit the rwserver.conf file.

The file is located in the following directory:

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_11.1.1.2.0/configuration/

There is a fixed order for entries in the server configuration file. Add the following element immediately after the <jobStatusRepository> element in the rwserver.conf file:

<jobRepository>
 <property name="dbuser" value="dbuser"/>
 <property name="dbpassword" value="csf:reports:dbpasswdKey"/>
 <property name="dbconn" value="dbconn"/>
</jobRepository>

where:

  • dbuser is the name of the schema where the reports queue resides

  • dbconn references a database entry in the tnsnames.ora file in the ORACLE_INSTANCE/config directory

For example:

<jobRepository>
 <property name="dbuser" value="report_queue"/>
 <property name="dbpassword" value="csf:reports:queuePassword"/>
 <property name="dbconn" value="myrepq.mycompany.com"/>
</jobRepository>
14.6.4.8.5 Configure the Reports Server to Access Shared Output Directory

Add the CacheDir or JOCCacheDir property to the <cache> element the file rwserver.conf file, located in the following directory:

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_11.1.1.2.0/configuration/

For example:

<property name="JOCCacheDir" value="folder_name"/>
<property name="CacheDir" value="folder_name"/>

On UNIX:

<cache class="oracle.reports.cache.RWCache">
 <property name="cacheSize" value="50"/>
 <!--property name="cacheDir" value="your cache directory"/-->
 <!--property name="maxCacheFileNumber" value="max number of cache files"/-->
 <property name="JOCCacheDir" value="/share/reports"/>
 <property name="CacheDir" value="/share/reports"/>
</cache>
14.6.4.8.6 Create a Reports Server Cluster

If you create a Reports Server cluster with a database reports queue, you can link all Reports Servers to the same queue. Benefits of configuring a Reports Server Cluster include:

  • The Load Balancer does load balancing, not the Reports Cluster.

  • The new Shared Java Object Cache feature for Reports Server Cache allows other Reports Servers to retrieve the report outputs in the event that the reports server that served the request is not available.

  • The new Shared Job Repository can view the consolidated jobs queue for the complete group of Reports Servers in the Report Cluster, and enhances the scheduled jobs feature with Reports clusters.

  • Enabling the Database Job Repository allows scheduled jobs to be available to all Reports Servers in the cluster. It does not matter if the Reports Server that submits a scheduled job isn't available; the database stores the job information, not a DAT file as in 10gR2.

To create a reports cluster, add a cluster entry into the file rwservlet.properties on APPHOST1 and APPHOST2, as shown below.

Note:

The value of clusternodes is the value which appears in the <server> tag in the file rwservlet.properties on APPHOST2.

The clusternodes parameter should list all Reports Servers in the cluster (comma separated) except the local report server.

Cluster APPHOST1

Edit the file rwservlet.properties located at: DOM_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_<version>/configuration

Add the line:

<cluster clustername="cluster_reports" clusternodes="rep_wls_reports1_APPHOST2_reports2"/>

Cluster APPHOST2

Edit the file rwservlet.properties located at: DOM_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_<version>/configuration

Add the line:

<cluster clustername="cluster_reports" clusternodes="rep_wls_reports_APPHOST1_reports1"/>
14.6.4.8.7 Restart WLS_REPORTS

To restart the Managed Server WLS_REPORTS, log into the WebLogic Administration Console, and follow these steps:

  1. Select Servers from the Home page or Environment > Servers from the Domain structure menu.

  2. Select the Control tab.

  3. Select the box next to the WLS_REPORTS Managed Server.

  4. Choose Shutdown > Force Shutdown Now.

  5. Click Yes to shut down the Managed Server.

  6. Once the Managed Server is shut down, select the box next to the WLS_REPORTS Managed Server.

  7. Click Start.

  8. Click Yes to start the Managed Server.

14.6.4.8.8 Validate Configuration

Validate the initial Reports configuration by performing these tests:

Test URL Result
Reports Queue http://mysite.mycompany.com/reports/rwservlet/showjobs Single Sign On screen and then Reports Queue opens

For an alternate test, download a sample report from Oracle Technology Network, and run it. The URL for Oracle Technology Network is:

http://www.oracle.com/technology/index.html

14.6.4.9 Configure Oracle Discoverer for High Availability

Follow these steps to configure high availability for Oracle Discoverer only.

14.6.4.9.1 Create TNSNAMES Entries for Customer Databases

If the application accesses one or more databases, place an entry for each database being accessed into the tnsnames.ora file, by following these steps:

  1. Edit the file ORACLE_INSTANCE/config/tnsnames.ora, and add an entry similar to this:

    mydb.mycompany.com =
      (DESCRIPTION =
        (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
        (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
        (LOAD_BALANCE = yes)
        (CONNECT_DATA =
          (SERVER = DEDICATED)
          (SERVICE_NAME = mydb.mycompany.com)
        )
      )
    

    Note:

    This is an Oracle RAC database connect string.
  2. Save the file and test that the database connection is configured correctly using the following command:

    tnsping mydb.mycompany.com
    

    Note:

    Set the environment variable TNS_ADMIN before issuing the tnsping command.
14.6.4.9.2 Update configuration.xml

The configuration.xml stores information about the Discoverer configuration. The file is located in the following directory:

DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/

Update the line beginning with applicationURL= and change the URL to:

http://mysite.mycompany.com/discoverer

For example:

applicationURL="http://mysite.mycompany.com/discoverer">
14.6.4.9.3 Discoverer Viewer and Web Cache

By default, Discoverer Viewer is not configured to make full use of Oracle Web Cache. When enabled, significant performance gains can be attained. However, it is not always appropriate to enable this functionality.

For details on when and how to enable Discoverer Viewer with Oracle Web Cache, see the "Using Discoverer Viewer with Oracle Web Cache" section of Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer.

14.6.4.9.4 Enable Single Sign On

By default, Discoverer is not protected by single sign-on. To secure Discoverer Plus and Viewer, use the following steps:

  1. Edit the file mod_osso.conf file, located in the following directory:

    ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
    
  2. Add the following lines to the file before the line that begins with </IfModule>:

    <Location /discoverer/plus>
     require valid-user
     AuthType Osso
    </Location>
     
    <Location /discoverer/viewer>        
     require valid-user
     AuthType Osso
    </Location>
     
    <Location /discoverer/app>
     require valid-user
     AuthType Osso
    </Location>
    
14.6.4.9.5 Restart All Components

After making the changes in previous sections, restart the Web tier components using the procedures described in this section

Restart Web Components

Restart the Oracle HTTP Server using the following commands:

opmnctl stopall 
opmnctl startall

Restart WLS_DISCO

Restart the Managed Server WLS_DISCO by logging into the WebLogic Administration Console and following these steps:

  1. Select Servers from the Home page or Environment > Servers from the Domain structure menu.

  2. Select the Control tab.

  3. Select the box next to the WLS_DISCO Managed Server.

  4. Choose Shutdown > Force Shutdown Now.

  5. Click Yes to shut down the Managed Server.

  6. Once the Managed Server is shut down, select the box next to the WLS_DISCO Managed Server.

  7. Click Start.

  8. Click Yes to start the Managed Server.

14.6.4.9.6 Validate Configuration

Validate the initial Discoverer configuration by performing these tests:

Test URL Result
Test load balancer http://mysite.mycompany.com/ Home page opens
Discoverer http://mysite.mycompany.com/discoverer/viewer Single Sign-On and then Discoverer Viewer opens

14.6.5 Install and Configure Application Tier on APPHOST2

The following sections describe how to install and configure the Application Tier on APPHOST2.

14.6.5.1 Install Oracle WebLogic Server

To install Oracle WebLogic Server binaries, see the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

See "Understanding Your Installation Starting Point" in Oracle Fusion Middleware Installation Planning Guide for the version of Oracle WebLogic Server to use with the latest version of Oracle Fusion Middleware.

14.6.5.2 Install Oracle Portal, Forms, Reports, and Discoverer Software

To install the Oracle Portal, Forms, Reports, and Discoverer binaries, see Oracle Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer.

Note:

Before you run the Configuration Wizard by following the instructions in Section 14.6.5.3, "Configure Oracle Portal, Forms, Reports, and Discoverer Software," ensure that you applied the latest Oracle Fusion Middleware patch set and other known patches to your Middleware Home.

See "Understanding Your Installation Starting Point" in Oracle Fusion Middleware Installation Planning Guide for the steps you must perform to get the latest version of Oracle Fusion Middleware.

14.6.5.3 Configure Oracle Portal, Forms, Reports, and Discoverer Software

Start the Oracle Fusion Middleware Configuration Wizard by running this command:

ORACLE_HOME/bin/config.sh

Note:

Before starting the configuration ensure that the following environment variables (UNIX) are not set:
  • LD_ASSUME_KERNEL

  • ORACLE_BASE

  • LD_LIBRARY_PATH

Continue with the following steps:

  1. In the Welcome screen, click Next.

  2. In the Prerequisite Checks screen, once all the prerequisites have been validated, click Next.

  3. In the Create Domain screen, select Expand Cluster and enter these values:

    • Host Name: Name of the host running the WebLogic Administration Server, for example: APPHOST1.mycompany.com

    • Port: The Administration Server port. For example: 7001

    • User Name: Administration Server administrator account name.

    • User Password: Password for the Administration Server administrator account.

    Click Next.

  4. In the Specify Security Updates screen, if required, enter a username and password to receive Oracle Security updates for Oracle Support.

  5. In the Specify Installation Location screen, enter these values:

    • WebLogic Server Location: Enter the installation directory for Oracle WebLogic Server. This should be MW_HOME/wlserver_10.3, for example:

      /u01/app/oracle/product/FMW/wlserver_10.3
      
    • Oracle Instance Location: Enter the directory where the Oracle configuration files will be placed. This should be outside of the Oracle home directory. This directory will be known as the ORACLE_INSTANCE. For example:

      /u01/app/oracle/admin/fmw2
      
    • Oracle Instance Name: fmw2

    Click Next.

  6. In the Configure Components screen, choose which products to install and configure. If placing Oracle Web Cache or the Oracle HTTP Server onto this node, ensure that they are selected.

    Note:

    This should be the same list as selected on APPHOST1.

    Click Next.

  7. Select the same staticports.ini file used for APPHOST1.

  8. In the Specify Application Identity Store screen, specify the following values:

    • Hostname: Name of the Oracle Internet Directory server, for example: login.myoid.com

    • Port: Oracle Internet Directory port, for example: 389

    • User Name: cn=orcladmin

    • Password: Password for Oracle Internet Directory's orcladmin account

  9. In the Summary screen, click Install to begin the creation process.

14.6.5.4 Generic Configuration

The following steps are required regardless of the component you are configuring.

14.6.5.4.1 Copy Configuration Information from APPHOST1

After the Expand Cluster operation has created a new WebLogic Managed Server and associated machine, it is necessary to copy some configuration information from APPHOST1 to APPHOST2.

Copy the following files located on APPHOST1 to the APPHOST2 locations shown in the following table:

File APPHOST1 Location APPHOST2 Location
mod_oradav.conf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
mod_osso.conf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
plsql.conf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
portal.conf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
forms.conf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
reports_ohs.conf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
module_disco.conf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
virtual_hosts.conf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
osso.conf ORACLE_INSTANCE/config/OHS/ohs1/ ORACLE_INSTANCE/config/OHS/ohs1/
sqlnet.ora ORACLE_INSTANCE/config ORACLE_INSTANCE/config
tnsnames.ora ORACLE_INSTANCE/config ORACLE_INSTANCE/config

14.6.5.4.2 Configure Virtual Hosts

For the site to function properly with the load balancer, you must add two virtual hosts. You can configure the virtual hosts using Oracle Enterprise Manager Fusion Middleware Control, edit the file ORACLE_INSTANCE/config/OHS/ohs1/httpd.conf, or edit the virtual_hosts.conf file located in the in ORACLE_INSTANCE/config/OHS/ohs1/moduleconf directory (copied from APPHOST1).

In a text editor, update the file to change APPHOST1 to APPHOST2:

NameVirtualHost *:7778
<VirtualHost *:7778>
     ServerName http://mysite.mycompany.com:80
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>

<VirtualHost *:7778>
    ServerName apphost2.mycompany.com:7777
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>
14.6.5.4.3 Update Oracle HTTP Server Configuration to be Cluster Aware

When the installation was first created, it was configured so that all Web Logic requests were directed to the initially created Managed Servers residing on APPHOST1. Now that APPHOST2 exists, both the Oracle HTTP Servers on APPHOST1 and APPHOST2 must be made aware of all of the Oracle WebLogic Managed Servers.

To make the Oracle HTTP Server aware of APPHOST2, edit files located in the following directory:

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

There are different files to edit for Portal, Forms, Reports, and Discoverer, as shown in the following table:

Product File
Portal portal.conf
Forms forms.conf
Reports reports_ohs.conf
Discoverer module_disco.conf

Edit the files as follows:

  1. Remove the lines that begin with WebLogicHost and WebLogicPort and add the following lines:

    WebLogicCluster apphost1:9001,apphost2:9001
    
  2. Change any lines that begin with WebLogicCluster to look similar to this:

    WebLogicCluster apphost1:9001,apphost2:9001
    

    For example, change the following:

    <Location /portal>
        SetHandler weblogic-handler
        WebLogicHost apphost1.mycompany.com
        WebLogicPort PORT
    </Location>
    

    to this:

    <Location /portal>
        SetHandler weblogic-handler
        WebLogicCluster apphost1.mycompany.com:PORT,apphost2.mycompany.com:PORT
    </Location>
    

    Change the following:

    <Location /Forms>
        SetHandler weblogic-handler
        WebLogicCluster apphost1.mycompany.com:PORT
    </Location>
    

    to this:

    <Location /Forms>
        SetHandler weblogic-handler
        WebLogicCluster apphost1.mycompany.com:PORT,apphost2.mycompany.com:PORT
    </Location>
    

Repeat these steps on APPHOST2.

14.6.5.4.4 Change the Web Cache Passwords

Web Cache passwords are randomly generated, however they are required in later stages. It is therefore recommended that the Web Cache passwords be changed from the default value to a new known value.

To change the default password, follow these steps:

  1. In the Navigator window, expand the Web Tier tree.

  2. Click on the component wc1.

  3. From the drop down list at the top of the page, select Administration - Passwords.

  4. Enter new invalidation and administration passwords, confirm them, and click Apply.

Note:

The passwords used in this procedure must be the same as those used on APPHOST1. This is required for the web caches to be clustered together in later procedures.
14.6.5.4.5 Configure Web Cache

Web Cache is optional for Oracle Forms, Reports and Discoverer, but mandatory for Oracle Portal. If Web Cache was not configured for APPHOST1, ignore the following Web Cache configuration steps:

Log into the Enterprise Manager Console

Log into the Enterprise Manager Console using the following URL:

http://apphost1.mycompany.com:7001/em

The default User Name and Password are the same as the WebLogic domain user name and password entered during the installation.

Create the Origin Server

To create the origin server:

  1. In the Navigator Window, expand the Web Tier tree.

  2. Click on the component wc1 (make sure it is the one associated with APPHOST1).

  3. From the drop down list at the top of the page select Administration - Origin Servers.

  4. Click Create.

  5. Enter the following information to add the origin server:

    Field Value
    Host APPHOST2.mycompany.com
    Port 7778
    Capacity 100
    Protocol HTTP
    Failover Threshold 5
    Ping URL /
    Ping Interval 10

  6. Click OK to save the changes.

  7. Click Apply to save the changes.

Add Origin Server to Existing Site to Server Mapping

To add the origin server site to server mapping:

  1. In the Navigator Window, expand the Web Tier tree.

  2. Click on the component wc1 (make sure it is the one associated with APPHOST1).

  3. From the drop down list at the top of the page select Administration - Sites.

  4. In the Site to Server Mapping section, click on the Host:Port, for example:

    mysite.mycompany.com:80
    
  5. Click Edit.

  6. Select the origin server APPHOST2.mycompany.com:7778 and move it to the selected Origin servers list.

  7. Click OK to save the changes.

  8. Click Apply to save the changes.

Cluster Web Cache on APPHOST1 and APPHOST2

Follow these steps to cluster Oracle Web Cache on APPHOST1 and APPHOST2:

Note:

For Oracle Web Cache clustering to function properly, the administration password of each of the Web Caches clustered together must be the same.
  1. In the Navigator Window, expand the Web Tier tree.

  2. Click on the component wc1 (make sure it is the one associated with APPHOST1).

  3. From the drop down list at the top of the page select Administration - Cluster.

  4. Click Add.

    The Web Cache from APPHOST2 is automatically added.

  5. Click Apply to apply the changes.

  6. Click on the newly created Web Cache entry (be sure not to click on the URL part of the entry).

  7. Click Synchronize to copy the configuration to the Web Cache on APPHOST2.

  8. Click Yes when prompted to confirm that you wish you perform the operation.

  9. Click Apply to apply the new configuration.

14.6.5.4.6 Restart Web Processes on APPHOST1 and APPHOST2

After making the previous changes, restart the Web Tier components on APPHOST1 and APPHOST2 using the following commands on each of the servers:

opmnctl stopall 
opmnctl startall
14.6.5.4.7 Start Oracle Node Manager on APPHOST2

To start the newly created Managed Server, start WebLogic Node Manager on APPHOST2 using the following commands on APPHOST2:

export ORACLE_HOME=oracle home path
export LD_LIBRARY_PATH=ORACLE_HOME/lib
WL_HOME/server/bin/startNodeManager.sh

14.6.5.5 Configure Oracle Portal for High Availability

This section describes the procedure for configuring only Oracle Portal for high availability.

14.6.5.5.1 Copy Configuration Information from APPHOST1

Even though the Expand Cluster has created a new WebLogic Managed Server and associated machine, it is still necessary to copy some configuration information from APPHOST1 to APPHOST2.

Copy the following files located on APPHOST1 to the APPHOST2 locations shown in the following table:

File or Directory APPHOST1 Location APPHOST2 Location
ORACLE_HOME/portal ORACLE_HOME/portal ORACLE_HOME/portal
appConfig.xml DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/ DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration/
portal_cache.conf DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/ DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration/
portal_dads.conf DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/ DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration/
portal_plsql.conf DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/ DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration/

14.6.5.5.2 Create Portal Directories

Create the following directories on APPHOST2 to allow the storage of the Oracle Portal Cache:

ORACLE_INSTANCE/portal/cache
ORACLE_INSTANCE/diagnostics/logs/portal
14.6.5.5.3 Update Instance Paths

Edit the hard coded entries in the following two copied files to reflect the paths above.

  • In the portal_cache.conf file, change PlsqlCacheDirectory.

  • In the portal_plsql.conf file, change PlsqlLogDirectory.

These files are located in the DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration directory.

14.6.5.5.4 Restart the Web Processes

Restart the Web Tier components on APPHOST2 using the following commands on each of the servers:

opmnctl stopall
opmnctl startall
14.6.5.5.5 Start WLS_PORTAL1

Now that the application files have been copied across. Start the managed server, WLS_PORTAL1:

  1. Log into the Administration Server on APPHOST1 using the URL:

    http://APPHOST1.mycompany.com:7001/console
    
  2. Provide the WebLogic Administration Console login credentials.

  3. Select Environment -> Servers from the Domain structure menu.

  4. Select the Control tab.

  5. Select the box next to the Managed Server WLS_PORTAL1, and click Shutdown - Force Shutdown Now.

  6. Click on Yes to confirm the operation.

    This resets the server's status.

14.6.5.5.6 Validate the Configuration

To validate the configuration:

Test URL Result
Test Portal via Load Balancer http://mysite.mycompany.com/portal/pls/portal Portal Home Page Displayed
Test Portal Login via Load Balancer http://mysite.mycompany.com/portal/pls/portal Should be able to log in using account orcladmin

14.6.5.5.7 Best Practices

By default configuration information is not automatically propagated to all server instances. If configuration files are changed on one portal server, propagate the configuration to all of the servers.

14.6.5.6 Configure Oracle Forms for High Availability

The section describes the procedure for configuring only Oracle Forms for high availability.

14.6.5.6.1 Create a TNSNAMES entries for Customer Databases

If the application is to access one or more databases, place an entry for each database being accessed into the file tnsnames.ora.

Edit the file ORACLE_INSTANCE/config/tnsnames.ora, and add an entry similar to the one below:

mydb.mycompany.com =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = mydb.mycompany.com)
    )
  )

This is an Oracle RAC database connect string.

14.6.5.6.2 Copy Forms Configuration Files

Even though the expand cluster has created a new WebLogic Managed Server and associated machine. It is still necessary to copy some configuration information from APPHOST1 to APPHOST2.

Copy the following files located on APPHOST1:

File Location of APPHOST1 Location of APPHOST2
ALL DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config
ALL ORACLE_INSTANCE/config/FormsComponent/forms ORACLE_INSTANCE/config/FormsComponent/forms
ALL ORACLE_INSTANCE/config/FRComponent/frcommon ORACLE_INSTANCE/config/FRComponent/frcommon

14.6.5.6.3 Update default.env

Having copied the above files, update the file default.env, located in the DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config directory with the correct values for APPHOST2. In particular, the following entries must be changed:

  • ORACLE_INSTANCE

  • TNS_ADMIN

  • FORMS_PATH

  • WEBUTIL_CONFIG

Typically these entries have the following values:

ORACLE_INSTANCE=/u01/app/oracle/admin/Forms1
TNS_ADMIN=/u01/app/oracle/admin/Forms1/config
FORMS_PATH=/u01/app/oracle/product/FMW/Forms/forms:/u01/app/oracle/admin/Forms1/FormsComponent/forms
WEBUTIL_CONFIG=/u01/app/oracle/admin/Forms1/config/FormsComponent/forms/server/webutil.cfg

And must be changed to:

ORACLE_INSTANCE=/u01/app/oracle/admin/Forms2
TNS_ADMIN=/u01/app/oracle/admin/Forms2/config
FORMS_PATH=/u01/app/oracle/product/FMW/Forms/forms:/u01/app/oracle/admin/Forms2/FormsComponent/forms
WEBUTIL_CONFIG=/u01/app/oracle/admin/Forms2/config/FormsComponent/forms/server/webutil.cfg
14.6.5.6.4 Restart WLS_FORMS1

After making the changes in the previous section, restart the WebLogic managed servers WLS_FORMS and WLS_FORMS1 by logging into the Oracle WebLogic Administration Console using the following URL

http://apphost1.mycompany.com:7001/console
  1. Select Environment -> Servers from the Domain Structure menu.

  2. Select the Control tab.

  3. Select the boxes next to the server WLS_FORMS1.

  4. Select Shutdown -> Force shutdown now.

  5. Select Yes when the confirmation dialogue opens.

  6. When the server is shutdown, restart it by selecting the boxes next to the server WLS_FORMS1.

  7. Click Start.

14.6.5.6.5 Validate the Configuration

To validate the configuration, use the following tests:

Test URL Result
Test Load Balancer http://mysite.mycompany.com/ AS Home Page Displayed
Forms http://mysite.mycompany.com/forms/frmservlet Forms Servlet Home Page displayed.

14.6.5.6.6 Best Practices

WebLogic Application Server does not replicate configuration information automatically between nodes. It is important to manually propagate any changes to any of the following to the other servers in the deployment:

  • ORACLE_INSTANCE

  • DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config

14.6.5.7 Configure Oracle Reports for High Availability

This section describes the procedures for configuring only Oracle Reports for high availability.

14.6.5.7.1 Create TNSNAMES Entries for Customer Databases

Oracle Reports uses entries in the tnsnames.ora file to determine database connection information. Place an entry into this file for the Oracle Reports queue database.

Edit the file ORACLE_INSTANCE/config/tnsnames.ora and add an entry similar to the following:

mydb.mycompany.com =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = mydb.mycompany.com)
    )
  )

Save the file and test that the database connection is configured correctly using the following command:

tnsping myreportq.mycompany.com
14.6.5.7.2 Configure the Reports Server to Access Shared Output Directory

Add the CacheDir or JOCCacheDir property to the <cache> element of each of the rwserver.conf files, which are located in the DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_11.1.1.2.0/configuration/ directory.

For example:

<property name="JOCCacheDir" value="folder_name"/>
<property name="CacheDir" value="folder_name"/>

For UNIX

<cache class="oracle.reports.cache.RWCache">
      <property name="cacheSize" value="50"/>
      <!--property name="cacheDir" value="your cache directory"/-->
      <!--property name="maxCacheFileNumber" value="max number of cache files"/-->
      <property name="JOCCacheDir" value="/share/reports"/>
      <property name="CacheDir" value="/share/reports"/>
   </cache>
14.6.5.7.3 Configure the Database Job Repository for In-process Reports Servers

Now that the reports queue has been placed into the database, notify the Reports server how to access it using the by editing the file rwserver.conf file, located in the DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_11.1.1.2.0/configuration directory.

When editing the file, the order in which different entries appear inside the server configuration file is fixed. As a result, the following element must be added immediately after the <jobStatusRepository> element in the server configuration file:

<jobRepository>
        <property name="dbuser" value="dbuser"/>
        <property name="dbpassword" value="csf:reports:dbpasswdKey"/>
        <property name="dbconn" value="dbconn"/>
      </jobRepository>

Where dbuser is the name of the schema where the reports queue resides.

Also, dbconn references a database entry in the tnsnames.ora file located in ORACLE_INSTANCE/config directory. dbpasswdKey is the name of the entry created.

For example:

<jobRepository>
        <property name="dbuser" value="reports_queue"/>
        <property name="dbpassword" value="csf:reports:queuePassword"/>
        <property name="dbconn" value="myrepq.mycompany.com"/>
</jobRepository>

The value of clusternodes is the value that appears in the <server> tag in the file rwservlet.properties file on APPHOST1.

The clusternodes parameter should list all of the reports servers in the cluster (comma separated) EXCEPT the local report server.

14.6.5.7.4 Creating an Oracle Reports Server Cluster

By creating a Reports cluster with a database reports queue it is possible to link all of the Reports servers to the same queue. The benefit of this procedure is that when a server has spare capacity, it can execute the next report in the queue, distributing the load. It also ensures that if a cluster member becomes unavailable, another Reports server can detect this and run any reports on which the failed server was working.

Create a Reports cluster by adding a cluster entry to the rwservlet.properties file on both APPHOST1 and APPHOST2.

Cluster APPHOST1

Edit the rwservlet.properties file located in the DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_11.1.1.2.0/configuration directory.

Add the following line:

<cluster clustername="cluster_reports" clusternodes="rep_wls_reports1_APPHOST2_reports2"/>

Note:

The value of clusternodes is the value which appears in the <server> tag in the rwservlet.properties file located on APPHOST2.

Note:

The clusternodes parameter should list all of the Reports servers in the cluster (comma separated) EXCEPT the local Reports server.

Cluster APPHOST2

Edit the rwservlet.properties file located in the DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_11.1.1.2.0/configuration directory.

Add the following line:

<cluster clustername="cluster_reports" clusternodes="rep_wls_reports_APPHOST1_reports1"/>

Note:

The value of clusternodes is the value which appears in the <server> tag in the rwservlet.properties file located on APPHOST1.

Note:

The clusternodes parameter should list all of the Reports servers in the cluster (comma separated) EXCEPT the local Reports server.
14.6.5.7.5 Restart WLS_REPORTS and WLS_REPORTS1

Restart the Web Logic managed servers WLS_REPORTS and WLS_REPORTS1 by logging into the WebLogic Administration Console using the following URL:

http://apphost1.mycompany.com:7001/console
  1. Select Environment -> Servers from the Domain Structure menu.

  2. Select the Control tab.

  3. Select the boxes next to the server WLS_REPORTS and WLS_REPORTS1.

  4. Select Shutdown -> Force shutdown now.

  5. Select Yes when the confirmation dialogue opens.

  6. When the server is shutdown, restart it by selecting the boxes next to the server WLS_REPORTS and WLS_REPORTS1.

  7. Click Start.

14.6.5.7.6 Validate the Configuration

To validate the configuration, run the following tests:

Test URL Result
Test Load Balancer http://mysite.mycompany.com/ AS Home Page Displayed
Test Reports Queue http://mysite.mycompany.com/reports/rwservlet/showjobs Single Sign On and Reports Queue pages are displayed

14.6.5.7.7 Managing Connection Availability for Oracle Reports Services

You must tune the time out settings to manage idle connections for the Load Balancing Router, firewall, Oracle HTTP Server, and WebLogic Server according to their Oracle Reports Services application requirements. For example, if the Load Balancing Router and firewall connection timeout is set to ten minutes, and the execution time for a report exceeds ten minutes, then the browser connection is timed out by the Load Balancing Router, and the Oracle Reports Services output does not reach the browser. The time out value for the connection between Oracle Reports Services clients and the Oracle Reports server is governed by the idleTimeout attribute of the connection element in the Oracle Reports Services Server configuration file rwserver.conf.

14.6.5.8 Configure Oracle Discoverer for High Availability

This section describes the procedures for configuring high availability for only Oracle Discoverer.

14.6.5.8.1 Create TNSNAMES Entries for Customer Databases

If the application is to access one or more databases, place an entry for each database being accessed into the tnsnames.ora file.

Edit the file ORACLE_INSTANCE/config/tnsnames.ora and add an entry as follows:

mydb.mycompany.com =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = mydb.mycompany.com)
    )
  )

This is an Oracle RAC database connect string.

Save the file and test that the database connection is configured correctly using the following command:

tnsping myreportq.mycompany.com
14.6.5.8.2 Copy Discoverer Configuration Files.

The expand cluster procedure has created a new WebLogic Managed Server and associated machine. However, you must still copy some configuration information from APPHOST1 to APPHOST2.

Prior to performing this step make a copy of the configuration.xml file located in the DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/ directory.

Copy this file from APPHOST1 to the same directory in APPHOST2.

14.6.5.8.3 Update configuration.xml

Update the configuration.xml file you just copied, replacing the following values with the values in the configuration.xml.orig file.

<oracleInstance>
<discovererComponentName>
14.6.5.8.4 Changing the Preference Store

In an enterprise deployment, there should only be one Discoverer preference store active at one time. To change the preference store, change Oracle Discoverer on APPHOST2 to point to the preference store on APPHOST1.

Identify Preference Store Host Name and Port

The nominated preference server in this example is configured to run on APPHOST1. When installed onto the server, the Preference server is assigned a port. Locate this value before proceeding to the following next steps:

  1. On APPHOST1, open the opmn.xml file is located in the ORACLE_INSTANCE/config/OPMN/opmn directory.

  2. Search the file for the entry PREFERENCE_PORT the value= shows the port assigned to the preference server.

Specifying a Discoverer Preferences Server on other Machines

Having identified the host name and port number of the machine that is going to run the Preferences component (that is, the Discoverer Preferences server machine), you must now ensure that other machines use the Preferences component on the Discoverer Preferences server machine.

To modify the opmn.xml file of other machines to use the Discoverer Preferences server machine, perform the following steps on every other machine in the installation.

  1. On each machine except the Preferences server machine, open the opmn.xml file in a text editor (or XML editor).

  2. Locate the PREFERENCE_HOST variable, and change its value to the host name of the Discoverer Preferences server machine, as follows:

    <variable id="PREFERENCE_HOST" value="hostname">
    
  3. Locate the PREFERENCE_PORT variable, and change its value to the port number of the Discoverer Preferences server machine, as follows:

    <variable id="PREFERENCE_PORT" value="port">
    
  4. Locate the PreferenceServer process type, and change its status to disabled, as follows:

    <process-type id="PreferenceServer" module-id="Disco_PreferenceServer"
    working-dir="$DC_LOG_DIR" status="disabled">
    
  5. Save the opmn.xml file.

14.6.5.8.5 Restart WLS_DISCO and WLS_DISCO1

Restart the Web Logic managed servers WLS_DISCO and WLS_DISCO1 by logging into the WebLogic Administration Console using the following URL:

http://apphost1.mycompany.com:7001/console
  1. Select Environment -> Servers from the Domain Structure menu.

  2. Select the Control tab.

  3. Select the boxes next to the server WLS_DISCO and WLS_DISCO1.

  4. Select Shutdown -> Force shutdown now.

  5. Select Yes when the confirmation dialogue opens.

  6. When the server is shutdown, restart it by selecting the boxes next to the server WLS_DISCO and WLS_DISCO1.

  7. Click Start.

14.6.5.8.6 Validate the Configuration

Validate the configuration using the following tests:

Test URL Result
Test Load Balancer http://mysite.mycompany.com/ AS Home Page Displayed
Discoverer http://mysite.mycompany.com /discoverer/viewer Discoverer Servlet Home Page displayed.

14.6.5.8.7 Failover of the Preference Server

If the server hosting the preference server fails, the preference server must be started on one of the surviving nodes using the following procedure:

Identify Preference Store Host Name and Port

The nominated preference server in this example is configured to run on APPHOST1. When installed onto the server, the Preference server is assigned a port. Locate this value using the following procedure:

  1. On APPHOST1, open the opmn.xml file is located in the ORACLE_INSTANCE/config/OPMN/opmn directory.

  2. Search the file for the entry PREFERENCE_PORT the value= shows the port assigned to the preference server.

Enable the Preference Store on APPHOST2

Now that APPHOST2 is using the preference store on APPHOST1, disable the preference store on APPHOST2 by editing the opmn.xml file located in the ORACLE_INSTANCE/config/OPMN/opmn directory

Locate the following line:

<process-type id="PreferenceServer" module-id="Disco_PreferenceServer" working-dir="$DC_LOG_DIR" status="disabled">

Change status=disabled to status=enabled.

For example:

<process-type id="PreferenceServer" module-id="Disco_PreferenceServer" working-dir="$DC_LOG_DIR" status="enabled">

Start the Preference Server on APPHOST2

Start the preference server on APPHOST2 using the following command:

opmnctl startproc process-type=PreferenceServer

Change Surviving Servers to Use the Preference Store on APPHOST2

Now that the preference server has been started on APPHOST2, amend all discoverer instances to use this preference server, including APPHOST2.

The preference store being used is determined at the startup of the WebLogic Managed Server WLS_DISCO1. In order to get WLS_DISCO1 to use a different preference store the startup parameters must be changed, by logging into the WebLogic Administration Console using the following URL:

http://apphost1.mycompany.com:7001/console

Continue with the following steps:

  1. Select Environment -> Servers from the Domain Structure menu.

  2. In the Change Center, click Lock & Edit.

  3. Click on the server WLS_DISCO1

  4. Click on the Configuration Tab and the Server Start sub tab.

  5. In the arguments field append the following

    -Doracle.disco.activation.preferencePort=<portno>
    -Doracle.disco.activation.preferenceHost=<hostname>
    

    the port number is the value of PREFERENCE_PORT defined previously.

    The hostname is the name of the host on which the preference server is started, for example, APPHOST2.

14.6.5.8.8 Setting up Discoverer WSRP Portlet Producer in a Clustered Environment

The portlet preference store is used for persisting consumer registration handles and portlet preference data.

Discoverer WSRP portlet producer uses a file-based preference store and the location of preference store is defined by the value of the discoWsrpPrefStoreSharedPath variable of the Discoverer deployment plan (an XML file). The default value of the discoWsrpPrefStoreSharedPath variable is portletData.

For more information about deployment plan and its contents, see the "Understanding Deployment Plan Contents" section in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.

In a clustered environment, for the file-based preference store, all Discoverer WSRP portlet producers running within the same Oracle WebLogic Server must use the same path for the discoWsrpPrefStoreSharedPath variable in the deployment plan. Therefore, the value of the discoWsrpPrefStoreSharedPath variable must be changed to a shared path in the deployment plan as described in the section "Setting Up the Preference Store".

When you change the discoWsrpPrefStoreSharedPath variable and if you want to migrate the preference store content from the existing preference store to a shared path, you must run the migration utility to transfer preference data from the source path to the destination path as described in the section "Using the Migration Utility to Transfer Preference Store Content".

Setting Up the Preference Store

To view and edit the Discoverer deployment plan by using WebLogic Server Administration Console:

  1. Log in to Oracle WebLogic Server Administration Console.

  2. In the left pane, click Deployments.

  3. In the right pane, select the Discoverer application for which you want to update the deployment plan. The Discoverer: Overview page appears.

The Deployment Plan field on the Overview page displays the path of the Discoverer application deployment plan (an XML file). Modify the deployment plan as described the following procedure:

  1. Open the deployment plan from the location (as displayed on the Discoverer: Overview page) in an XML editor.

  2. Navigate to the variable-definition section.

    ...
          <variable-definition>
            <variable>
              <name>discoWsrpPrefStoreSharedPath</name>
              <value>portletData</value>
            </variable>
          <variable-definition>
    ...
    

    Note:

    The discoWsrpPrefStoreSharedPath variable is defined in the variable-definition and variable-assignment sections of the deployment plan. You should modify only the discoWsrpPrefStoreSharedPath variable which is defined in the variable-definition section.
  3. Change the value of the discoWsrpPrefStoreSharedPath variable to a SharedPath which all Managed Servers can access.

    ...
          <variable-definition>
            <variable>
              <name>discoWsrpPrefStoreSharedPath</name>
              <value>SharedPath</value>
            </variable>
          <variable-definition>
    ...
    

    Note:

    You must specify a absolute path for the value. A relative path for the value is interpreted relative to the ORACLE_HOME/portal directory.
  4. Save your changes and close the XML file.

Once you update the deployment plan with the new value for the discoWsrpPrefStoreSharedPath variable, you must update the Discoverer application as described in the "Update (redeploy) an Enterprise application" section of Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

Using the Migration Utility to Transfer Preference Store Content

The WSRP container preference store migration utility, PersistenceMigrationTool, enables you to migrate existing data between different preference stores.

The syntax of the PersistenceMigrationTool is:

java oracle.portlet.server.containerimpl.PersistenceMigrationTool
-sourceType file -destType file -sourcePath dir -destPath dir

sourceType indicates that the source store is in a file.

destType indicates that the destination store is in a file.

Note:

Discoverer WSRP producer uses the file-based preference store. Therefore, you must specify file for the sourceType and destType arguments.

sourcePath and destPath are locations of file-based preference stores.

Note:

You must set the classpath when running this tool to include wsrp-container.jar, oracle.portlet-api.jar and ojdbc6.jar. For example:
java -classpath $ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/oracle-portlet-api.jar:$ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/wsrp-container.jar:$WL_HOME/server/lib/ojdbc6.jar
14.6.5.8.9 Best Practices

Oracle WebLogic Server does not replicate configuration information automatically between nodes. Therefore, it is important that any changes to any of the following be manually propagated to the other servers in the deployment:

  • ORACLE_INSTANCE

  • DOMAIN_HOME/servers/WLS_DISCO1/applications/discoverer_version/configuration/configuration.xml

Preference Server

The preference server contains details about user preferences, which can be updated on a frequent basis. If the Oracle Discoverer preference server fails, you must restart the preference server on another server. You would need to copy the preference information to these potential hosts on a regular basis.

The following file needs to be propagated to other servers, which could host the preference server on a regular basis:

ORACLE_INSTANCE/config/PreferenceServer/Discoverer_Instance/.reg_key.dc

14.6.6 Scaling Out the Deployment

To scale out the deployment to an additional node, follow the steps in Section 14.6.5, "Install and Configure Application Tier on APPHOST2." Be sure to use the same directory structure used for previous nodes.