Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Portal
11g Release 1 (11.1.1)

Part Number E10239-07
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

6 Advanced Configuration

This chapter describes 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 5.1, "Getting Started with Oracle Portal Administration" in order to perform these configurations.

This chapter contains the following sections:

6.1 Changing Oracle Fusion Middleware Listen Ports

For information about changing ports in Oracle Fusion Middleware Listen Ports, refer to the Oracle Fusion Middleware Administrator's Guide.

6.2 Configuring SSL

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

The following sections in Chapter 7, "Securing Oracle Portal" describe the SSL configuration options that are available with Oracle Portal.

6.3 Configuring Multiple Middle Tiers with a Load–Balancing Router

This section describes how you can set up Oracle Portal in a multiple middle-tier environment, front-ended by a Load Balancing Router (LBR) to access the same Oracle 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 Fusion Middleware High Availability 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 6-1. In the example, we show Oracle Web Cache on the same computer as the Oracle Portal middle tier, although they can theoretically be on different computers.

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

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

Table 6-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)

Portal middle tier 1 (M1)

Computer Name: m1.abc.com

IP Address: M1.M1.M1.M1

Oracle HTTP Server Listening Port: 8888

Oracle Web Cache Listening Port: 8090

Oracle Web Cache Invalidation Port: 4001

Oracle Web Cache Administration Port: 4002

Oracle Portal Managed Server (WLS_PORTAL): 9001

Portal middle tier 2 (M2)

Computer Name: m2.abc.com

IP Address: M2.M2.M2.M2

Oracle HTTP Server Listening Port: 8888

Oracle Web Cache Listening Port: 8090

Oracle Web Cache Invalidation Port: 4001

Oracle Portal Managed Server (WLS_PORTAL): 9001


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 8.4, "Viewing Oracle Fusion Middleware Port Usage" to view a list of all the ports currently in use by the components of a particular Oracle Portal instance.

Additional LBR configuration is required to successfully handle:

Loopback Communication

Oracle 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 Oracle Web Cache and Oracle Portal reside on the same computer.

If an LBR is front-ending Oracle Fusion Middleware, it will need additional configuration if Oracle 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 Oracle Portal generates a page. This loopback request goes directly to the LBR.

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

  3. Oracle 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 Oracle Web Cache.

  5. Oracle 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 Oracle Web Cache, using the LBR's known socket connection, instead of using the PPE's socket connection.

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

  9. Oracle 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 Oracle 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.

Oracle Web Cache Invalidation

Oracle Portal leverages Oracle Web Cache to cache a lot of its content. When cached content in Oracle Web Cache changes, Oracle Portal sends invalidation messages from the database to Oracle Web Cache. Oracle Portal can only send invalidation messages to one Web Cache node in an Oracle Web Cache cluster. Oracle Portal relies on that Oracle Web Cache member to invalidate content in the other members of the cluster. When Oracle Fusion Middleware 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.

Notes:

  • After you have completed the Oracle Web Cache Invalidation, ensure that its password is also updated in the Oracle Portal Repository.

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

6.3.1 Step 1: Install a Single Portal Middle Tier (M1)

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

  1. Follow the steps described in Oracle Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer, to install a Portal middle tier on the first computer (M1). It is assumed that you use the services of an existing Oracle Fusion Middleware Infrastructure.

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

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

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

    Figure 6-2 Installation of Oracle Portal Middle Tier

    Description of Figure 6-2 follows
    Description of "Figure 6-2 Installation of Oracle Portal Middle Tier"

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

6.3.2 Step 2: Configure Oracle Portal on M1 to Be Accessed Through the LBR

To configure Oracle 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 Oracle Web Cache port (8090) 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 Oracle Web Cache is listening on.

      Note:

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

  2. Configure the Oracle 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 Oracle 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 6.4.1.1, "Create the Virtual Host for www.xyz.com", and specify the host name of the LBR (lbr.abc.com:80) in the Server Name field for your virtual host.

    2. Define a second virtual host, using the Create Virtual Host wizard, as explained in Section 6.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:

      • Specify the host name of M1 (m1.abc.com:8090) in the Server Name field for your virtual host.

      • Restart the Oracle HTTP Server.

    3. After you have configured the virtual hosts, open the httpd.conf file in the Oracle Enterprise Manager 11g Fusion Middleware Control, and do the following:

      • Expand Web Tier and click the Oracle HTTP Server (ohs1) link for your Oracle Portal instance.

      • In the Oracle HTTP Server home page, select Administration, and then Advanced Configuration.

      • In the Advanced Server Configuration page, select httpd.conf from Select File option, and click Go.

      • Add the virtual host definitions in the httpd.conf file:

        NameVirtualHost *:8888
        <VirtualHost *:8888>
            ServerName http://lbr.abc.com:80
            RewriteEngine On
            RewriteOptions inherit
            UseCanonicalName On
        </VirtualHost>
        
        <VirtualHost *:8888>
            ServerName http://m1.abc.com:8090
            RewriteEngine On
            RewriteOptions inherit
            UseCanonicalName On
        </VirtualHost>
        
      • Click Apply.

      • Restart the Oracle HTTP Server.

  3. Define a site that matches the virtual host entry, created in the previous step (lbr.abc.com), using Oracle Fusion Middleware Control on M1, as follows:

    1. Navigate to the Web Cache Home Page in the Oracle Enterprise Manager 11g Fusion Middleware Control on M1, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

    2. From the Web Cache menu, select Administration, and then Sites.

      The Sites page is displayed.

    3. Click Create under Sites.

    4. On the Create Site page, specify lbr.abc.com for the Host and 80 for Port.

    5. Select Default Site and Compression.

    6. Leave the URL Prefix field blank.

    7. Click OK. You will now see lbr.abc.com in the Sites table.

    8. Select lbr.abc.com from the Sites table and click Edit.

    9. In the Aliases section, click Create to create a new alias and enter the following information:

      Host Name: m1.abc.com

      Port: 8090

    10. Click OK.

    11. Click Apply.

  4. Use Oracle Enterprise Manager 11g Fusion Middleware Control on M1, to map the site lbr.abc.com to middle tier m1.abc.com.

    1. From the Sites page, in the Site-to-Server Mapping section, click Create.

      The Create Site-to-Server Mapping Definition page is displayed.

    2. Enter the following information in the Create Site-to-Server Mapping section:

      Host Pattern: lbr.abc.com

      Port Pattern: 80

      Leave the Prefix field blank.

    3. In the Origin Servers section, select m1.abc.com:8888 from All Origin Servers, and move it to Selected Origin Servers.

    4. Click OK.

    5. Click Apply.

    6. Select m1.abc.com from the Sites table and click Delete to remove the unused site.

    7. From the Site-to-Server Mapping table, click Delete to remove the unused sites.

    8. Restart your Oracle Web Cache by selecting Control, and then Restart from the Web Cache Home page in the Oracle Enterprise Manager 11g.

    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 Oracle 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 Oracle Web Cache or Oracle HTTP Server through the LBR.

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

    Note:

    The LBR does not have to listen on the Oracle Web Cache invalidation port. On LBRs that do not have Port Mapping ability the port number must match the Oracle 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 Oracle 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 Oracle Web Cache is listening on.

      Notes:

      • Consult the LBR documentation to set up the groups, and virtual server.

      • If the Oracle Fusion Middleware Infrastructure is behind another firewall, you need to make sure that it can send invalidation messages to the LBR.

      • If the Oracle Portal Metadata Repository Database is behind another firewall, make sure that the database machine can access Web Provider using the provider registration URL.

      WARNING:

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

  8. Configure the portal middle tier as follows:

    1. Navigate to the Portal Home page in the Enterprise Manager.

    2. From the Portal menu, select Settings, and then Wire Configuration.

      The Portal Wire Configuration page is displayed.

    3. Enter the following information under Portal Middle Tier section in the Portal Wire Configuration page:

      • Published Host: lbr.abc.com

      • Listening Port: 80

    4. Under Oracle Web Cache section in the Portal Wire Configuration page, enter lbr.abc.com as the Host, and 8093 as the Invalidation Port.

    5. Click Apply.

    6. Restart your managed server.

  9. You need to configure the HTTP settings for lbr.abc.com in the Oracle WebLogic Server Administration Console as follows:

    1. Log in to Oracle WebLogic Server Administration Console.

    2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

    3. In the left pane of the Console, expand Environment and select Clusters.

    4. Select the cluster server and, then the HTTP tab.

    5. In the HTTP page enter the following information:

      • Frontend Host: lbr.abc.com

      • Frontend HTTPPort: 80

    6. Click Save.

    7. Click Activate Changes.

    8. Restart your managed server.

  10. 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 Identity Management instance in ORACLE_HOME/sso/bin.

    The following example shows the usage of ssoreg on UNIX:

    $ ssoreg.sh
      -site_name lbr.abc.com 
      -mod_osso_url http://lbr.abc.com:port 
      -config_mod_osso TRUE 
      -oracle_home_path ORACLE_HOME 
      -config_file /tmp/osso.conf 
      -admin_info cn=orcladmin 
      -virtualhost
      -remote_midtier
    

    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.

  11. Back up osso.conf which is located in ORACLE_INSTANCE/config/OHS/ohs1.

  12. Copy the osso.conf file to the ORACLE_INSTANCE/config/OHS/ohs1 directory.

  13. Restart your Oracle HTTP Server.

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

Figure 6-3 Oracle Portal Being Accessed Through the LBR

Description of Figure 6-3 follows
Description of "Figure 6-3 Oracle Portal Being Accessed Through the LBR "

6.3.3 Step 3: Confirm That Oracle Portal is Up and Running

Confirm that Oracle 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 Oracle Web Cache, Oracle HTTP Server, and LBR configuration and logs, refer to the Oracle Fusion Middleware Administrator's Guide.

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

    http://lbr.abc.com:port/index.html
    
  2. Test the connection to Oracle Metadata Repository through the LBR, by accessing the following URL:

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

    The response should be "test". If this succeeds, it means that the Oracle Fusion Middleware middle tier can connect to the Oracle Metadata Repository. If this fails, then scan the WLS_PORTAL-diagnostic.log file for the WLS_Portal instance for details about the request failure, and take appropriate actions.

  3. Test access to Oracle Portal, by completing the following steps:

    1. Access the Oracle Portal home page at http://lbr.abc.com:port/portal/pls/portal. If this does not work, then scan the WLS_PORTAL-diagnostic.log file for the WLS_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. While accessing the Oracle Portal home page, it may give an XML Parsing Error, in such case review the diagnostic logs. One of the causes for this error may be a mismatch of the WebCache invalidation password between Oracle Web Cache and Oracle Portal. Review the settings at both ends and make sure that the password matches.

    3. Click the portal login link. If this does not work, review the steps performed to run ssoreg to register the virtual host for which mod_osso facilitates single sign-on. Check the WLS_PORTAL-diagnostic.log file for the WLS_PORTAL instance in the DOMAIN_HOME\servers\WLS_PORTAL\logs for more details.

    4. Click some links in the portal.

    5. Confirm that content is getting cached in Oracle Web Cache.

      From the Web Cache menu in the Oracle Enterprise Manager, select Monitoring, and then Popular Requests. Select Cache Popular Requests from the Show Popular Request drop-down list. In the Cache Popular Requests, click Go to refresh the page content. If you accessed Oracle Portal, you will see portal content (For example, URLs that contains strings like _esiReqType=2, wwpob_smd.has_previlege, and wwv_setting.render_css. If you do not see any portal content, open another browser and log in to Oracle Portal. Return to the Cache Popular Requests page, and click Go, to refresh the page content. This should provide enough content for verification.

    6. Perform some basic page edits in Oracle 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, Oracle Web Cache invalidation is misconfigured.

6.3.4 Step 4: Install a New Portal (M2)

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

Note:

Before you proceed with installing a Oracle Portal, ensure that you have installed WebLogic Server. See Oracle WebLogic Server Installation Guide. The WebLogic Server installation creates the Middleware Home, which is used to install all the Oracle Fusion Middleware components.

  1. Run Oracle Universal Installer to install a Portal middle tier on the second computer (M2).

  2. Select the Install Software and Configure option in the Select Installation Type screen during the installation of Oracle Fusion Middleware middle tier and click Next.

  3. From the Prerequisite Checks screen, click Next to continue.

  4. In the Select Domain screen, select Expand Cluster and enter the following information:

    • Host: Enter m1.abc.com

    • Port: Enter the WebLogic Administration port number (default: 7001).

    • User Name: Enter the user name of the WebLogic Administration server.

    • User Password: Enter the password of the WebLogic Administration server.

  5. Enter the information in the Specify Email for Security Updates screen and click Next to continue.

  6. Specify the Middleware Home, Oracle Home, and Oracle Instance locations, along with the Oracle Instance name in the Specify Installation Location screen and click Next to continue.

    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.

  7. In the Configure Components screen, select the components you have selected for M1 and click Next.

  8. In the Configure Ports screen, select Specify Ports Using Configuration file, and click Browse to select the staticports.ini file used by M1.

    If you did not save the file during M1 installation, the file does not exist. In this scenario, click View\Edit File and edit the file as follows:

    Domain Port No = 7001
    [OHS]
    Oracle HTTP Server Port No = 8888 
    [WEBCACHE]
    Oracle WebCache Port No = 8090
    Oracle WebCache Invalidation Port No = 4001
    [MANAGEDSERVER]
    Oracle WLS Portal Managed Server Port No = 9001
    

    Note:

    The port values should be the same as in MI.

  9. In the Specify Application OID screen, enter your Oracle Internet Directory server details and click Next.

  10. In the Installation Summary screen, verify the information and click Install.

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

6.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. Copy the configuration settings for Oracle 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, copy the following files:

    • appConfig.xml

    • portal_cache.conf

    • portal_dads.conf

    • portal_plsql.conf

    From DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration of M1 to M2.

    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.

  2. Configure the new Oracle 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 Fusion Middleware Control on M2:

    1. Define a virtual host, using the Create Virtual Host wizard, as explained in Section 6.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:

      • Select New listen address option, and enter lbr.abc.com:80.

      • Specify the host name of the LBR (lbr.abc.com) in the Server Name field for your virtual host.

    2. Define a second virtual host, using the Create Virtual Host wizard, as explained in Section 6.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:

      • Select New listen address option, and enter m2.abc.com:8090.

      • Specify the host name of M2 (m2.abc.com) in the Server Name field for your virtual host.

      • Restart the Oracle HTTP Server.

    3. After you have configured the virtual hosts, open the httpd.conf file in the Oracle Enterprise Manager 11g Fusion Middleware Control, and do the following:

      • Expand Web Tier and click the Oracle HTTP Server (ohs1) link for your Oracle Portal instance.

      • In the Oracle HTTP Server home page, select Administration, and then Advanced Configuration.

      • In the Advanced Server Configuration page, select httpd.conf from Select File option, and click Go.

      • Add the virtual host definitions in the httpd.conf file:

        NameVirtualHost *:8888
        <VirtualHost *:8888>
            ServerName http://lbr.abc.com
            RewriteEngine On
            RewriteOptions inherit
            UseCanonicalName On
        </VirtualHost>
        
        <VirtualHost *:8888>
            ServerName http://m2.abc.com:8090
            RewriteEngine On
            RewriteOptions inherit
            UseCanonicalName On
        </VirtualHost>
        
      • Click Apply.

      • Restart the Oracle HTTP Server.

  3. Copy mod_oradav.conf, mod_osso.conf, plsql.conf, and portal.conf from ORACLE_INSTANCE\config\OHS\ohs1\moduleconf of M1 to M2.

  4. Copy ORACLE_INSTANCE\config\OHS\ohs1\osso.conf from M1 to M2.

  5. Open portal.conf file located in ORACLE_INSTANCE\config\OHS\ohs1\moduleconf and remove all lines beginning with WebLogicHost and WebLogicPort and replace them with a WebLogicCluster directive and update it as follows for the Oracle HTTP Server to be made aware of all of the Oracle WebLogic Managed Servers:

    For M1:

    <Location /portal>
        SetHandler weblogic-handler
        WebLogicCluster m1.abc.com:9001,m2.abc.com:9001
    </Location>
    

    For M2:

    <Location /portal>
        SetHandler weblogic-handler
        WebLogicCluster m2.abc.com:9001,m1.abc.com:9001
    </Location>
    
  6. Restart the Oracle HTTP Server using the following commands:

    ORACLE_INSTANCE\bin\opmnctl stopall
    ORACLE_INSTANCE\bin\opmnctl startall
    
  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 Oracle Web Cache Manager on M1, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

  9. Use Oracle Enterprise Manager 11g on M1, to add M2 as an additional origin server to the Oracle Web Cache. To do this, perform the following steps:

    1. Navigate to the M1 Web Cache Home page in the Oracle Enterprise Manager 11g.

    2. From the Web Cache menu, select Administration, and then Origin Server.

      The Origin Servers page displays.

    3. Click Create.

      The Create Origin Server page displays.

    4. In the Create Origin Server page displays page, provide the following information:

      Property Value

      Host

      m2.abc.com

      Port

      8888

      Capacity

      100

      Protocol

      HTTP

      Routing Enabled

      ENABLED

      Failover Threshold

      5

      Ping URL

      /

      Ping Frequency (seconds)

      10


      Note:

      For the Port value, use the M2's Oracle HTTP Server listening port.

    5. Click OK.

    6. Click Apply.

    7. 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 Fusion Middleware Administrator's Guide for Oracle Web Cache for more information.

  10. Use Fusion Middleware Control 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. Navigate to the M1 Web Cache Home page in the Oracle Enterprise Manager 11g.

    2. From the Web Cache Menu, select Administration, and then Sites.

      The Sites page displays.

    3. On the Site-to-Server Mapping page, select the mapping for the LBR site in the table and click Edit.

    4. Select m2.abc.com:8888 in the All Origins Servers and move it to Selected Origin Server.

    5. Click OK.

    6. Click Apply.

    7. 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 by accessing Web Cache menu in the Enterprise Manager, Administration > Sites.

    Refer to the section on mapping sites to origin servers in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for more information.

  11. Use Oracle Fusion Middleware Control on M1, to add the Oracle Web Cache on M2 to the Oracle Web Cache cluster on M1 and ensure that the password for both the Oracle Web Cache are same. To do this, perform the following steps:

    1. Navigate to the Web Cache Home page in the Fusion Middleware Control.

    2. From the Web Cache menu, select Administration, and then Cluster.

    3. In the Cluster page, click Add.

      The Web Cache for M2 will be added.

    4. Click Apply.

    5. Click Synchronize and, click Yes to confirm.

    6. Restart the Oracle Web Cache on M1 and M2.

      For information about configuring a cache cluster, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

  12. 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 6.3.2, "Step 2: Configure Oracle Portal on M1 to Be Accessed Through the LBR " section for more information.

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

    Note:

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

6.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 B.10, "Using the PDK-Java Preference Store Migration and Upgrade Utility" for more information about this utility.

For the WSRP producer, the Oracle Metadata Repository is used as the default portlet preference store. If you want to use a different preference store, then refer to the Oracle Fusion Middleware Developer's Guide for Oracle Portal 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. The Portal Tools configuration information is stored in the OmniPortlet and Web Clipping 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. For more information, see Section E.1.3, "Configuring HTTP or HTTPS Proxy Settings".

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

    • Copy DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\dir_name\war\WEB-INF\providers\omniPortlet\provider.xml from M1 to M2.

      Note that dir_name is a randomly generated directory name for each deployment instance.

    • Copy DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\dir_name\war\WEB-INF\providers\webClipping\provider.xml from M1 to M2.

  2. Restart middle tier M2.

  3. 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 Oracle Web Cache. Refer to "Step 7: Enable Session Binding on Oracle Web Cache" for more information.

  4. In Oracle Portal, click Edit Registration for the OmniPortlet producer on the Producers tab of the Navigator, under Locally Built Producers. Then click the Connection tab, and change the first part of the producer registration URL from http://m1.abc.com:7777/ to http://lbr.abc.com/.

  5. In Oracle Portal, click Edit Registration for the Web Clipping producer on the Providers tab of the Navigator, under Locally Built Producers. Then click the Connection tab and change the first part of the producer registration URL from http://m1.abc.com:7777/ to http://lbr.abc.com/.

  6. 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 Oracle Portal. These locally built providers are available if you have migrated them from the previous release. 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 migrate provider.xml to one middle tier (for example, M1) using upgrade assistance 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. Propagate the changes made to the files in M1 to middle tier M2:

    1. Go to DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\dir_name\war\WEB-INF and copy the deployment, deployment_providerui, and providers folders from M1 to M2.

      Note that dir_name is a randomly generated directory name for each deployment instance.

    2. Change the <warDir> element in the DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\dir_name\war\WEB-INF\\deployment_providerui\provideruiacls.xml file with the appropriate value for M2 (shown in bold):

      <providerMap name="MyProducer" 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>{providerBuilder war directory of this mid-tier}</warDir>
          <warFile>providerBuilder</warFile>
      </providerMap>
      
  3. Restart the middle tier M2.

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

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

By default, WSRP producers store their portlet preference data in the Oracle 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 theOracle Fusion Middleware Developer's Guide for Oracle Portal 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 Oracle 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/.

6.3.7 Step 7: Enable Session Binding on Oracle Web Cache

The Session Binding feature in Oracle Web Cache is used to bind user sessions to a given origin server to maintain state for a period of time. Although almost all components running in a default Oracle 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 E, "Configuring the Portal Tools Providers" for more information about Web Clipping.

  • Enabling session binding forces all the user requests to go to a given Oracle 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 Oracle Web Cache if you have more than one middle tier. In this configuration Oracle Portal does not require session binding to be set up on the LBR.

To make Oracle Web Cache bind the portal user session to the Oracle Portal middle tier, perform the following steps in the Oracle Fusion Middleware Control:

  1. Navigate to the Web Cache Home page, in the Oracle Enterprise Manager 11g.

  2. From the Web Cache menu, select Administration, and then Session Configuration.

    The Session Configuration page displays.

  3. Create a session definition in the Session Definition table. Refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for information on how to create session definitions.

  4. Specify session-binding settings:

    1. In the Session Policy Configuration section, click Create.

      A new row in the table appears.

    2. From the Session Name list, select the session you created in Step 3, and then With Session from the Cache option.

    3. From the Session Binding Configuration section, check the Bind using a session radio button. Select session you created in Step 3 and select Cookie-based.

    4. Click Apply to submit changes.

For more information refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

6.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 Oracle Web Cache, restart M1 and M2, as follows:

    1. Access Oracle Enterprise Manager 11g and open the M1 instance.

      For details, see "Accessing Oracle Enterprise Manager 11g Fusion Middleware Control".

    2. From the M1 menu, select Control, then Start Down and Control, then Start Up.

    3. Repeat the steps for M2.

  2. Test access to Oracle Portal through the LBR by completing the following steps:

    1. Access the Oracle 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 Oracle Web Cache, by completing the following steps:

      Access Fusion Middleware Control, expand Web Tier, and select Web Cache. Right click Web Cache menu and select Monitoring, and then Popular Requests. The Popular Requests page displays. Perform some basic page edits in Oracle Portal, like adding a portlet to a page and make sure that the new content shows up on the Popular Requests page by refreshing the page If the new content does not display properly, or if you see errors, Oracle Web Cache invalidation is misconfigured.

6.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 Oracle Portal, you must set this up on the Oracle HTTP Server. Additional Oracle Web Cache and Oracle Application Server Single Sign-On configuration is also required.

Portal pages are cached in Oracle 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 Oracle 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 refer to 824225.1 from http://metalink.oracle.com for information on creating two sites with host independent invalidation in the Web Cache site definitions.

Note:

If your intent is only to change the host name of your middle tier, refer to the Oracle Fusion Middleware Administrator's Guide.

Let's assume that your server name is www.abc.com, and you connect to Oracle Portal at http://www.abc.com:8090/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 Oracle Portal at http://www.abc.com:8090/portal/pls/portal, using the real server name, and http://www.xyz.com:8090/portal/pls/portal, using a virtual host name, where both URLs resolve to the same IP address.

In this example, port 8090 is the Oracle Web Cache listening port, and port 8888 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:8091/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 Oracle 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 Fusion Middleware Administrator's Guide.

Figure 6-4 shows the previously described configuration. Oracle Web Cache and the Oracle Fusion Middleware are shown as residing on the same middle-tier computer, although they can exist on different computers.

Figure 6-4 Virtual Host Overview

Description of Figure 6-4 follows
Description of "Figure 6-4 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 Oracle Web Cache

  3. Register Oracle Portal with OracleAS Single Sign-On

  4. Verify the Configuration

6.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 11g Fusion Middleware Control 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

6.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 11g Fusion Middleware Control.

    For details, see "Accessing Oracle Enterprise Manager 11g Fusion Middleware Control".

  2. Expand Web Tier and then click the HTTP Server link for your Oracle Portal instance.

  3. In the Oracle HTTP Server home page, select Administration, and then Virtual Hosts.

    The Virtual Hosts page is displayed.

  4. Click the Create button.

    The Create Virtual Host page is displayed.

  5. On the Create Virtual Host page, provide the information listed in Table 6-2.

    Table 6-2 Virtual Host Information

    Virtual Host Information Value

    Virtual Host Name

    Select Use existing listen address and select a port number from the drop-down option.

    Server Name

    Your Domain name, http://www.xyz.com.

    Document Root Directory

    ORACLE_INSTANCE\config\OHS\ohs1\htdocs

    Directory Index

    Can be left blank

    Administration E-Mail Address

    Valid e-mail address

    Type

    name-based


  6. Click OK.

  7. Ensure that your server name, http://www.xyz.com, is listed in the table.

  8. After you have configured the virtual hosts, open the httpd.conf file in the Oracle Enterprise Manager 11g Fusion Middleware Control, and do the following:

    • Expand Web Tier and click the Oracle HTTP Server (ohs1) link for your Oracle Portal instance.

    • In the Oracle HTTP Server home page, select Administration, and then Advanced Configuration.

    • In the Advanced Server Configuration page, select httpd.conf from Select File option, and click Go.

    • Add the Port to the ServerName, and the Rewrite and RewriteOptions directives in the VirtualHost container, as follows (shown in bold text):

      NameVirtualHost *:8888
      
      <VirtualHost *:8888>
           ServerName http://www.xyz.com:8090
           DocumentRoot <ORACLE_INSTANCE>/config/OHS/ohs1/htdocs
           ServerAdmin you@your.address
           RewriteEngine On
           RewriteOptions inherit
      </VirtualHost>
      
    • Click Apply.

    • Restart the Oracle HTTP Server by selecting Control, and then Restart from the Oracle HTTP Server Home page.

6.4.1.2 Create the Virtual Host for www.abc.com

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

  1. In Section 6.4.1.1, "Create the Virtual Host for www.xyz.com" follow steps 1 through 6.

  2. Provide the following information in the Server Name field for your virtual host:

    www.abc.com
    
  3. In Section 6.4.1.1, "Create the Virtual Host for www.xyz.com" follow step 8.

  4. Restart the Oracle HTTP Server.

6.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 Fusion Middleware Control, as follows:

  1. Access the Oracle Enterprise Manager 11g Fusion Middleware Control.

  2. Right click the HTTP Server link for your Oracle Portal instance.

  3. In the Oracle HTTP Server home page, select Administration, and then Advanced Configuration.

  4. In the Advanced Server Configuration page, select httpd.conf from Select File option and click Go.

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

    NameVirtualHost *:8888
    
    <VirtualHost *:8888>
       ServerName http://www.xyz.com:8090
       ServerAdmin you@your.address 
       RewriteEngine On 
       RewriteOptions inherit 
    </VirtualHost> 
    
    <VirtualHost *:8888> 
       ServerName http://www.abc.com:8090 
       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.

  5. Click Apply to update the file.

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.

    Finally, restart Oracle HTTP Server, by running the following command from:

    ORACLE_INSTANCE\bin\opmnctl stopall
    ORACLE_INSTANCE\bin\opmnctl startall
    
  • 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.

6.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:8090/portal/pls/portal

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

6.4.2 Configure Oracle Web Cache

The site www.abc.com is already defined in Oracle Web Cache. Additionally, you must create a site alias in Oracle Web Cache, to make the multiple virtual hosts transparent to the Oracle 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 Oracle Web Cache invalidate content that is cached for both sites.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for information about setting up a site alias.

6.4.3 Register Oracle Portal with OracleAS Single Sign-On

To register Oracle Portal with OracleAS Single Sign-On, do the following:

  1. 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 osso.conf file. The ssoreg script is located on the infrastructure tier in ORACLE_HOME/sso/bin (UNIX).

    The following example shows the usage of ssoreg in UNIX:

    ORACLE_HOME/sso/bin/ssoreg.sh
    -site_name www.xyz.com:8090
    -config_mod_osso TRUE
    -mod_osso_url http://www.xyz.com:8090
    -remote_midtier
    -config_file ORACLE_HOME/Apache/Apache/conf/osso/osso_xyz.conf
    
  2. Copy the osso_xyz.conf file from your infrastructure home to the ORACLE_INSTANCE/config/OHS/ohs1 directory.

  3. Open the httpd.conf file using Oracle Enterprise Manager 11g Fusion Middleware Control, and add the following osso parameters shown in bold:

    <VirtualHost *:8888>
       ServerName www.xyz.com:8090
       ServerAdmin you@your.address
       RewriteEngine On
       RewriteOptions inherit
       OssoIpCheck off   
       OssoSecureCookies off   
       OssoIdleTimeout off
       OssoConfigFile osso_xyz.conf
    </VirtualHost>
    
  4. Restart the Oracle HTTP Server.

6.4.4 Verify the Configuration

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

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

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

6.4.5 Reconfiguring Portal for a Change in the OracleAS Single Sign-On 10g Host Name

To reconfigure Oracle Portal for a change in the OracleAS Single Sign-On 10g host name, perform the following steps:

  1. In the ORACLE_HOME/Apache/Apache/conf/httpd.conf file that is located in the 10g infrastructure home, change the server name to the new host name as shown below.

    ServerName new_sso_host
    

    Example:

    ServerName sso.mycompany.com
    
  2. Set the ORACLE_HOME environment variable to the 10g infrastructure home.

    1. Change the directory to ORACLE_HOME/sso/bin in the 10g infrastructure home.

    2. Run the following script (on UNIX):

      ssocfg.sh http new_sso_host new_sso_port
      

      Example:

      ssocfg.sh http sso.mycompany.com 7777
      

      Note:

      On Windows, use the ssocfg.bat script.

  3. Register the new OracleAS Single Sign-On 10g partner application.

    1. Change the directory to ORACLE_HOME/sso/bin in the 10g infrastructure home.

    2. Run the following script:

      ssoreg.sh \
       -oracle_home_path $ORACLE_HOME \
       -site_name infrastructure_middle_tier:port \
       -config_mod_osso TRUE \
       -mod_osso_url http://new_sso_host:new_sso_port \
       -config_file file_name.conf
      

      Example:

      ssoreg.sh \
       -oracle_home_path $ORACLE_HOME \
       -site_name sso.mycompany.com:7777 \
       -config_mod_osso TRUE \
       -mod_osso_url http://sso.mycompany.com:7777 \
       -config_file $ORACLE_HOME/Apache/Apache/conf/osso/osso-sso.conf
      

      Note:

      The command-line syntax and example shown here are for UNIX.

      For Windows, use the ssoreg.bat script, use a backslash (\) as the directory path separator, and enter the full command on a single line.

    3. Back up ORACLE_HOME/Apache/Apache/conf/osso/osso.conf, and replace it with the content from the ORACLE_HOME/Apache/Apache/conf/osso/osso-sso.conf file that you created in the previous step.

  4. Update the DCM repository.

    $ORACLE_HOME/dcm/bin/dcmctl updateconfig
    
  5. Change the DAS operation URL.

    1. Start the OID administration tool (oidadmin).

    2. Log in as orcladmin.

    3. Navigate to the DAS operation URL as shown below:

      Description of oid_nav.gif follows
      Description of the illustration oid_nav.gif

    4. Update orcldasurlbase with the following value:

      http://new_sso_host:new_sso_port/
      

      Example:

      http://sso.mycompany.com:7777/
      
    5. Click Apply.

  6. Restart the 10g infrastructure tier.

    $ORACLE_HOME/opmn/bin/opmnctl stopall
    $ORACLE_HOME/opmn/bin/opmnctl startall
    
  7. Register the new mod_osso partner application for Oracle Portal 11g.

    1. Change the directory to ORACLE_HOME/sso/bin in the 10g infrastructure home.

    2. Run the following script:

      ssoreg.sh \
       -site_name portal_middle_tier:port \
       -config_mod_osso TRUE \
       -oracle_home_path $ORACLE_HOME \
       -mod_osso_url http://portal_host:port \
       -config_file file_name.conf \
       -admin_info cn=orcladmin \
       -remote_midtier
      

      Example:

      ssoreg.sh \
       -site_name portal.mycompany.com:8090 \
       -config_mod_osso TRUE \
       -oracle_home_path $ORACLE_HOME \
       -mod_osso_url http://portal.mycompany.com:8090 \
       -config_file $ORACLE_HOME/Apache/Apache/conf/osso/osso-portal.conf \
       -admin_info cn=orcladmin \
       -remote_midtier
      

      Note:

      The command-line syntax and example shown here are for UNIX.

      For Windows, use the ssoreg.bat script, use a backslash (\) as the directory path separator, and enter the full command on a single line.

    3. In the Oracle Portal 11g ORACLE_HOME, back up /config/OHS/ohs1/osso.conf, and replace it with the content from the ORACLE_HOME/Apache/Apache/conf/osso/osso-portal.conf file that you created in the previous step.

  8. Restart the WLS_PORTAL managed servers.

    Restart Oracle Web Cache by selecting Control, and then Restart from the Web Cache Home page in the Oracle Enterprise Manager 11g.

    Finally, restart Oracle HTTP Server, by running the following command from:

    ORACLE_INSTANCE\bin\opmnctl stopall
    ORACLE_INSTANCE\bin\opmnctl startall
    

6.5 Configuring Oracle Portal to Use a Proxy Server

You can configure Oracle 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/.

6.6 Configuring Oracle Portal to Work with a Reverse Proxy Server

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

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

Caution:

For this configuration to work properly, you must first configure OracleAS Single Sign-On to work with the reverse proxy server. Information on deploying OracleAS Single Sign-On with a proxy server can be found in the Oracle Application Server Single Sign-On Administrator's Guide.

Figure 6-5 Reverse Proxy Server Configuration

Description of Figure 6-5 follows
Description of "Figure 6-5 Reverse Proxy Server Configuration"

For this example, consider the following:

Property Value

External server name

www.abc.com

External server port

80

Internal server name

internal.company.com

Web Cache listening port

8090

Web Cache Administration port

8091

Web Cache invalidation port

8093

OHS listening port

8888


Note:

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 Managing Ports, in the Oracle Fusion Middleware Administrator's Guide.

Configuring Oracle Portal for the architecture depicted in Figure 6-5 involves the following steps:

  1. Configuring Your Reverse Proxy Server

  2. Configuring the Virtual Host for Oracle HTTP Server

  3. Configuring your Web Cache to Work with the Reverse Proxy Server

  4. Configuring the Portal Middle Tier to Work with Reverse Proxy Server

  5. Configuring the Oracle WebLogic Server to Work with Reverse Proxy Server

  6. Configuring Loopback to the Internal Server

  7. Configuring the osso.conf File

  8. Verifying Your Configuration

Configuring Your Reverse Proxy Server

You can choose any proxy server to function as a reverse proxy. For example, you can use Oracle Web Cache, Oracle HTTP Server, or Internet Information Services (IIS) listener.

Note:

This section describes how to configure Oracle HTTP Server as a reverse proxy. It is assumed that you have set up and configured Oracle HTTP Server to listen on port 80 and accessed as www.abc.com. On some platforms, if you are using ports less than 1024, it requires additional configuration steps. For more information, refer to the Oracle Fusion Middleware Administrator's Guide.

To use the Oracle HTTP Server as a reverse proxy first install the standalone version of the Oracle HTTP Server on the reverse proxy server. This section explains how to configure the Oracle HTTP Server to pass incoming requests to Oracle Application Server Single Sign-On, Oracle Delegated Administration Services and Oracle Portal, and modify all HTTP headers so that only the identity of the reverse proxy server computer is visible to clients. To configure the Oracle HTTP Server as a reverse proxy, use the RewriteRule directive with the [P] (force proxy) flag to define URL rewriting rules and to pass requests through mod_proxy. Add the Port and the Rewrite directives in the httpd.conf file (ORACLE_INSTANCE\config\OHS\ohs1) at a location by following the LoadModule directives.

ProxyPassReverse / http://internal.company.com:8090
     RewriteEngine On
     RewriteRule ^/(.*) http://internal.company.com:8090/$1 [P]

Restart your Oracle HTTP Server:

ORACLE_INSTANCE\bin\opmnctl restartproc process-type=OHS

Configuring the Virtual Host for Oracle HTTP Server

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

  1. Define a virtual host for the Oracle HTTP Server instance that will be used for the reverse proxy, by using the Create Virtual Host wizard, as explained in Section 6.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:

    • Specify www.abc.com in the Server Name field.

    • Specify 80 for the Port directive in the Virtual Host container.

  2. Define a virtual host for the Oracle HTTP Server instance that is the Apache Server installed with Oracle Portal, by using the Create Virtual Host wizard, as explained in Section Section 6.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:

    • Specify internal.company.com in the Server Name field.

    • Specify 8090 for the Port directive in the VirtualHost container.

  3. After you have configured the virtual host, open the httpd.conf file using the Oracle Enterprise Manager 11g Fusion Middleware Control as follows:

    1. Expand Web Tier and click the Oracle HTTP Server (ohs1) link for your Oracle Portal instance.

    2. In the Oracle HTTP Server home page, select Administration, and then Advanced Configuration.

    3. In the Advanced Server Configuration page, select httpd.conf from Select File option, and click Go.

    4. Edit the following syntax in the httpd.conf file:

      NameVirtualHost *:8888
      <VirtualHost *:8888>
          ServerName http://www.abc.com:80
          RewriteEngine On
          RewriteOptions inherit
          UseCanonicalName Off
      </VirtualHost>
       
      <VirtualHost *:8888>
          ServerName internal.company.com:8090
          RewriteEngine On
          RewriteOptions inherit
          UseCanonicalName Off
      </VirtualHost>
      
    5. Restart your Oracle HTTP Server:

      ORACLE_INSTANCE\bin\opmnctl restartproc process-type=OHS
      

Configuring your Web Cache to Work with the Reverse Proxy Server

To configure the reverse proxy for Web Cache, you must define a site that matches the virtual host entry, created in the previous section and then create ordered mappings of site to the origin server using the Oracle Fusion Middleware Control. To do this complete the following steps:

  1. Navigate to the Web Cache Home page in Enterprise Manager.

  2. From the Web Cache menu, select Administration, and then Sites.

    The Sites page is displayed.

  3. From the Site Definitions section, click Create.

    The Create Site Definition page is displayed.

  4. Enter the following information:

    • Host: www.abc.com

    • Port: 80

  5. In the Aliases section, click Create to create a new alias.

  6. Enter the following information:

    • Host: internal.company.com

    • Port: 8090

      Accept the default settings for the remaining fields.

  7. Click OK.

    Note:

    It is recommended that you delete your unused sites, so that webcache allows only certain types of URLs.

  8. From the Sites page, in the Site-to-Server Mapping section, click Create.

    The Create Site-to-Server Mapping Definition page is displayed.

  9. Enter the following information in the Create Site-to-Server Mapping section:

    • Host Pattern: www.abc.com

    • Port Pattern: 80

  10. In the Origin Servers section, select internal.company.com:8888 from All Origin Servers, and move it to Selected Origin Servers.

  11. Click OK.

  12. Restart your Oracle Web Cache by selecting Control, and then Restart from the Web Cache Home page in the Oracle Enterprise Manager 11g.

Configuring the Portal Middle Tier to Work with Reverse Proxy Server

Oracle Portal maintains some information related to the URL used to access Portal, you must update the portal middle tier configuration as follows:

  1. Navigate to the Portal Home page in the Enterprise Manager.

  2. From the Portal menu, select Settings, and then Wire Configuration.

    The Portal Wire Configuration page is displayed.

  3. Enter the following information under Portal Middle Tier section in the Portal Wire Configuration page:

    • Published Host Name: www.abc.com

    • Listening Port: 80

  4. Click Apply.

  5. Restart your managed server (WLS_PORTAL).

Configuring the Oracle WebLogic Server to Work with Reverse Proxy Server

You need to configure the HTTP settings for www.abc.com as follows:

  1. Log in to Oracle WebLogic Server Administration Console.

  2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

  3. In the left pane of the Console, expand Environment and select Clusters.

  4. Select the cluster server and, then the HTTP tab.

  5. In the HTTP page enter the following information:

    • Frontend Host: www.abc.com

    • Frontend HTTPPort: 80

  6. Click Save.

  7. Restart your managed server (WLS_PORTAL).

Configuring Loopback to the Internal Server

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

For example, the Oracle Fusion Middleware host for internal.company.com makes requests to itself, but the URLs that it is requesting are referring to www.abc.com. You must create host entries in the local HOSTS file on that machine, allowing it to resolve this name within the firewall, and ensure that you add an entry for the proxy machine in the /etc/hosts file on the database machine. This step is required for the database machine to resolve the address of the proxy machine on the network. The hosts entry for this example in Windows should include the following lines:

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

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

Note:

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

Configuring the osso.conf File

You must configure the osso.conf file as follows:

  1. Run ssoreg.sh located in ORACLE_HOME/sso/bin (Unix) from your Identity Management instance to register the virtual host for which mod_osso facilitates single sign-on.

    The following example shows the usage of ssoreg.sh in UNIX:

    $ORACLE_HOME/sso/bin/ssoreg.sh
      -site_name www.abc.com:80
      -config_mod_osso TRUE 
      -mod_osso_url http://www.abc.com:80 
      -update_mode MODIFY
      -remote_midtier
      -config_file/tmp/osso.conf
    

    On Windows, you must run ssoreg.bat instead.

  2. Back up the osso.conf file.

  3. Copy the osso.conf file to the ORACLE_INSTANCE/config/OHS/ohs1 directory.

Verifying Your Configuration

After completing the configuration procedures, you can verify your configuration now by accessing the Oracle Portal using the proxy host name and port at http://www.abc.com/portal/pls/portal. Hover over the URLs to ensure that they all show up as www.abc.com and not internal.company.com and the port number in the browser should not be 8090 or 8888.

6.7 Managing Oracle Portal Content Cached in Oracle Web Cache

Oracle Web Cache offers caching, page assembly, and compression features. Oracle Web Cache accelerates the delivery of both static and dynamic Web content, and provides load balancing and failover features for Oracle Fusion Middleware. Refer to Section 1.3, "Understanding Caching in Oracle Portal" for an overview of how caching works in Oracle Portal.

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

This section contains the following topics:

6.7.1 Managing Oracle Web Cache

In previous releases, you had to use Oracle Web Cache Manager to configure Oracle Web Cache. In this release you can use Oracle Enterprise Manager 11g Fusion Middleware Control to configure Oracle Web Cache and update the Oracle Web Cache configuration file, webcache.xml. Refer to Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for more information.

6.7.2 Configuring Portal Web Cache Settings Using Oracle Enterprise Manager

Use the Oracle Enterprise Manager 11g Fusion Middleware Control to change Oracle Web Cache settings that Oracle Portal uses, such as the host name, and the invalidation port number. You configure these settings on the Portal Wire Configuration page.

See Also:

Section 8.2.2.6, "Portal Wire Configuration Page" for a detailed description of how to use the Portal Wire Configuration page.

6.7.3 Configuring Portal Web Cache Settings Using WLST

You can use the WLST (Online) command for Portal Web Cache to:

6.7.3.1 Listing the Attributes

To List the attributes of Web Cache configuration used by the Portal repository:

Syntax

listPortalWebcacheConfigAttributes ([dad_name])
Argument Definition
dad_name

Optional. Name of the Database Access Descriptor. Default DAD name is 'portal'.


Example

The following example lists the Web Cache configuration used by the Portal repository. The Web Cache host name to which the invalidation messages are sent, the invalidation user name, password and the invalidation port to which the invalidation messages are sent are listed.

listPortalWebcacheConfigAttributes(dad_name='portal')

---------------
WebCacheConfig
---------------
WebCache Host: foo.oracle.com
WebCache Invalidation Password: invalidator
WebCache Invalidation Port: 6523
WebCache Invalidation User: invalidator

6.7.3.2 Updating the Attributes

To List the attributes of Web Cache configuration used by the Portal repository:

Syntax

setPortalWebcacheConfig([dad_name], [host], [inv_port], [inv_user], [inv_passwd])
Argument Definition
dad_name

Optional. Name of the Database Access Descriptor. Default DAD name is 'portal'.

host

Optional. The name of the Web Cache host to which invalidation messages are sent.

inv_port

Optional. The Web Cache port number to which invalidation messages are sent.

inv_user

Optional. The user name used for sending the invalidation messages.

inv_password

Optional. Web Cache invalidation password.


Example

The following example updates the Web Cache configuration based on the specified values.

setPortalWebcacheConfig(dad_name='portal',host='example.mycompany.com',inv_port='6523',inv_user='invalidator',inv_passwd='invalidator')

6.7.4 Managing Portal Content Cached in Oracle Web Cache

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

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

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

6.7.4.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 Oracle 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 Oracle 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.

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

6.7.5 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 Oracle 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 Oracle Web Cache will introduce a network load, as Oracle Portal communicates with the Oracle 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 Oracle Portal user interface. Refer to Section 6.7.4.1, "Clearing the Entire Web Cache" for information about performing this task.

6.7.6 Managing the Invalidation Message Processing Job

Oracle 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 B.1, "Managing the Invalidation Message Processing Job Using cachjsub.sql" for more information and instructions on how to run cachjsub.sql.

6.8 Configuring Oracle Portal to Use a Dedicated Oracle Web Cache Instance

You can deploy Oracle Web Cache on a dedicated server that front-ends one or more Oracle Portal middle-tier servers. Oracle 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 Oracle Portal" for an overview of how caching works in Oracle Portal.

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

Figure 6-6 Oracle Portal Using a Dedicated Oracle Web Cache Instance

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

6.8.1 Understanding Installation Prerequisites and Requirements

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

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

6.8.2 Configuring a Dedicated Oracle Web Cache

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

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

6.8.2.1 Task 1: Verify That the Oracle Web Cache on the Dedicated Server Is Running

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

6.8.2.2 Task 2: Configure Oracle Web Cache on the Dedicated Server

To properly configure Oracle Web Cache on the dedicated server, you will need the origin server information from the Oracle Web Cache installed on the same computer as Oracle Portal middle tier. To modify the origin server properties setting from the dedicated Oracle Web Cache instance, follow the instructions in section 2.11.2 Task 2: Specify Origin Server Settings, from the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

6.8.2.3 Task 3: Stop the Unused Oracle Web Cache on the Middle-Tier Server

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

6.8.2.4 Task 4: Configure Oracle Portal Middle Tier with Oracle Web Cache Settings

Oracle Portal middle tier needs to know the Oracle 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 Oracle Web Cache to Oracle Portal middle tier by modifying these settings in the Portal Wire Configuration page:

  1. In the Oracle Enterprise Manager 11g, select Portal in the System Components section. The Oracle Portal Home page appears.

  2. Right click Portal, and select Settings > Wire Configuration.

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

  4. On the Portal Wire Configuration page, under Portal Midtier modify the Host field with proper host name: www.company.com, modify the Listening Port field with proper port number 7777.

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

6.8.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 Oracle Portal middle tier, with the dedicated Oracle Web Cache settings. In this example, you will set up virtual host name www.company.com and port number 7777 (same as the dedicated Oracle Web Cache Listen port). The virtual host name and port number must be consistent with the site definition value defined in Oracle Web Cache. To do this, perform the following tasks:

  1. Configure Virtual Hosts Settings, as follows:

    1. Log in to the Oracle Enterprise Manager.

    2. From the Oracle Enterprise Manager home page, expand Web Tier and select the HTTP Server for your instance.

    3. Go to HTTP Server >Administration, and select Virtual Hosts.

    4. Click Create.

    5. On the Create Virtual Host page, provide the information listed in Table 6-3.

      Table 6-3 Virtual Host Information

      Virtual Host Information Value

      Virtual Host Name

      Select Use existing listen address.

      Server Name

      Your Domain name, www.company.com

      Document Root Directory

      ORACLE_INSTANCE\config\OHS\ohs1\htdocs

      Directory Index

      Can be left blank

      Administration E-Mail Address

      Valid e-mail address

      Type

      name-based


    6. Click OK.

      Note:

      Do not restart your Oracle HTTP Server.

  2. After you have configured the virtual host, open the httpd.conf file (located at ORACLE_INSTANCE\config\OHS\ohs1) using a text editor and add the Port and the Rewrite directives in the VirtualHost container, as follows (shown in bold text): syntax:

    NameVirtualHost *:8888
    <VirtualHost *:8888>
          ServerName http://www.company.com:7777
          RewriteEngine On
          RewriteOptions inherit
    </VirtualHost>
    

6.8.2.6 Task 6: Re-Registering the Oracle HTTP Server Partner Application

For information about Re-registering the Oracle HTTP Server Partner application, see Re-register the Oracle HTTP Server Partner Application.

6.9 Changing the Infrastructure Services Used By a Middle Tier

Oracle Portal enables you to change the OracleAS Infrastructure services (either Oracle Identity Management or Oracle 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 Oracle Metadata Repository that your Oracle Portal uses, then you will also need to move application-specific data stored in the stage Oracle Metadata Repository to an Oracle 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 Fusion Middleware Administrator's Guide.

Note:

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

6.10 Configuring the Cluster Environment After Installation

Portal Configuration includes configuring the middle tier in the filesystem and the repository in the database. For post install configuration changes in the cluster environment, you must update and replicate both these types of configurations in each of the nodes.

6.10.1 Middle Tier Configuration

You must update the middle tier (file system) configuration, for each nodes of the cluster configuration. You can update the midtier configuration, by performing one of the following:

Login to the Oracle Enterprise Manager 11g, and perform the following:

  • To change the Portal Cache configuration, from the Portal home page, select Portal, Settings, and then Portal Cache to display the Portal Cache Configuration page. Make the required changes and click Apply. If you want to use the WLST commands, see Configuring the Portal Cache Using WLST.

  • To change the Page Engine configuration, from the Portal home page, select Portal, Settings, and then Page Engine to display the Page Engine Configuration page. Make the required changes and click Apply. If you want to use the WLST commands, see Configuring the Parallel Page Engine Using WLST.

6.10.2 Repository Configuration

You must update the repository configuration (database) only once in a cluster configuration, as the updates are made to the backend Portal schema in the database that is shared by all the nodes of the cluster. However the repository configuration can be run repeatedly for each of the nodes like the midtier configuration. To update the repository configuration. login to the Oracle Enterprise Manager 11g Fusion Middleware Control, and from the Portal menu, select Settings, and then Wire Configuration, to display the Portal Wire Configuration page. Make the required changes and click Apply.

If you want to use WLST commands, see Configuring Oracle Portal Using WLST.

6.11 Configuring OracleAS Wireless

In case of multiple middle-tier installations, the first configured OracleAS Wireless service URL is stored in the Oracle Portal instance. You can change this to your choice of OracleAS Wireless service by running the cfgiasw.pl script. Refer to Section B.7, "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.

6.12 Changing the Oracle Portal Schema Password

This section provides information about changing schema passwords for both default and nondefault Oracle Portals. For information on how to retrieve the Portal schema password, refer to Section 5.6.10, "Retrieving the Portal Schema Password". The Oracle Portal schema password is created when you load the Portal schema through RCU, and is required for some operations where you need to log in to the Portal schema. The Portal schema password is stored in a an LDAP-Based Credential Store. An LDAP-based policy store is specified in the configuration file jps-config.xml with the element serviceInstance, as illustrated in the following example, which shows the specification of an LDAP-base credential store using an Oracle Internet Directory LDAP server:

<serviceInstance name="someInstance" provider="some_ldap_provider">
   ...
   <property name="credstore.type" value="OID"/>
   <property name="ldap.url" value="ldap://someURL"/>
   ...
</serviceInstance>

The default location of the file jps-config.xml is DOMAIN_HOME\config\fmwconfig.

To Change the Oracle Portal Schema Password, perform the following:

6.12.1 Changing the Schema Password for a Default Oracle Portal Instance

For information about changing the Oracle Portal schema password for the default Oracle Portal instance, refer to the section on changing Oracle Metadata Repository schema passwords, in the Oracle Fusion Middleware Administrator's Guide.

Note:

By default, an Oracle Portal middle tier is made up of one portal instance. Both the DAD name and the Oracle Metadata Repository schema name for this instance are portal. The section on changing Oracle Metadata Repository schema passwords in the Oracle Fusion Middleware Administrator's Guide describes how to change the schema password for this default Oracle Portal instance.

6.12.2 Changing the Portal Credentials

You can change the Portal credentials using the following option:

6.12.2.1 Managing Portal Credentials Using Oracle Enterprise Manager

This section explains the steps you follow to manage credentials in a domain credential store with Oracle Enterprise Manager.

  1. Log in to Oracle Enterprise Manager and navigate to WebLogic Domain > Domain Name. Right click Domain Name, and select Security > Credentials, to display the Credentials page.

    The area Credential Store Provider is read-only and, when expanded, displays the credential store provider currently in use in the domain.

    The table below this read-only area allows creating, editing, and searching credentials.

  2. At any point, use the button Delete to remove a selected item (key or map) in the table. Note that deleting a credential map, deletes all keys in it. Similarly, use the button Edit to view or modify the data in a selected item.

  3. To display credentials matching a given key name, enter the string to match in the box Credential Key Name, and then click the blue button to the right of it. The result of the query is displayed in the table.

  4. To redisplay the list of credentials after examining the results of a query, right click Classic Domain and select Security > Credentials.

Create a New Credential Map

To create a new credential map:

  1. Click Create Map to display the Create Map dialog.

  2. In this dialog, enter the name of the map for the credential being created.

  3. Click OK to return to the Credentials page. The new credential map name is displayed with a folder icon in the table.

Add a New Key

To add a new key to a credential map:

  1. Click Create Key to display the Create Key dialog.

  2. In this dialog, select a map from the pull-down list Select Map where the new key will be inserted, enter a key in the text box Key, select a type from the pull-down list Type (the appearance of the dialog changes according to the type selected), enter the required data.

  3. Click OK when finished to return to the Credentials page. The new key is shown under the map icon corresponding to the map you selected.

6.12.2.2 Managing Portal Credentials Using WLST Commands

WLST supports the following online commands to administer credentials:

listCred

The command listCred returns the list of attribute values of a credential in the domain credential store with given map name and key name. This command lists the data encapsulated in credentials of type password only.

Script Mode Syntax

listCred -map mapName -key keyName

Interactive Mode Syntax

listCred(map="mapName", key="keyName")

The meanings of the arguments (all required) are as follows:

  • map specifies a map name (folder).

  • key specifies a key name.

Example

The following invocation returns all the information (such as user name, password, and description) in the credential with map name myMap and key name myKey:

listCred -map myMap -key myKey

updateCred

The command updateCred modifies the type, user name, and password of a credential in the domain credential store with given map name and key name. This command updates the data encapsulated in credentials of type password only.

Script Mode Syntax

updateCred -map mapName 
           -key keyName 
           -user userName 
           -password passW
           [-desc description] 

Interactive Mode Syntax

updateCred(map="mapName", key="keyName", user="userName", password="passW", [desc="description"])   

The meanings of the arguments (optional arguments are enclosed by square brackets) are as follows:

  • map specifies a map name (folder) in the credential store.

  • key specifies a key name.

  • user specifies the credential user name.

  • password specifies the credential password.

  • desc specifies a string describing the credential.

Example

The following invocation updates the user name, password, and description of the password credential with map name myMap and key name myKey:

updateCred -map myMap 
           -key myKey 
           -user myUsr 
           -password myPassw 
           -desc "updated usr name and passw to connect to app xyz"

createCred

The command createCred creates a new credential in the domain credential store with a given map name, key name, user name and password. This command can create a credential of type password only.

Script Mode Syntax

createCred -map mapName 
           -key keyName 
           -user userName 
           -password passW
           [-desc description] 

Interactive Mode Syntax

createCred(map="mapName", key="keyName", user="userName", password="passW", [desc="description"])  

The meanings of the arguments (optional arguments are enclosed by square brackets) are as follows:

  • map specifies the map name (folder) of the new credential.

  • key specifies the key name of the new credential.

  • user specifies the new credential user name.

  • password specifies the new credential password.

  • desc specifies a string describing the new credential.

Example

The following invocation creates a new password credential with the specified data:

createCred -map myMap 
           -key myKey 
           -user myUsr 
           -password myPassw 
           -desc "new passw cred to connect to app xyz"

deleteCred

The command deleteCred removes a credential with given map name and key name from the domain credential store.

Script Mode Syntax

deleteCred -map mapName -key keyName

Interactive Mode Syntax

deleteCred(map="mapName",key="keyName")

Example

  • map specifies a map name (folder).

  • key specifies a key name.

Example

The following invocation removes the credential with map name myMap and key name myKey:

deleteCred -map myMap -key myKey

6.12.3 Changing the Schema Password for a Nondefault Oracle Portal Instance

Typically, you use Fusion Middleware Control to change the Oracle Portal schema password, but in the case of a portal instance whose schema resides outside the Oracle Metadata Repository, you have to change the portal schema password using SQL*Plus.

Follow these steps to change schema passwords directly in the database:

  1. Connect to the database as a user with SYSDBA privileges.

  2. Enter the following command:

    SQL> ALTER USER <schema> IDENTIFIED BY <new_password>;
    

    For example, to change the PORTAL30 schema password to "abc123":

    SQL> ALTER USER PORTAL30 IDENTIFIED BY abc123;
    

After this, you have to update the Database Access Descriptor (DAD) with the new password. Perform the following steps to update the DAD update the attributes of the Portal DAD using the following WLST(online) command:

updatePortalDad (name, [schema], [password], [connect_string], [nls_language])

This will update the portal_dads.conf, and then restart your managed server (WLS_PORTAL).

6.13 Configuring Oracle Portal Using WLST

This section provides information on using WLST as an option for the following Portal configuration:

Note:

You need to restart your managed server after making the configuration changes.

See:

Chapter 8, "Monitoring and Administering Oracle Portal" for performing the task using the Enterprise Manager.

6.13.1 Configuring Portal Middle Tier

You can use the following WLST Online command to updates the Portal repository with the Portal midtier configuration:

Syntax

setPortalMidtierConfig([dad_name], [ohs_host], [ohs_port], [ohs_protocol], [webcache_host], [webcache_inv_user], [webcache_inv_port], [webcache_inv_passwd])
Argument Definition
dad_name

Optional. Name of the Database Access Descriptor. Default DAD name is 'portal'.

ohs_host

Optional. Oracle HTTP Server host name.

ohs_port

Optional. Oracle HTTP Server port number.

ohs_protocol

Optional. Oracle HTTP Server protocol.

webcache_host

Optional. The name of the Web Cache host to which invalidation messages are sent.

webcache_inv_user

Optional. The Web Cache user name used for sending the invalidation messages.

webcache_inv_port

Optional. The Web Cache port number to which invalidation messages are sent.

webcache_inv_passwd

Optional. Web Cache invalidation password.


Example

The following example updates the Portal midtier configuration based on the specified values.

setPortalMidtierConfig(dad_name='portal1',ohs_host='foo.oracle.com',ohs_port='8090',ohs_protocol=false,webcache_host='foo.oracle.com',webcache_inv_user= 'invalidator',webcache_inv_port='6523',webcache_inv_passwd='invalidator')

6.13.2 Configuring Portal Site Attributes

You can use the WLST (Online) command to list the attributes of the portal site configuration:

Syntax

listPortalSiteConfigAttributes ([dad_name])
Argument Definition
dad_name

Optional. Name of the Database Access Descriptor. Default DAD name is 'portal'.


Example

The following example lists the Portal site configuration. Site protocol can be true or false. HTTP is the protocol when site protocol is false and HTTPS is the protocol when the site protocol is true. The site host name and port number are also listed.

listPortalSiteConfigAttributes ([dad_name])

---------------
SiteConfig
---------------
Site Protocol: false
Site Host: foo.oracle.com
Site Port: 8090

6.13.3 Configuring Portal Oracle Internet Directory Attributes

You can use the WLST(Online) command to list and update the attributes of the Oracle Internet Directory configuration:

6.13.3.1 Listing the Attributes

To list the attributes of the Oracle Internet Directory configuration, do the following:

Syntax

listPortalOIDConfigAttributes ([dad_name])
Argument Definition
dad_name

Optional. Name of the Database Access Descriptor. Default DAD name is 'portal'.


Example

The following example lists the Oracle Internet Directory data, which includes the Oracle Internet Directory host name and port number.

listPortalOIDConfigAttributes(dad_name='portal1')
listPortalOIDConfigAttributes('portal1')
 
---------------
OidConfig
---------------
OID Port: 13060
OID Host: foo.oracle.com

6.13.3.2 Updating the Attributes

To update the attributes of the Oracle Internet Directory configuration, do the following:

Syntax

setPortalOIDConfig ([dad_name], [host], [port], [protocol], [admin_user], [admin_passwd])
Argument Definition
dad_name

Optional. Name of the Database Access Descriptor. Default DAD name is 'portal'.

host

Optional. Oracle Internet Directory host name.

port

Optional. Oracle Internet Directory port number.

protocol

Optional. Oracle Internet Directory protocol.

admin_user

Optional. Oracle Internet Directory administrator's name.

admin_passwd

Optional. Oracle Internet Directory administrator's password.


Example

The following example updates the OID configuration based on the specified values.

setPortalOIDConfig(dad_name='portal1',host='foo.oracle.com',port='13060',protocol=false,admin_user='cn=orcladmin',admin_passwd='oracle1')