6 Advanced Configuration

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.

   
   

   See Also: Oracle Fusion Middleware Installation Planning Guide

   
   

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:7777/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 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 following syntax 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 8093, 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 4001 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. Copy the osso.conf file to the ORACLE_INSTANCE/config/OHS/ohs1 directory.

12. 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 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 MW_HOME\user_projects\domains\<DomainName>\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):

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: m1.abc.com

   • Port: The WebLogic Administration port number. The default is 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. This file does not exist if you have not saved the file during M1 installation. In this scenario, click View\Edit File and edit the file as follows:

   This port indicates the Domain port noDomain Port No = 7001
   [OHS]
   Oracle HTTP Server Port No = 8888 
   [WEBCACHE]
   Oracle WebCache Port No = 8090
   Oracle WebCache Invalidation Port No = 8093
   [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 MW_HOME\user_projects\domains\<DomainName>\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 following syntax 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. Refer to Section E.1.3, "Configuring HTTP or HTTPS Proxy Settings" for more information. Propagate the changes made to the provider.xml file to middle tier M2:

   • Copy MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet\provider.xml from M1 to M2.

   • Copy MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\tr7qwp\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 MW_HOME\user_projects\domains\<Domain Name>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\kjdcke\war\WEB-INF and copy deployment, deployment_providerui, and providers folders from M1 to M2.

   2. Copy the MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\kjdcke\war\WEB-INF\deployment_providerui\provideruiacls.xml file from M1 to M2.

   3. Change the <warDir> element 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.

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 one of the following mechanisms:

      Cookie-based: Select if the client supports cookies. Oracle Web Cache uses its own cookie to track a session. This cookie, which contains routing information, is maintained between Oracle Web Cache and the client browser.

      Internal-tracking: Select if the client does not support cookies and the application is not based on Oracle HTTP Server and WLS. This option is intended for backward compatibility with earlier releases of Oracle Web Cache. Oracle Web Cache maintains an in-memory routing table, of which each entry maps a session ID to an origin server. The routing table is not shared among cluster nodes. If you select this option and you have a cache cluster configuration, then you must bind at the load balancer layer.

      Session Binding IAS: Select if the application is based on WLS. Oracle Web Cache forwards routing information with each request to WLS through Oracle HTTP Server.

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

• Create the Virtual Host for www.xyz.com

• Create the Virtual Host for www.abc.com

Once you have finished this step, do the following:

1. Verify the httpd.conf File

2. Verify That the Virtual Hosts Are Configured Correctly

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.

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 file osso.conf. ssoreg 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 [email protected]
      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.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 11g Fusion Middleware Control

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.

6.7.3 Configuring Portal Web Cache Settings Using WLST

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

• Listing the Attributes

• Updating the Attributes

listPortalWebcacheConfigAttributes ([dad_name])

dad_name

listPortalWebcacheConfigAttributes(dad_name='portal1')

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

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

dad_name

host

inv_port

inv_user

inv_password

setPortalWebcacheConfig(dad_name='portal1',host='foo.oracle.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.

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:

• Clearing the Entire Web Cache

• Clearing the Cache for a Particular User

• Setting the Expiry Time for Invalidation-based Caching

• Clearing the Cache for a Particular Portal Object

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.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 J2EE and Web Cache middle tier on the dedicated server.

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

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:

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

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

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

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

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

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

6.12.2 Changing the Portal Credentials

You can change the Portal credentials using the following option:

• Managing Portal Credentials Using Oracle Enterprise Manager

• Managing Portal Credentials Using WLST Commands

listCred -map mapName -key keyName

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

listCred -map myMap -key myKey

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

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

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

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

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

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

deleteCred -map mapName -key keyName

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

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.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])

dad_name

ohs_host

ohs_port

ohs_protocol

webcache_host

webcache_inv_user

webcache_inv_port

webcache_inv_passwd

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

dad_name

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:

listPortalOIDConfigAttributes ([dad_name])

dad_name

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

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

dad_name

host

port

protocol

admin_user

admin_passwd

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