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

14.2.1.6.1 Oracle Portal Log Files

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

14.6.1.2.1 Load Balancer

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

• Virtual server name and port configuration

• Process failure detection

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

• SSL Translation (if required)

14.6.1.2.2 Load Balancer Configuration - Virtual Server Names and Ports

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

If using SSL traffic terminated at the load balancer

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

If using site SSL

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

If using HTTP traffic terminated at the load balancer

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

Web Cache

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

  Note:

  For security reasons, ports 9401, 9402 and 9403 on the load balancing router should not be visible to external users.

• HTTP/HTTPS monitoring of Oracle Web Cache: The Load Balancing Router must be configured to detect an inoperative computer and stop routing requests to it until it is functioning again. Two Oracle Web Cache ports must be monitored: the HTTP request port and the invalidation port.

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

  hostname:port/_oracle_http_server_webcache_static_.html
  

  For example:

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

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

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

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

  For example:

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

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

  HTTP/1.0
  

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

  Note:

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

  To summarize, the load balancer requires the following configuration:

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

  
  

14.6.4.5.1 Set Admin Server Listen Address

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

To do this:

1. Log in to the WebLogic Console using the URL

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

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

3. Click AdminServer (admin)

4. Click on Lock and Edit from the change center.

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

6. Click Save.

7. Click Activate Changes from the change center.

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

14.6.4.5.2 Configure Virtual Hosts

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

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

NameVirtualHost *:7778
<VirtualHost *:7778>
    ServerName https://mysite.mycompany.com:443 ** If using SSL Termination/site at LB
    ServerName http://mysite.mycompany.com:80 ** If not using SSL
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>
 
<VirtualHost *:7778>
    ServerName apphost1.mycompany.com:7777
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>

Restart the Web Tier using these commands:

opmnctl stopall
opmnctl startall

14.6.4.5.3 Create boot.properties File

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

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

username=adminuser
password=password

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

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

14.6.4.5.4 Configure sqlnet.ora

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

TCP.CONNECT_TIMEOUT=10

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

14.6.4.5.5 Configure Web Cache

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

Log Into Enterprise Manager Console

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

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

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

Create Site

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

2. Click on the component wc1.

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

4. Select Create Site.

5. Enter the following information to add a site.

   Field	Value
   Host Name	mysite.mycompany.com
   Port	Specify the port number on the load balancer where requests are received, for example, 80 for HTTP requests and 443 for HTTPS request. If using a load balancer, this is the listening port on the load balancer.
   Default site	Yes
   Site Wide Compression	Yes
   Site Alias - Host Name	mysite.mycompany.com
   Site Alias - Port	7777
   Site Alias - Host Name	mysite.mycompany.com
   Site Alias - Port	80 Foot 1

   
   

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

6. Do not change any other defaults.

7. Select Submit.

8. Select OK to save each entry.

Create Site-to-Server Mapping

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

2. Enter the following information to add the site:

   Field	Value
   Host Pattern	mysite.mycompany.com
   Port Pattern	443 or 80, depending on whether SSL is being used or not.
   Selected Origin Servers	apphost1.mycompany.com:7778

   
   

3. Click OK to store the site.

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

5. Click Apply to save the changes.

Enable Session Binding

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

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

Follow these steps to enable session binding:

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

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

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

4. Click Apply to save the changes.

opmnctl stopall 
opmnctl startall

14.6.4.6.1 Rewire Portal Repository

Follow these steps to rewire the Oracle Portal repository:

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

   http://apphost1.us.oracle.com:7001/em
   

2. Expand the Fusion Middleware menu on the left hand side.

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

4. Click Portal.

   The Portal Domain information page is displayed.

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

6. Enter the following information for Portal midtier:

   Parameter	Value
   Host	Enter the DNS name of the load balancer. For example: mysite.mycompany.com
   Port	Enter the port that the load balancer is listening on. For example, 443 for SSL Termination/Site Enabled SSL or 80 for HTTP.
   SSL Protocol	Select this if SSL Termination/Site Enabled SSL is being used. This will ensure that when Portal needs to generate URLs that it generates them in these formats: https://mysite.mycompany.com:443/ (If selected) or: http://mysite.mycompany.com:80/ (If not selected)

   
   

7. Enter the following information for Web Cache:

   Parameter	Value
   Host	Enter the DNS name of the load balancer. For example: mysite.mycompany.com
   Invalidation Port	Enter the Portal Invalidation port as configured at the load balancer, for example: 9401
   Invalidation User Name	Enter the user name to be used for Portal invalidations, for example: invalidator
   Invalidation Password	Password for the above account. If you do not know the value of this password, it can be changed in Enterprise Manager as described above.

   
   

8. Click Apply to start the rewire.

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

10. Ensure that the Portal URL now shows:

    https://mysite.mycompany.com:443/portal/pls/portal
    

    or:

    http://mysite.mycompany.com:80/portal/pls/portal
    

14.6.4.6.2 Configure Parallel Page Engine Loop-Back with Load Balancer

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

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

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

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

   http://apphost1.us.oracle.com:7001/em
   

2. Select Fusion Middleware > Classic -> Portal from the object browser on the left.

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

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

   Parameter	Value
   UsePort	Select the internal loopback port number, for example: 7777. This port will have been configured at the load balancer for internal requests.
   Use Scheme	Change to the value of HTTP
   HTTPS Ports	443. Set this to the SSL listening port on the load balancer.

   
   

5. Click Apply to save the settings.

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

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

   2. Select the Control tab.

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

   4. Choose Shutdown > Force Shutdown Now.

   5. Click Yes to shut down the Managed Server.

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

   7. Click Start.

   8. Click Yes to start the Managed Server.

14.6.4.6.3 Database Wallets and Portal

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

Create a Database Wallet

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

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

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

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

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

4. Copy this file to the database server.

5. Save the certificate if requested.

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

   1. Type owm to invoke the Oracle Wallet Manager.

   2. Select Wallet > New.

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

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

   5. Set the Wallet Type to Standard.

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

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

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

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

   10. Select Wallet and Save As.

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

       ORACLE_BASE/admin/DB_NAME/wallet
       

   12. Repeat this procedure for other Oracle RAC database nodes.

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

Identify the Wallet to Portal

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

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

   ORACLE_HOME/portal/admin/plsql/wwc
   

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

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

   In the command above:

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

   • walletpassword is the password for the wallet.

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

opmnctl stopall 
opmnctl startall

14.6.4.6.5 Post-installation Step for Portal Installation with Oracle RAC

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

14.6.4.6.6 Validate Configuration

To validate the configuration, perform the following tests for SSL:

To validate the configuration, perform the following tests for non-SSL:

Troubleshooting Single Sign-On Errors

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

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

14.6.4.7.1 Create TNSNAMES Entries for Customer Databases

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

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

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

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

   Note:

   This is an Oracle RAC database connect string.

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

   tnsping mydb.mycompany.com
   

   Note:

   Set the environment variable TNS_ADMIN before issuing the tnsping command above.

14.6.4.7.2 Restart WLS_FORMS

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

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

2. Select the Control tab.

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

4. Choose Shutdown > Force Shutdown Now.

5. Click Yes to shut down the Managed Server.

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

7. Click Start.

8. Click Yes to start the Managed Server.

14.6.4.7.3 Validate Configuration

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

14.6.4.8.1 Create Reports Queue in Database

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

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

The script is located in this directory:

ORACLE_HOME/reports/admin/sql

Follow these steps:

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

   sql> create user report_queue identified by MYSpassword;
   sql> grant connect, resource,create view to report_queue;
   

2. Connect to the Reports user and execute the following script:

   sqlplus report_queue/MYSpasswd
   sql> @ORACLE_HOME/reports/admin/sql/rw_server.sql
   

14.6.4.8.2 Create a TNSNAMES Entry for Reports Queue

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

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

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

   Note:

   This is an Oracle RAC database connect string.

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

   tnsping myrepq.mycompany.com
   

   Note:

   Set the environment variable TNS_ADMIN before using the tnsping command.

14.6.4.8.3 Create a Security Key for the Reports Queue

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

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

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

2. In the navigation tree on the left hand side, expand WebLogicDomain, and click on the name of the domain, for example: ReportsDomain.

   The ReportsDomain overview page appears.

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

4. Click Create Key.

5. Provide the following information:

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

   
   

6. Click OK when finished.

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

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

To do this, edit the rwserver.conf file.

The file is located in the following directory:

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

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

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

where:

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

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

For example:

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

14.6.4.8.5 Configure the Reports Server to Access Shared Output Directory

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

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

For example:

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

On UNIX:

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

14.6.4.8.6 Restart WLS_REPORTS

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

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

2. Select the Control tab.

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

4. Choose Shutdown > Force Shutdown Now.

5. Click Yes to shut down the Managed Server.

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

7. Click Start.

8. Click Yes to start the Managed Server.

14.6.4.8.7 Validate Configuration

Validate the initial Reports configuration by performing these tests:

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

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

14.6.4.9.1 Create TNSNAMES Entries for Customer Databases

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

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

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

   Note:

   This is an Oracle RAC database connect string.

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

   tnsping mydb.mycompany.com
   

   Note:

   Set the environment variable TNS_ADMIN before issuing the tnsping command.

14.6.4.9.2 Update configuration.xml

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

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

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

http://mysite.mycompany.com/discoverer

For example:

applicationURL="http://mysite.mycompany.com/discoverer">

14.6.4.9.3 Discoverer Viewer and Web Cache

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

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

14.6.4.9.4 Enable Single Sign On

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

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

   ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
   

2. Add the following lines to the file before the line that begins with </IfModule>:

   <Location /discoverer/plus>
    require valid-user
    AuthType Osso
   </Location>
    
   <Location /discoverer/viewer>        
    require valid-user
    AuthType Osso
   </Location>
    
   <Location /discoverer/app>
    require valid-user
    AuthType Osso
   </Location>
   

14.6.4.9.5 Restart All Components

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

Restart Web Components

Restart the Oracle HTTP Server using the following commands:

opmnctl stopall 
opmnctl startall

Restart WLS_DISCO

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

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

2. Select the Control tab.

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

4. Choose Shutdown > Force Shutdown Now.

5. Click Yes to shut down the Managed Server.

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

7. Click Start.

8. Click Yes to start the Managed Server.

14.6.4.9.6 Validate Configuration

Validate the initial Discoverer configuration by performing these tests:

14.6.5.4.1 Copy Configuration Information from APPHOST1

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

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

14.6.5.4.2 Configure Virtual Hosts

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

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

NameVirtualHost *:7778
<VirtualHost *:7778>
     ServerName https://mysite.mycompany.com:443 ** If using SSLTermination/site at LB
     ServerName http://mysite.mycompany.com:80 ** If not using SSL
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>

<VirtualHost *:7778>
    ServerName apphost2.mycompany.com:7777
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>

14.6.5.4.3 Update Oracle HTTP Server Configuration to be Cluster Aware

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

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

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

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

Edit the files as follows:

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

   WebLogicCluster apphost1:9001,apphost2:9001
   

2. Change any lines that begin with WebLogicCluster to look similar to this:

   WebLogicCluster apphost1:9001,apphost2:9001
   

   For example, change the following:

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

   to this:

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

   Change the following:

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

   to this:

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

Repeat these steps on APPHOST2.

14.6.5.4.4 Change the Web Cache Passwords

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

To change the default password, follow these steps:

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

2. Click on the component wc1.

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

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

14.6.5.4.5 Configure Web Cache

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

Log into the Enterprise Manager Console

Log into the Enterprise Manager Console using the following URL:

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

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

Create the Origin Server

To create the origin server:

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

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

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

4. Click Create.

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

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

   
   

6. Click OK to save the changes.

7. Click Apply to save the changes.

Add Origin Server to existing Site to Server Mapping

To add the origin server site to server mapping:

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

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

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

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

   mysite.mycompany.com:443/80
   

5. Click Edit.

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

7. Click OK to save the changes.

8. Click Apply to save the changes.

Cluster Web Cache on APPHOST1 and APPHOST2

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

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

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

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

4. Click Add.

   The Web Cache from APPHOST2 is automatically added.

5. Click Apply to apply the changes.

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

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

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

9. Click Apply to apply the new configuration.

14.6.5.4.6 Restart Web Processes on APPHOST1 and APPHOST2

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

opmnctl stopall 
opmnctl startall

14.6.5.4.7 Start Oracle Node Manager on APPHOST2

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

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

14.6.5.5.1 Copy Configuration Information from APPHOST1

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

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

14.6.5.5.2 Create Portal Directories

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

ORACLE_INSTANCE/portal/cache
ORACLE_INSTANCE/diagnostics/logs/portal

14.6.5.5.3 Update Instance Paths

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

• In the portal_cache.conf file, change PlsqlCacheDirectory.

• In the portal_plsql.conf file, change PlsqlLogDirectory.

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

14.6.5.5.4 Restart the Web Processes

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

opmnctl stopall
opmnctl startall

14.6.5.5.5 Start WLS_PORTAL1

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

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

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

2. Provide the WebLogic Administration Console login credentials.

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

4. Select the Control tab.

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

6. Click on Yes to confirm the operation.

   This resets the server's status.

14.6.5.5.6 Validate the Configuration

To validate the configuration:

With no SSL:

14.6.5.5.7 Best Practices

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

14.6.5.6.1 Create a TNSNAMES entries for Customer Databases

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

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

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

This is an Oracle RAC database connect string.

14.6.5.6.2 Copy Forms Configuration Files

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

Copy the following files located on APPHOST1:

14.6.5.6.3 Update default.env

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

• ORACLE_INSTANCE

• TNS_ADMIN

• FORMS_PATH

• WEBUTIL_CONFIG

Typically these entries have the following values:

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

And must be changed to:

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

14.6.5.6.4 Restart WLS_FORMS1

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

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

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

2. Select the Control tab.

3. Select the boxes next to the server WLS_FORMS1.

4. Select Shutdown -> Force shutdown now.

5. Select Yes when the confirmation dialogue is displayed.

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

7. Click Start.

14.6.5.6.5 Validate the Configuration

To validate the configuration, sue the following tests:

14.6.5.6.6 Best Practices

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

• ORACLE_INSTANCE

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

14.6.5.7.1 Create TNSNAMES Entries for Customer Databases

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

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

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

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

tnsping myreportq.mycompany.com

14.6.5.7.2 Configure the Reports Server to Access Shared Output Directory

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

For example:

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

For UNIX

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

14.6.5.7.3 Configure the Database Job Repository for In-process Reports Servers

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

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

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

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

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

For example:

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

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

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

14.6.5.7.4 Creating an Oracle Reports Server Cluster

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

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

Cluster APPHOST1

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

Add the following line:

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

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"/>

14.6.5.7.5 Restart WLS_REPORTS and WLS_REPORTS1

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

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

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

2. Select the Control tab.

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

4. Select Shutdown -> Force shutdown now.

5. Select Yes when the confirmation dialogue is displayed.

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

7. Click Start.

14.6.5.7.6 Validate the Configuration

To validate the configuration run the following tests:

14.6.5.7.7 Managing Connection Availability for Oracle Reports Services

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

14.6.5.8.1 Create TNSNAMES Entries for Customer Databases

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

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

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

This is an Oracle RAC database connect string.

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

tnsping myreportq.mycompany.com

14.6.5.8.2 Copy Discoverer Configuration Files.

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

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

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

14.6.5.8.3 Update configuration.xml

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

<oracleInstance>
<discovererComponentName>

14.6.5.8.4 Changing the Preference Store

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

Identify Preference Store Host Name and Port

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

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

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

Specifying a Discoverer Preferences Server on other Machines

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

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

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

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

   <variable id="PREFERENCE_HOST" value="hostname">
   

3. Locate the PREFERENCE_PORT variable, and change its value to the port number of the Discoverer Preferences server machine, as follows:

   <variable id="PREFERENCE_PORT" value="port">
   

4. Locate the PreferenceServer process type, and change its status to disabled, as follows:

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

5. Save the opmn.xml file.

14.6.5.8.5 Restart WLS_DISCO and WLS_DISCO1

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

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

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

2. Select the Control tab.

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

4. Select Shutdown -> Force shutdown now.

5. Select Yes when the confirmation dialogue is displayed.

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

7. Click Start.

14.6.5.8.6 Validate the Configuration

Validate the configuration using the following tests:

14.6.5.8.7 Failover of the Preference Server

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

Identify Preference Store Host Name and Port

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

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

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

Enable the Preference Store on APPHOST2

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

Locate the following line:

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

Change status=disabled to status=enabled.

For example:

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

Start the Preference Server on APPHOST2

Start the preference server on APPHOST2 using the following command:

opmnctl startproc process-type=PreferenceServer

Change Surviving Servers to Use the Preference Store on APPHOST2

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

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

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

Continue with the following steps:

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

2. Click on Lock and Edit in the change center window

3. Click on the server WLS_DISCO1

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

5. In the arguments field append the following

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

   the port number is the value of PREFERENCE_PORT defined previously.

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

14.6.5.8.8 Setting up Discoverer WSRP Portlet Producer in a Clustered Environment

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

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

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

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

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

Setting Up the Preference Store

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

1. Log in to Oracle WebLogic Server Administration Console.

2. In the left pane, click Deployments.

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

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

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

2. Navigate to the variable-definition section.

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

   Note:

   The discoWsrpPrefStoreSharedPath variable is defined in the variable-definition and variable-assignment sections of the deployment plan. You should modify only the discoWsrpPrefStoreSharedPath variable which is defined in the variable-definition section.

3. Change the value of the discoWsrpPrefStoreSharedPath variable to a SharedPath which all Managed Servers can access.

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

   Note:

   You must specify a absolute path for the value. A relative path for the value is interpreted relative to the ORACLE_HOME/portal directory.

4. Save your changes and close the XML file.

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

Using the Migration Utility to Transfer Preference Store Content

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

The syntax of the PersistenceMigrationTool is:

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

sourceType indicates that the source store is in a file.

destType indicates that the destination store is in a file.

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

java -classpath $ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/oracle-portlet-api.jar:$ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/wsrp-container.jar:$WL_HOME/server/lib/ojdbc6.jar

14.6.5.8.9 Best Practices

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

• ORACLE_INSTANCE

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

Preference Server

The preference server contains details about user preferences, which can be updated on a frequent basis. In the event of the failure of the Oracle Discoverer preference server, the preference server must be started on another server. The preference information therefore must be copied to these potential hosts on a regular basis.

To this end 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