Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter
11g Release 1 (11.1.1)

Part Number E12037-04
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
View PDF

6 Extending the Domain for WebCenter Components

This chapter describes how to use the Configuration wizard to extend the domain that you created in Chapter 4, "Creating a Domain." It contains the following sections:

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.

Note:

You must back up the current domain before extending the domain. You may use the backup to recover in case any errors were made in the domain extension. See Oracle Fusion Middleware Administrator's Guide.
  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 Review WebLogic Domain screen, click Next.

  18. In the Extend WebLogic Domain 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:

Note:

If the Middleware homes are shared between systems, the domain template should already be in the proper directory and you can skip step 1 below.
  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_dir>/mserver/apps
    
  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:

Note:

If the Middleware homes are shared between the systems, and SOA was configured earlier, the nodemanager.properties file should already exist, properly configured. If this is the case, perform step 2 only if Node Manager is not already running.
  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.

Note:

ADMINVHN is the virtual hostname that maps to the virtual IP where the Administration Server is listening (in SOAHOST1).

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.

Note:

After configuring the Java Object Cache using the wlst commands or configure-joc.py script, all affected managed servers should be restarted for the configurations to take effect.

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:

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

Note:

Clustered Analytics Collectors are not supported for collecting WebCenter events.

6.16.1 Configure the Collectors

The Collectors do not need to be configured. By default they are listening on localhost. You must configure only the WebCenter Spaces clients to send their messages to localhost.

6.16.2 Configure the WebCenter Spaces Servers

  1. Open the WLST shell:

    ORACLE_HOME/common/bin/wlst.sh
    
  2. Connect to WLS Server:

    connect('weblogic_admin_username', 'weblogic_admin_pwd', 'WCHOST1:9000')
    

    Note that you are connecting to the host and port of the Spaces Server.

  3. Create the Analytics Collector connection and make it the default connection:

    createAnalyticsCollectorConnection('webcenter','HAConn1',isUnicast=1,
    collectorHost='localhost',collectorPort=31314,isEnabled=1,timeout=30,default=1)
    
  4. List the changes made:

    listDefaultAnalyticsCollectorConnection('webcenter')
    
  5. Repeat steps 3 and 4 for the Spaces Servers.

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.

# 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>
     WebLogicCluster wchost1:9003
     SetHandler weblogic-handler
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

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:

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.

6.19.1 Virtual Host for the Pagelet Producer

The Pagelet Producer uses the context root of '/'. In order to accommodate this we need to set up a different virtual host.

The required configuration to be made in the Oracle HTTP Server httpd.conf file is as follows:

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

All access to Pagelet Producer applications should be through pagelet-producer.example.com. For example: When you register a Pagelet Producer in WebCenter Spaces, or a custom application, it should use the virtual host.

Similarly access to Pagelet Producer admin applications and access to any Pagelet Producer resources should be through the Virtual Host.

Configure the Load Balancer with a new virtual host - wcedg-pagelet.mycompany.com which routes to the virtual host pagelet-producer.example.com which is configured on all Oracle HTTP Servers.

6.20 Validating Access Through Oracle HTTP Server

Verify that you can access these URLs:

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:

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>