Skip Headers
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.4)
B19305-03
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

5 Performing Advanced Configuration

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

This chapter contains the following sections:

5.1 Changing the OracleAS Portal Port

For information about changing ports in Oracle Application Server, refer to the Oracle Application Server Administrator's Guide.

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 and the Secure Sockets Layer (SSL), rather than HTTP.

Chapter 6, "Securing OracleAS Portal" describes the SSL configuration options that are available with OracleAS Portal. Refer to the following sections:

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.


Note:

As with all out-of-the-box portal installations, this solution is best for internal deployments because it is not configured to use SSL. For the Oracle recommended way of configuring secure enterprise deployments, refer to the Oracle Application Server Enterprise Deployment Guide.

The purpose of an 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 computer as the OracleAS Portal and OracleAS Wireless middle tier, although they can theoretically be on different computers.

Figure 5-1 Multiple Middle-Tier Configuration with a Load Balancing Router

Description of Figure 5-1  follows
Description of "Figure 5-1 Multiple Middle-Tier Configuration with a Load Balancing Router"

Table 5-1 Additional Information

Computer Details

Load Balancing Router (LBR)

Computer 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)

Computer 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)

Computer 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.

  • Refer to the steps outlined in Section 7.5, "Viewing Oracle Application Server Port Information" to view a list of all the ports currently in use by the components of a particular Oracle Application Server instance.


Additional LBR configuration is required to successfully handle:

Loopback Communication

OracleAS Portal's Parallel Page Engine (PPE) retrieves page metadata information. This communication is referred to as Loopback Connections. In a default configuration, the loopback connections are local, because OracleAS Web Cache and OracleAS Portal reside on the same computer.

If an LBR is front-ending Oracle Application Server, it will need additional configuration if OracleAS Web Cache is located on the same subnet. To understand this better, let's take a look at the different parts of the loopback connections without this additional configuration.

  1. The PPE sends a loopback request for page metadata when OracleAS Portal generates a page. This loopback request goes directly to the LBR.

  2. The request is forwarded by the LBR to OracleAS Web Cache.

  3. OracleAS Web Cache forwards the request to Portal Services, running under Oracle HTTP Server.

  4. Portal Services processes the request and sends back the response to the loopback request to OracleAS Web Cache.

  5. OracleAS Web Cache forwards the response to the LBR.

  6. The LBR receives the response that is supposed to be routed back to the PPE.

  7. The LBR detects that the source address, to which the response needs to be sent, is on the same subnet and it sends it back to OracleAS Web Cache, using the LBR's known socket connection, instead of using the PPE's socket connection.

  8. OracleAS Web Cache is not listening for the request at all, and the incoming reply is dropped as there is no valid session.

  9. OracleAS Portal pages time out with the error 'Timeout occurred while retrieving page metadata.'

As you can see, under normal circumstances, the behavior of the LBR is correct, as the LBR is programmed to forward all requests to OracleAS Web Cache. However, when loopback requests come from an internal network, the outcome is not desirable.

To avoid this, you must set up a Network Address Translation (NAT) bounce back rule on the LBR. This configures the LBR as a proxy for requests coming to it from inside the firewall. This setup ensures that the internal requests are forwarded correctly, and when the response reaches the LBR, it is translated correctly and sent to the correct source address on the network (the PPE in this case).

The required steps for setting this up are discussed later. NAT bounce back is set up differently on individual LBRs. Consult your LBR's configuration guide for more information.

OracleAS Web Cache Invalidation

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. OracleAS 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. Depending on how your routing is set up you may also need to set up NAT and open the appropriate outbound ports on your data tier. The required steps for setting this up are discussed later.


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. To configure the infrastructure properly, refer to the advanced configuration information 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:

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 computer (M1). It is assumed that you use the services of an existing Oracle Application Server Infrastructure.


    See Also:

    Oracle Application Server 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/portal/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

    Description of Figure 5-2  follows
    Description of "Figure 5-2 Installation of OracleAS Portal Middle Tier"

  3. Access your iasconfig.xml file, located in MID_TIER_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"> 
      <WebCacheComponent ListenPort="7777" InvalidationPort="4001" InvalidationUsername="invalidator" InvalidationPassword="@Bd4D+TnIEqRc3/kleybcc70A==" SSLEnabled="false"/>
      <EMComponent ConsoleHTTPPort="1814" SSLEnabled="false"/>
   </IASInstance>
   <IASInstance Name="iAS.infra.abc.com" Host="infra.abc.com">
      <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.infra.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 (LBR), 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 computer 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 host name (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 host name 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 host name 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 25), 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 on M1, as described in the Oracle Application Server Web Cache Administrator's Guide.

    2. From Properties, click Sites.

    3. Click Create under Named Sites Definitions.

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

    5. Click OK. You will now see lbr.abc.com in the Named Sites 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 Edit/Add 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 computer m1.abc.com so that it can resolve the LBR host name 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.


    WARNING:

    Ensure that the /etc/hosts file does not have an entry that points the local host name 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 computer 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.



      WARNING:

      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 MID_TIER_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" InvalidationPort="4001" InvalidationUsername="invalidator" InvalidationPassword="welcome1" SSLEnabled="false"/> 
       </IASFarm>
    
       <IASInstance Name="iAS.infra.abc.com" Host="infra.abc.com">
          <OIDComponent AdminPassword="@BVs2KPJEWC5a0l4n8lbTxUY=" PortSSLEnabled="true" LDAPPort="3060" AdminDN="cn=orcladmin"/>
       </IASInstance>
    
       <IASInstance Name="iAS-1.m1.abc.com" Host="m1.abc.com"> 
          <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.infra.abc.com"/> 
          <EMDependency ContainerType="IASInstance" Name="iAS-1.m1.abc.com"/> 
       </PortalInstance> 
    
    </IASConfig>
    
    

    Note:

    If OracleAS Web Cache on iAS-1.m1.abc.com (shown in Example 5-1) is not referenced by any other OracleAS Portal instance, you can remove the entry from iasconfig.xml, as seen in Example 5-2.

  9. Encrypt any plain text passwords in the iasconfig.xml configuration file. To do this, navigate to MID_TIER_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 host name and port, and that the OracleAS Web Cache invalidation URLs (OracleAS Web Cache host name and invalidation ports) are that of the LBR. To do this, navigate to MID_TIER_ORACLE_HOME/portal/conf, and run the following command:

    ptlconfig -dad <portal_dadname> -wc -site
    
    

    For example,

    ptlconfig -dad portal -wc -site
    
    
  11. If the URL is using the HTTPS protocol, then the URL must be updated to use the HTTP protocol instead. Refer to the section "Setting the OracleAS Single Sign-On Query Path URL (HTTP)" for information about updating the OracleAS Single Sign-On Query Path URL.


    Note:

    Running ptlconfig in the -sso and -site modes updates the OracleAS Single Sign-On query path URL, which is used by OracleAS Portal to access the list of external applications, with the URL prefix of OracleAS Single Sign-On. If this URL is using the HTTPS protocol, then the URL must be updated to use the HTTP protocol instead.

  12. Run ssoreg to register the virtual host for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the osso.conf file. ssoreg is located on the middle tier in MID_TIER_ORACLE_HOME/sso/bin.

    The following example shows the usage of ssoreg on UNIX:

    MID_TIER_ORACLE_HOME/sso/bin/ssoreg.sh
      -site_name lbr.abc.com 
      -mod_osso_url http://lbr.abc.com 
      -config_mod_osso TRUE 
      -oracle_home_path MID_TIER_ORACLE_HOME 
      -config_file MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf 
      -admin_info cn=orcladmin 
      -virtualhost
    
    

    On Windows, you must run ssoreg.bat instead. Refer to the information about registering mod_osso in the Oracle Application Server Single Sign-On Administrator's Guide.

  13. To enable monitoring of the LBR's front-end host and port settings for OracleAS Portal, you must edit targets.xml (located in MID_TIER_ORACLE_HOME/sysman/emd/) on M1, as follows:

    1. Open targets.xml on M1, using a text editor.

    2. Search for OracleAS Portal targets, that is, TYPE="oracle_portal".

    3. Edit the PortalListeningHostPort property, to point to the LBR. For example:

      <Property NAME="PortalListeningHostPort" VALUE=http://lbr.abc.com:80/>
      
      
    4. Save the changes to targets.xml.

    5. Reload the targets in the Application Server Control Console:

      On Solaris and Linux, enter:

      MID_TIER_ORACLE_HOME/bin/emctl reload
      
      

      On Windows, enter:

      MID_TIER_ORACLE_HOME\bin\emctl reload
      
      
  14. Optionally, re-register the Wireless gateway URL with the load-balancer's address. See Section 5.11, "Configuring OracleAS Wireless" 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

Description of Figure 5-3  follows
Description of "Figure 5-3 OracleAS Portal Being Accessed Through the LBR "

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 Oracle Application Server 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/index.html
    
    
  2. Test the connection to Oracle Application Server Metadata Repository through the LBR, by accessing the following URL:

    http://lbr.abc.com/portal/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, then scan the application.log file for the OC4J_Portal instance 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 home page at http://lbr.abc.com/portal/pls/portal. If this does not work, then 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 application.log file for the OC4J_Portal instance 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 the Oracle Application Server Web Cache Administrator's Guide.


      Note:

      The Portal Service Monitoring link in the Services portlet will not work in the multiple middle-tier configuration.

      Under Monitoring, click Popular Requests. Select Cached from the Filter Objects drop-down list, and click Update. If you accessed OracleAS Portal, you will see portal content (For example, URLs that contain /portal/pls/portal). If you do not see any portal content, open another browser and log in 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 basic 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 computer 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 computers 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/as101202
    
    

    Note:

    By default, iasconfig.xml resides in MID_TIER_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.2.4, "Updating the Portal Dependency Settings File" for more information.

  2. Run Oracle Universal Installer to install a Portal and Wireless Oracle Application Server 10g middle tier on the second computer (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 computer and want to transfer the changes to another computer. If the physical path is different on other computers, 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

    Description of Figure 5-4  follows
    Description of "Figure 5-4 Select Configuration Options Screen"


    WARNING:

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


  4. Enable OracleAS Portal to be configured using Application Server Control Console. Refer to Section 7.2.2, "Using Application Server Control Console to Configure OracleAS Portal", for more information.


    Note:

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

  5. 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 about how to check this.

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

Perform the following 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 Load Balancing Router (LBR) host name (lbr.abc.com) and LBR port number (80). To do this, perform the following steps, using the Application Server Control Console 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 host name 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 host name 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 25), 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 MID_TIER_ORACLE_HOME/Apache/modplsql/conf/dads.conf from M1 to M2.

    2. Copy MID_TIER_ORACLE_HOME/Apache/oradav/conf/oradav.conf from M1 to M2.

    3. Copy MID_TIER_ORACLE_HOME/Apache/modplsql/conf/cache.conf from M1 to M2.

    4. Copy MID_TIER_ORACLE_HOME/j2ee/OC4J_Portal/applications/portal/portal/WEB-INF/web.xml 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 copy the iasconfig.xml file from M1 to M2.

  3. Re-register mod_osso on M2. To do this, perform the following steps:

    1. Copy the MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf from M1 to M2. osso.conf is a binary file.

    2. Synchronize the Distributed Configuration Management (DCM) repository by issuing the following command:

      MID_TIER_ORACLE_HOME/Apache/Apache/bin/ssotransfer MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf
      
      

      Note:

      This does not create any new partner applications; it enables the partner application lbr.abc.com for M1 and M2.

  4. Synchronize the manual configuration changes done on M2 by running the following command from the directory MID-TIER_ORACLE_HOME/dcm/bin/:

    dcmctl updateConfig
    
    
  5. After copying the dads.conf file, you must add the necessary mod_rewrite and mod_oc4j directives to the httpd.conf and mod_oc4j.conf files respectively. To do this, perform the steps mentioned in Section E.2, "DAD Configuration File (dads.conf)" using the Application Server Control Console.

  6. Run the following commands:

    MID_TIER_ORACLE_HOME/dcm/bin/dcmctl updateConfig -ct ohs
    MID_TIER_ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server
    MID_TIER_ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_Portal
    
    
  7. Configure the computer m2.abc.com to resolve the LBR host name 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
    
    

    WARNING:

    Ensure that the /etc/hosts file does not have an entry that points the local host name to 127.0.0.1. For example:

    127.0.0.1 m2.abc.com
    

  8. Access the OracleAS Web Cache Manager on M1, as described in the Oracle Application Server Web Cache Administrator's Guide.

  9. 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 - OracleAS Web Cache
      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.

      For information about configuring a cache cluster, refer to the Oracle Application Server Web Cache Administrator's Guide.

  10. 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 Oracle HTTP Server 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 on mapping sites to origin servers in the Oracle Application Server Web Cache Administrator's Guide for more information.

  11. 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 on mapping sites to origin servers in the Oracle Application Server Web Cache Administrator's Guide for more information.

  12. 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.

  13. Configure the LBR (lbr.abc.com) to forward requests on the invalidation port to OracleAS Web Cache running on the second middle tier m2.abc.com on port 4001, similar to the configuration previously done for the first middle tier m1.abc.com.


    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.

  14. Configure the LBR (lbr.abc.com) to forward requests on port 80 to OracleAS Web Cache running on computer m2.abc.com on port 7777, similar to the configuration previously done for the first middle tier m1.abc.com.


    Note:

    Consult the LBR documentation to complete this step.

  15. Configure the LBR to perform Network Address Translation (NAT) bounce back for loopback requests coming from Oracle HTTP Server 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.

  16. To enable monitoring of the LBR's front-end host and port settings for OracleAS Portal, you must edit targets.xml (located in MID_TIER_ORACLE_HOME/sysman/emd/) on M2, as follows:

    1. Open targets.xml on M2, using a text editor.

    2. Search for OracleAS Portal targets, that is, TYPE="oracle_portal".

    3. Edit the PortalListeningHostPort property, to point to the LBR. For example:

      <Property NAME="PortalListeningHostPort" VALUE=http://lbr.abc.com:80/>
      
      
    4. Save the changes to targets.xml.

    5. Reload the targets in the Application Server Control Console:

      On Solaris and Linux, enter:

      MID_TIER_ORACLE_HOME/bin/emctl reload
      
      

      On Windows, enter:

      MID_TIER_ORACLE_HOME\bin\emctl reload
      
      

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

Some additional configuration is required to ensure that Portal Tools providers (OmniPortlet and Web Clipping) and locally and custom built Web providers work properly in the middle-tier environment. If OmniPortlet or any other Web providers already have personalizations in the file system, you can use the PDK-Java Preference Store Migration and Upgrade Utility to migrate the personalizations to the database and upgrade personalizations from earlier releases. Refer to Section C.11, "Using the PDK-Java Preference Store Migration and Upgrade Utility" for more information about this utility.

For the WSRP producer, the OracleAS Metadata Repository is used as the default portlet preference store. If you want to use a different preference store, then refer to the Oracle Application Server Portal Developer's Guide for more information.

Configuring Portal Tools Providers in the Multiple Middle-Tier Environment

Perform the following steps for Portal Tools (OmniPortlet and 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. Create a user on the database containing the PORTAL schema, and grant create resource and connect privileges, using the create user and grant connect commands in SQL*Plus. Substitute the actual password in the following command. Do not use the default password of welcome, as this poses a security risk. For example:

      create user prefstore identified by password;
      grant connect, resource to prefstore;
      
      
    3. Connect as user prefstore and 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="prefstore"
         password="password"
         url="jdbc:oracle:thin:@infra.host.com:1521:orcl"
         inactivity-timeout="30"
      /> 
      
      

      Note:

      Embedding passwords in deployment and configuration files poses a security risk. If you do not want to use a clear text password in the data-sources.xml file, then you can create an indirect password by performing the following steps:
      1. Edit the ORACLE_HOME/j2ee/OC4J_Portal/config/jazn-data.xml file to add the prefstore user in the jazn.com realm as shown in the following example (You can create a new realm for this instead of using the jazn.com realm):

        <realm>
            <name>jazn.com</name>
            <users>
              <user>
                 <name>prefstore</name>
                 <display-name>OmniPortletprefstore</display-name>
                 <description>OmniPortlet prefstore</description>
                 <credentials>!welcome</credentials>
              </user>
              <user>
                 ... 
        
        

        Note that the password is included in the <credentials> element and is prefixed with an exclamation (!) mark. The next time OC4J reads the jazn-data.xml, it will rewrite the file with this password obfuscated.

      2. Edit the ORACLE_HOME/j2ee/OC4J_Portal/config/data-sources.xml file again to use the indirect password that you created in the previous step by replacing the password attribute as follows:

        password="->jazn.com/prefstore"
        
        

        For more information about creating an indirect password, refer to the Oracle Containers for J2EE Security Guide.


    5. Edit the file provider.xml located in the directory ORACLE_HOME/j2ee/OC4J_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> 
      
      
    6. Restart OC4J_Portal.

    More information about configuring the database preference store can be found at the following locations:

    Refer to Section C.11, "Using the PDK-Java Preference Store Migration and Upgrade Utility" for more information about the PDK Preference Store Migration Utility.

  2. If you have already created an OmniPortlet instance with personalizations in the file system, then you must migrate these personalizations to the database using the Preference Store Migration Utility. To run the migration utility, perform the following steps:

    1. Navigate to the middle-tier Oracle home directory using the following command:

      cd ORACLE_HOME
      
      
    2. Run the following command to migrate OmniPortlet data from a file-based preference store (FilePreferenceStore) to the database preference store (DBPreferenceStore):

      java -classpath portal/jlib/pdkjava.jar oracle.portal.provider.v2.preference.MigrationTool -mode filetodb
      -pref1UseHashing true -pref1RootDirectory j2ee/OC4J_Portal/applications/portalTools/omniPortlet/WEB-INF
      /providers/omniPortlet -pref2User prefstore 
      -pref2Password password -pref2URL jdbc:oracle:thin:@infra.host.com:1521:orcl
      
      
  3. Typically, you perform the HTTP Proxy configuration for OmniPortlet and Web Clipping before you configure the LBR. To do it after the LBR is configured, perform the following steps:

    1. The Portal Tools configuration information is stored in the provider.xml file on the middle-tier server. You need to update the configuration directly on one middle tier (for example, M1) and then propagate it across all middle tiers front-ended by the LBR. Before you do this, you must shut down all middle tiers except M1.

    2. You can change the HTTP Proxy settings on the Portal Tools Edit Provider pages (for OmniPortlet and Web Clipping). To display these pages, access the Portal Tools providers' test pages and then click the Edit link next to the HTTP Proxy setting. The test pages are located at the following URLs:

      • OmniPortlet provider test page:

        http://lbr.abc.com/portalTools/omniPortlet/providers/omniPortlet
        
        
      • Web Clipping provider test page:

        http://lbr.abc.com/portalTools/webClipping/providers/webClipping
        
        

      Refer to Section I.1.3, "Configuring HTTP or HTTPS Proxy Settings" for more information.

    3. Propagate the changes made to the provider.xml file to middle tier M2:

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

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

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

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

  6. Restart middle tier M2.

  7. In OracleAS Portal, 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/.

  8. In OracleAS Portal, 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/.

  9. Verify that OmniPortlet and the Web Clipping providers work properly through the LBR, by going to the test pages at the following URLs.

    • OmniPortlet Provider: http://lbr.abc.com/portalTools/omniPortlet/providers/omniPortlet

      If you see the "No Portlets Available" message under the Portlet Information section in the OmniPortlet Provider test page, then you may not have configured OmniPortlet correctly in Step 1. If OmniPortlet is configured correctly, the OmniPortlet and Simple Parameter Form portlets are available on the test page.

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


    Note:

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

  10. Refresh the Portlet Repository so that the Portal Tools portlets appear in the Portlet Builders folder in the Portlet Repository:

    1. Log in as the portal administrator, and click the Builder link.

    2. Click the Administrator tab.

    3. Click the Portlets sub-tab.

    4. Click the Refresh Portlet Repository link in the Portlet Repository portlet.

    5. The refresh operation continues in the background.

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

Locally built providers are providers that are defined within an instance of OracleAS Portal. You typically create or edit these providers before configuring for LBR. If you are doing it after the LBR is configured, perform the following steps:

  1. The Web provider information is kept in the provider.xml file on the middle-tier server. You need to update the configuration directly on one middle tier (for example, M1) and then propagate it across all middle tiers front-ended by the LBR. Before you do this, you must shut down all middle tiers except M1.

  2. Create or edit a Web provider, and its portlets. A provider.xml file is created for each new provider.

  3. Propagate the changes made to the files in M1 to middle tier 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. 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>.

  4. Restart the middle tier M2.

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 about configuring the database preference store can be found in the PDK article titled "Installing the DBPreferenceStore Sample (V2)", located on Portal Center at http://portalcenter.oracle.com.

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

  3. In OracleAS Portal, click Edit Registration for the provider on the Providers tab of the Navigator, under Registered Providers. 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.

  4. Verify that the custom built provider works properly through the LBR, by going to the test pages at the following URL:

    http://lbr.abc.com:80/<webApp>/providers/<providerName>
    
    

Configuring Custom Built WSRP Producers in a Multiple Middle-Tier Environment

By default, WSRP producers store their portlet preference data in the OracleAS Metadata Repository, and will work correctly in a multiple middle-tier environment. If you want to use a custom database to store this information, then refer to the Oracle Application Server Portal Developer's Guide for the steps to be performed.


Note:

When using a custom database for portlet preference data in a multiple middle-tier environment, all WSRP producers must reference the same database schema in data-sources.xml.

Configuring Load Balanced Session-Based Web Providers

To configure session-based Web providers, front-ended by a Load Balancing Router (LBR), the login frequency should be set to "Once Per User Session", on the provider information page, and the LBR must be configured to do cookie-based routing. To set the login frequency, take the following steps:

  1. Log in to OracleAS Portal. On the Portal Builder page.

  2. In Portal Builder, click the Administer tab and then the Portlets tab.

  3. Under Remote Providers, enter the name of the Web provider you want to configure, and then click Edit.

  4. Click the Connection tab.

  5. Under User/Session Information, set the Login Frequency to Once Per User Session.

  6. Click OK.

Refer to the specific documentation of your LBR for information about how to configure an LBR to do cookie-based routing.

Editing an External Application Login URL

If your external application is hosted on the middle tier, then you need to update the external application login URL in the OracleAS Single Sign-On Server. You can do this by following the procedure in the "Editing an External Application" section in the Oracle Application Server Single Sign-On Administrator's Guide. Change the first part of the login URL from http://m1.abc.com:7777/ to http://lbr.abc.com/.

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 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, "Configuring the Portal Tools Providers" 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 drop-down list, change the session value to Any Set-Cookie.

  4. From the Please select a session binding mechanism drop-down list, select Cookie-based.

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

  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 Oracle Enterprise Manager 10g Application Server Control Console. For example:

      http://m1.abc.com:1810
      
      

      For details, see Section 7.2.1, "Accessing the Application Server Control Console".

    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 home page at http://lbr.abc.com/portal/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 the Oracle Application Server Web Cache Administrator's Guide.

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

      Perform some basic 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 supports the configuration of virtual hosts. Virtual hosts allow a single computer to appear as any number of different sites. You can, for example, configure a computer to represent both www.abc.com and www.xyz.com. Another example would be configuring a computer to represent both my.oracle.com and oraclepartnernetwork.oracle.com. To configure virtual hosts with OracleAS 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.

Portal pages are cached in OracleAS Web Cache with the host name of the host that you access first. Subsequent requests to the same page will always contain links with that host name irrespective of which host you are accessing.

For example, if you access Page A using virtual host www.abc.com, then all links in Page A will show up relative to www.abc.com. If another user accesses the same page, Page A, using the virtual host www.xyz.com, then due to the aliasing in OracleAS Web Cache, all links created for this page will still reference www.abc.com and clicking on these links will result in portal pages being served from www.abc.com.

Unless the pages served from both virtual hosts are mutually exclusive, that is, portal pages served from site www.abc.com are not being served from www.xyz.com, users will be bouncing back and forth between the two virtual hosts. If this is not desired, then you can set up a dedicated intranet and Internet for OracleAS Portal as described in the Oracle Application Server Enterprise Deployment Guide.


Note:

If your intent is only to change the host name of your middle tier, refer to the Oracle Application Server 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/portal/pls/portal. The IP address of the computer that the middle tier is installed on is 196.12.67.8.

You want to access OracleAS Portal at http://www.abc.com:7779/portal/pls/portal, using the real server name, and http://www.xyz.com:7779/portal/pls/portal, using a virtual host name, 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 Oracle HTTP Server listening port.

Let's also assume that the OracleAS Single Sign-On is installed on a different computer 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 host name for OracleAS Single Sign-On. For more information about how to customize the OracleAS Single Sign-On host name, refer to the information about deploying OracleAS Single Sign-On with a proxy server, in the Oracle Application Server Single Sign-On Administrator's Guide, and the Oracle Application Server Administrator's Guide.


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

Figure 5-5 Virtual Host Overview

Description of Figure 5-5  follows
Description of "Figure 5-5 Virtual Host Overview"


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, and for the real server name www.abc.com. To define the virtual hosts, use Oracle Enterprise Manager 10g Application Server Control Console to perform the following steps:

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 10g Application Server Control Console.

    For details, see Section 7.2.1, "Accessing the Application Server Control Console".

  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 Oracle HTTP Server listening port, 7778 in our example, from the port drop-down 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 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 you@your.address
         RewriteEngine On
         RewriteOptions inherit
    </VirtualHost>
    
    
  24. Click Apply.

  25. When asked to restart Oracle 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. In Section 5.4.1.1, "Create the Virtual Host for www.xyz.com" follow steps 1 through 8.

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

    www.abc.com
    
    
  3. In Section 5.4.1.1, "Create the Virtual Host for www.xyz.com" follow steps 10 through 24.

  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 Console, as follows:

  1. Access the Oracle Enterprise Manager 10g Application Server Control Console.

  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 you@your.address 
   RewriteEngine On 
   RewriteOptions inherit 
</VirtualHost> 

<VirtualHost *:7778> 
   ServerName www.abc.com 
   Port 7779 
   ServerAdmin you@your.address 
   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
    
    
  • If your site name is not registered with the DNS, you need to update the hosts file on your client computer 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.
    #
    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 server name, and the virtual host are working, by accessing these URLs:

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

  • http://www.abc.com:7779/portal/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 Oracle Application Server Single Sign-On to work properly, it must always be referenced by a partner application with the same host name in the URL. This is because cookies are sent back only to the host that generated them. So, in the preceding example, 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 the script ptlconfig, as follows:

    ptlconfig -dad portal -sso -host www.abc.com -port 7779
    
    
  2. Add a partner application entry for www.xyz.com, by running the script ptlconfig, as follows:

    ptlconfig -dad portal -sso -host www.xyz.com -port 7779
    
    
  3. Run ssoreg to register the virtual host, www.abc.com, for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the file osso.conf. ssoreg is located on the middle tier in MID_TIER_ORACLE_HOME/sso/bin.

    The following example shows the usage of ssoreg on UNIX:

    MID_TIER_ORACLE_HOME/sso/bin/ssoreg.sh
      -site_name www.abc.com 
      -mod_osso_url http://www.abc.com:7779 
      -config_mod_osso TRUE 
      -oracle_home_path MID_TIER_ORACLE_HOME 
      -config_file MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf
      -admin_info cn=orcladmin 
    
    

    On Windows, you must run ssoreg.bat instead. Refer to the Oracle Application Server Single Sign-On Administrator's Guide for more information.

  4. Run ssoreg to register the virtual host, www.xyz.com, for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the file osso.conf.

    The following example shows the usage of ssoreg on UNIX:

    MID_TIER_ORACLE_HOME/sso/bin/ssoreg.sh
      -site_name www.xyz.com 
      -mod_osso_url http://www.xyz.com:7779 
      -config_mod_osso TRUE 
      -oracle_home_path MID_TIER_ORACLE_HOME
      -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 you@your.address
       RewriteEngine On
       RewriteOptions inherit
       OssoConfigFile MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso_xyz.conf
       OssoIpCheck off
    </VirtualHost>
    
    

Refer to the information about registering mod_osso in the Oracle Application Server Single Sign-On Administrator's Guide.

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/portal/pls/portal

  • http://www.xyz.com:7779/portal/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:


To specify a proxy server:

  1. In the Services portlet, click Global Settings.

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

  2. Click the Proxy tab.

  3. 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.

  4. 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.

  5. Click Add.

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

  6. 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.

  7. 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 (,).

  8. Click OK.

More on OTN

You will find additional information about how to set up proxy servers in the paper "A Primer on Proxy Servers" on the Oracle Technology Network (OTN), http://www.oracle.com/technology/.

5.6 Configuring Reverse Proxy Servers

For information about configuring reverse proxy servers for OracleAS Portal and OracleAS Single Sign-On, refer to the Oracle Application Server Enterprise Deployment Guide.

5.7 Configuring a Dedicated Intranet and Internet for OracleAS Portal

You can configure OracleAS Portal to be accessible from within a company network as well as from external clients. The following links describes some important characteristics of this configuration, and provides instructions on how to configure OracleAS Portal for this purpose:

5.8 Managing OracleAS Portal Content Cached in OracleAS Web Cache

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. Refer to Section 1.3, "Understanding Caching in OracleAS Portal" for an overview of how caching works in OracleAS Portal.

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

This section contains the following topics:

5.8.1 Managing Oracle Application Server Web Cache

In previous releases, you had to use OracleAS Web Cache Manager to configure OracleAS Web Cache. In this release, you have two choices:

These interfaces enable you to update to the OracleAS Web Cache configuration file, webcache.xml.

5.8.2 Configuring Portal Web Cache Settings Using Application Server Control Console

Use the Application Server Control Console to change OracleAS Web Cache settings that OracleAS Portal uses, such as the host name, and the invalidation port number. You configure these settings on the Portal Web Cache Settings page.

When you change OracleAS Web Cache properties in the Portal Web Cache Settings page, the properties are saved to iasconfig.xml, but not to the webcache.xml file. You must navigate back to the Web Cache Administration page in Application Server Control Console to make the appropriate changes.


See Also:

Section 7.3.3, "Portal Web Cache Settings Link" for a detailed description of how to use the Portal Web Cache Settings page.

5.8.3 Managing Portal Content Cached in OracleAS Web Cache

From the OracleAS Portal user interface, you can perform various other tasks to manage portal content cached in OracleAS Web Cache. You can either clear the entire portal content cached in OracleAS Web Cache, or clear content for each portal 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, 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.

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

5.8.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.

    By default, the Services portlet is on the Portal subtab 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.8.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.

    By default, the Services portlet is on the Portal subtab 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.8.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.

    By default, the Services portlet is on the Portal subtab 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.


    Note:

    Choosing a small value for this leads to cache misses more frequently because the cache expires more often. However, choosing a large value might lead to stale content. Avoid a value of 0 because it makes all the portal content non-cacheable.

  4. Click OK.

5.8.3.4 Clearing the Cache for a Particular Portal Object

You can clear cache entries for page groups, pages, Portal Templates for pages, portlets in the Portlet Repository, Portal DB Providers, and Portal DB 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 Portal Templates for pages, click Properties, then click the Access tab.

    • For Portal DB Providers, and Portal DB 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, click the Actions icon next to the portlet, and then click Access.

  2. Click Clear Cache.

  3. Click OK.

5.8.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 Personalize, 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 OracleAS Portal user interface. Refer to Section 5.8.3.1, "Clearing the Entire Web Cache" for information about performing this task.

5.8.5 Managing the Invalidation Message Processing Job

OracleAS Portal uses invalidation messages to expire objects in the cache. You can use the cachjsub.sql script to configure the frequency at which the invalidation job executes. Refer to Section C.1, "Managing the Invalidation Message Processing Job Using cachjsub.sql" for more information and instructions on how to run cachjsub.sql.

5.9 Configuring OracleAS Portal to Use a Dedicated OracleAS Web Cache Instance

You can deploy OracleAS Web Cache on a dedicated server that front-ends one or more OracleAS Portal middle-tier servers. OracleAS Web Cache performs well even on commodity hardware, so a dedicated deployment does not have to be costly in terms of hardware expenditure. In general, it is recommended to use a computer with 1 GB of memory. Both the cache server and middle-tier server need to use a high speed network card to ensure site performance. Refer to Section 1.3, "Understanding Caching in OracleAS Portal" for an overview of how caching works in OracleAS Portal.

To set up this topology, the administrator of the Web site needs to disable the OracleAS Web Cache that was installed on the same computer as OracleAS Portal middle tier, and set up a new OracleAS Web Cache instance on a dedicated server. Figure 5-6 shows the topology where OracleAS Portal uses a dedicated OracleAS Web Cache instance.

Figure 5-6 OracleAS Portal Using a Dedicated OracleAS Web Cache Instance

Description of Figure 5-6  follows
Description of "Figure 5-6 OracleAS Portal Using a Dedicated OracleAS Web Cache Instance"

5.9.1 Understanding Installation Prerequisites and Requirements

  • For the OracleAS Portal middle tier, you must install OracleAS Infrastructure first, and then the Portal and Wireless middle tier.

  • After installing the OracleAS Infrastructure and middle tier on their respective servers, install J2EE and Web Cache middle tier on the dedicated server.

    You can also install a standalone version of OracleAS Web Cache from: http://www.oracle.com/technology/software/products/ias/web_cache/index.html

5.9.2 Configuring a Dedicated OracleAS Web Cache

Oracle Universal Installer automatically configures and starts OracleAS Portal middle tier and OracleAS Web Cache on the same computer during the OracleAS Portal and Wireless middle-tier installation. You need to disable the OracleAS Web Cache installed on the OracleAS Portal middle-tier computer that is not used, and configure the dedicated OracleAS Web Cache installed on a different computer to communicate with OracleAS Portal middle tier.

Configuring a dedicated OracleAS Web Cache for Web site: www.company.com, port number: 7777 involves the following six tasks:

5.9.2.1 Task 1: Verify That the OracleAS Web Cache on the Dedicated Server Is Running

To properly configure OracleAS Web Cache on the dedicated server, OracleAS Web Cache needs to be up and running. Refer to the Oracle Application Server Administrator's Guide for information about how to start, stop, restart, and view the status of OracleAS Web Cache on the Application Server Control Console home page.

5.9.2.2 Task 2: Configure OracleAS Web Cache on the Dedicated Server

You must manually configure OracleAS Web Cache on the dedicated server to properly deliver content to OracleAS Portal middle tier on a different computer. You must make appropriate changes in Origin Servers page from OracleAS Web Cache Manager, (Origin Servers, Sites, and Load Balancing > Origin Servers) and the Listen Ports page (Ports > Listen Ports).

To properly configure OracleAS Web Cache, installed on the dedicated server, you will need the origin server information from the OracleAS Web Cache installed on the same computer as OracleAS Portal middle tier.

To modify the origin server properties setting from the dedicated OracleAS Web Cache instance:

  1. Make a backup copy of the webcache.xml file, located in the ORACLE_HOME/webcache directory.

  2. In OracleAS Web Cache Manager on the dedicated computer, click Origin Server under Origin Servers, Sites, and Load Balancing.

  3. In the Origin Servers page, select the Host and click Edit.

  4. Modify the Application Web Servers properties for the dedicated OracleAS Web Cache using the value copied from the same page on the OracleAS Web Cache instance that was installed on the middle-tier computer. Use the online Help for guidance on changing the default Application Web Servers properties.

  5. Click OK.

  6. Click Restart Web Cache.

You must manually configure OracleAS Web Cache on the dedicated server to create a site definition that includes a host name www.company.com, and a listening port number 7777. You must make appropriate changes in the Site Definitions page from OracleAS Web Cache Manager (Origin Servers, Sites, and Load Balancing > Site Definitions).

5.9.2.3 Task 3: Stop the Unused OracleAS Web Cache on the Middle-Tier Server

This task is optional. To save resources on the OracleAS Portal middle-tier server, follow the instructions in the Oracle Application Server Administrator's Guide to stop the unused cache on the middle-tier server. This cache instance will not be used for this deployment option.

5.9.2.4 Task 4: Configure OracleAS Portal Middle Tier with OracleAS Web Cache Settings

OracleAS Portal middle tier needs to know the OracleAS Web Cache Listen ports, the invalidator user name, invalidator password settings, and so on. You need to apply the new host name and port number of the dedicated OracleAS Web Cache to OracleAS Portal middle tier by modifying these settings in the Portal Web Cache Settings page:

  1. From the Application Server home page on the Application Server Control Console in Oracle Enterprise Manager 10g, click Portal in the System Components section. The OracleAS Portal Home page appears.

  2. Click the Portal Web Cache Settings link from the Administration section. The Portal Web Cache Settings page appears.

  3. On the Portal Web Cache Settings page, modify the Published Host field with proper host name: www.company.com, modify the Listening Port field with proper port number 7777.

  4. Review the other Web Cache Settings, like Invalidation Host, to match the cache information on the dedicated server and click Apply. A confirmation page appears. See the online Help for guidance on changing the default ports and password settings.

5.9.2.5 Task 5: Configure Virtual Host Settings for Oracle HTTP Server

You must create virtual host entries in the httpd.conf file of the Oracle HTTP Server that is part of the OracleAS Portal middle tier, with the dedicated OracleAS Web Cache settings. In this example, you will set up virtual host name www.company.com and port number 7777 (same as the dedicated OracleAS Web Cache Listen port). The virtual host name and port number must be consistent with the site definition value defined in OracleAS Web Cache. To do this, perform the following tasks:

  1. Configure Virtual Hosts Settings, as follows:

    1. From the Application Server home page on the OracleAS Portal middle-tier server, on the Application Server Control Console, click HTTP_Server in the System Components section.

      The HTTP Server Home page is displayed.

    2. Click the Virtual Hosts tab.

    3. Click Create.

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

    5. On the Create Virtual Host: General page, choose name-based for Virtual Host Type, click Next.

    6. On the Create Virtual Host: Addresses page, enter www.company.com in the Server Name field for your virtual host.

    7. Select the Listen on all the main server IP addresses option, and click Next.

    8. On the Create Virtual Host: Ports page, select Listen on a specific port, and select the Oracle HTTP Server Listen port, for example, 7778, from the port list.

    9. Click Next, and click Next again on the Create Virtual Host: Error Log page.

    10. Review the summary on the Summary page, and then click Finish. A Confirmation page appears.

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

    12. Ensure that your server name, www.company.com, is listed in the table.

  2. Configure the newly created Virtual Host, as follows:

    1. Click the Administration tab from the HTTP Server Home page.

    2. Click Advanced Server Properties.

    3. Click httpd.conf.

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

      NameVirtualHost *:7778
      <VirtualHost *:7778>
            ServerName www.company.com
            Port 7777
            RewriteEngine On
            RewriteOptions inherit
      </VirtualHost>
      
      
    5. Click Apply.

    6. When prompted to restart Oracle HTTP Server, click Yes.

    You can verify the configuration by performing basic tests, such as navigating the Web site, or removing a portlet.

5.10 Changing the Infrastructure Services Used By a Middle Tier

Oracle Application Server 10g enables you to change the OracleAS 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 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.11 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.


Note:

If you did not configure OracleAS Wireless during installation, you can use Application Server Control Console to deploy OracleAS Wireless on the middle tier. Refer to Section 7.2.2, "Using Application Server Control Console to Configure OracleAS Portal" for similar steps used to configure OracleAS Portal.

In case of multiple middle-tier installations, the first 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 cfgiasw.pl script. Refer to Section C.8, "Using the cfgiasw Script to Configure Mobile Settings" for more information.


Note:

You can also change the URL to your choice of OracleAS Wireless service by running the portalRegistrar script in the Oracle Application Server middle tier selected for the OracleAS Wireless service. Refer to the Oracle Application Server Wireless Administrator's Guide for more information about configuring OracleAS Wireless.

5.12 Changing the OracleAS Portal Schema Password

This section provides information about changing schema passwords for both default and nondefault OracleAS Portals.

Changing the Schema Password for a Default OracleAS Portal Instance

For information about changing the OracleAS Portal schema password for the default OracleAS Portal instance, refer to the section on changing OracleAS Metadata Repository schema passwords, in the Oracle Application Server 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. The section on changing OracleAS Metadata Repository schema passwords in the Oracle Application Server Administrator's Guide describes how to change the schema password for this default OracleAS Portal instance.

Changing the Schema Password for a Nondefault OracleAS Portal Instance

Refer to Section B.1.1, "Changing the OracleAS Portal Schema Password" to change the OracleAS Portal schema password for a nondefault OracleAS Portal instance.