6 Extending the Domain for WebCenter Components

6.1 Installing Oracle Fusion Middleware Home

You must install Oracle Fusion Middleware on WCHOST1 and WCHOST2. These nodes will run managed servers configured with WebCenter components.

Follow the steps in Section 4.1, "Installing Oracle Fusion Middleware Home". You must install both Oracle WebLogic Server and WebCenter.

6.2 Extending the Domain for WebCenter Components

In this step, you extend the domain created in Chapter 4, "Creating a Domain" to contain WebCenter components.

1. Change directory to the location of the Configuration wizard. This is within the WebCenter home directory.

   SOAHOST1> cd MW_HOME/wc/common/bin
   

2. Start the Configuration Wizard.

   SOAHOST1> ./config.sh
   

   Note:

   If you run the Configuration Wizard from the same shell and environment that you used to create the domain, you must deselect the CONFIG_JVM_ARGS=-DTemplateCatalog.enable.selectable.all=true variable. Otherwise, the Configuration Wizard displays all of the available templates, which are not needed for extending the domain for WebCenter components.

3. In the Welcome screen, select Extend an existing WebLogic domain, and click Next.

4. In the WebLogic Domain Directory screen, Select the WebLogic domain directory (ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>), and click Next.

5. In the Select Extension Source screen, do the following:

   • Select Extend my domain automatically to support the following added products.

   • Select the following products:

     • Oracle WebCenter Spaces

     • Oracle Portlet Producers

     • Oracle WebCenter Discussions Server

     • Oracle WebCenter Activity Graph Engines

     • Oracle WebCenter Personalization

     • Oracle Webcenter Analytics Collector

     • Oracle WebCenter Pagelet Producer

     The following products should already be selected, and grayed out. They were selected when you created in domain in Section 4.4, "Running the Configuration Wizard on SOAHOST1 to Create a Domain."

     • Basic WebLogic Server Domain

     • JRF

     • WSM-PM

   Click Next.

6. If you get a "Conflict Detected" message that Oracle JRF is already defined in the domain, select the Keep Existing Component option and click OK.

7. In the Configure JDBC Data Sources screen, do the following:

   1. Ensure that the following data sources appear on the screen. The user names shown in Table 6-1 assume that wcedg was used as prefix for schema creation from RCU.

      Table 6-1 Values for Data Sources

      Data Source	User Name
      ActivitiesDS Schema	wcedg_activities
      DiscussionDS Schema	wcedg_discussions
      PersonalizationDS Schema	wcedg_webcenter
      PortletDS Schema	wcedg_portlet
      WebCenter DS Schema	wcedg_webcenter
      WebCenter MDS Schema	wcedg_mds
      Personalization MDS Schema	wcedg_mds
      mds-PageletProducerDS Schema	wcedg_mds

      
      

   2. Select the check box next to all the component schemas.

   3. Select Configure all datasources as RAC multi-datasources in the next panel.

   4. Click Next.

8. Configure RAC Multi Data Sources screen

   1. Enter values for the following fields, specifying the connect information for the RAC database that was seeded with RCU.

      • Driver: Select Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11.

      • Service Name: Enter the service name of the database, for example, wcedg.mycompany.com.

      • Username prefix: Enter the user name for each of the schemas by selecting each schema individually. The user names shown in Table 6-1 assume that wcedg was used as prefix for schema creation from RCU.

      • Password and Confirm Password: enter the password to use to access the schemas.

   2. Click Add and enter the details for the first RAC instance.

   3. Repeat for each RAC instance.

   4. Click Next.

9. In the Test JDBC Data Sources screen, the connections should be tested automatically. The Status column displays the results. Ensure that all connections were successful. If not, click Previous to return to the previous screen and correct your entries.

   Click Next when all the connections are successful.

10. In the Advanced Configuration Screen, select the following:

    • Managed Servers, Clusters and Machines

    • Deployments and Services

    Click Next.

11. In the Configure Managed Servers screen, add the following managed servers:

    Table 6-2 Managed Servers

    Name	Server	Listen Port	SSL Listen Port	SSL Enabled
    WC_Spaces1	WCHOST1	9000	n/a	No
    WC_Spaces2	WCHOST2	9000	n/a	No
    WC_Portlet1	WCHOST1	9001	n/a	No
    WC_Portlet2	WCHOST2	9001	n/a	No
    WC_Collaboration1	WCHOST1	9002	n/a	No
    WC_Collaboration2	WCHOST2	9002	n/a	No
    WC_Utilities1	WCHOST1	9003	n/a	No
    WC_Utilities2	WCHOST2	9003	n/a	No

    
    

    Note:

    Managed Servers may be renamed here but DO NOT remove any of the original Managed Servers on this page.

    Note:

    Providing the listen address is mandatory if the cluster mode is 'unicast'.

    Click Next.

12. The Configure Clusters screen should already include the WSM_PM Cluster in the list. Add the following three new clusters:

    Table 6-3 Clusters

    Name	Cluster Messaging Mode	Multicast Address	Multicast Port	Cluster Address
    Spaces_Cluster	unicast	n/a	n/a	Leave it empty.
    Portlet_Cluster	unicast	n/a	n/a	Leave it empty.
    Collab_Cluster	unicast	n/a	n/a	Leave it empty.
    Utilities_Custer	unicast	n/a	n/a	Leave it empty.

    
    

    Click Next.

13. In the Assign Servers to Clusters screen, assign servers to clusters as follows:

    • Spaces_Cluster:

      • WC_Spaces1

      • WC_Spaces2

    • Portlet_Cluster:

      • WC_Portlet1

      • WC_Portlet2

    • Collab_Cluster:

      • WC_Collaboration1

      • WC_Collaboration2

    • Utilities_Cluster:

      • WC_Utilities1

      • WC_Utilities2

    Click Next.

14. In the Configure Machines screen, click the Unix Machine tab. Make sure the following four entries exist:

    Table 6-4 Machines

    Name	Node Manager Listen Address
    SOAHOST1	SOAHOST1 Note that SOAHOST1 should already be configured when you ran the Configuration wizard in Section 4.4, "Running the Configuration Wizard on SOAHOST1 to Create a Domain."
    SOAHOST2	SOAHOST2 Note that SOAHOST2 should already be configured when you ran the Configuration wizard in Section 4.4, "Running the Configuration Wizard on SOAHOST1 to Create a Domain."
    WCHOST1	WCHOST1
    WCHOST2	WCHOST2

    
    

    Leave all other fields to their default values.

    Click Next.

15. In the Assign Servers to Machines screen, assign servers to machines as follows:

    • SOAHOST1:

      • AdminServer

      • WLS_WSM1

    • SOAHOST2:

      • WLS_WSM2

    • WCHOST1:

      • WC_Spaces1

      • WC_Portlet1

      • WC_Collaboration1

      • WC_Utilities1

    • WCHOST2:

      • WC_Spaces2

      • WC_Portlet2

      • WC_Collaboration2

      • WC_Utilities2

        Note:

        You can rename the originals servers, which appear by default in the Configuration Wizard, but never delete them.

    Click Next.

16. In the Target Deployment to Clusters or Servers screen, click Next.

17. In the Target Services to Clusters or Servers screen, click Next.

18. In the Configuration Summary screen, do not change the values that appear on the screen (since you are extending a domain). Click Extend.

19. In the Extending Domain screen, click Done.

6.3 Restarting the Administration Server

Restart the Administration Server so that the changes to the domain are picked up.

1. Stop the Administration Server.

   SOAHOST1> ./stopWebLogic.sh
   

2. Start the Administration Server:

   SOAHOST1> ./startWebLogic.sh
   

6.4 Disabling Host Name Verification for the WebCenter Managed Servers

Before you can start and verify the managed servers, you must disable host name verification. You can re-enable it after you set up SSL communication between the Administration Server and the Node Manager.

To disable host name verification, complete these steps:

1. Expand the Environment node in the Oracle WebLogic Server Administration Console.

2. Select Servers. The Summary of Servers page appears.

3. Select WC_Spaces1 (represented as a hyperlink) from the Names column of the table. The Settings page appears.

4. Select the SSL tab.

5. Expand the Advanced section of the page.

6. Set Hostname Verification to None.

7. Repeat these steps for the WC_Spaces2, WC_Portlet1, WC_Portlet2, WC_Collaboration1, WC_Collaboration2, WC_Utilities1, and WC_Utilities2 managed servers.

6.5 Starting Node Manager on SOAHOST1

Make sure that Node Manager was started on SOAHOST1. If this is not the case, start Node Manager:

SOAHOST1> cd WL_HOME/server/bin
SOAHOST1> ./startNodeManager.sh

6.6 Propagating the Domain Changes to the Managed Server Domain Directory

As described in Section 2.3.2, "Directory Structure," we need to separate the Administration Server domain directory from the managed server directories. In this step, we propagate the changes from one to the other. To propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory, complete these steps:

1. Create a copy of the managed server domain directory and the managed server applications directory.

2. Move these directories using the following command (both commands :

   mv ORACLE_BASE/admin/<domain_name>/mserver/apps ORACLE_BASE/admin/<domain_name>/mserver/appsbackup
   
   mv ORACLE_BASE/admin/<domain_name>/mserver/<domain_name> ORACLE_BASE/admin/<domain_name>/mserver/>domain_name>backup
   

3. Run the pack command on SOAHOST1 to create a template pack using the following commands:

   SOAHOST1> cd MW_HOME/wc/common/bin
   
   SOAHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/admin/<domain_name>/aserver/<domain_name> -template=wcdomaintemplateExtWC.jar -template_name=wc_domain_templateExtWC
   

4. Run the unpack command on SOAHOST1 to unpack the propagated template to the domain directory of the managed server using the following command:

   SOAHOST1> ./unpack.sh -domain=ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/ -template=wcdomaintemplateExtWC.jar -overwrite_domain=true -app_dir=ORACLE_BASE/admin/<domain_name>/mserver/apps
   

6.7 Propagating the Domain Configuration to SOAHOST2, WCHOST1, and WCHOST2 Using the unpack Utility

To propagate the domain configuration, complete these steps:

1. Run the following commands on SOAHOST1 to copy the template file created earlier to SOAHOST2, WCHOST1, and WCHOST:

   SOAHOST1> scp wcdomaintemplate.jar
          oracle@SOAHOST2:MW_HOME/wc/common/bin
   

   SOAHOST1> scp wcdomaintemplate.jar
          oracle@WCHOST1:MW_HOME/wc/common/bin
   

   SOAHOST1> scp wcdomaintemplate.jar
          oracle@WCHOST2:MW_HOME/wc/common/bin
   

2. Run the unpack command on SOAHOST2, WCHOST1, and WCHOST2 to unpack the propagated template.

   SOAHOST2> cd MW_HOME/wc/common/bin
   
   SOAHOST2> ./unpack.sh
      -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/   -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications 
   

3. Repeat the above steps for WCHOST1 and WCHOST2.

6.8 Starting the Node Manager on WCHOST1 and WCHOST2

To start the Node Manager on WCHOST1 and WCHOST2, follow these steps:

1. Run the setNMProps.sh script, located in the ORACLE_COMMON_HOME/common/bin directory, to set the StartScriptEnabled property to 'true' before starting Node Manager on both WCHOST1 and WCHOST2:

   WCHOSTn> cd ORACLE_COMMON_HOME/common/bin
   WCHOSTn> ./setNMProps.sh
   

2. Start Node Manager:

   WCHOST1> cd WL_HOME/server/bin
   WCHOST1> ./startNodeManager.sh
   
   WCHOST2> cd WL_HOME/server/bin
   WCHOST2> ./startNodeManager.sh
   

6.9 Starting the WC_Spaces1, WC_Portlet1, and WC_Collaboration1 Managed Servers on WCHOST1

Follow these steps to start the WC_Spaces1, WC_Portlet1, and WC_Collaboration1 managed servers:

1. Access the Administration Console at http://ADMINVHN:7001/console.

2. Click Servers.

3. Open the Control tab.

4. Select WC_Spaces1, WC_Portlet1, and WC_Collaboration1.

5. Click Start.

6.10 Validating the WC_Spaces1, WC_Portlet1, and WC_Collaboration1 Managed Servers

1. Check that the managed servers are accessible by testing the following URLs:

   • http://WCHOST1:9000/webcenter

   • http://WCHOST1:9001/portalTools

   • http://WCHOST1:9002/owc_discussions

   • http://WCHOST1:9001/wsrp-tools

2. Check that all deployments are active. In the Administration Console, select Deployments. If any failed, check the log files for any errors. The log files can be found at ORACLE_BASE/admin/<domain_name>/mserver/<domain_home/servers/[server_name]/logs.

6.11 Starting the WC_Spaces2, WC_Portlet2, and WC_Collaboration2 Managed Servers on WCHOST2

Follow these steps to start the WC_Spaces2, WC_Portlet2, and WC_Collaboration2 managed servers:

1. Access the Administration Console at http://ADMINVHN:7001/console.

2. Click Servers.

3. Open the Control tab.

4. Select WC_Spaces2, WC_Portlet2, and WC_Collaboration2.

5. Click Start.

6.12 Validating the WC_Spaces2, WC_Portlet2, and WC_Collaboration2 Managed Servers

1. Check that the managed servers are accessible by testing the following URLs:

   • http://WCHOST1:9000/webcenter

   • http://WCHOST1:9001/portalTools

   • http://WCHOST1:9002/owc_discussions

   • http://WCHOST1:9001/wsrp-tools

2. Check that all deployments are active. In the Administration Console, select Deployments. If any failed, check the log files for any errors. The log files can be found at ORACLE_BASE/admin/<domain_name>/mserver/<domain_home/servers/[server_name]/logs.

6.13 Setting Up the Java Object Cache

The Java Object Cache (JOC) should be configured among all the servers running WebCenter Spaces. This local cache is provided to increase the performance of Oracle WebCenter Spaces.

The Java Object Cache can be configured using the MW_HOME/oracle_common/bin/configure-joc.py script. This is a Python script which can be used to configure JOC in the managed servers. The script runs in WLST online mode and expects Administration Server to be up and running.

Usage

1. Connect to the Administration Server using the command-line Oracle WebLogic Scripting Tool (WLST), for example:

   MW_HOME/wc/common/bin/wlst.sh
   $ connect()
   

   Enter the Oracle WebLogic Administration user name and password when prompted.

2. After connecting to the Administration Server using wlst, start the script using the execfile command, for example:

   wls:/mydomain/serverConfig>execfile('FMW_HOME/oracle_common/bin/configure-joc.py')
   

3. Configure JOC for all the managed servers for a given cluster.

   Enter 'y' when the script prompts whether you want to specify a cluster name, and also specify the cluster name and discover port, when prompted. This discovers all the managed servers for the given cluster and configure the JOC. The discover port is common for the entire JOC configuration across the cluster. For example:

   Do you want to specify a cluster name (y/n) <y>
   Enter Cluster Name : Spaces_Cluster
   Enter Discover Port : 9988
   

   Here is a walkthrough for using configure-joc.py for HA environments:

   execfile('MW_HOME/oracle_common/bin/configure-joc.py')
   .
   Enter Hostnames (eg host1,host2) : WCHOST1, WCHOST2
   .
   Do you want to specify a cluster name (y/n) <y>y
   .
   Enter Cluster Name : Spaces_Cluster
   .
   Enter Discover Port : 9988
   .
   Enter Distribute Mode (true|false) <true> : true
   .
   Do you want to exclude any server(s) from JOC configuration (y/n) <n> n
   

The script can also be used to perform the following JOC configurations:

• Configure JOC for all specified managed servers.

  Enter 'n' when the script prompts whether you want to specify a cluster name, and also specify the managed server and discover port, when prompted. For example:

  Do you want to specify a cluster name (y/n) <y>n
  Enter Managed Server and Discover Port (eg WC_Spaces1:9988, WC_Spaces2:9988) : WC_Spaces1:9988,WC_Spaces2:9988
  

• Exclude JOC configuration for some managed servers.

  The script allows you to specify the list of managed servers for which the JOC configuration "DistributeMode" will be set to 'false'. Enter 'y' when the script prompts whether you want to exclude any servers from JOC configuration, and enter the managed server names to be excluded, when prompted. For example:

  Do you want to exclude any server(s) from JOC configuration (y/n) <n>y
  Exclude Managed Server List (eg Server1,Server2) : WC_Spaces1,WC_Spaces3
  

• Disable the distribution mode for all managed servers.

  The script allows you to disable the distribution to all the managed servers for a specified cluster. Specify 'false' when the script prompts for the distribution mode. By default, the distribution mode is set to 'true'.

Verify JOC configuration using the CacheWatcher utility. See Oracle Fusion Middleware High Availability Guide.

You can configure the Java Object Cache (JOC) using the HA Power Tools tab in the Oracle WebLogic Administration Console as described in the Oracle Fusion Middleware High Availability Guide.

6.14 Converting Discussions Forum from Multicast to Unicast

To convert Discussions Forum from multicast to unicast, add the relevant startup parameters:

1. In the Oracle WebLogic Server Administration Console, select Servers, WC_Collaboration1, Configuration, and then Server Start.

2. In the Arguments box, add the following:

   -Dtangosol.coherence.wka1=WCHost1  -Dtangosol.coherence.wka2=WCHost2
   -Dtangosol.coherence.localhost=WCHost1 -Dtangosol.coherence.wka1.port=8089
   -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.localport=8089
   

   Where WCHost1 is where WC_Collaboration1 is running.

   Port 8089 is a port reserved for WebCenter Coherence communications.

3. Repeat steps 1 and 2 for WC_Collaboration2, swapping WCHost1 for WCHost2 and WCHost2 for WCHost1.

4. Restart the WC_Collaboration servers.

6.15 Configuring Clustering for Discussions Server

If this is a Unicast cluster, first ensure that the steps in Section 6.14, "Converting Discussions Forum from Multicast to Unicast" are performed first.

Ensure that all members of the Discussions Server cluster can communicate with each other using the Discussions Server Administration Console:

1. Login to each member of the cluster at:

   http://<host>:<port>/owc_discussions/admin

2. Go to Cache Settings.

   Figure 6-1 Cache Settings Section

   
   Description of "Figure 6-1 Cache Settings Section"
   
   

3. At the bottom of the page, in the Cache Features section, ensure that Clustering is set to Enabled.

   The top of the page should now list all members of the cluster.

4. Again, towards the end of the page, under the Cache Tools section, do Cluster wide cache reset and the Cache warm up Task. Repeat the Cache warm up task on all members of the cluster.

   Figure 6-2 Cache Tools Section

   
   Description of "Figure 6-2 Cache Tools Section"
   
   

6.16 Configuring the Analytics Collectors

The Analytics Collectors must be configured to communicate with WebCenter Spaces. Each Collector is configured to only communicate with the local WebCenter Spaces in a 1-1 relationship.

6.17 Configuring Activity Graph

Activity Graph should run as a singleton. In a cluster environment, all but one instance of Activity Graph should be disabled.

To disable Activity Graph:

1. Log in to the Administration Console.

2. Shut down the WC_Spaces and WC_Utilities servers.

3. Select Deployments

4. Click Lock & Edit.

5. Alter the targets for these three deployments:

   • activitygraph-engines (11.1.1.4.0)

   • oracle.webcenter.activitygraph.enginelib (11.1.1,11.1.1)

   • oracle.webcenter.activitygraph.lib (11.1.1,11.1.1)

6. For each of the deployments above:

   1. Select the deployment.

   2. Select the Targets tab.

   3. Click Change Targets.

   4. Ensure that the deployment is only targeted to Part of the Cluster/one of the Managed Servers.

   5. Click OK to save the changes.

7. When finished with all three deployments, Activate all Changes.

8. Start up the WC_Utilities and WC_Spaces servers.

Since Activity Graph is only running on one node, if this node is lost, or the Managed Server is not available, Activity Graph will be unavailable.

In the case of node failure, Activity Graph can be manually deployed on any other available Managed Server in the cluster.

6.18 Configuring WebCenter REST APIs

Before you use the WebCenter REST APIs, you must perform the server-side configurations described in this section.

1. Connect to the Administration Server using the command-line Oracle WebLogic Scripting Tool (WLST), for example:

   MW_HOME/wc/common/bin/wlst.sh
   

2. Run the following WLST commands to configure the credential store:

   createCred(map="o.webcenter.jf.csf.map", key="keygen.algorithm", 
        user="keygen.algorithm", password="AES") 
   createCred(map="o.webcenter.jf.csf.map", key="cipher.transformation", 
        user="cipher.transformation", password="AES/CBC/PKCS5Padding")
   

For more information on REST APIs, see the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.

6.19 Configuring Oracle HTTP Server for the WC_Spacesn, WC_Portletn, and WC_Collaborationn Managed Servers on WCHOST2

To enable Oracle HTTP Server to route to the WebCenter clusters, you must set the WebLogicCluster parameter to the list of nodes in the cluster. Add the following lines to the OHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.conf file on all WEBHOST machines. Keep any previous configuration for the Admin and SOA Servers. Restart all HTTP Servers when finished.

# Virtual Host for wc.mycompany.com holds all the external URLs. The Virtual Host should already exist
# and any existing Location blocks should be kept.
 
NameVirtualHost *:7777 
 <VirtualHost *:7777>
     ServerName https://wc.mycompany.com:443 
     ServerAdmin you@your.address 
     RewriteEngine On
     RewriteOptions inherit

# Spaces
<Location /webcenter>
     WebLogicCluster wchost1:9000,wchost2:9000
     SetHandler weblogic-handler
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

<Location /webcenterhelp>
     WebLogicCluster wchost1:9000,wchost2:9000
     SetHandler weblogic-handler
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

 <Location /rss>
     WebLogicCluster wchost1:9000,wchost2:9000
     SetHandler weblogic-handler
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

 <Location /rest>
     WebLogicCluster wchost1:9000,wchost2:9000
     SetHandler weblogic-handler
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

# Portlet

 <Location /portalTools>
     WebLogicCluster wchost1:9001,wchost2:9001
     SetHandler weblogic-handler
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

 <Location /wsrp-tools>
     WebLogicCluster wchost1:9001,wchost2:9001
     SetHandler weblogic-handler
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

# Discussions
 <Location /owc_discussions>
     WebLogicCluster wchost1:9002,wchost2:9002
     SetHandler weblogic-handler
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

# Personalization

 <Location /wcps>
     WebLogicCluster wchost1:9001,wchost2:9001
     SetHandler weblogic-handler
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

#Activity Graph
#The WebLogicHost below should be set to the Host on which ActivityGraph is running.

 <Location /activitygraph-engines>
     WebLogicHost wchost1
     WebLogicPort 9003
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>
</VirtualHost>

# Virtual host entry for internal http URL. This should already be in the config file. The new Location blocks go inside of it

NameVirtualHost *:7777 

 <VirtualHost *:7777>
     ServerName wcinternal.mycompany.com:80 
     ServerAdmin you@your.address 
     RewriteEngine On
     RewriteOptions inherit

# Portlet Internal access

<Location /portalTools>
     WebLogicCluster wchost1:9001,wchost2:9001
     SetHandler weblogic-handler
</Location>

<Location /wsrp-tools>
     WebLogicCluster wchost1:9001,wchost2:9001
     SetHandler weblogic-handler
</Location>

# Discussions Internal access
<Location /owc_discussions>
     WebLogicCluster wchost1:9001,wchost2:9002
     SetHandler weblogic-handler
</Location>
</VirtualHost>

The servers specified in the WebLogicCluster parameter are only important at startup time for the plug-in. The list needs to provide at least one running cluster member for the plug-in to discover other members of the cluster. Note that the listed cluster member must be running when Oracle HTTP Server is started. Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.

Some example scenarios:

• Example 1: If you have a two-node cluster and then add a third member, you do not need to update the configuration to add the third member. The third member will be discovered on the fly at runtime.

• Example 2: You have a three-node cluster but only two nodes are listed in the configuration. However, if both listed nodes are down when you start Oracle HTTP Server, then the plug-in would fail to route to the cluster. You must ensure that at least one of the listed nodes is running when you start Oracle HTTP Server.

  If you list all members of the cluster, then you guarantee you can route to the cluster, assuming at least one member is running when Oracle HTTP Server is started.

For more information on configuring the WebLogic Server plug-in, see the Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server guide.

<VirtualHost *:7777>
  ServerName pagelet-producer.example.com
  <Location  />
      SetHandler weblogic-handler
      WebLogicCluster wchost1:9000,wchost2:9000
  </Location>
</VirtualHost>

6.20 Validating Access Through Oracle HTTP Server

Verify that you can access these URLs:

• http://webhostN:7777/webcenter

• http://webhostN:7777/webcenterhelp

• http://webhostN:7777/rss

• http://webhostN:7777/portalTools

• http://webhostN:7777/wsrp-tools

• http://webhostN:7777/owc_discussions

where 'webhostN' specifies the name of each Oracle HTTP Server host (for example, WEBHOST1, WEBHOST2).

6.21 Validating Access Through the Load Balancer

Verify that you can access these URLs:

• https://wc.mycompany.com/webcenter

• https://wc.mycompany.com/webcenterhelp

• https://wc.mycompany.com/rss

• https://wc.mycompany.com/portalTools

• https://wc.mycompany.com/wsrp-tools

• https://wc.mycompany.com/owc_discussions

6.22 Backing Up the Installation

After you have verified that the extended domain is working, back up the installation. This is a quick backup for the express purpose of immediate restore in case of problems in the further steps. The backup destination is the local disk. This backup can be discarded once the enterprise deployment setup is complete. At this point, the regular deployment-specific backup and recovery process can be initiated. The Oracle Fusion Middleware Administrator's Guide provides further details. For information on describing the Oracle HTTP Server data that must be backed up and restored, refer to the "Backup and Recovery Recommendations for Oracle HTTP Server" section in this guide. For information on how to recover components, see "Recovery of Components" and "Recovery After Loss of Component" sections in the guide. For recommendations specific to recovering from the loss of a host, see the "Recovering Oracle HTTP Server to a Different Host" in the guide. Also refer to the Oracle Database Backup and Recovery Guide for information on database backup.

To back up the installation a this point, complete these steps:

1. Back up the web tier:

   1. Shut down the instance using opmnctl.

      ORACLE_BASE/admin/<instance_name>/bin/opmnctl stopall
      

   2. Back up the Middleware Home on the web tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME
      

   3. Back up the Instance Home on the web tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE
      

   4. Start the instance using opmnctl:

      ORACLE_BASE/admin/<instance_name>/bin/opmnctl startall
      

2. Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or OS tools such as tar for cold backups if possible.

3. Back up the AdminServer domain directory. Perform a backup to save your domain configuration. The configuration files all exist under the ORACLE_BASE/admin/<domain_name> directory.

   SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/<domain_name>