5 Performing Advanced Configuration

This chapter discusses the configuration that must be performed to achieve some of the more advanced configurations. To perform these configurations, you must be familiar with the available administrative tools, described in Section 4.1, "Getting Started with OracleAS Portal Administration".

This chapter contains the following sections:

• Changing the OracleAS Portal Port

• Configuring SSL

• Configuring Multiple Middle-Tiers with a Load Balancing Router

• Configuring Virtual Hosts

• Configuring OracleAS Portal to Use a Proxy Server

• Configuring Reverse Proxy Servers

• Configuring OracleAS Web Cache Caching in OracleAS Portal

• Changing the Infrastructure Services Used By a Middle-Tier

• Configuring OracleAS Wireless

• Changing the OracleAS Portal Schema Password

5.1 Changing the OracleAS Portal Port

Refer to the chapter "Port Change Procedures" in the Oracle Application Server 10g Administrator's Guide for information about procedures involved in changing ports in Oracle Application Server. If you change the OracleAS Web Cache port you must specify the OracleAS Web Cache settings that Portal should use on the Portal Web Cache Settings screen, as described in Section 7.2.3, "Portal Web Cache Settings Page".

Note: To view a list of all the ports currently in use by the components of a particular Oracle Application Server instance, refer to the steps outlined in Section 7.4, "Viewing Oracle Application Server Port Information".

5.2 Configuring SSL

OracleAS Portal uses a number of different components (such as the Parallel Page Engine, Oracle HTTP Server, and OracleAS Web Cache) each of which may act as a client or server in an HTTP communication. As a result, each component in OracleAS Portal's middle-tier must be configured individually to use the HTTPS protocol.

Configuring SSL is described in Chapter 6, "Securing OracleAS Portal". The following sections describe the various configuration options you have available for SSL with OracleAS Portal:

• Section 6.3.2.1.2, "SSL to OracleAS Single Sign-On"

• Section 6.3.2.1.3, "SSL to OracleAS Web Cache"

• Section 6.3.2.1.4, "SSL Throughout OracleAS Portal"

• Section 6.3.2.1.5, "External SSL with Non-SSL Within Oracle Application Server"

5.3 Configuring Multiple Middle-Tiers with a Load Balancing Router

This section describes how you can set up OracleAS Portal in a multiple middle-tier environment, front-ended by a load balancing router (LBR) to access the same Oracle Application Server Metadata Repository.

The purpose of a Load Balancing Router (LBR) is to provide a single published address to the client tier, and front-end a farm of servers that actually service the requests, based on the distribution of the requests done by the LBR. The LBR itself is a very fast network device that can distribute Web requests to a large number of physical servers.

Let us assume that we want to configure the multiple middle-tier configuration, shown in Figure 5-1. In the example, we show OracleAS Web Cache on the same machine as the Portal and Wireless middle-tier, although they can theoretically be on different machines.

Figure 5-1 Multiple Middle-Tier Configuration with Load Balancer

Text description of the illustration cg_topo_lbr_sepr_mmtier.gif

Table 5-1  Additional Information

Machine	Details
Load Balancing Router (LBR)	Machine Name: lbr.abc.com IP Address: L1.L1.L1.L1 Listening Port: 80 Invalidation Port: 4001 (accessible only from inside)
Oracle Application Server (Portal and Wireless middle-tier) 1 (M1)	Machine Name: m1.abc.com IP Address: M1.M1.M1.M1 Oracle HTTP Server Listening Port: 7778 OracleAS Web Cache Listening Port: 7777 OracleAS Web Cache Invalidation Port: 4001 OracleAS Web Cache Administration Port: 4002
Oracle Application Server (Portal and Wireless middle-tier) 2 (M2)	Machine Name: m2.abc.com IP Address: M2.M2.M2.M2 Oracle HTTP Server Listening Port: 7778 OracleAS Web Cache Listening Port: 7777 OracleAS Web Cache Invalidation Port: 4001 OracleAS Web Cache Administration Port: 4002

Notes: The name and port values used in this section are for illustration purposes only, and you will need to substitute these with your own. To view a list of all the ports currently in use by the components of a particular Oracle Application Server instance, refer to the steps outlined in Section 7.4, "Viewing Oracle Application Server Port Information".

To understand how to configure OracleAS Portal with an LBR, it is important to understand a bit more about the internal architecture of Portal.

• The Parallel Page Engine (PPE) in Portal makes loopback connections to Oracle Application Server Web Cache to request page metadata information. In a default configuration, OracleAS Web Cache and the OracleAS Portal middle-tier are on the same machine and the loopback is local. When Oracle Application Server is front-ended by an LBR, all loopback requests from the PPE will start contacting OracleAS Web Cache through the LBR. Assume that the OracleAS Portal middle-tier and OracleAS Web Cache are on the same machine, or on the same subnet. Then, without additional configuration, loopback requests result in network handshake issues during the socket connection calls.

  In order for loopbacks to happen successfully, you must set up a Network Address Translation (NAT) bounce back rule in the LBR, which essentially configures the LBR as a proxy for requests coming to it from inside the firewall. This causes the response to be sent back to the source address on the network, and then forwarded back to the client.

• OracleAS Portal leverages OracleAS Web Cache to cache a lot of its content. When cached content in OracleAS Web Cache changes, OracleAS Portal sends invalidation messages from the database to OracleAS Web Cache. OracleAS Portal can only send invalidation messages to one Web Cache node. In an OracleAS Web Cache cluster. Portal relies on that OracleAS Web Cache member to invalidate content in the other members of the cluster. When Oracle Application Server is front-ended by an LBR, the LBR must be configured to accept invalidation requests from the database and balance the load among the cluster members.

  Note: You will notice in Figure 5-1 that the infrastructure is behind the LBR. The infrastructure can be one host, or distributed over multiple hosts. In order to configure the infrastructure properly, refer to the Chapter titled "Advanced Configurations" in the Oracle Application Server Single Sign-On Administrator's Guide.

To configure OracleAS Portal in a multiple middle-tier environment, front-ended by an LBR, you must perform the following steps:

• Step 1: Install a Single Portal and Wireless Middle-Tier (M1)

• Step 2: Configure OracleAS Portal on M1 to Be Accessed Through the LBR

• Step 3: Confirm That OracleAS Portal is Up and Running

• Step 4: Install a New Portal and Wireless Middle-Tier (M2)

• Step 5: Configure the New Middle-Tier (M2) to Run Your Existing Portal

• Step 6: Configure Portal Tools and Web Providers (Optional)

• Step 7: Enable Session Binding on OracleAS Web Cache

• Step 8: Confirm the Completed Configuration

5.3.1 Step 1: Install a Single Portal and Wireless Middle-Tier (M1)

Install a single Portal and Wireless application server middle-tier, and verify the installation. To do this perform the following steps:

1. Follow the steps described in Chapter 3, "Installing OracleAS Portal", to install a Portal and Wireless Oracle Application Server 10g middle-tier on the first machine (M1). It is assumed that you use the services of an existing Oracle Application Server Infrastructure.

   See Also: Oracle Application Server 10g Installation Guide.

2. Verify that you have installed the middle-tier successfully by ensuring that you can access the OracleAS Portal home page at:

   http://m1.abc.com:7777/pls/portal
   
   

   Your configuration now looks like Figure 5-2, with the details described in Table 5-1.

Figure 5-2 Installation of OracleAS Portal Middle-Tier

Text description of the illustration cg_wc_mtier_infra.gif

3. Access your iasconfig.xml file, located in ORACLE_HOME/portal/conf, and verify that it looks something like Example 5-1:

Example 5-1 iasconfig.xml After the First Middle-Tier Installation

<IASConfig XSDVersion="1.0">
   <IASInstance Name="iAS-1.m1.abc.com" Host="m1.abc.com" Version="9.0.4"> 
      <WebCacheComponent ListenPort="7777" AdminPort="4002" InvalidationPort="4001" 
InvalidationUsername="invalidator" InvalidationPassword="@Bd4D+TnaUYFTJebppI
EqRc3/kleybcc70A==" SSLEnabled="false"/>
      <EMComponent ConsoleHTTPPort="1814" SSLEnabled="false"/>
   </IASInstance>
   <IASInstance Name="iAS.infra.abc.com" Host="infra.abc.com" Version="9.0.4">
      <OIDComponent AdminPassword="@BVs2KPJEWC5a0l4n8lbTxUY=" PortSSLEnabled="true" 
LDAPPort="3060" AdminDN="cn=orcladmin"/>
   </IASInstance>
   <PortalInstance DADLocation="/pls/portal" SchemaUsername="portal" 
SchemaPassword="@Beyh8p2bOWELQCsA5zRtuYc=" ConnectString="cn=iasdb,cn=oraclecontext">
      <WebCacheDependency ContainerType="IASInstance" Name="iAS-1.m1.abc.com"/> 
      <OIDDependency ContainerType="IASInstance" Name="iAS-1.m1.abc.com"/> 
      <EMDependency ContainerType="IASInstance" Name="iAS-1.m1.abc.com"/> 
   </PortalInstance> 
</IASConfig>

You now proceed with the next step where you configure OracleAS Portal to be accessed through an LBR.

5.3.2 Step 2: Configure OracleAS Portal on M1 to Be Accessed Through the LBR

To configure OracleAS Portal so it can be accessed through the load balancing router, perform the following steps:

1. Configure the LBR (lbr.abc.com) to accept requests on port 80 and forward those to the OracleAS Web Cache port (7777) running on machine m1.abc.com. To do this, you need to:
   1. Set up a group, or pool on the LBR, to which individual servers can be added.

   2. Add the desired servers' IP addresses, and port numbers to the group.

   3. Create a virtual server that listens on port 80, and balances load between the members of the group.

   4. Make sure the LBR translates the port that it is listening on to forward requests to the port that OracleAS Web Cache is listening on.

      Note: Consult the LBR documentation to set up the groups, and a virtual server.

2. Configure the OracleAS Portal middle-tier on M1 to allow underlying components to construct URLs based on the LBR hostname (lbr.abc.com) and LBR port number (80), so that self-referential URLs rendered on OracleAS Portal pages are valid for the browser. To do this, perform the following steps:
   1. Define a virtual host, using the Create Virtual Host wizard, as explained in Section 5.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:
      • On the Addresses page (step 9), specify the hostname of the LBR (lbr.abc.com) in the Server Name field for your virtual host.

      • In step 23, specify 80 for the Port directive in the VirtualHost container.

   2. Define a second virtual host, using the Create Virtual Host wizard, as explained in Section 5.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:
      • On the Addresses page (step 9), specify the hostname of M1 (m1.abc.com) in the Server Name field for your virtual host.

      • In step 23, specify 7777 for the Port directive in the VirtualHost container.

      • When prompted to restart the Oracle HTTP Server (step 26), click Yes.

3. Define a site that matches the virtual host entry, created in the previous step (lbr.abc.com), using OracleAS Web Cache Manager on M1, as follows:
   1. Access the OracleAS Web Cache Manager, using Oracle Enterprise Manager Application Server Control on M1 as described in Section 5.7.1, "Accessing OracleAS Web Cache Manager".

   2. Click Site Definitions under Origin Servers, Sites, and Load Balancing.

   3. Click Add Site.

   4. On the Add Site page, specify lbr.abc.com for the Host Name and 80 for Port Number. Keep the default values for all other fields.

   5. Click Submit. You will now see lbr.abc.com in the Site Definitions table.

4. Use OracleAS Web Cache Manager on M1, to map the site lbr.abc.com to middle-tier m1.abc.com.
   1. In the navigation frame, select Site-to-Server Mapping under Origin Servers, Sites, and Load Balancing.

   2. In the Site-to-Server Mapping page, select the first mapping in the table and click Insert Above.

   3. In the Create Site-to-Server Mapping page, select the Select from Site definitions option and then select a site definition created in the previous step (lbr.abc.com).

   4. In the Select Application Web Servers section, select the application server M1 (m1.abc.com) specified in the Origin Servers page.

   5. Click Submit.

   6. Click Apply Changes on the top of the page.

   7. In the Cache Operations page, click Restart to restart Web Cache on M1.

   To verify that the site has been mapped correctly, navigate to the Site-to-Server Mapping page, and ensure that M1 is mapped to the site lbr.abc.com.

5. Configure machine m1.abc.com so that it can resolve the LBR hostname to have the correct IP address. You can either rely on DNS resolution, or make entries in the /etc/hosts file as follows:

   L1.L1.L1.L1  lbr.abc.com
   
   

   Where L1.L1.L1.L1 is the IP address for the LBR. There is no need to restart the system after making these changes.

   Caution: Ensure that the /etc/hosts file does not have an entry that points the local hostname to 127.0.0.1. For example: 127.0.0.1 m1.abc.com

6. Configure the LBR to perform Network Address Translation (NAT) bounce back for loopback requests coming from the PPE running on m1.abc.com. This ensures that when the PPE makes a loopback request to OracleAS Web Cache, there are no errors.

   Notes: NAT bounce back is set up differently on individual LBRs. Consult your LBR's configuration guide on how to set this up. The log files contain the NAT bounce back addresses for all loopback requests from the Parallel Page Engine (PPE), that get forwarded to OracleAS Web Cache or Oracle HTTP Server through the LBR.

7. Configure the LBR (lbr.abc.com) to accept invalidation requests from the OracleAS Metadata Repository on a separate port (4001 in this example), so that it is forwarded to the OracleAS Web Cache running on machine m1.abc.com on port 4001.

   Note: The LBR does not have to listen on the OracleAS Web Cache invalidation port. On LBRs that do not have Port Mapping ability the port number must match the OracleAS Web Cache invalidation port.

   1. Set up a group, or pool on the LBR, to which individual servers can be added.

   2. Add the desired servers' IP addresses, and port numbers to the group.

   3. Create a virtual server that listens on port 4001, and balances load between the members of the group.

   4. In the case where the LBR's port, that is listening for the invalidation requests, and the OracleAS Web Cache's invalidation port are different, you must ensure that the LBR translates the port that it is listening on to forward requests to the port that OracleAS Web Cache is listening on.

      Notes: Consult the LBR documentation to set up the groups, and virtual server. If the Oracle Application Server Infrastructure is behind another firewall, you need to make sure that it can send invalidation messages to the LBR.

      Caution: For security reasons, the invalidation port on the LBR (port 4001) should only be accessible from within the network.

8. You must manually edit the iasconfig.xml file, typically located in ORACLE_HOME/portal/conf. Before editing the file, it is recommended that you make a backup copy of it. The file must be updated to have the correct farmname, hostname, and port information used to access OracleAS Portal, and to perform the OracleAS Web Cache invalidation, as shown in Example 5-2 (all changes are shown in bold):

Example 5-2 iasconfig.xml File Edited to Include Farm Element

<IASConfig XSDVersion="1.0">

   <IASFarm Name="Farm-1.lbr.abc.com" Host="lbr.abc.com">
      <WebCacheComponent ListenPort="80" AdminPort="4002" InvalidationPort="4001" 
InvalidationUsername="invalidator" InvalidationPassword="welcome1" SSLEnabled="false"/> 
   </IASFarm>

   <IASInstance Name="iAS-1.m1.abc.com" Host="m1.abc.com" Version="9.0.4">
      <OIDComponent AdminPassword="@BVs2KPJEWC5a0l4n8lbTxUY=" PortSSLEnabled="true" 
LDAPPort="3060" AdminDN="cn=orcladmin"/>
      <EMComponent ConsoleHTTPPort="1814" SSLEnabled="false"/> 
   </IASInstance>

   <PortalInstance DADLocation="/pls/portal" SchemaUsername="portal" 
SchemaPassword="@Beyh8p2bOWELQCsA5zRtuYc=" ConnectString="cn=iasdb,cn=oraclecontext">
      <WebCacheDependency ContainerType="IASFarm" Name="Farm-1.lbr.abc.com"/> 
      <OIDDependency ContainerType="IASInstance" Name="iAS-1.m1.abc.com"/> 
      <EMDependency ContainerType="IASInstance" Name="iAS-1.m1.abc.com"/> 
   </PortalInstance> 

</IASConfig>

9. Encrypt any plain text passwords in the iasconfig.xml configuration file. To do this, navigate to ORACLE_HOME/portal/conf, and run the following command:

   ptlconfig -encrypt
   
   

   Note: To use ptlconfig, the ORACLE_HOME environment variable must be set.

10. Register the URL changes with OracleAS Portal. Make sure that the new URLs used for accessing OracleAS Portal use the LBR hostname and port, and that the OracleAS Web Cache invalidation URLs (OracleAS Web Cache hostname and invalidation ports) are that of the LBR. To do this, navigate to ORACLE_HOME/portal/conf, and run the following command:

    ptlconfig -dad <portal_dadname> -wc -site
    

For example,

ptlconfig -dad portal -wc -site

11. Register the secured request with OracleAS Single Sign-On by configuring it as a partner application. The script ossoreg performs this registration. ossoreg is located on the middle-tier in MID_TIER_ORACLE_HOME/sso/lib.
    1. Ensure that you have your environment configured properly to run ossoreg:

       ORACLE_HOME=MID_TIER_ORACLE_HOME
       LD_LIBRARY_PATH=ORACLE_HOME/lib
       
       

    2. Run ossoreg. The following example illustrates the usage of ossoreg.

       MID_TIER_ORACLE_HOME/jdk/bin/java -jar 
         MID_TIER_ORACLE_HOME/sso/lib/ossoreg.jar -site_name lbr.abc.com 
         -mod_osso_url http://lbr.abc.com -config_mod_osso TRUE 
         -oracle_home_path MID_TIER_ORACLE_HOME -u install_user -config_file 
         MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf 
         -admin_info cn=orcladmin -virtualhost
       
       

Refer to the section titled "Registering mod_osso" in Chapter 4 of the Oracle Application Server Single Sign-On Administrator's Guide for more information.

After these steps, your configuration looks like Figure 5-3 with the details described in Table 5-1.

Figure 5-3 OracleAS Portal Being Accessed Through the LBR

Text description of the illustration cg_topo_load_balancer.gif

5.3.3 Step 3: Confirm That OracleAS Portal is Up and Running

Confirm that OracleAS Portal is up and running by performing the following tests in the specified order. If a test fails, address the issues, before proceeding with the next test. To diagnose the OracleAS Web Cache, Oracle HTTP Server, and LBR configuration and logs, refer to the chapter "Managing Diagnostic Log Files" in the Oracle Application Server 10g Administrator's Guide.

1. Test access to OracleAS Web Cache and Oracle HTTP Server through the LBR, by accessing a static file that is cached in OracleAS Web Cache, and make sure it works. For example, you can access the following URL:

   http://lbr.abc.com/relnotes.htm
   
   

2. Test the connection to Oracle Application Server Metadata Repository through the LBR, by accessing the following URL:

   http://lbr.abc.com/pls/portal/htp.p?cbuf=test
   
   

   The response should be "test". If this succeeds, it means that the Oracle Application Server middle-tier can connect to the OracleAS Metadata Repository. If this fails, scan the Oracle HTTP Server error_log file for details about the request failure, and take appropriate actions.

3. Test access to OracleAS Portal, by completing the following steps:
   1. Access the OracleAS Portal homepage at http://lbr.abc.com/pls/portal. If this does not work, scan the application.log file for the OC4J_Portal instance, and look for errors. The most common reason for this error is because the PPE cannot make loopback connections. For this to work:
      • Ensure that Network Address Translation (NAT) is enabled in the LBR.

      • Ensure that the middle-tier on m1.abc.com can resolve the address of lbr.abc.com. To do this, run the following command from m1.abc.com:

        ping lbr.abc.com
        
        

   2. Click the portal login link. If this does not work, it could be due to one of the following reasons:
      • The Infrastructure middle-tier is down or is not working. Check the OHS error_log file in the INFRA_ORACLE_HOME for more details.

      • The partner application URL registration for OracleAS Portal is incorrect, or OracleAS Single Sign-On is down.

   3. Click some links in the portal.

   4. Confirm that content is getting cached in OracleAS Web Cache. To do this, access the OracleAS Web Cache Manager on M1 as described in Section 5.7.1, "Accessing OracleAS Web Cache Manager".

      Note: The Web Cache Administration link in the Services portlet will not work in the multiple middle-tier configuration.

      Under Monitoring, click Popular Requests. Select Cached from the Filtered Documents drop-down list, and click Update. If you accessed OracleAS Portal, you will see portal content (For example, URLs that contain /pls/portal). If you don't see any portal content, open another browser and login to OracleAS Portal. Return to the Popular Requests page, and click Update, to refresh the page content. This should provide enough content for verification.

   5. Perform some simple page edits in OracleAS Portal, like adding a portlet to a page and make sure that the new content shows up. If the new content does not display properly, or if you see errors, OracleAS Web Cache invalidation is misconfigured.

5.3.4 Step 4: Install a New Portal and Wireless Middle-Tier (M2)

Follow these steps to install a new Portal and Wireless middle-tier on M2 (m2.abc.com):

1. Set the IASCONFIG_LOC environment variable to point to the same location that IASCONFIG_LOC is pointing to on machine m1.abc.com. The iasconfig.xml file allows Portal configuration to be performed from any of the hosts involved in a Web site topology. The environment variable should ideally point to a location that is accessible over a shared file system, so that installations done on different machines can reference and update the same file.

   The environment variable should be set in the second middle-tier before starting the installation. To override the default location of the configuration file, you must set the environment variable IASCONFIG_LOC to a directory in which the file is stored, for example:

   set IASCONFIG_LOC=/usr/local/ias904
   
   

   Note: By default, iasconfig.xml resides in ORACLE_HOME/portal/conf. If the Portal Dependency Settings file is accessible over a network file system, you can share the file across multiple hosts, avoiding the need to manually replicate it every time the file is modified. If the installation is running on an operating system that supports symbolic links, it is recommended that you use this mechanism to reference a shared file. If, however, the Portal Dependency Settings file is not accessible over the network, you must ensure that the file is kept up-to-date with changes to your site topology. Refer to Section A.1.2, "Updating the Portal Dependency Settings File" for more information.

2. Run Oracle's Universal Installer to install a Portal and Wireless Oracle Application Server 10g middle-tier on the second machine (M2).

   Note: It is recommended that you use the same physical path for installing the second middle-tier. This helps when you make configuration changes on one machine and want to transfer the changes to another machine. If the physical path is different on other machines, you must ensure that the path elements are corrected after copying the files.

3. Clear the selection for OracleAS Portal in the Select Configuration Options screen during the installation of Oracle Application Server middle-tier, as shown in Figure 5-4.

Figure 5-4 Select Configuration Options Screen

Text description of the illustration cg_advnc_sshot_cfgopts.gif

Caution: Selecting OracleAS Portal in the Select Configuration Options screen overwrites your previous configuration entries in OracleAS Portal. For more information, see Section 3.3, "Configuring OracleAS Portal During and After Installation".

4. Enable OracleAS Portal, accessing the Application Server Control. Refer to Section 7.1.2, "Using Application Server Control to Configure OracleAS Portal", for further instructions.

   Note: This will deploy the OracleAS Portal middle-tier components, but will not overwrite information in the OracleAS Metadata Repository.

5. Optionally, re-register the Wireless gateway URL with the load-balancer's address. See Section 5.9, "Configuring OracleAS Wireless" for more information.

6. This new installation should not have affected your previous configuration. Confirm that OracleAS Portal is up and running on M1, and can be accessed through the LBR. See Section 5.3.3, "Step 3: Confirm That OracleAS Portal is Up and Running" for more information on how to check this.

5.3.5 Step 5: Configure the New Middle-Tier (M2) to Run Your Existing Portal

Follow these steps, in the order specified, to configure M2 to run your existing portal:

1. Configure the new OracleAS Portal middle-tier to allow underlying components to construct URLs based on the LBR hostname (lbr.abc.com) and LBR port number (80). To do this, perform the following steps, using the Application Server Control on M2:
   1. Define a virtual host, using the Create Virtual Host wizard, as explained in Section 5.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:
      • On the Addresses page (step 9), specify the hostname of the LBR (lbr.abc.com) in the Server Name field for your virtual host.

      • In step 23, specify 80 for the Port directive in the VirtualHost container.

   2. Define a second virtual host, using the Create Virtual Host wizard, as explained in Section 5.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:
      • On the Addresses page (step 9), specify the hostname of M2 (m2.abc.com) in the Server Name field for your virtual host.

      • In step 23, specify 7777 for the Port directive in the VirtualHost container.

      • When prompted to restart the Oracle HTTP Server (step 26), click Yes.

2. Copy the configuration settings for OracleAS Portal from the middle-tier M1, to the middle-tier M2. It is a good idea to make backup copies of the files first. To do this, perform the following steps:
   1. Copy ORACLE_HOME/Apache/modplsql/conf/dads.conf from M1 to M2.

   2. Copy ORACLE_HOME/Apache/modplsql/conf/cache.conf from M1 to M2.

   3. Copy ORACLE_HOME/j2ee/OC4J_Portal/applications/portal/portal/WEB-INF/web.xml from M1 to M2.

   4. Copy ORACLE_HOME/Apache/Apache/conf/osso/osso.conf from M1 to M2

   5. If M1 and M2 are installed using different physical paths, you need to make sure that the path elements are corrected after copying the files.

   6. If you have not defined IASCONFIG_LOC in Section 5.3.4, "Step 4: Install a New Portal and Wireless Middle-Tier (M2)", you must update the iasconfig.xml file on M2, by following the steps described in Section A.1.2, "Updating the Portal Dependency Settings File".

   7. To synchronize the manual configuration changes done on M2, run the following command from ORACLE_HOME/dcm/bin/dcmctl:

      dcmctl updateConfig
      
      

   8. Restart OHS on M2, by running the following command from ORACLE_HOME/opmn/bin:

      opmnctl restartproc type=ohs
      
      

3. Configure the machine m2.abc.com to resolve the LBR hostname to have the correct IP address. You can either rely on DNS resolution for this, or make entries in the /etc/hosts file as follows:

   L1.L1.L1.L1  lbr.abc.com
   
   

   Caution: Ensure that the /etc/hosts file does not have an entry that points the local hostname to 127.0.0.1. For example: 127.0.0.1 m2.abc.com

4. Access the OracleAS Web Cache Manager on M1 from the Oracle Enterprise Manager Application Server Control on the middle-tier where OracleAS Web Cache is installed, as described in Section 5.7.1, "Accessing OracleAS Web Cache Manager".

5. Use OracleAS Web Cache Manager on M1, to add the OracleAS Web Cache on M2 to the OracleAS Web Cache cluster on M1. To do this, perform the following steps:
   1. Click Clustering under Properties.

   2. On the Clustering page, under the Cluster Members table, click Add.

   3. On the Add Cache to Cluster page, specify the following information for M2 to be included in this Web Cache cluster:

      Property	Value
      Host Name	m2.abc.com
      Admin Port	4002
      Protocol for Admin Port	HTTP
      Cache Name	m2.abc.com-WebCache
      Capacity	30

      Note: For the value of the Cache Name property, you can specify any name.

   4. Click Submit.

   5. To verify that the OracleAS Web Cache on M2 has been added to the cluster, locate m2.abc.com in the Cluster Member table.

      Refer to the section "Configuring a Cache Cluster" in the "Specialized Configurations" chapter of the Oracle Application Server Web Cache Administrator's Guide for more information.

6. Use OracleAS Web Cache Manager on M1, to add M2 as an additional origin server to the OracleAS Web Cache cluster, created in the previous step. To do this, perform the following steps:
   1. Click Origin Server, under Origin Servers, Sites, and Load Balancing.

   2. In the Origin Server page, click Add under the Application Web Servers table.

   3. In the Add Application Web Server page, provide the following information:

      Property	Value
      Hostname	m2.abc.com
      Port	7778
      Routing	ENABLED
      Capacity	100
      Failover Threshold	5
      Ping URL	/
      Ping Interval	10
      Protocol	HTTP

      Note: For the Port value, use the M2's OHS listening port.

   4. Click Submit

   5. To verify that the origin server has been added properly, locate m2.abc.com in the Origin Server table.

   Refer to the section "Map Sites to Origin Servers" in the Oracle Application Server Web Cache Administrator's Guide for more information.

7. Use OracleAS Web Cache Manager on M1, to map the site lbr.abc.com to the two origin servers m1.abc.com, and m2.abc.com, by performing the following steps:
   1. In the navigation frame, select Site-to-Server Mapping under Origin Servers, Sites, and Load Balancing.

   2. On the Site-to-Server Mapping page, Select the mapping for the LBR site in the table and click Edit Selected.

   3. In the Select Application Web Servers section, select an application Web server specified in the Origins Servers page for M2 (m2.abc.com).

   4. Click Submit.

   5. To verify that the site has been mapped correctly, ensure that both M1 and M2 are mapped to the site lbr.abc.com in the Site to Server Mappings table.

   Refer to the section "Map Sites to Origin Servers" in the Oracle Application Server Web Cache Administrator's Guide for more information.

8. To save your configuration changes, click Apply Changes on the top of the page. Perform the following steps in the Cache Operations page:
   1. Click Propagate to propagate changes to M2.

   2. Click Restart to restart Web Caches on M1 and M2.

9. Configure the LBR (lbr.abc.com) to accept invalidation requests from the OracleAS Metadata Repository on a separate port (4001 in this example), so that it is forwarded to the OracleAS Web Cache running on machine m1.abc.com on port 4001, and m2.abc.com on port 4001.

   Note: The LBR does not have to listen on the OracleAS Web Cache invalidation port. On LBRs that do not have Port Mapping ability, the port number must match the OracleAS Web Cache invalidation port.

10. Configure the LBR (lbr.abc.com) to accept requests on Port 80, so that it balances the load between the OracleAS Web Cache running on machine m2.abc.com:7777, and the OracleAS Web Cache running on m1.abc.com:7777.

    Note: Consult the LBR documentation to complete this step.

11. Configure the LBR to perform Network Address Translation (NAT) bounce back for loopback requests coming from OHS on m2.abc.com. Refer to Step 6 in Section 5.3.2, "Step 2: Configure OracleAS Portal on M1 to Be Accessed Through the LBR" section for more information.

    After these steps, your configuration looks like Figure 5-1.

    Note: For adding more middle-tiers, follow the procedures outlined in the sections Section 5.3.4, "Step 4: Install a New Portal and Wireless Middle-Tier (M2)" and Section 5.3.5, "Step 5: Configure the New Middle-Tier (M2) to Run Your Existing Portal", for each middle-tier.

5.3.6 Step 6: Configure Portal Tools and Web Providers (Optional)

To ensure that the Portal Tools (OmniPortlet and OracleAS Web Clipping) providers and Locally Built, as well as Custom built Web providers work properly, in the middle-tier environment, some additional configuration is required.

Configuring Portal Tools Providers in the Multiple Middle-Tier Environment

Perform the following steps for Portal Tools (OmniPortlet and OracleAS Web Clipping) providers to function properly in the multiple middle-tier environment:

1. Configure OmniPortlet to use a shared preference store. By default, the OmniPortlet provider uses the file-based preference store. However, in a multiple middle-tier environment, you must use a shared preference store, like the database preference store (DBPreferenceStore). To configure Portal Tools providers to use DBPreferenceStore, perform the following steps:
   1. Navigate to the directory ORACLE_HOME/j2ee/OC4J_Portal/applications/jpdk/jpdk/doc/dbPreferenceStore. For example:

      cd ORACLE_HOME/j2ee/OC4J_Portal/applications/jpdk/jpdk/doc/dbPreferenceStore
      
      

   2. On the database where the PORTAL schema is installed, log on to SQL*Plus as the user that owns the DBPreferenceStore table. Ensure that this user has the necessary privileges to create tables and indexes. For example:

      sqlplus scott/tiger
      
      

   3. Run the jpdk_preference_store2.sql script as follows in SQL*Plus:

      @jpdk_preference_store2
      
      

   4. Add the following entry to the file data-sources.xml, located in the directory ORACLE_HOME/j2ee/OC4J_Portal/config:

      <data-source
         class="com.evermind.sql.DriverManagerDataSource"
         name="omniPortletprefStore"
         location="jdbc/UnPooledConnection"
         xa-location="jdbc/xa/XAConnection"
         ejb-location="jdbc/PooledConnection"
         connection-driver="oracle.jdbc.driver.OracleDriver"
         username="scott"
         password="tiger"
         url="jdbc:oracle:thin:@infra.host.com:1521:orcl"
         inactivity-timeout="30"
      /> 
      
      

   5. Edit the file provider.xml located in the directory ORACLE_HOME/j2ee/OC4_Portal/applications/portalTools/omniPortlet/WEB-INF/providers/omniPortlet. Edit the preferenceStore tag as shown in bold:

      <provider class="oracle.webdb.reformlet.ReformletProvider"> 
         <vaultId>0</vaultId> 
         <session>true</session> 
         <preferenceStore 
      class="oracle.portal.provider.v2.preference.DBPreferenceStore"> 
            <name>omniPortletprefStore</name> 
            <connection>jdbc/PooledConnection</connection> 
         </preferenceStore> 
      
      

   More information on configuring the database preference store can be found in the PDK article titled "Installing the DBPreferenceStore Sample", located at http://portalstudio.oracle.com/pls/ops/docs/FOLDER/COMMUNITY/PDK/jpdk/v2/doc/dbPreferenceStore/installing.db.preference.store.v2.html, on Portal Studio at http://portalstudio.oracle.com.

2. Optionally, you can change the settings for the HTTP proxy configuration, or the repository used by OmniPortlet and OracleAS Web Clipping. You can change the settings on the Portal Tools Edit Provider pages (OmniPortlet, and OracleAS Web Clipping), accessible from the Portal Tools providers' test pages. The test pages are located at the following URLs:
   • OmniPortlet provider test page on M1: http://m1.abc.com:7777/portalTools/omniPortlet/providers/omniPortlet

   • Web Clipping provider test page on M1: http://m1.abc.com:7777/portalTools/webClipping/providers/webClipping

   Refer to Section I.1, "Configuring the Web Clipping Repository", and Section I.2, "Configuring HTTP or HTTPS Proxy Settings" for more information.

3. Copy the ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/omniPortlet/WEB-INF/providers/omniPortlet/provider.xml from M1 to M2.

4. Copy the ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/webClipping/WEB-INF/providers/webClipping/provider.xml from M1 to M2.

5. Copy the ORACLE_HOME/j2ee/OC4J_Portal/config/data-sources.xml from M1 to M2.

6. Click Edit Registration for the OmniPortlet Provider on the Providers tab of the Navigator, under Locally Built Providers. Then click the Connection tab, and change the first part of the provider registration URL from http://m1.abc.com:7777/ to http://lbr.abc.com/.

7. Click Edit Registration for the Web Clipping Provider on the Providers tab of the Navigator, under Locally Built Providers. Then click the Connection tab and change the first part of the provider registration URL from http://m1.abc.com:7777/ to http://lbr.abc.com/.

8. Verify that OmniPortlet and the Web Clipping Provider work properly through the LBR, by going to the test pages at the following URLs.
   • OmniPortlet Provider: http://lbr.abc.com:80/portalTools/omniPortlet/providers/omniPortlet

   • Web Clipping Provider: http://lbr.abc.com:80/portalTools/webClipping/providers/webClipping

     Note: If you want to use the OracleAS Web Clipping provider, or the Web Page Data Source for OmniPortlet, you must also enable session binding in OracleAS Web Cache, as described in Step 7: Enable Session Binding on OracleAS Web Cache.

Creating Locally Built Web Providers in the Multiple Middle-Tier Environment

Locally Built providers are providers that are defined within an instance of OracleAS Portal. Perform the following steps to create a Locally Built Web Provider that functions properly in the multiple middle-tier environment:

1. Access OracleAS Portal through the LBR at the URL http://lbr.abc.com/pls/portal.

2. In the Services portlet, click Global Settings. By default, the Services portlet is on the Portal sub-tab of the Administer tab on the Portal Builder page. Click the Configuration tab, and point the Default JPDK Instance URL to the M1 middle-tier, by specifying http://m1.abc.com:7777/jpdk/servlet/soaprouter/.

3. Create Web providers and create portlets under them. This creates a provider.xml file for each new provider.

4. To use the Locally Built Web provider in the multiple middle-tier environment, you need to copy the following files to M2:
   1. Copy the ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/providerBuilder/WEB-INF/providers/<providerName> directory from M1 to M2.

   2. Copy the ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/providerBuilder/WEB-INF/deployment/<providerName>.properties file from M1 to M2.

   3. Copy the ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/providerBuilder/WEB-INF/deployment_providerui/provideruiacls.xml file from M1 to M2.

   4. Copy the entry for <providerMap> in ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/providerBuilder/WEB-INF/deployment_providerui/providerstore.xml from M1 to M2 and change the <warDir> element with the appropriate value for the ORACLE_HOME for M2 (shown in bold):

      <providerMap name="MyProvider" baseLanguage="en">
          <displayName language="en" translation="myprovider"></displayName>
          <timeout>20</timeout>
          <timeoutMessage language="en" translation="Timed Out"></timeoutMessage>
          <loginFrequency>Never</loginFrequency>
          <httpURL>http://lbr.abc.com:80/portalTools/builder/providers/MYPROVIDER</httpURL>
          <cookieDomain>abc.com</cookieDomain>
          <serviceId>MYPROVIDER</serviceId>
          <requireSessionData>false</requireSessionData>
          <httpAppType>Portal</httpAppType>
          <warDir>ORACLE_HOME/j2ee/OC4J_
      Portal/applications/portalTools/providerBuilder/WEB-INF</warDir>
          <warFile>providerBuilder</warFile>
      </providerMap>
      
      

   5. Click Edit Registration for the provider on the Providers tab of the Navigator, under Locally Built Providers. Then click the Connection tab and change the first part of the provider registration URL from http://m1.abc.com:7777/ to http://lbr.abc.com/.

   6. Verify that the Web provider works properly through the LBR, by going to the test page at the URL http://lbr.abc.com:80/portalTools/builder/providers/<providerName>.

5. In the Services portlet, click Global Settings. By default, the Services portlet is on the Portal sub-tab of the Administer tab on the Portal Builder page. Click the Configuration tab, and point the Default JPDK Instance URL to the LBR, by specifying http://lbr.abc.com:80/jpdk/servlet/soaprouter/.

   Note: If you edit Locally Built Web Providers again, you will need to manually replicate the changes in the previously mentioned files to the other middle-tiers. However, since the middle-tiers are accessed through the LBR, you cannot specify on which middle-tier the changes are being made. If you want to create new Web providers, repeat the previous steps.

Configuring Custom Built Providers in a Multiple Middle-Tier Environment

A custom built provider is any web provider that is not seeded by the OracleAS Portal installation, or created using OracleAS Portal. To configure the custom built provider, you must deploy it on the first middle-tier, and register it to OracleAS Portal, using the M1 URL (http://m1.abc.com:7777/<webApp>/providers/<providerName>. To configure it to work in the multiple middle-tier environment, you must perform the following steps:

1. Configure the custom built provider to use a shared preference store. Refer to the steps in the section, Configuring Portal Tools Providers in the Multiple Middle-Tier Environment, in this document.

   More information on configuring the database preference store can be found in the PDK article titled "Installing the DBPreferenceStore Sample", located at http://portalstudio.oracle.com/pls/ops/docs/FOLDER/COMMUNITY/PDK/jpdk/v2/doc/dbPreferenceStore/installing.db.preference.store.v2.html, on Portal Studio at http://portalstudio.oracle.com.

2. Copy the ORACLE_HOME/j2ee/OC4J_Portal/applications/<webApp>/WEB-INF/providers/<providerName>/provider.xml from M1 to M2.

3. Click Edit Registration for the provider on the Providers tab of the Navigator, under Registered Providers. Then click the Connection tab, and change the first part of the provider registration URL from http://m1.abc.com:7777/ to http://lbr.abc/

4. Verify that the custom built provider works properly through the LBR, by going to the test pages at the URL http://lbr.abc.com:80/<webApp>/providers/<providerName>

5.3.7 Step 7: Enable Session Binding on OracleAS Web Cache

The Session Binding feature in OracleAS 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 OracleAS Portal middle-tier are stateless, session binding is required for two reasons:

• The Web Clipping Studio, used by both the OracleAS Web Clipping Portlet and the Web Page Data Source of OmniPortlet, uses HTTP session to maintain state, for which session binding must be enabled. Refer to Appendix I, "Administering Web Clipping" for more information about Web Clipping.

• Enabling session binding forces all the user requests to go to a given OracleAS Portal middle-tier, resulting in a better cache hit ratio for the portal cache. Refer to Section 1.3.2, "Understanding Portal Cache" for details on the portal cache.

  Note: Regardless of whether you have configured an LBR in your topology, you must enable session binding in OracleAS Web Cache, if you have more than one middle-tier. In this configuration OracleAS Portal does not require session binding to be set up on the LBR.

To make OracleAS Web Cache bind the portal user session to the OracleAS Portal middle-tier, perform the following steps:

1. In OracleAS Web Cache Manager on either M1, or M2, click Session Binding under Origin Servers, Sites, and Load Balancing.

2. In the Session Binding page, select the LBR site name (lbr.abc.com:80) in the table, and then click Edit Selected.

3. From the Please select a session list, change the session value to All Sessions. Leave Inactivity Timeout at the default setting.

4. Click Submit to apply the new settings to the site lbr.abc.com:80.

5. If Session Binding Cookie is disabled, click Enable.

6. To save your configuration changes, click Apply Changes at the top of the page.

7. On the Cache Operations page, click Propagate to propagate the changes.

8. Click Restart to restart OracleAS Web Cache on M1 and M2.

5.3.8 Step 8: Confirm the Completed Configuration

To verify that your complete configuration is working as expected, perform the following steps:

1. To clear the contents stored in OracleAS Web Cache, restart M1 and M2, as follows:
   1. Access the Application Server Control, typically located at http://www.abc.com:1812.

   2. Click the M1 instance.

   3. Click Restart All.

   4. Repeat the steps for M2.

2. Test access to OracleAS Portal through the LBR, by completing the following steps:
   1. Access the OracleAS Portal homepage at http://lbr.abc.com/pls/portal.

   2. Click the portal login link.

   3. Click some links in the portal.

   4. Confirm that content is getting cached in OracleAS Web Cache. To do this, access the OracleAS Web Cache Manager on M1 as described in Section 5.7.1, "Accessing OracleAS Web Cache Manager".

      Under Monitoring, click Popular Requests. Select Cached from the Filtered Documents drop-down list, and click Update. If you accessed OracleAS Portal, you will see portal content (For example, URLs that contain /pls/portal).

      Perform some simple page edits in OracleAS Portal, like adding a portlet to a page and make sure that the new content shows up. If the new content does not display properly, or if you see errors, OracleAS Web Cache invalidation is misconfigured.

5.4 Configuring Virtual Hosts

The Oracle HTTP Server (OHS) supports the configuration of virtual hosts. Virtual hosts allow a single machine to appear as any number of different sites. You can, for example, configure a machine to represent both www.abc.com, as well as www.xyz.com. Another example would be configuring a machine to represent both my.oracle.com, as well as oraclepartnernetwork.oracle.com. To configure virtual hosts with Oracle Application Server Portal, you must set this up on the Oracle HTTP Server. Additional Oracle Application Server Web Cache and Oracle Application Server Single Sign-On configuration is also required.

Note: If your intent is simply to change the hostname of your middle-tier, refer to the chapter titled "Changing Network Configurations" in the Oracle Application Server 10g Administrator's Guide.

Let's assume that your server name is www.abc.com, and you connect to OracleAS Portal at http://www.abc.com:7779/pls/portal. The IP address of the machine that the middle-tier is installed on is 196.12.67.8.

You want to access OracleAS Portal at http://www.abc.com:7779/pls/portal, using the real servername, as well as http://www.xyz.com:7779, using a virtual hostname, where both URLs resolve to the same IP address.

In this example, port 7779 is the OracleAS Web Cache listening port, and port 7778 is the OHS listening port.

Let's also assume that the OracleAS Single Sign-On is installed on a different machine with the IP address 123.45.67.8, and accessed at the URL http://www.login.com:7777/pls/orasso.

Notes: The IP addresses used in this example are for illustration purposes only and may not be valid IP addresses. The name and port values used in this section are for illustration purposes only and you will need to substitute these with your own. In this section we only describe how to configure virtual hosts for the OracleAS Portal middle-tier, and this does not modify the hostname for OracleAS Single Sign-On. For more information on how to customize the OracleAS Single Sign-On hostname, refer to the section titled "Deploying OracleAS Single Sign-On with a Proxy Server" in the "Advanced Configurations" chapter of the Oracle Application Server Single Sign-On Administrator's Guide, and to the chapter titled "Changing Network Configurations" in the Oracle Application Server 10g Administrator's Guide.

Figure 5-5 illustrates the previously described configuration. OracleAS Web Cache and the Oracle Application Server are shown as residing on the same middle-tier machine, although they can exist on different machines.

Figure 5-5 Virtual Host Overview

Text description of the illustration cg_advnc_topo_virtual_hosts.gif

Note: The domain names www.abc.com, www.xyz.com, and www.login.com must be valid domain names, and you must be able to ping them.

To configure the virtual host, perform the following steps in the specified order:

1. Create Virtual Hosts.

2. Configure OracleAS Web Cache.

3. Register OracleAS Portal with OracleAS Single Sign-On.

4. Verify the Configuration.

5.4.1 Create Virtual Hosts

You must create virtual hosts entries in the httpd.conf file for the virtual host name www.xyz.com, as well as for the real server name www.abc.com. To define the virtual hosts, use Oracle Enterprise Manager Application Server Control to perform the following steps:

• Create the Virtual Host for www.xyz.com.

• Create the Virtual Host for www.abc.com.

Once you have finished this step, do the following:

1. Verify the httpd.conf File.

2. Verify That the Virtual Hosts are Configured Correctly.

5.4.1.1 Create the Virtual Host for www.xyz.com

To create the virtual host for www.xyz.com:

1. Access the Oracle Enterprise Manager Application Server Control.

   Typically the Application Server Control is located at http://www.xyz.com:1812. Refer to Chapter 7, "Monitoring and Administering OracleAS Portal" for more information about using the Application Server Control.

2. Click the link for the middle-tier where OracleAS Portal is installed.

3. Click the HTTP Server link.

4. Click the Virtual Hosts link.

5. Click the Create button in the Virtual Hosts page.

6. On the Introduction page, click Next to create a new virtual host, using the Virtual Host Creation wizard.

7. On the General page, provide the information listed in Table 5-2.

   Table 5-2  Virtual Host Information

   Virtual Host Information	Value
   Document Root Directory	ORACLE_HOME/Apache/Apache/htdocs
   Directory Index	Can be left blank
   Server Administration E-Mail	Valid e-mail address
   Virtual Host Type	name-based

8. Click Next.

9. On the Addresses Page, provide the following information in the Server Name field for your virtual host:

   www.xyz.com
   
   

10. Select the option Listen on all the main server IP addresses.

11. Click Next.

12. On the Ports page, select Listen on a specific port, and select the OHS listening port, 7778 in our example, from the port dropdown list.

13. Click Next.

14. On the Error Log page, select all default values.

15. Click Next.

16. Review the summary on the Summary page.

17. Click Finish.

18. When prompted to restart the Oracle HTTP Server, click No.

19. Ensure that your server name, www.xyz.com, is listed in the table.

20. Click the Administration link.

21. Click Advanced Server Properties.

22. Select httpd.conf.

23. Add the Port and the Rewrite directives in the VirtualHost container, as follows (shown in bold text):

    NameVirtualHost *:7778
    
    <VirtualHost *:7778>
         ServerName www.xyz.com
         Port 7779
         ServerAdmin [e-mail]
         RewriteEngine On
         RewriteOptions inherit
    </VirtualHost>
    
    

24. Click Apply.

25. When asked to restart the HTTP Server, click No.

5.4.1.2 Create the Virtual Host for www.abc.com

To create the virtual host for www.abc.com:

1. Follow steps 1 through 8 in Section 5.4.1.1, "Create the Virtual Host for www.xyz.com".

2. On the Addresses Page (step 9), provide the following information in the Server Name field for your virtual host:

   www.abc.com
   
   

3. Follow steps 10 through 24 in Section 5.4.1.1, "Create the Virtual Host for www.xyz.com".

4. When prompted to restart the Oracle HTTP Server, click Yes.

5.4.1.3 Verify the httpd.conf File

After configuring virtual hosts for www.abc.com and www.xyz.com, take a look at your httpd.conf file, using Application Server Control, as follows:

1. Access the Oracle Enterprise Manager Application Server Control.

2. Click the link for the application server where OracleAS Portal is installed.

3. Click the HTTP Server link.

4. Click the Administration link.

5. Click Advanced Server Properties.

6. Select httpd.conf.

Your httpd.conf file should have the following new section:

NameVirtualHost *:7778

<VirtualHost *:7778>
   ServerName www.xyz.com
   Port 7779 
   ServerAdmin [e-mail] 
   RewriteEngine On 
   RewriteOptions inherit 
</VirtualHost> 

<VirtualHost *:7778> 
   ServerName www.abc.com 
   Port 7779 
   ServerAdmin [e-mail] 
   RewriteEngine On 
   RewriteOptions inherit 
</VirtualHost> 

Entries for the virtual hosts can vary depending on the existing content of the httpd.conf file, but you must have virtual host entries for both www.abc.com and www.xyz.com.

Note: The httpd.conf file can also be updated manually. The file can be edited manually, to contain the right VirtualHost directives, as shown previously. To synchronize the manual configuration changes done on the middle-tier, run ORACLE_HOME/dcm/bin/dcmctl as follows: dcmctl updateConfig -ct ohs Finally, restart Oracle HTTP Server, by running the following command from ORACLE_HOME/opmn/bin: opmnctl restartproc type=ohs

Note: If your site name is not registered with the DNS, you need to update the hosts file on your client machine as follows: On Windows, this file is typically located in the directory C:\WINNT\system32\drivers\etc. Here is an example of the hosts file on Windows. # Copyright (c) 1993-1995 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP # for Windows NT/2000. # 127.0.0.1 localhost 196.12.67.8 www.abc.com 196.12.67.8 www.xyz.com On UNIX, the file is typically located in the directory /etc/hosts. You do not have to restart the system after making these changes.

5.4.1.4 Verify That the Virtual Hosts are Configured Correctly

Verify that both the servername, and the virtual host are working, by accessing these URLs:

• http://www.xyz.com:7779/pls/portal

• http://www.abc.com:7779/pls/portal

5.4.2 Configure OracleAS Web Cache

The site www.abc.com is already defined in OracleAS Web Cache. Additionally, you must create a site alias in OracleAS Web Cache, to make the multiple virtual hosts transparent to the OracleAS Metadata Repository. Note that www.abc.com must be set up as a site, while www.xyz.com must be defined as a site alias. This way, invalidation messages sent to OracleAS Web Cache invalidate content that is cached for both sites.

See Also: Oracle Application Server Web Cache Administrator's Guide for information about setting up a site alias.

5.4.3 Register OracleAS Portal with OracleAS Single Sign-On

For Single Sign-On in the Oracle Application Server Single Sign-On to work properly, it must always be referenced by any partner application with the same hostname in the URL. This is because cookies are sent back only to the host that generated them. So, in the preceding example, the OracleAS Single Sign-On must always be referenced as http://www.login.com. Therefore, you must register www.abc.com, and www.xyz.com as partner applications. To do this:

1. Add a partner application entry for www.abc.com, by running OracleAS Portal Configuration Assistant (OPCA) with -mode MIDTIER and -type SSO, as follows:

   ptlasst.csh -mode MIDTIER -type SSO -host www.abc.com -port 7779 -sdad portal
   
   

2. Add a partner application entry for www.xyz.com, by running OPCA in the SSO type of the MIDTIER mode:

   ptlasst.csh -mode MIDTIER -type SSO -host www.xyz.com -port 7779 -sdad portal
   
   

3. Register the secured request with OracleAS Single Sign-On by configuring it as a partner application for www.abc.com. The script ossoreg performs this registration. ossoreg is located on the middle-tier in MID_TIER_ORACLE_HOME/sso/lib.
   1. Ensure that you have your environment configured properly to run ossoreg:

      ORACLE_HOME=MID_TIER_ORACLE_HOME
      LD_LIBRARY_PATH=ORACLE_HOME/lib
      
      

   2. Run ossoreg. The following example illustrates the usage of ossoreg.

      MID_TIER_ORACLE_HOME/jdk/bin/java -jar 
        MID_TIER_ORACLE_HOME/sso/lib/ossoreg.jar -site_name www.abc.com 
        -mod_osso_url http://www.abc.com:7779 -config_mod_osso TRUE 
        -oracle_home_path MID_TIER_ORACLE_HOME -u install_user -config_file 
        MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf 
        -admin_info cn=orcladmin
      
      

4. Register the secured request with OracleAS Single Sign-On by configuring it as a partner application for www.xyz.com, using the virtual host mode of ossoreg, as shown in the following example.

   MID_TIER_ORACLE_HOME/jdk/bin/java -jar
   MID_TIER_ORACLE_HOME/sso/lib/ossoreg.jar -site_name www.xyz.com    
   -mod_osso_url http://www.xyz.com:7779 -config_mod_osso TRUE    -oracle_home_
   path 
   MID_TIER_ORACLE_HOME -u install_user -config_file    
   MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso_xyz.conf    -admin_info 
   cn=orcladmin -virtualhost
   
   

   Note that the -config_file parameter refers to the file osso_xyz.conf.

5. You must edit the Virtual Host container for www.xyz.com as follows (changes shown in bold).

   <VirtualHost *:7778>
      ServerName www.xyz.com
      Port 7779
      ServerAdmin [e-mail]
      RewriteEngine On
      RewriteOptions inherit
      OssoConfigFile MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso_xyz.conf
      OssoIpCheck off
   </VirtualHost>
   
   

Refer to the section titled "Registering mod_osso" in Chapter 4 of the Oracle Application Server Single Sign-On Administrator's Guide for more information.

5.4.4 Verify the Configuration

To verify that the virtual hosts are set up correctly, connect to OracleAS Portal using either of the following URLs:

• http://www.abc.com:7779/pls/portal

• http://www.xyz.com:7779/pls/portal

You should get a login screen at http://www.login.com on the first login and must be able to log in successfully. A subsequent login from the other virtual host should result in a successful single sign-on without a prompt for login credentials.

5.5 Configuring OracleAS Portal to Use a Proxy Server

You can configure OracleAS Portal to use proxy servers to connect to providers and Web sites outside of your firewall.

Notes: Oracle Text uses these proxy server settings when indexing URL content. For more information, see Section 8.3.6.4, "URL Index Proxy Settings". To configure OracleAS Portal to use a proxy server, you must be a portal administrator.

To specify a proxy server:

1. In the Services portlet, click Proxy Settings.

   Note: The Services portlet is on the Administer tab of the Builder page.

2. In the HTTP Proxy Host field, enter the address for the HTTP proxy server that you want to use to access applications outside your firewall, for example, myproxy.mycompany.com. Do not prefix http:// to the proxy server name.

3. In the Port field, enter the port number for the proxy server. The port number defaults to 80 if no value is specified.

   Note: Contact your server administrator for the names of servers running proxy software and their port numbers.

4. Click Add.

   You can now use this proxy server for connections between the portal and Web providers. You can also use this proxy for other connections, for example, to connect to the URLs specified for URL items.

5. In the Select Proxy section, choose the proxy server you want to use for such connections. Choose None if you do not want to use a proxy server for non-provider connections.

6. In the No Proxy Servers for Domains beginning with field, enter the domains for which the proxy server should not be used.

   Note: The domains must begin with a period (.), for example, mycompany.com. Separate multiple domains with a comma (,).

7. Click OK.

You'll find additional information about how to set up proxy servers in the paper "A Primer on Proxy Servers," on Portal Center, http://portalcenter.oracle.com. Click the Search icon in the upper right corner of any Portal Center page.

5.6 Configuring Reverse Proxy Servers

A reverse proxy server is a host process that is used as part of a firewall architecture to isolate the internal hosts from the externally accessible host(s). It does this by providing a proxy through which external requests must pass to access internal services. Typically, a proxy server takes the form of a dual-homed host. This means that it is a host with two network interface cards. One interface connects to the external network, and the other interface connects to the internal network, or demilitarized zone (DMZ) of the firewall.

Figure 5-6 shows an architecture in which the browser accesses the server through the hostname that is published by the proxy server. The proxy server then forwards the request to the actual host within the firewall.

For this example, we will assume that you have properly configured the OracleAS Single Sign-On server to work with the reverse proxy server.

See Also: The chapter "Deploying Oracle Application Server Single Sign-On with a Proxy Server" in the Oracle Application Server Single Sign-On Administrator's Guide.

Figure 5-6 Reverse Proxy Server Configuration

Text description of the illustration cg_topo_example_proxy.gif

For this example, let's assume the following:

Property	Value
External server name	www.abc.com
External server port	80
OracleAS Web Cache server name (internal server)	internal.company.com
OracleAS Web Cache listening port (internal server)	7777
OracleAS Web Cache administration port (internal server)	4000
OracleAS Web Cache invalidation port (internal server)	4001

Notes: The name and port values used in this section are for illustration purposes only and you will need to substitute these with your own.

Complete these steps to configure OracleAS Portal for the architecture shown in Figure 5-6 in the order specified:

• Ensure That Self-Referential URLs Work

• Configure Loopback to the Internal Server

• Specify the OracleAS Portal Published Address and Protocol

• Configure Seeded Providers and Locally Hosted Web Providers

• Register the Domain Name

• Verify Your Configuration

5.6.1 Ensure That Self-Referential URLs Work

On the middle-tier, set the ServerName directive to point to the server name of the reverse proxy, so that self-referential URLs rendered on OracleAS Portal pages are valid for the browser. To do this, perform the following steps:

1. Define a virtual host, using the Create Virtual Host wizard, as explained in Section 5.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:
   • On the Addresses page (step 9), specify www.abc.com in the Server Name field.

   • In step 23, specify 80 for the Port directive in the VirtualHost container.

2. Define a virtual host, using the Create Virtual Host wizard, as explained in Section 5.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:
   • On the Addresses page (step 9), specify internal.company.com in the Server Name field.

   • In step 23, specify 7777 for the Port directive in the VirtualHost container.

   • When prompted to restart the Oracle HTTP Server (step 26), click Yes.

5.6.2 Configure Loopback to the Internal Server

To improve performance, and to ensure that seeded providers work correctly, the local HOSTS file must be used to resolve domain names that are not normally visible to the internal network. For more information about this loopback connection, refer to Section 1.2.2.2, "How Does Communication Flow in OracleAS Portal?".

For example, the Oracle Application Server host for internal.company.com makes requests to itself, but the URLs that it is requesting are referring to www.abc.com. You must create host entries in the local HOSTS file on that machine, allowing it to resolve this name within the firewall. The hosts entry for this example should include the following lines:

# This is a sample HOSTS file used by Microsoft TCP/IP
# for Windows NT/2000.
127.0.0.1    localhost
123.45.67.8  www.abc.com

If you do not provide these entries in the local HOSTS file, then you need to set the Oracle Application Server host to recognize a proxy server that would take the request out to the Internet and back in through the reverse proxy (www.abc.com), or configure the reverse proxy server's internal interface to respond to www.abc.com.

Note: On some platforms, such as HP, there is a file that indicates the search order that should be applied to the sources for IP name mapping. For the preceding example to work, if such a file exists on your platform, make sure that it specifies the local hosts file to be checked for IP mapping, before any DNS servers.

5.6.3 Specify the OracleAS Portal Published Address and Protocol

Typically, the hostname and port number, by which OracleAS Portal is addressed, uses the OracleAS Web Cache hostname and port number. This is because, in a simple configuration, browser requests go directly to OracleAS Web Cache. However, in a configuration that has a reverse proxy server front-ending OracleAS Web Cache, the hostname and port number defined should reflect that of the reverse proxy server.

In this configuration, you want OracleAS Web Cache invalidation messages to be sent directly to the OracleAS Web Cache host, as opposed to the reverse proxy server. In the scenario where your published hostname is different from the hostname used for OracleAS Web Cache invalidation, you cannot use the Portal Web Cache Settings page in the Oracle Enterprise Manager Application Server Control, or the Portal Dependency Settings file, to establish these settings.

To configure this appropriately, take the following steps:

1. Run OPCA (ptlasst) with -mode MIDTIER and -type OHS, as follows:

   ptlasst.csh -i typical -mode MIDTIER -type OHS -sdad portal -host 
   www.abc.com -chost internal.company.com -port 80 -cport_i 4001 -cport_a 4000
   
   

2. Register the secured request with OracleAS Single Sign-On by configuring it as a partner application. The script ossoreg performs this registration. ossoreg is located on the middle-tier in MID_TIER_ORACLE_HOME/sso/lib.
   1. Ensure that you have your environment configured properly to run ossoreg:

      ORACLE_HOME=MID_TIER_ORACLE_HOME
      LD_LIBRARY_PATH=ORACLE_HOME/lib
      
      

   2. The following example illustrates the usage of ossoreg:

      MID_TIER_ORACLE_HOME/jdk/bin/java -jar 
        MID_TIER_ORACLE_HOME/sso/lib/ossoreg.jar -site_name www.abc.com 
        -mod_osso_url http://www.abc.com -config_mod_osso TRUE 
        -oracle_home_path MID_TIER_ORACLE_HOME -u install_user -config_file 
        MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf 
        -admin_info cn=orcladmin
      
      

   Refer to the section titled "Registering mod_osso" in Chapter 4 of the Oracle Application Server Single Sign-On Administrator's Guide for more information.

3. To prevent access to Oracle Enterprise Manager from the outside, the Oracle Enterprise Manager link provided by OracleAS Portal needs to be changed back to point to the internal server. To do this, run ptlconfig (typically located in the directory MID_TIER_ORACLE_HOME/portal/conf) as shown in the following example:

   ptlconfig -dad portal -em
   
   

   See Also: Appendix B, "Using the OracleAS Portal Configuration Assistant Command Line Utility" for more information on how to use OPCA. Section 7.2.3, "Portal Web Cache Settings Page" for more information about the Portal Web Cache Settings page. Appendix A, "Using the Portal Dependency Settings File" for more information about the Portal Dependency Settings File and Tool.

5.6.4 Configure Seeded Providers and Locally Hosted Web Providers

To configure the seeded providers (WebClipping and OmniPortlet), and locally hosted Web providers, you must take the following steps:

1. Login to OracleAS Portal as the administrator (for example, PORTAL).

2. Click the Administer tab.

3. Click the Portlets sub-tab.

4. In the Remote Providers portlet, type WEBCLIPPING in the Name field.

5. Click Edit.

6. Click the Connection tab.

7. In the URL field, change the URL from:

   http://www.abc.com:80/portalTools/webClipping/providers/webClipping 
   
   

   to:

   http://www.abc.com:7777/portalTools/webClipping/providers/webClipping 
   
   

8. Click OK to commit the change.

9. Repeat steps 4 through 8, with the following exceptions:
   • Type OMNIPORTLET instead of WEBCLIPPING in step 4.

   • In step 7, change the URL from:

     http://www.abc.com:80/portalTools/omniPortlet/providers/omniPortlet
     
     

     to:

     http://www.abc.com:7777/portalTools/omniPortlet/providers/omniPortlet 
     
     

When you register locally hosted Web Providers (such as the JPDK Sample provider), you need to register them using HTTP as the protocol, www.abc.com as the hostname, and 7777 as the port number. This restriction only applies to locally hosted Web Providers (that is, Web Providers running on the same middle-tier as OracleAS Portal).

For example, to register the JPDK Sample provider, the URL is:

http://www.abc.com:7777/jpdk/providers/sample

Note: If your infrastructure is located on a separate machine than your OracleAS Portal middle- tier, you need to add the following to your /etc/host file: 123.45.67.8 www.abc.com where w1.w1.w1.w1 is the IP Address of your OracleAS Web Cache machine (internal.company.com).

5.6.5 Register the Domain Name

Register the www.abc.com domain name on a domain name server on the Internet, with IP address 196.12.67.8.

Note: In order for OracleAS Portal to work with a reverse proxy server, the reverse proxy server must preserve the incoming Host HTTP request header from the client. If this is not the default setting in your proxy server, refer to the configuration manual of the reverse proxy to set this. For example, if you are using mod_proxy in Apache 2.0, you will need to set the ProxyPreserveHost directive to On.

5.6.6 Verify Your Configuration

You can now access OracleAS Portal at http://www.abc.com/pls/portal.

Note: The Web Cache Administration link in the Services portlet will not work in the new configuration. Instead, you can access OracleAS Web Cache Manager, using the Application Server Control on the middle-tier where OracleAS Web Cache is installed.

5.7 Configuring OracleAS Web Cache Caching in OracleAS Portal

Oracle Application Server Web Cache offers caching, page assembly, and compression features. OracleAS Web Cache accelerates the delivery of both static and dynamic Web content, and provides load balancing and failover features for Oracle Application Server.

This section discusses how to configure OracleAS Portal to work with OracleAS Web Cache.

This section contains the following topics:

• Accessing OracleAS Web Cache Manager

• Configuring OracleAS Web Cache Settings Using Application Server Control

• Configuring OracleAS Web Cache Settings Using OracleAS Portal

• Clearing the Cache Invalidation Queue Through SQL*PLUS

• Evaluating the OracleAS Web Cache Logs

• OracleAS Web Cache Configuration Scripts

• Troubleshooting OracleAS Web Cache Configuration

5.7.1 Accessing OracleAS Web Cache Manager

OracleAS Web Cache Manager is a graphical user interface tool that combines configuration and monitoring options to provide an integrated environment for configuring and managing OracleAS Web Cache and the Web sites for which it caches content.

You can access OracleAS Web Cache Manager in different ways:

1. From the Oracle Enterprise Manager Application Server Control on the middle-tier where OracleAS Web Cache is installed:
   1. On the Application Server home page, select Web Cache from the list of system components.

   2. Click Web Cache Administration on the Web Cache home page.

2. From OracleAS Portal:
   1. Navigate to the Services portlet on the Portal sub-tab of the Administer tab on the Portal Builder page.

   2. In the Services portlet, click the Web Cache Administration link.

After entering the OracleAS Web Cache administrator username and password (typically the ias_admin password), you will be able to use OracleAS Web Cache Manager, as shown in the Figure 5-7.

Figure 5-7 OracleAS Web Cache Manager

Text description of the illustration cg_sshot_wc_home.gif

For more information on the usage of the OracleAS Web Cache Administration Manager, refer to the Oracle Application Server Web Cache Administrator's Guide.

5.7.2 Configuring OracleAS Web Cache Settings Using Application Server Control

You must use the Oracle Enterprise Manager Application Server Control to configure OracleAS Web Cache settings that OracleAS Portal uses, such as the hostname, and the invalidation port number. These settings can be configured on the Portal Web Cache Settings page.

Using Application Server Control, you can specify the OracleAS Web Cache settings that OracleAS Portal should use. Setting the OracleAS Web Cache properties on this page will automatically result in the Portal Dependency Settings file located on this middle-tier being updated, and the ptlconfig script being executed.

For a detailed description of how to access, and use the Application Server Control, and specifically the Portal Web Cache Settings page, refer to Section 7.2.3, "Portal Web Cache Settings Page".

5.7.3 Configuring OracleAS Web Cache Settings Using OracleAS Portal

From the OracleAS Portal user interface, you can perform various other OracleAS Web Cache related configuration tasks. The entire OracleAS Web Cache can be cleared, or it can be cleared for each user.

Caution: Clearing the cache results in cache misses on subsequent requests and may degrade the portal's performance until the cache is repopulated.

You may want to clear the cache if a user's group membership has changed, in order to remove the cache entries for that user, so that he or she has new privileges. Similarly, if you change a user or group's privileges on an object, you can clear the cache entries for that object.

To clear the entire cache, or to clear the cache for a particular user, you must be the portal administrator. To clear the cache for a particular portal object, you must have at least Manage privileges on the object.

It is also possible to configure OracleAS Portal's OracleAS Web Cache settings, using the Cache tab on the Portal Global Settings page. However, this is not the recommended approach. You must use Oracle Enterprise Manager Application Server Control to change these settings, as this will update the iasconfig.xml file.

If you have used the Portal Global Settings page to change any of the OracleAS Web Cache settings, you must take the following manual steps to update the iasconfig.xml file:

1. Edit ORACLE_HOME/portal/conf/iasconfig.xml.

2. Locate the WebCacheComponent element for the portal instance you want to update and modify the properties of the WebCacheComponent as required.

3. Run the following script to update the Oracle Application Server Metadata Repository with the new settings:

   ORACLE_HOME/portal/conf/ptlconfig -dad <dad> -wc
   
   

The following sections describe the actions that can be performed using OracleAS Portal in more detail:

• Clearing the Entire Web Cache

• Clearing the Cache for a Particular User

• Setting the Expiry Time for Invalidation-based Caching

• Clearing the Cache for a Particular Portal Object

5.7.3.1 Clearing the Entire Web Cache

You can clear the entire Web Cache by performing the following steps:

1. In the Services portlet, click Global Settings.

   Note: By default, the Services portlet is on the Portal sub-tab of the Administer tab on the Portal Builder page.

2. Click the Cache tab.

3. Select Clear The Entire Web Cache.

4. Click Apply or OK to clear the cache.

   Note: This clears all the page URLs and style sheets but not the Portal images.

5.7.3.2 Clearing the Cache for a Particular User

You can clear the cache for a particular user by performing the following steps:

1. In the Services portlet, click Global Settings.

   Note: By default, the Services portlet is on the Portal sub-tab of the Administer tab on the Portal Builder page.

2. Click the Cache tab.

3. In the Clear Cache For User field, enter the name of the user for whom you want to clear the cache.

   Note: If you are not sure of the user name, click the Browse Users icon and select from the list provided.

4. Click Apply or OK to clear the cache for the specified user.

   Note: Alternatively, you can clear the cache for a particular user by editing the user's portal profile.

5.7.3.3 Setting the Expiry Time for Invalidation-based Caching

With invalidation-based caching, a cache entry is purged when the portal or a provider sends a message informing OracleAS Web Cache that the object has changed (for example, when an item is edited). However you can also set an expiry time for cache entries. A cache entry that reaches this time limit is purged, even if OracleAS Web Cache has not received an invalidation message for it.

Note: To set the expiry time for invalidation-based cache entries, you must be the portal administrator.

To set the expiry time for invalidation-based cache entries:

1. In the Services portlet, click Global Settings.

   Note: By default, the Services portlet is on the Portal sub-tab of the Administer tab on the Portal Builder page.

2. Click the Cache tab.

3. In the Maximum Expiry Time field, enter the maximum amount of time (in minutes) a cache entry should remain in the cache before being purged.

4. Click OK.

5.7.3.4 Clearing the Cache for a Particular Portal Object

You can clear cache entries for page groups, pages, page templates, portlets in the Portlet Repository, Portal database providers, and Portal database provider components, by performing the following steps:

1. In the Navigator, drill down to the object with which you want to work.
   • For page groups, pages, and page templates, click Properties, then click the Access tab.

   • For Portal database providers, and Portal database provider components, click Grant Access.

   • For portlets, click Edit Root Page next to the Portlet Repository page group, drill down to the page that contains the portlet, edit the portlet, and click the Access tab.

2. Click Clear Cache.

3. Click OK.

5.7.4 Clearing the Cache Invalidation Queue Through SQL*PLUS

Sometimes, the cache invalidation queue can grow excessively large as a result of user actions. For example, repeated granting of security privileges on a page to a group with a large number of members will place one soft invalidation in the queue for every user for every grant.

Some soft invalidations may not be necessary, but OracleAS Portal may not be able to determine this. For example, if a group's privileges on a page are upgraded from View to Fully Customize, and no member of the group has viewed the page yet, then no invalidation is necessary. However, Portal does not have a record of who has viewed the page. Therefore, it proceeds with the soft invalidation configured to use the security change.

The Portal administrator can check the number of soft invalidations in the queue by executing the following query in SQL*PLUS as the Portal schema owner:

select count(1) from wwutl_cache_inval_msg$ where process_type=2;

The Portal administrator can check the total number of invalidations, hard or soft, in the queue by executing the following query in SQL*PLUS as the Portal schema owner:

select count(1) from wwutl_cache_inval_msg$;

The number of rows in the table wwutl_cache_inval_msg$ that can be considered excessive depends, to some extent, on the speed of the infrastructure running the database. Typically, 50000 messages will slow down the soft invalidation job, and sending 50000 invalidation messages to OracleAS Web Cache will introduce a network load, as OracleAS Portal communicates with the OracleAS Web Cache invalidation port.

If the soft invalidations are found to be unnecessary, the Portal administrator can perform the following query in SQL*PLUS as the Portal schema owner:

delete from wwutl_cache_inval_msg$ where process_type=2;

This removes soft invalidations from the queue.

If the soft invalidations are necessary but there is an excessively large number, the Portal administrator can clear the cache invalidation queue using the following command:

truncate table  wwutl_cache_inval_msg$;

The Portal administrator should then clear the entire cache through the Portal UI as described in Section 5.7.3.1, "Clearing the Entire Web Cache".

5.7.5 Evaluating the OracleAS Web Cache Logs

Log files for OracleAS Web Cache are typically stored in ORACLE_HOME/webcache/logs on UNIX and ORACLE_HOME\webcache\logs on Windows.

There are two log files:

• The access_log file.

• The event_log file.

  See Also: Oracle Application Server Web Cache Administrator's Guide

5.7.6 OracleAS Web Cache Configuration Scripts

You can configure OracleAS Portal to work with OracleAS Web Cache in a variety of ways, and some scripts are supplied to facilitate this. These scripts are covered in more detail in Section C.1, "OracleAS Web Cache Configuration Scripts".

The scripts covered in Appendix C, "Using OracleAS Portal Installation and Configuration Scripts" are:

• cachset.sql, which enables you to turn the use of OracleAS Web Cache on or off. Information on how to disable OracleAS Web Cache completely is covered as well.

• cachjsub.sql, which enables you to manage the invalidation message processing job.

5.7.7 Troubleshooting OracleAS Web Cache Configuration

See: Oracle Application Server Portal Error Messages Guide

5.8 Changing the Infrastructure Services Used By a Middle-Tier

Oracle Application Server 10g enables you to change the Infrastructure services (either Oracle Identity Management or OracleAS Metadata Repository) that a middle-tier uses. You can use this feature, for example, to move middle-tiers (and their applications) from stage to production. If you are changing the OracleAS Metadata Repository that your OracleAS Portal uses, then you will also need to move application-specific data stored in the stage OracleAS Metadata Repository to an OracleAS Metadata Repository in the production environment. Changing the Infrastructure services is convenient, if you need additional computers for the production environment. In a single step, you add a computer that already has a middle-tier and deployed applications. For instructions on how to change the Infrastructure Services used by a middle-tier instance, refer to the Oracle Application Server 10g Administrator's Guide.

Note: By default, an OracleAS Portal middle-tier is made up of one portal instance. Both the DAD name and the OracleAS Metadata Repository schema name for this instance are portal. You can only change the Infrastructure services of this default OracleAS Portal instance in the previously described way.

5.9 Configuring OracleAS Wireless

If Oracle Application Server Wireless is configured with OracleAS Portal during the middle-tier installation, the middle-tier installation registers the Portal on the OracleAS Wireless service. In case of multiple middle-tier installs, the last configured OracleAS Wireless service URL is stored in the OracleAS Portal instance. You can change this to your choice of OracleAS Wireless service by running the portalRegistrar.sh script in the Oracle Application Server middle-tier selected for the OracleAS Wireless service:

On UNIX:

ORACLE_HOME/wireless/bin/internal/portalRegistrar.sh

On Windows:

ORACLE_HOME/wireless/bin/internal/portalRegistrar.bat

Specify the following arguments when running the portalRegistrar script:

• admin_user (typically orcladmin).

• url (for example, http://lbr.abc.com).

5.10 Changing the OracleAS Portal Schema Password

Refer to the chapter "Managing Administrative Passwords" in the Oracle Application Server 10g Administrator's Guide for information about changing the OracleAS Portal schema password.

Note: By default, an OracleAS Portal middle-tier is made up of one portal instance. Both the DAD name and the OracleAS Metadata Repository schema name for this instance are portal. You can only change the schema password of this default OracleAS Portal instance in the previously described way.