| Oracle® Fusion Middleware High Availability Guide 11g Release 1 (11.1.1) Part Number E10106-20 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware High Availability Guide 11g Release 1 (11.1.1) Part Number E10106-20 |
|
|
PDF · Mobi · ePub |
This chapter describes high availability concepts and configuration procedures for Oracle Portals, Forms, Reports, and Discoverer. This chapter includes the following topics:
Section 14.1, "Overview of Oracle Portal, Forms, Reports, and Discoverer"
Section 14.2, "Oracle Portal and High Availability Concepts"
Section 14.3, "Oracle Reports and High Availability Concepts"
Section 14.5, "Oracle Discoverer and High Availability Concepts"
Section 14.6, "Configuring Oracle Portal, Forms, Reports, and Discoverer for High Availability"
Oracle Portal offers a complete portal framework for building, deploying, and managing portals that are tightly integrated with Oracle Fusion Middleware.
With Oracle Portal, you can enhance your deployments with enterprise content management capabilities through Oracle WebCenter Content. In addition, you can add Enterprise 2.0 capabilities to existing portals using Oracle WebCenter Portal Services. Oracle Portal has certified interoperability with both of these complementary solutions, and 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 Portal, enabling rapid deployment of Discoverer workbooks and worksheets to Web portals.
Oracle Portal, Forms, Reports and Discoverer can be installed individually or collectively.
Figure 14-1 shows 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 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 running 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 running 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.
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 |
This section describes high availability concepts that apply to Oracle Portal, Forms, Reports, and Discoverer.
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.
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.
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 enables redirected requests access to the same state information.
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.
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
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.
This section describes single-instance information and 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.
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.
Understanding the Oracle Portal Components - this section introduces the components of the Oracle Fusion Middleware. It describes how these components work with Oracle Portal.
Understanding the Oracle Portal Architecture - this section describes the Portal architecture. Read the following topics in this section:
Understanding Caching in Oracle Portal - this section describes the caching configurations you can implement to increase the availability and scalability of medium to large deployments.
Understanding WSRP and JPS - this section provides an introduction to the Web Services for Remote Portlets (WSRP) specifications and Java Portlet Specification (JPS). These two standards enable the development of portlets that interoperate with different Portal products, thereby increasing the availability of portlets within an organization.
For information about request flow in Oracle Portal, see the following sections in the Oracle Fusion Middleware Administrator's Guide for Portal Guide:
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.
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
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
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 |
|---|---|
|
|
Portal Page Engine configuration |
|
|
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 configuration |
|
|
Portal global settings |
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.
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. |
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.
Figure 14-2 shows a high availability configuration for Oracle Portal.
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 runs 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 enables 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 deploy 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.
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.
For information about Oracle Portal Node failure, see Section 14.1.3.2, "Common Component Node Failures."
For information about Oracle Portal WebLogic Managed Server failure, see Section 14.1.3.3, "Common Component WebLogic Managed Server Failures."
For information about Oracle Portal database failure, see Section 14.1.3.4, "Common Component Database Failures."
This section describes single-instance information and 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.
Note:
Oracle Fusion Middleware 11g Release 1 (11.1.1) does not support cloning Reports Managed Servers.
Note:
Active-active configurations support Web clients only. The command-line client, rwclient, is not supported. rwclient connects to a specific Reports Server by name and there can be only one named instance of a specific Reports Server.
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. You can use Oracle Reports Services to publish in both Web-based and non-Web-based environments.
The following table describes components specific to Oracle Reports:
Table 14-2 Oracle Reports Components
| Component | Description |
|---|---|
|
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 |
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 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 |
Use to store the output of reports that run successfully. By doing this, you do not need to run the same report repeatedly. |
|
Oracle Reports Queue |
List of report requests. When processing capacity becomes available, the next report in queue is run. |
|
Oracle Reports Customer Databases |
Reports are typically compiled using information stored in a variety of databases, referred to as customer databases. |
Oracle Single Sign On
Oracle recommends restricting access to Oracle Reports using Oracle Single Sign-On (SSO).
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 in a database.
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.
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 |
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 enable valid reports to run but not so high as to cause excessively long waits.
The Oracle Reports Services components contribute to the process of running a report as follows:
The client requests a report by contacting a server through a URL (Web)
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.
At runtime, the Reports Server spawns a Reports Engine and sends the request to that engine to be run.
The Reports Engine retrieves and formats the data.
The Reports Engine populates the Reports Server cache.
The Reports Engine notifies the Reports Server that the report is ready.
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.
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 |
Figure 14-3 shows an example Oracle Reports high availability deployment.
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.
If the Reports Server hangs or fails to respond, but the WebLogic Managed Server does not, the WebLogic Managed Server must be restarted manually.
For information about Oracle Reports Node failure, see Section 14.1.3.2, "Common Component Node Failures."
For information about Oracle Reports WebLogic Managed Server failure, see Section 14.1.3.3, "Common Component WebLogic Managed Server Failures."
For information about Oracle Reports database failure, see Section 14.1.3.4, "Common Component Database Failures."
This section describes single-instance information and 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.
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.
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
Oracle Forms only requires access to the databases with which it will interact. There are no special requirements for Oracle Forms itself.
The Oracle Forms request flow is as follows:
The user chooses a Link from a Web page, or types a URL directly in the Browser.
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.
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.
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.
The CLASS or JAR files are downloaded (if not already present) to the Browser and the Java applet starts.
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.
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.
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.
The user is prompted for database login information, if this had not already been supplied, and the connection to the database server is established.
The user is now ready to work.
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/
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
The various components of Oracle Forms Services contribute to the process of running and Oracle Form as follows:
Client requests a form by contacting a server through a URL.
Oracle HTTP Server routes the request to Oracle WebLogic Server
Oracle WebLogic Server creates a forms Runtime process to run the form.
If a middle tier server fails 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.
The following table shows configuration files used by Oracle Forms:
| File | APPHOST1 Location | APPHOST2 Location |
|---|---|---|
|
formsweb.cfg |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS2/applications/formsapp_11.1.1/config |
|
default.env |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS2/applications/formsapp_11.1.1/config |
|
base(jpi).htm |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS2/applications/formsapp_11.1.1/config |
|
Registry.dat |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config/forms/registry/oracle/forms/registry |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS2/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 |
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.
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 |
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
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.
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.
In a datacenter that uses virtual machines, the standby machine can be brought online using any spare hardware and thus be implemented very cheaply.
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 on all other machines, including the standby machine. This can create a problem, especially if the spare machine is virtual. You must keep the image that is the virtual machine in sync with the changes made to the other machines.
For information about Oracle Forms process failure, see Section 14.1.3.1, "Oracle Web Cache and Oracle HTTP Server Process Failures."
For information about Oracle Forms Node failure, see Section 14.1.3.2, "Common Component Node Failures."
For information about Oracle Forms WebLogic Managed Server failure, see Section 14.1.3.3, "Common Component WebLogic Managed Server Failures."
For information about Oracle Forms database failure, see Section 14.1.3.4, "Common Component Database Failures."
This section describes single-instance information and 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.
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
Figure 14-6 shows the runtime interaction between Discoverer components.
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 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.
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.
The environment and behavior of Oracle Discoverer are controlled by Discoverer preferences and configuration parameters.
For information about the list of preferences and the procedure to change preference settings, see Managing Discoverer Preferences in the Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer
Configuration parameters are stored in the configuration.xml file. For information about configuration parameters and how you can define settings for those parameters, see Managing and Configuring Discoverer in the Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer.
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.
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.
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.
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. |
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
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.
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.
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.
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.
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.
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.
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.jarORACLE_HOME/modules/oracle.jrf_11.1.1/jrf.jarORACLE_HOME/opmn/lib/nonj2eembeans.jarORACLE_HOME/server/lib/ojdbc6.jarORACLE_HOME/opmn/lib/optic.jarORACLE_HOME/opmn/lib/iasprovision.jarORACLE_HOME/opmn/lib/ons.jarORACLE_HOME/modules/oracle.adf.share_11.1.1/oracle-el.jarORACLE_HOME/jlib/share.jarORACLE_HOME/jlib/jewt4.jarFor 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.
For information about Oracle Discoverer Node failure, see Section 14.1.3.2, "Common Component Node Failures."
For information about Oracle Discoverer WebLogic Managed Server failure, see Section 14.1.3.3, "Common Component WebLogic Managed Server Failures."
For information about Oracle Discoverer database failure, see Section 14.1.3.4, "Common Component Database Failures."
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.
Section 14.6.4, "Install and Configure Application Tier on APPHOST1"
Section 14.6.5, "Install and Configure Application Tier on APPHOST2"
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.
Before installing Oracle Portal, Forms, Reports and Discoverer, review the prerequisites described in this section.
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.
This section describes network requirements.
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)
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 |
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 store Discoverer End User Layers and work books as well as the data on which it reports.
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 |
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.
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.
For the example high availability configuration described in this chapter, consider the following assumptions:
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_FORMS1 |
APPHOST1 |
7053 |
WebLogic Managed Server port |
|
WLS_FORMS2 |
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 |
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.
Install the latest version of the Repository Creation Utility, as described in the Oracle Fusion Middleware Repository Creation Utility User's Guide.
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.
In the Create Repository screen, select Create and then click Next.
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.
In the Check Prerequisites screen, click OK when the prerequisites have been validated.
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.
In the Check Prerequisites screen, click OK when the prerequisites have been validated.
In the Schema Passwords screen, enter passwords for each of the portal schemas or use the same password for all schemas.
Click Next.
In the Map Tablespaces screen, click Next to accept the defaults.
In the Create Tablespaces screen, click Yes to enable RCU to create any missing tablespaces.
In the Creating Tablespaces screen, click OK to acknowledge tablespace creation.
In the Summary screen, click Create to begin the creation process.
The following steps are applicable for Oracle Portal, Forms, Reports and Discoverer installations.
Section 14.6.4.2, "Install Oracle Portal, Forms, Reports, and Discoverer"
Section 14.6.4.3, "Configure Oracle Portal, Forms, Reports, and Discoverer Software"
Section 14.6.4.6, "Configure Oracle Portal for High Availability"
Section 14.6.4.7, "Configure Oracle Forms for High Availability"
Section 14.6.4.8, "Configure Oracle Reports for High Availability"
Section 14.6.4.9, "Configure Oracle Discoverer for High Availability"
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.
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.
To start the Oracle Fusion Middleware Configuration Wizard, run 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:
In the Welcome screen, click Next.
In the Prerequisite Checks screen, once all the prerequisites have been validated, click Next.
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.
In the Specify Security Updates screen, if required, enter a username and password to receive Oracle Security updates for Oracle Support.
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.
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.
In high availability implementations, it is not mandatory for all of the ports used by the various components to be synchronized across hosts, but Oracle strongly recommends it. Oracle enables bypassing 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.
In the Specify Proxy Details screen (Reports only), if a proxy server is in use, enter the details in this screen.
Otherwise, click Next.
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.
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.
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
In the Summary screen, click Install to begin the creation process.
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 |
The following steps are required regardless of the product being configured:
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:
Log in to the WebLogic Console using the URL
http://apphost1.mycompany.com:7001/console
In the Domain Structure menu, select Environment, and then Servers.
Click AdminServer (admin)
In the Change Center, click Lock & Edit.
Set the listen address to the DNS name referring to the network card you wish to use. This is generally the public server name.
Click Save.
Click Activate Changes from the change center.
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.
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
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.
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.
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
In the Navigator window, expand the Web Tier tree.
Click on the component wc1.
From the list at the top of the page, select Administration - Sites.
Select Create Site.
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 and port 443.
Do not change any other defaults.
Select Submit.
Select OK to save each entry.
Create Site-to-Server Mapping
On the same page, select Create in the Site-to-Server Mapping section.
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 |
Click OK to store the site.
Ensure that the site mysite.mycompany.com:443/80 appears first in the list of site-to-server mappings.
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:
Select Administration - Session Configuration at the top of the page.
Select the site mysite.mycompany.com:443/80 from the drop down list.
In the Session Binding section, select Cookie based Session Binding with any Set Cookie.
Click Apply to save the changes.
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:
In the Navigator window, expand the Web Tier tree.
Click on the component wc1.
From the drop down list at the top of the page, select Administration - Passwords.
Enter new invalidation and administration passwords, confirm them, and click Apply.
After making the previous changes, restart the Web Tier components using these commands:
opmnctl stopall opmnctl startall
Perform these steps from the Single Sign-On server:
Set the ORACLE_HOME variable to the Single Sign-On Server ORACLE_HOME location.
Run 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
Copy /tmp/osso.conf to the mid-tier home location, which is:
ORACLE_INSTANCE/config/OHS/ohs1
Restart Oracle HTTP server on APPHOST1 using the following command:
opmnctl restartproc process-type=OHS
Log into the Single Sign-On Server using the following URL:
http://login.mycompany.com/pls/orasso
Go to the Administration page and then Administer Partner applications. Delete the entry for apphost1.mycompany.com.
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:
Log on to the Administration Console.
In the Domain Structure window, click on the domain name.
Click on the Web Applications tab.
Click Lock & Edit.
Select the WebLogic Plugin Enabled box.
Save and activate the changes.
Restart the Administration Server.
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.
Log into the Administration Console using the following URL:
http://apphost1.mycompany.com:7001/console
Select Clusters from the home page or choose Environment -> Clusters from the Domain structure menu.
In the Change Center, click Lock & Edit.
Click on the Cluster Name (cluster_portal, cluster_forms, cluster_reports, cluster_disco).
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.
Click Activate Changes in the Change Center window to save the changes.
Restart the WLS_PORTAL, WLS_FORMS, WLS_REPORTS, WLS_DISCO Managed Servers using the following steps:
Select Servers from the Home page or Environment > Servers from the Domain structure menu.
Select the Control tab.
Select the box next to each Managed Server.
Choose Shutdown > Force Shutdown Now.
Click Yes to shut down the Managed Server.
Once the Managed Server is shut down, select the box next to the Managed Server.
Click Start.
Click Yes to start the Managed Server.
The following steps are required to configure Oracle Portal only.
Follow these steps to rewire the Oracle Portal repository:
Log into the domain using Oracle Fusion Middleware Enterprise Manager using the following URL:
http://apphost1.example.com:7001/em
Expand the Fusion Middleware menu on the left hand side.
Expand the Portal menu (under Fusion Middleware menu).
Click Portal.
Right-click Portal and select settings Wire Configuration.
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. |
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. |
Click Apply to start the rewire.
After the rewire completes, click the Portal menu option again.
Ensure that the Portal URL now shows:
http://mysite.mycompany.com:80/portal/pls/portal
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 use a load balancer.
Log into the Oracle Fusion Middleware Enterprise Manager using this URL:
http://apphost1.example.com:7001/em
Select Fusion Middleware > Classic -> Portal from the object browser on the left.
Right-click Portal, and select Settings > Page Engine.
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 |
Click Apply to save the settings.
Restart the WebLogic Managed Server from the Oracle WebLogic Administration Console as follows:
Select Servers from the Home page or Environment > Servers from the Domain structure menu.
Select the Control tab.
Select the box next to the WLS_PORTAL Managed Server.
Choose Shutdown > Force Shutdown Now.
Click Yes to shut down the Managed Server.
Once the Managed Server is shut down, select the box next to the Managed Server.
Click Start.
Click Yes to start the Managed Server.
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:
Use a browser to access the URL https://mysite.mycompany.com.
Go to Firefox > Preferences > Advanced > Encryption > view certificates.
Highlight the certificate for mysite.mycompany.com select export and give the file a name.
Copy this file to the database server.
Save the certificate if requested.
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:
Type owm to invoke the Oracle Wallet Manager.
Select Wallet > New.
Select No so that you do not create the wallet in the default location.
Enter a password for the wallet (remember this password - it is needed later)
Set the Wallet Type to Standard.
Select No to the question Do you want to create a certificate at this time?.
In Oracle Wallet Manager, select Operations > Import Trusted certificate.
Select Select a file that contains the certificate and click OK.
Select the certificate file selected above and click Import.
Select Wallet and Save As.
Select a location for the wallet. For example:
ORACLE_BASE/admin/DB_NAME/wallet
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:
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.
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:
Select Servers from the Home page or Environment > Servers from the Domain structure menu.
Select the Control tab.
Select the box next to the WLS_PORTAL Managed Server.
Choose Shutdown > Force Shutdown Now.
Click Yes to shut down the Managed Server.
Once the Managed Server is shut down, select the box next to the WLS_PORTAL Managed Server.
Click Start.
Click Yes to start the Managed Server.
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.
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.
Use the following steps to configure Oracle Forms only.
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:
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.
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.
Restart the Managed Server WLS_FORMS by logging into the WebLogic Administration Console and following these steps:
Select Servers from the Home page or Environment > Servers from the Domain structure menu.
Select the Control tab.
Select the box next to the WLS_FORMS Managed Server.
Choose Shutdown > Force Shutdown Now.
Click Yes to shut down the Managed Server.
After the Managed Server is shut down, select the box next to the WLS_FORMS Managed Server. Click Start.
Click Yes to start the Managed Server.
The following steps are required to configure Oracle Reports only.
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:
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;
Connect to the Reports user and execute the following script:
cd ORACLE_HOME/reports/admin/sql
sqlplus reports_queue/MYpasswd@rw_server.sql
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:
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.
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.
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:
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
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.
From the drop-down menu at the top of the page select Security > Credentials.
Click Create Key.
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 |
Click OK when finished.
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>
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>
To restart the Managed Server WLS_REPORTS, log into the WebLogic Administration Console, and follow these steps:
Select Servers from the Home page or Environment > Servers from the Domain structure menu.
Select the Control tab.
Select the box next to the WLS_REPORTS Managed Server.
Choose Shutdown > Force Shutdown Now.
Click Yes to shut down the Managed Server.
Once the Managed Server is shut down, select the box next to the WLS_REPORTS Managed Server.
Click Start.
Click Yes to start the Managed Server.
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:
Follow these steps to configure high availability for Oracle Discoverer only.
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:
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.
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.
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">
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.
By default, Discoverer is not protected by single sign-on. To secure Discoverer Plus and Viewer, use the following steps:
Edit the file mod_osso.conf file, located in the following directory:
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
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>
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:
Select Servers from the Home page or Environment > Servers from the Domain structure menu.
Select the Control tab.
Select the box next to the WLS_DISCO Managed Server.
Choose Shutdown > Force Shutdown Now.
Click Yes to shut down the Managed Server.
Once the Managed Server is shut down, select the box next to the WLS_DISCO Managed Server.
Click Start.
Click Yes to start the Managed Server.
The following sections describe how to install and configure the Application Tier on APPHOST2.
Section 14.6.5.2, "Install Oracle Portal, Forms, Reports, and Discoverer Software"
Section 14.6.5.3, "Configure Oracle Portal, Forms, Reports, and Discoverer Software"
Section 14.6.5.5, "Configure Oracle Portal for High Availability"
Section 14.6.5.6, "Configure Oracle Forms for High Availability"
Section 14.6.5.7, "Configure Oracle Reports for High Availability"
Section 14.6.5.8, "Configure Oracle Discoverer for High Availability"
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.
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.
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:
In the Welcome screen, click Next.
In the Prerequisite Checks screen, once all the prerequisites have been validated, click Next.
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.
In the Specify Security Updates screen, if required, enter a username and password to receive Oracle Security updates for Oracle Support.
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.
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.
Select the same staticports.ini file used for APPHOST1.
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
In the Summary screen, click Install to begin the creation process.
The following steps are required regardless of the component you are configuring.
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 |
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>
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:
Remove the lines that begin with WebLogicHost and WebLogicPort and add the following lines:
WebLogicCluster apphost1:9001,apphost2:9001
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.
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:
In the Navigator window, expand the Web Tier tree.
Click on the component wc1.
From the drop down list at the top of the page, select Administration - Passwords.
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.
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:
In the Navigator Window, expand the Web Tier tree.
Click on the component wc1 (make sure it is the one associated with APPHOST1).
From the drop down list at the top of the page select Administration - Origin Servers.
Click Create.
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 |
Click OK to save the changes.
Click Apply to save the changes.
Add Origin Server to Existing Site to Server Mapping
To add the origin server site to server mapping:
In the Navigator Window, expand the Web Tier tree.
Click on the component wc1 (make sure it is the one associated with APPHOST1).
From the drop down list at the top of the page select Administration - Sites.
In the Site to Server Mapping section, click on the Host:Port, for example:
mysite.mycompany.com:80
Click Edit.
Select the origin server APPHOST2.mycompany.com:7778 and move it to the selected Origin servers list.
Click OK to save the changes.
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.
In the Navigator Window, expand the Web Tier tree.
Click on the component wc1 (make sure it is the one associated with APPHOST1).
From the drop down list at the top of the page select Administration - Cluster.
Click Add.
The Web Cache from APPHOST2 is automatically added.
Click Apply to apply the changes.
Click on the newly created Web Cache entry (be sure not to click on the URL part of the entry).
Click Synchronize to copy the configuration to the Web Cache on APPHOST2.
Click Yes when prompted to confirm that you wish you perform the operation.
Click Apply to apply the new configuration.
This section describes the procedure for configuring only Oracle Portal for high availability.
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/ |
Create the following directories on APPHOST2 to enable the storage of the Oracle Portal Cache:
ORACLE_INSTANCE/portal/cache ORACLE_INSTANCE/diagnostics/logs/portal
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.
Restart the Web Tier components on APPHOST2 using the following commands on each of the servers:
opmnctl stopall opmnctl startall
Now that the application files have been copied across. Start the managed server, WLS_PORTAL1:
Log into the Administration Server on APPHOST1 using the URL:
http://APPHOST1.mycompany.com:7001/console
Provide the WebLogic Administration Console login credentials.
Select Environment -> Servers from the Domain structure menu.
Select the Control tab.
Select the box next to the Managed Server WLS_PORTAL1, and click Shutdown - Force Shutdown Now.
Click on Yes to confirm the operation.
This resets the server's status.
To validate the configuration:
| Test | URL | Result |
|---|---|---|
|
Test Portal via Load Balancer |
http://mysite.mycompany.com/portal/pls/portal |
Portal Home Page opens |
|
Test Portal Login via Load Balancer |
http://mysite.mycompany.com/portal/pls/portal |
Should be able to log in using account orcladmin |
The section describes the procedure for configuring only Oracle Forms for high availability.
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.
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 |
Having copied the above files, update the file default.env, located in the DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/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
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
Select Environment -> Servers from the Domain Structure menu.
Select the Control tab.
Select the boxes next to the server WLS_FORMS1.
Select Shutdown -> Force shutdown now.
Select Yes when the confirmation dialogue opens.
When the server is shutdown, restart it by selecting the boxes next to the server WLS_FORMS1.
Click Start.
To validate the configuration, use the following tests:
| Test | URL | Result |
|---|---|---|
|
Test Load Balancer |
http://mysite.mycompany.com/ |
AS Home Page opens |
|
Forms |
http://mysite.mycompany.com/forms/frmservlet |
Forms Servlet Home Page opens. |
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
This section describes the procedures for configuring only Oracle Reports for high availability.
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
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>
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.
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.
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
Select Environment -> Servers from the Domain Structure menu.
Select the Control tab.
Select the boxes next to the server WLS_REPORTS and WLS_REPORTS1.
Select Shutdown -> Force shutdown now.
Select Yes when the confirmation dialogue opens.
When the server is shutdown, restart it by selecting the boxes next to the server WLS_REPORTS and WLS_REPORTS1.
Click Start.
To validate the configuration, run the following tests:
| Test | URL | Result |
|---|---|---|
|
Test Load Balancer |
http://mysite.mycompany.com/ |
AS Home Page opens |
|
Test Reports Queue |
http://mysite.mycompany.com/reports/rwservlet/showjobs |
Single Sign On and Reports Queue pages are opens |
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.
This section describes the procedures for configuring high availability for only Oracle Discoverer.
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
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.
Update the configuration.xml file you just copied, replacing the following values with the values in the configuration.xml.orig file.
<oracleInstance> <discovererComponentName>
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:
On APPHOST1, open the opmn.xml file is located in the ORACLE_INSTANCE/config/OPMN/opmn directory.
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 hostname 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.
On each machine except the Preferences server machine, open the opmn.xml file in a text editor (or XML editor).
Locate the PREFERENCE_HOST variable, and change its value to the hostname of the Discoverer Preferences server machine, as follows:
<variable id="PREFERENCE_HOST" value="hostname">
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">
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">
Save the opmn.xml file.
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
Select Environment -> Servers from the Domain Structure menu.
Select the Control tab.
Select the boxes next to the server WLS_DISCO and WLS_DISCO1.
Select Shutdown -> Force shutdown now.
Select Yes when the confirmation dialogue opens.
When the server is shutdown, restart it by selecting the boxes next to the server WLS_DISCO and WLS_DISCO1.
Click Start.
Validate the configuration using the following tests:
| Test | URL | Result |
|---|---|---|
|
Test Load Balancer |
http://mysite.mycompany.com/ |
AS Home Page opens |
|
Discoverer |
http://mysite.mycompany.com /discoverer/viewer |
Discoverer Servlet Home Page opens. |
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:
On APPHOST1, open the opmn.xml file is located in the ORACLE_INSTANCE/config/OPMN/opmn directory.
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:
Select Environment -> Servers from the Domain Structure menu.
In the Change Center, click Lock & Edit.
Click on the server WLS_DISCO1
Click on the Configuration Tab and the Server Start sub tab.
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.
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:
Log into the Administration Console.
In the left pane, click Deployments.
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:
Open the deployment plan from the location (as shown on the Discoverer: Overview page) in an XML editor.
Go 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.
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.
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
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
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.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|