Common Log Files Oracle Portal, Forms, Reports, and Discoverer Cluster-Wide Configuration Changes Common Component Log File Information

14-4 Oracle Fusion Middleware High Availability Guide ■ Oracle Single Sign-On is Oracles Enterprise authentication mechanism. Oracle Single Sign-On is integrated into Oracle HTTP Server for each of the product components. When a request which requires authentication comes in to the Oracle HTTP Server, it determines whether the user has been authenticated through the Oracle Single Sign-On server. If the user has been authenticated, the request is processed. If however, the user has not been authenticated, the Oracle Single Sign-On server is contacted to gain authorization.

14.1.2 Common Log Files

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

14.1.3 Common Component Failures and Expected Behaviors

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

14.1.3.1 Oracle Web Cache and Oracle HTTP Server Process Failures

Oracle HTTP Server, Oracle Web Cache, and Oracle Discoverer preference server processes are protected by the Oracle Process Manager and Notification system OPMN. If one of these processes fails, OPMN automatically restarts the process. Oracle WebLogic Managed Servers are started and monitored by Oracle Node Manager. If an Oracle WebLogic Managed Server fails, Oracle Node Manager restarts the process.

14.1.3.2 Common Component Node Failures

If a node that is not fronted by Oracle Web Cache fails, the Load balancer automatically reroutes requests to a surviving node. If Oracle Web Cache fails, the Load Balancer automatically reroutes requests to a surviving web cache node. If a node with Oracle HTTP Server fronted by Oracle Web Cache fails, Oracle Web Cache reroutes the request to a surviving Oracle HTTP Server. File Location Description access_log ORACLE_ INSTANCEdiagnosticslogsO HSohs1 Lists each access to the Oracle HTTP Server and the HTTP Return code ohs1.log ORACLE_ INSTANCEdiagnosticslogsO HSohs1 HTTP Server error log access_log ORACLE_ INSTANCEdiagnosticslogsWe bCacheweb1 Lists each access to Oracle WebCache and the HTTP Return code access_log DOMAIN_HOMEserversWLS_ PORTALlogs Lists access requests being received by the WebLogic Managed Server opmn.log ORACLE_ INSTANCEdiagnosticslogsOP MN OPMN log files Configuring High Availability for Oracle Portal, Forms, Reports, and Discoverer 14-5 If Oracle WebLogic Server fails, Oracle HTTP Server reroutes requests to another WebLogic cluster member. Oracle Portal, Forms, Reports and Discoverer requests being processed by the failed node must be restarted.

14.1.3.3 Common Component WebLogic Managed Server Failures

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

14.1.3.4 Common Component Database Failures

Databases are recommended to be implemented using high availability technologies such as Oracle Real Application Clusters. If one of the database nodes fails, the database as a whole remains available. In some cases you may have to resubmit the request. In a multi database node environment, if a user session is connected to the database node that fails, the following occurs: ■ Oracle Portal: The user is required to resubmit the request. ■ Oracle Forms: The user is required to resubmit the request. ■ Oracle Reports: If the database connect string is configured using Oracle Transparent Application Failover, no action is required unless the report writes to a database during its execution. If the database containing the reports queue loses a node, then the user is required to resubmit the report request. ■ Oracle Discoverer: The user is required to resubmit the request.

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

Oracle Web Cache instances are clustered. Once a configuration change is made through the Oracle Fusion Middleware Console or through the Oracle Web Cache Administration utility, these changes are propagated to other cluster members. Propagation is done manually using these tools. Oracle HTTP Servers are not clustered. The Oracle HTTP server configuration is file-based. As a result, changes made to one Oracle HTTP Server must be manually copied to other Oracle HTTP Servers in the configuration. This also applies to static HTML files stored in the htdocs directory. Configure Oracle Portal, Forms, Reports and Discoverer using a series of configuration files. Any changes to these files must be manually applied to all members in the architecture. WebLogic Managed Servers are clustered and share resources at the cluster level. Changes to these resources can be made once without the need for propagation. These resources include: ■ Data sources ■ Application redeployments 14-6 Oracle Fusion Middleware High Availability Guide ■ State replication

14.1.5 Common Component Log File Information

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

14.2 Oracle Portal and High Availability Concepts

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

14.2.1 Oracle Portal Single-Instance Characteristics

For information about the single-instance architecture of Oracle Portal, see the following sections in the Oracle Fusion Middleware Administrators 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: – How Does Oracle Portal Integrate with Other Components? – How Are Pages Assembled in Oracle Portal? – How Does Communication Flow in Oracle Portal? ■ 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.

14.2.1.1 Oracle Portal Request Flow

For information about request flow in Oracle Portal, see the following sections in the Oracle Fusion Middleware Administrator’s Guide for Portal Guide: ■ How Are Pages Assembled in Oracle Portal? ■ How Does Communication Flow in Oracle Portal?

14.2.1.2 Oracle Portal Component Characteristics

The following lists the characteristics of Oracle Portal components: ■ Oracle Portal application runs inside a WebLogic container WLS_PORTAL.