Click Apply Changes on the top of the page. Perform the following steps in the Cache Operations page:

a. Click Propagate to propagate changes to APPHOST4.

b. Click Restart to restart Web Caches on APPHOST3 and APPHOST4.

13. Configure the Load Balancing Router (internal.mycompany.com) to forward requests on the invalidation port to OracleAS Web Cache on the second middle tier apphost4.mycompany.com on port 9401 (similar to the previous configuration on the first middle tier apphost3.mycompany.com).

14. Configure the Load Balancing Router (internal.mycompany.com) to forward requests on port 80 to OracleAS Web Cache on apphost2.mycompany.com on port 7777 (similar to the previous configuration on the first middle tier

apphost3.mycompany.com).

15. Configure the Load Balancing Router to perform Network Address Translation (NAT) bounce back for loopback requests coming from Oracle HTTP Server on apphost4.mycompany.com. Refer to Step 6 in "Configuring the First Internal Middle Tier on APPHOST3 for Load Balancing Router Access" for more information.

Note: Refer to the section "Map Sites to Origin Servers" in the Oracle Application Server Web Cache Administrator’s Guide, for more

information.

Notes: This procedure load balances invalidations sent from the OracleAS Metadata Repository to the internal Web Cache instances. If high availability is a concern, then the Load Balancing Router may be configured to load balance to both the internal and external Web Cache instances. However, the internal Web Cache instances should be given a member priority of 1 and the external Web Cache instances a member priority of 2. The Minimum Active Members should be set to 1. With this configuration, the Load Balancing Router will load balance across the internal Web Cache instances first, and only load balance to an external Web Cache instance if all internal Web Cache instances are unavailable.

The Load Balancing Router does not have to listen on the OracleAS Web Cache invalidation port. On Load Balancing Routers that do not have port mapping ability, the port number must match the OracleAS Web Cache invalidation port.

Note: Use the Load Balancing Router documentation to complete this step.

16. To enable monitoring of the Load Balancing Router's front-end host and port settings for OracleAS Portal, you must edit the ORACLE_

HOME/sysman/emd/targets.xml file on APPHOST4, as follows:

a. Open the targets.xml file, using a text editor.

b. Locate the OracleAS Portal targets (that is, TYPE="oracle_portal").

c. Edit the PortalListeningHostPort property, to point to the Load Balancing Router. For example:

<Property NAME="PortalListeningHostPort"

VALUE=http://internal.mycompany.com:80/>

d. Save the changes to targets.xml.

e. Reload the targets in the Application Server Control Console by issuing this command in ORACLE_HOME/bin/:

emctl reload

17. To verify if the internal middle tiers have been configured to work with the internal Load Balancing Router, you must perform the following steps:

a. Ensure that you can telnet to the listen and invalidation ports on the internal Load Balancing Router. To do this, leave APPHOST3 running and stop APPHOST4. Verify that you are able to contact port 80 on

internal.mycompany.com from the intranet and specifically, from the infrastructure database computer(s), APPDBHOST*.mycompany.com. The command to check this is:

telnet internal.mycompany.com 80

Ensure that no connection failure message is returned. Verify that the invalidation port can be reached in the same manner from the APPDB computer(s). The command used to check this is:

telnet internal.mycompany.com 9401 Perform the following tests:

Note: You can add more middle tiers by repeating the procedures in "Installing the Second Internal Middle Tier on APPHOST4" on page 9-5 and "Configuring the Second Internal Middle Tier on APPHOST4 for Load Balancing Router Access" on page 9-15, for each additional middle tier.

Note: This procedure load balances invalidations sent from the OracleAS Metadata Repository to the internal Web Cache instances. If high availability is a concern, then the Load Balancing Router may be configured to load balance to both the internal and external Web Cache instances. However, the internal Web Cache instances should be given a member priority of 1 and the external Web Cache instances a member priority of 2. The Minimum Active Members should be set to 1. With this configuration, the Load Balancing Router will load balance across the internal Web Cache instances first, and only load balance to an external Web Cache instance if all internal Web Cache instances are unavailable.

– Access OracleAS Web Cache and Oracle HTTP Server through the LBR using the following URL:

http://internal.mycompany.com

– Test the connection to the OracleAS Metadata Repository through the LBR, by accessing the following URL:

http://internal.mycompany.com/pls/portal/htp.p?cbuf=test The response should be test. If this succeeds, then the Oracle Applica-tion Server middle tier can connect to the OracleAS Metadata Repository.

If this test fails, then examine the Oracle HTTP Server ORACLE_

HOME/Apache/Apache/logs/error_log file to determine the cause.

b. Repeat the preceding steps with APPHOST3 stopped and APPHOST4 running.

9.1.7 Registering the Internal Middle Tier as a Partner Application

For the single sign-on component to work properly, it must always be referenced by a partner application with the same host name in the URL. This is because cookies are sent back only to the host that generated them. For example the Oracle Application Server Single Sign-On components must always be referenced as

http://login.mycompany.com.

You must register internal.mycompany.com as a partner application. To do this, perform the following steps from an external middle tier, APPHOST1:

1. Add a partner application entry for internal.mycompany.com by executing the script OH/portal/conf/ptlconfig, as follows:

ptlconfig -dad portal -sso -host internal.mycompany.com -port 80

2. Edit the SSO registration script ORACLE_HOME/sso/bin/ssoreg as shown in Example 9–2, and then execute it. Example 9–2 shows the usage of ssoreg.sh on UNIX; on Windows, the script name is ssoreg.bat.

Example 9–2 ssoreg Usage on UNIX ORACLE_HOME/sso/bin/ssoreg.sh -site_name internal.mycompany.com

-mod_osso_url https://internal.mycompany.com -config_mod_osso TRUE

-oracle_home_path ORACLE_HOME

-config_file ORACLE_HOME/Apache/Apache/conf/osso/osso.conf -admin_info cn=orcladmin

To verify whether the internal middle tier has been registered as a partner application, ensure that you can log in to the Portal at http://internal.mycompany.com.

Note: The script shown in Example 9–2 has multiple lines for readability only. When you execute the script, all parameters are on a single continuous line.

9.1.8 Updating the Default JPDK Instance URL and Seeded Provider Group URLs

The Default JPDK Instance URL determines the middle tier on which a web provider is created. In this configuration, web providers must be created in the external middle tier.

Follow these steps to set the URL:

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

2. Click the Administer tab.

3. Click the Portal tab.

4. Click Global Settings in the Services portlet.