10 Extending the Domain for WebCenter Portal Components

This chapter describes how to use the Configuration Wizard to extend the domain you created in Chapter 8, "Creating a Domain for an Enterprise Deployment" to include WebCenter Portal components.

Note:

Before starting the setup process, read the Oracle Fusion Middleware Release Notes for additional installation and deployment information.

This chapter contains the following sections:

• Section 10.1, "Overview of Extending the Domain for WebCenter Portal Components"

• Section 10.2, "Extending the Domain for WebCenter Portal Components using the Configuration Wizard"

• Section 10.3, "Post-Configuration Tasks"

• Section 10.4, "Propagating the Domain Configuration to SOAHOST2, WCPHOST1, and WCPHOST2"

• Section 10.5, "Configuring the Java Object Cache for Spaces_Cluster"

• Section 10.6, "Converting Discussions from Multicast to Unicast"

• Section 10.7, "Configuring Clustering on the Discussions Server"

• Section 10.8, "Configuring Analytics"

• Section 10.9, "Configuring Activity Graph"

• Section 10.10, "Configuring REST APIs"

• Section 10.11, "Configuring Oracle HTTP Server with the Extended Domain"

• Section 10.12, "Backing Up the WebCenter Portal Configuration"

10.1 Overview of Extending the Domain for WebCenter Portal Components

Extend the WebLogic domain to include Oracle WebCenter Portal components. Table 10-1 lists the steps for configuring WebCenter Portal and other tasks required for extending the domain for WebCenter Portal components.

Table 10-1 Steps for Extending the Domain for WebCenter Portal Components

Step	Description	More Information
Extend the domain for WebCenter Portal components	Extend the WebLogic domain you created in Chapter 8, "Creating a Domain for an Enterprise Deployment".	Section 10.2, "Extending the Domain for WebCenter Portal Components using the Configuration Wizard"
Disable host name verification for WebCenter Portal managed servers	Disable host name verification.	Section 10.3.1, "Disabling Host Name Verification for the WebCenter Portal Managed Servers"
Perform post-configuration tasks	Follow these instructions for post-configuration tasks.	Section 10.3, "Post-Configuration Tasks"
Propagate the domain configuration to the Managed Server domain directory	Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory.	Section 10.3.3, "Propagating the Domain Changes to the Managed Server Domain Directory"
Propagate the domain configuration to SOAHOST2, WCPHOST1, WCPHOST2	Propagate the domain configuration to all other managed servers.	Section 10.4.1, "Propagating the Domain Configuration to SOAHOST2, WCPHOST1, and WCPHOST2 Using the unpack Utility"
Configure Java object caching	Configure the Java Object Cache to increase the performance of the Spaces application.	Section 10.5, "Configuring the Java Object Cache for Spaces_Cluster"
Configure WebCenter Portal services	Configure Discussions, Analytics, Activity Graph, and REST API services.	Section 10.6, "Converting Discussions from Multicast to Unicast" Section 10.7, "Configuring Clustering on the Discussions Server" Section 10.8, "Configuring Analytics" Section 10.9, "Configuring Activity Graph" Section 10.10, "Configuring REST APIs"
Configure the Oracle HTTP Server with the extended domain	Configure the Oracle HTTP Server with the managed servers, and validate access.	Section 10.11.1, "Configuring Oracle HTTP Server for the WC_Spacesn, WC_Portletn, WC_Utilitiesn, and WC_Collaborationn Managed Servers"
Back Up the WebCenter Portal Configuration	Back up the newly extended domain configuration.	Section 10.12, "Backing Up the WebCenter Portal Configuration"

10.2 Extending the Domain for WebCenter Portal Components using the Configuration Wizard

Use the Configuration Wizard to extend the domain created in Chapter 8, "Creating a Domain for an Enterprise Deployment" to contain WebCenter Portal components.

Note:

You must back up the current domain before extending the domain. You may use the backup to recover in case any errors are made in the domain extension. See "Backing Up Your Environment" in the Oracle Fusion Middleware Administrator's Guide.

To extend the domain using the Configuration Wizard:

1. Ensure that the database where you installed the repository is running. For Oracle RAC databases, Oracle recommends that all instances are running, so that the validation check later on becomes more reliable.

2. Shut down all managed servers in the domain.

3. Change directory to the location of the Configuration Wizard. This is within the Oracle Common home directory (notice that domain extensions are run from SOAHOST1 where the Administration Server resides).

   cd ORACLE_COMMON_HOME/common/bin
   

4. Start the Configuration Wizard.

   ./config.sh
   

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

6. In the WebLogic Domain Directory screen, select the WebLogic domain directory:

   ORACLE_BASE/admin/domain_name/aserver/domain_name
   

   Click Next.

7. 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 WebCenter Services Portlets

     • Oracle WebCenter Pagelet Producer

     • Oracle Portlet Producers

     • Oracle WebCenter Discussions Server

     • Oracle WebCenter Activity Graph Engines

     • Oracle WebCenter Personalization

     • Oracle Webcenter Analytics Collector

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

     • Basic WebLogic Server Domain

     • Oracle JRF

     • Oracle WSM Policy Manager

   Click Next.

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

9. 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 10-2 assume that wcpedg was used as prefix for schema creation from RCU.

      Table 10-2 Values for Data Sources

      Data Source	User Name
      WebCenterDS Schema	wcpedg_webcenter
      ActivitiesDS Schema	wcpedg_activities
      DiscussionDS Schema	wcpedg_discussions
      PersonalizationDS Schema	wcpedg_webcenter
      PortletDS Schema	wcpedg_portlet
      Portlet-ServicesProducerDS	wcpedg_portlet
      WC-ServicesProducerDS	wcpedg_webcenter
      WebCenterMDS Schema	wcpedg_mds
      PersonalizationMDS Schema	wcpedg_mds
      mds-PageletProducerDS Schema	wcpedg_mds
      mds-ServicesProducerDS Schema	wcpedg_mds

      
      

   2. Select the check box next to all the component schemas shown in Table 10-2.

   3. For the RAC configuration, you can select Convert to GridLink or Convert to RAC multi data source (described in Appendix A, "Using Multi Data Sources with Oracle RAC").

      For the instructions given here, select Convert to GridLink.

   4. Click Next.

10. In the Configure GridLink RAC Component Schema screen:

    1. Select first GridLink data source schema, WebCenterDS Schema.

    2. Enter values for the following fields, specifying the connect information for the GridLink Oracle RAC database that was seeded through RCU.

       • Driver: Select Oracle driver (Thin) for GridLinkConnections,Versions:10 and later.

       • Service Name: Enter the service name of the Oracle RAC database in lowercase letters, followed by the domain name. For example, wcpedg.mycompany.com.

       • Username: Enter the complete user name (including the prefix) for the database schema owner. The user names shown in Table 10-2 assume that wcpedg was used as the prefix for schema creation through RCU.

       • Password: Enter the password for the database schema owner.

       • Enable FAN: Select this option.

       • Enable SSL: Deselect this option.

         If you select SSL, to enable Oracle Notification Service (ONS) notification encryption, provide appropriate Wallet File and Wallet Password details.

       • Service Listener: Enter the Oracle Single Client Access Name (SCAN) address and port for the Oracle RAC database being used. The protocol should be TCP.

         Oracle recommends that you use SCAN addresses to specify the Service Listener (and OSN Host) so you do not need to update a GridLink data source containing SCAN addresses if you add or remove Oracle RAC nodes. To determine the SCAN address, query the remote_listener parameter in the database:

         SQL>show parameter remote_listener;
          
         NAME              TYPE        VALUE
         -----             ------      -------
         remote_listener   string      db-scan.mycompany.com:1521
         

         Note:

         For database versions that do not support SCAN:

         • For Oracle Database 11g Release 1 (11.1), enter the Virtual IP and port of each database's instance listener, for example:

           custdbhost1-vip.mycompany.com (Port 1521)

           and

           custdbhost2-vip.mycompany.com (Port 1521)

         • For Oracle Database 10g, use multi data sources to connect to an Oracle RAC database. For information about configuring multi data sources see Appendix A, "Using Multi Data Sources with Oracle RAC".

       • ONS Host: Enter the SCAN address for the Oracle RAC database and the ONS remote port, as reported by the database:

         [orcl@db-scan1 ~]$ srvctl config nodeapps -s
         ONS exists: Local port 6100, remote port 6200, EM port 2016
         

         Note:

         For Oracle Database 11g Release 1 (11.1), enter the host name and port for the database's ONS service. For example:

         custdbhost1.mycompany.com (Port 6200)

         and

         custdbhost2.mycompany.com (Port 6200)

    3. Select the next schema, for example ActivitiesDS Schema, and specify appropriate details.

       Ensure that GridLink information is entered for all WebCenter Portal schemas listed in Table 10-2.

    4. Click Next.

11. In the Test JDBC Data Sources screen, select the schema you want to test (or click Select All), then click Test Connections.

    The Connection Results Log displays the results. Ensure that the connection to the database that contains the schema was successful. If not, click Previous to return to the previous screen, correct your entry, and then retry the test.

    Click Next when all the connections are successful.

12. In the Select Optional Configuration screen, select the following:

    • Managed Servers, Clusters and Machines

    • Deployments and Services

    Click Next.

13. In the Configure Managed Servers screen, add the following managed servers (Table 10-3):

    Table 10-3 Managed Servers

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

    
    

    Note:

    Managed Servers may be renamed 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.

14. In the Configure Clusters screen, add four new clusters (Table 10-4):

    Note:

    WSM-PM_Cluster should already display in the list.

    Table 10-4 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_Cluster	unicast	n/a	n/a	Leave it empty.

    
    

    Click Next.

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

16. In the Configure Machines screen, click the Unix Machine tab and ensure that the following four entries exist:

    Table 10-5 Machines

    Name	Node Manager Listen Address
    SOAHOST1	SOAHOST1 SOAHOST1 was configured when you ran the Configuration Wizard in Section 8.3, "Running the Configuration Wizard on SOAHOST1 to Create a Domain."
    SOAHOST2	SOAHOST2 SOAHOST2 was configured when you ran the Configuration Wizard in Section 8.3, "Running the Configuration Wizard on SOAHOST1 to Create a Domain."
    WCPHOST1	WCPHOST1
    WCPHOST2	WCPHOST2

    
    

    Leave all other fields to their default values.

    Click Next.

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

    • ADMINHOST:

      • AdminServer

    • SOAHOST1:

      • WLS_WSM1

    • SOAHOST2:

      • WLS_WSM2

    • WCPHOST1:

      • WC_Spaces1

      • WC_Portlet1

      • WC_Collaboration1

      • WC_Utilities1

    • WCPHOST2:

      • WC_Spaces2

      • WC_Portlet2

      • WC_Collaboration2

      • WC_Utilities2

        Note:

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

    Click Next.

18. In the Target Deployment to Clusters or Servers screen, ensure the following targets:

    • The wsm-pm application must be targeted only to WSM-PM_Cluster.

    Click Next.

19. In the Target Services to Clusters or Servers screen, ensure the following targets:

    • Target mds-owsm to both WSM-PM_Cluster and AdminServer.

    Click Next.

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

21. In the Extending Domain screen, click Done.

    You must start the Administration Server for this configuration to take effect.

22. Start the Administration Server using the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1".

10.3 Post-Configuration Tasks

After extending the domain with the Configuration Wizard, follow these instructions for post-configuration.

This section includes the following topics:

• Section 10.3.1, "Disabling Host Name Verification for the WebCenter Portal Managed Servers"

• Section 10.3.2, "Starting Node Manager on SOAHOST1"

• Section 10.3.3, "Propagating the Domain Changes to the Managed Server Domain Directory"

10.3.1 Disabling Host Name Verification for the WebCenter Portal Managed Servers

In this guide, you set up the appropriate certificates to authenticate the different nodes with the Administration Server after you have completed the procedures to extend the domain for WebCenter Portal. Therefore, you must disable host name verification for the WebCenter Portal managed servers to avoid errors when managing the different WebLogic Servers. You enable host name verification again once the Enterprise Deployment topology configuration is complete. See Section 11.5, "Enabling Host Name Verification Certificates for the Node Manager in SOAHOST2 and WCPHOST2" for more information.

To disable host name verification:

1. Log in to Oracle WebLogic Server Administration Console.

2. Click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

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

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

6. Select the SSL tab.

7. Expand the Advanced section of the page.

8. Set Hostname Verification to None.

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

10. Save and activate the changes.

11. This change requires a restart of the Administration Server and Node Managers.

    1. To restart the Administration Server see Chapter 8, "Starting the Administration Server on SOAHOST1."

    2. To restart Node Manager on SOAHOST1, see Chapter 10, "Starting Node Manager on SOAHOST1."

10.3.2 Starting Node Manager on SOAHOST1

Use the startNodeManager.sh script to restart Node Manager.

To restart the Node Manager on SOAHOST1:

1. Stop Node Manager by stopping the process associated with it:

   • If it is running in the foreground in a shell, simply use CTRL+C.

   • If it is running in the background in the shell, find the associate process and use the kill command to stop it. For example:

     ps -ef | grep NodeManager
     orcl      9139  9120  0 Mar03 pts/6    00:00:00 /bin/sh ./startNodeManager.sh
     
     kill -9 9139 
     

2. Start Node Manager:

   cd WL_HOME/server/bin
   ./startNodeManager.sh
   

10.3.3 Propagating the Domain Changes to the Managed Server Domain Directory

Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory.

To propagate start scripts and classpath configuration:

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

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

   cd ORACLE_COMMON_HOME/common/bin
   
   ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name 
   -template=wcdomaintemplate.jar -template_name=wcdomaintemplate
   

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

   ./unpack.sh 
   -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
   -template=wcdomaintemplate.jar 
   -overwrite_domain=true
   -app_dir=ORACLE_BASE/admin/domain_name/mserver/apps
   

Note:

The -overwrite_domain option in the unpack command, allows unpacking a managed server template into an existing domain and existing applications directories. For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and ear files in the managed server domain directory, they must be re-applied after this unpack operation.

10.4 Propagating the Domain Configuration to SOAHOST2, WCPHOST1, and WCPHOST2

After completing the configuration of SOAHOST1, propagate the configuration to SOAHOST2, WCPHOST1, and WCPHOST2 using the unpack utility, and then validate the propagated configuration.

This section includes the following topics:

• Section 10.4.1, "Propagating the Domain Configuration to SOAHOST2, WCPHOST1, and WCPHOST2 Using the unpack Utility"

• Section 10.4.2, "Starting the Node Manager on WCPHOST1 and WCPHOST2"

• Section 10.4.3, "Starting the WC_Spaces1, WC_Portlet1, WC_Utilities1, and WC_Collaboration1 Managed Servers on WCPHOST1"

• Section 10.4.4, "Verifying GridLink Data Source Configuration and ONS for WebCenter Portal"

• Section 10.4.5, "Validating the WC_Spaces1, WC_Portlet1, WC_Utilities1, and WC_Collaboration1 Managed Servers"

• Section 10.4.6, "Starting the WC_Spaces2, WC_Portlet2, WC_Utilities2, and WC_Collaboration2 Managed Servers on WCPHOST2"

• Section 10.4.7, "Validating the WC_Spaces2, WC_Portlet2, WC_Utilities2, and WC_Collaboration2 Managed Servers"

10.4.1 Propagating the Domain Configuration to SOAHOST2, WCPHOST1, and WCPHOST2 Using the unpack Utility

Propagate the domain you just configured to SOAHOST2. WCPHOST1, and WCPHOST2 using the unpack utility.

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.

To propagate the domain configuration:

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

   scp wcdomaintemplate.jar oracle@SOAHOST2:ORACLE_COMMON_HOME/common/bin
   

   scp wcdomaintemplate.jar oracle@WCPHOST1:ORACLE_COMMON_HOME/common/bin
   

   scp wcdomaintemplate.jar oracle@WCPHOST2:ORACLE_COMMON_HOME/common/bin
   

2. Run the unpack command on SOAHOST2, WCPHOST1, and WCPHOST2 to unpack the propagated template.

   cd ORACLE_COMMON_HOME/common/bin
   
   ./unpack.sh
    -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/
    -template=wcdomaintemplate.jar
    -overwrite_domain=true
    -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
   
   

3. Repeat the above steps for WCPHOST1 and WCPHOST2.

10.4.2 Starting the Node Manager on WCPHOST1 and WCPHOST2

Use the startNodeManager.sh script to start Node Manager.

To start the Node Manager on WCPHOST1 and WCPHOST2:

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 WCPHOST1 and WCPHOST2:

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

   Note:

   You can skip step 1 if the WebCenter Portal server is sharing the Middleware home in a local or shared storage with SOA (as suggested in Chapter 3, "Preparing the Network for an Enterprise Deployment"), and SOA was configured earlier. In this instance, you do not need to setNMProps.sh again, and Node Manager is already running on SOAHOST1 and SOAHOST2.

2. Run the following commands on both WCPHOST1 and WCPHOST2 to start Node Manager:

   WCPHOST1> cd WL_HOME/server/bin
   WCPHOST1> ./startNodeManager.sh
   
   WCPHOST2> cd WL_HOME/server/bin
   WCPHOST2> ./startNodeManager.sh
   

10.4.3 Starting the WC_Spaces1, WC_Portlet1, WC_Utilities1, and WC_Collaboration1 Managed Servers on WCPHOST1

To start the WC_Spaces1, WC_Portlet1, WC_Utilities1, and WC_Collaboration1 managed servers managed servers using the Administration Console:

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

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

2. Expand the Environment node in the Domain Structure window.

3. Click Servers.

4. Open the Control tab.

5. Select WC_Spaces1, WC_Portlet1, WC_Utilities1, and WC_Collaboration1.

6. Click Start.

10.4.4 Verifying GridLink Data Source Configuration and ONS for WebCenter Portal

Before you propagate WC_Spaces1, WC_Portlet1, WC_Utilities1, and WC_Collaboration1, verify that the GridLink data sources you created earlier are correctly configured and that the Oracle Notification Service (ONS) setup is correct for the data source.

To verify the configuration of GridLink data sources and ONS for WebCenter Portal:

1. Log in to the WebLogic Server Administration Console.

2. In the Domain Structure tree, expand Services, then select Data Sources.

3. Click the name of a GridLink data source that was created.

4. Click the Testing tab, select one of the WebCenter Portal managed servers, for example WC_Spaces1, and click Test Data Source.

   The test should be successful if the configuration is correct.

5. Repeat the test for each WebCenter managed server that uses the GridLink data source.

6. Click the Monitoring tab, and click the name of one of the servers.

7. Click the ONS tab and then the Testing tab.

8. Select one of the WebCenter Portal managed servers, for example WC_Spaces1, and click Test ONS.

   If the configuration is correct, the ONS test is successful. If the ONS test fails, verify that the ONS service is running in the Oracle RAC database nodes:

   [orcl@db-scan1 ~]$ srvctl status scan_listener
   SCAN Listener LISTENER_SCAN1 is enabled
   SCAN listener LISTENER_SCAN1 is running on node db-scan1
   SCAN Listener LISTENER_SCAN2 is enabled
   SCAN listener LISTENER_SCAN2 is running on node db-scan2
   SCAN Listener LISTENER_SCAN3 is enabled
   SCAN listener LISTENER_SCAN3 is running on node db-scan3
    
    
   [orcl@db-scan1 ~]$ srvctl config nodeapps -s 
   ONS exists: Local port 6100, remote port 6200, EM port 2016 
    
    
   [orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
   ONS is enabled
   ONS daemon is running on node: db-scan1
   ONS daemon is running on node: db-scan2
   

9. Repeat the ONS test for each WebCenter Portal managed server that uses the GridLink data source.

10.4.5 Validating the WC_Spaces1, WC_Portlet1, WC_Utilities1, and WC_Collaboration1 Managed Servers

To validate that all the WebCenter Portal managed servers on WCPHOST1 are up and running:

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

   • http://WCPHOST1:9000/webcenter

   • http://WCPHOST1:9000/webcenterhelp

   • http://WCPHOST1:9000/rss

   • http://WCPHOST1:9000/rest

   • http://WCPHOST1:9001/pagelets

   • http://WCPHOST1:9001/portalTools

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

   • http://WCPHOST1:9002/owc_discussions

   • http://WCPHOST1:9003/activitygraph-engines/Login.jsp

   • http://WCPHOST1:9003/wcps/api/property/resourceIndex

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
   

10.4.6 Starting the WC_Spaces2, WC_Portlet2, WC_Utilities2, and WC_Collaboration2 Managed Servers on WCPHOST2

To start the WC_Spaces2, WC_Portlet2, WC_Utilities2, and WC_Collaboration2 managed servers managed servers using the Administration Console:

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

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

2. Expand the Environment node in the Domain Structure window.

3. Click Servers.

4. Open the Control tab.

5. Select WC_Spaces2, WC_Portlet2, WC_Utilities2, and WC_Collaboration2.

6. Click Start.

10.4.7 Validating the WC_Spaces2, WC_Portlet2, WC_Utilities2, and WC_Collaboration2 Managed Servers

To validate that all the WebCenter Portal managed servers on WCPHOST2 are up and running:

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

   • http://WCPHOST2:9000/webcenter

   • http://WCPHOST2:9000/webcenterhelp

   • http://WCPHOST2:9000/rss

   • http://WCPHOST2:9000/rest

   • http://WCPHOST2:9001/pagelets

   • http://WCPHOST2:9001/portalTools

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

   • http://WCPHOST2:9002/owc_discussions

   • http://WCPHOST2:9003/wcps/api/property/resourceIndex

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
   

10.5 Configuring the Java Object Cache for Spaces_Cluster

Configure the Java Object Cache (JOC) among all the managed servers in Spaces_Cluster. This local cache is provided to increase the performance of the Spaces application.

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 the Administration Server to be up and running. For general information about WLST online mode, see "Getting Started Using the Oracle WebLogic Scripting Tool (WLST)" in Oracle Application Server Administrator's Guide.

Note:

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

To configure the Java Object Cache for WebCenter Portal managed servers:

1. Connect to the Administration Server using 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("MW_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 configures the JOC. The discover port is common for the entire JOC configuration across the cluster.

   Note:

   You can specify any free port for the "Discover Port".

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

   execfile("MW_HOME/oracle_common/bin/configure-joc.py")
   .
   Enter Hostnames (eg host1,host2) : WCPHOST1,WCPHOST2
   .
   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_Spaces2
  

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

10.6 Converting Discussions from Multicast to Unicast

To convert Discussions (on all managed servers in the Collab_Cluster) 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=WCPHOST1
   -Dtangosol.coherence.wka2=WCPHOST2
   -Dtangosol.coherence.localhost=WCPHOST1
   -Dtangosol.coherence.wka1.port=8089
   -Dtangosol.coherence.wka2.port=8089
   -Dtangosol.coherence.localport=8089
   

   Where WCPHOST1 is the host on which WC_Collaboration1 is running.

   Port 8089 is a port reserved for WebCenter Coherence communications.

3. Repeat steps 1 and 2 for WC_Collaboration2, swapping WCPHOST1 for WCPHOST2 and WCPHOST2 for WCPHOST1.

   -Dtangosol.coherence.wka1=WCPHOST2
   -Dtangosol.coherence.wka2=WCPHOST1
   -Dtangosol.coherence.localhost=WCPHOST2
   -Dtangosol.coherence.wka1.port=8089
   -Dtangosol.coherence.wka2.port=8089
   -Dtangosol.coherence.localport=8089
   

4. Restart the WC_Collaboration servers.

10.7 Configuring Clustering on the Discussions Server

If this is a unicast cluster, first complete all the steps in Section 10.6, "Converting Discussions from Multicast to Unicast".

To ensure that all members in the Discussions cluster can communicate with each other:

1. Log in to the discussions server's Administration Console for each member of the cluster at:

   http://host:port/owc_discussions/admin
   

2. Select Cache Settings.

   Figure 10-1 Cache Settings Section

   
   Description of "Figure 10-1 Cache Settings Section"
   
   

3. In the Cache Features section, ensure that Clustering is set to Enabled.

   As servers join the cluster they appear at the top of the screen.

4. In the Tool section, select Reset All Cluster Members and the Start Cache WarmUp Task. Repeat the Cache warm up task on all members of the cluster.

   Figure 10-2 Cache Tools Section

   
   Description of "Figure 10-2 Cache Tools Section"
   
   

5. Repeat steps 1 through 4 for all members of the cluster.

   As servers join the cluster they appear at the top of the screen.

10.8 Configuring Analytics

Out-of-the box, Analytics Collectors are configured to communicate with the local Spaces application in a 1-1 relationship (the collectors listen on localhost). No additional Analytics Collector configuration is required.

However, you must configure the Spaces applications to send event messages to localhost:

Note:

Clustered Analytics Collectors are not supported for collecting WebCenter Portal events.

To connect the Spaces application to the analytics collector:

1. Connect to the managed server where the Spaces application is running using WLST, for example:

   MW_HOME/wc/common/bin/wlst.sh
   connect("weblogic_admin_username", "weblogic_admin_pwd", "WCPHOST1:9000")
   

   Connect to the host and port of the WC_Spaces server.

2. Create a connection between the Spaces application and the Analytics Collector and make it the default connection (default=1).

   For example:

   createAnalyticsCollectorConnection(appName="webcenter", name="HAConn1", isUnicast=1,
   collectorHost="localhost", collectorPort=31314, isEnabled=1, timeout=30, default=1)
   

   See also, "createAnalyticsCollectorConnection" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

3. Verify the changes made:

   listDefaultAnalyticsCollectorConnection(appName="webcenter")
   

   See also, "listDefaultAnalyticsCollectorConnection" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

10.9 Configuring Activity Graph

Activity Graph should run as a singleton. In a cluster environment, all Activity Graph application instances should be disabled except for one.

To disable Activity Graph Engines applications:

1. Log in to the Administration Console.

2. Shut down the WC_Utilities1 and WC_Utilities2 servers.

3. Select Deployments

4. Click Lock & Edit.

5. Alter the targets for each of these deployments:

   • activitygraph-engines (11.1.1.6.0)

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

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

   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 for Utilities_Cluster. Targeting to other servers and Clusters should remain unchanged.

   5. Click OK to save the changes.

6. When finished with all three deployments, click Activate all Changes.

7. Start up WC_Utilities1 and WC_Utilities2 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.

Note:

Oracle does not recommend that you configure Server Migration for Activity Graph, since Activity Graph resides in the same server as other components that must not be failed over. For more information about server migration, see Chapter 14, "Configuring Server Migration for an Enterprise Deployment".

10.10 Configuring REST APIs

If you want to use WebCenter Portal REST APIs, you must perform the server-side configuration described in this section.

To seed entries in the credential store that enable the REST security tokens to function properly:

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

Later on, you must configure REST policies in OAM (Chapter 15, "Updating the REST Policies").

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

10.11 Configuring Oracle HTTP Server with the Extended Domain

This section includes the following topics:

• Section 10.11.1, "Configuring Oracle HTTP Server for the WC_Spacesn, WC_Portletn, WC_Utilitiesn, and WC_Collaborationn Managed Servers"

• Section 10.11.2, "Validating Access Through Oracle HTTP Server"

• Section 10.11.3, "Validating Access Through the Load Balancer"

10.11.1 Configuring Oracle HTTP Server for the WC_Spacesn, WC_Portletn, WC_Utilitiesn, and WC_Collaborationn Managed Servers

To enable Oracle HTTP Server to route to the WebCenter Portal 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 wcp.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://wcp.mycompany.com:443 
     ServerAdmin [e-mail] 
     RewriteEngine On
     RewriteOptions inherit

# Spaces Application
<Location /webcenter>
     WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
     SetHandler weblogic-handler
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

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

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

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

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

# Portlets

 <Location /pagelets>
     WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
     SetHandler weblogic-handler
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

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

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

# Personalization

 <Location /wcps>
     WebLogicCluster WCPHOST1:9003,WCPHOST2:9003
     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 WCPHOST1
     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 wcpinternal.mycompany.com:80 
     ServerAdmin [e-mail] 
     RewriteEngine On
     RewriteOptions inherit

# Portlet Internal access

<Location  /pagelets>
 WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
 SetHandler weblogic-handler
</Location>

<Location /portalTools>
     WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
     SetHandler weblogic-handler
</Location>

<Location /wsrp-tools>
     WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
     SetHandler weblogic-handler
</Location>

# Discussions Internal access
<Location /owc_discussions>
     WebLogicCluster WCPHOST1:9001,WCPHOST2:9002
     SetHandler weblogic-handler
</Location>

</VirtualHost>

#Virtual host for SharePoint access
<VirtualHost *:7777>
     ServerName wcp-spaces.mycompany.com
     ServerAdmin [e-mail] 
     RewriteEngine On
     RewriteOptions inherit

#SharePoint entry point
<Location />
     WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
     SetHandler weblogic-handler
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

# Spaces Application
<Location /webcenter>
   Deny from all
</Location>

<Location /webcenterhelp>
   Deny from all
</Location>

 <Location /rss>
   Deny from all
</Location>

 <Location /rest>
   Deny from all
</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.

10.11.1.1 Configuring Microsoft Clients

In order to accommodate Microsoft Clients, refer to the overview and detailed steps outlined in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal.

In particular, you must create another Virtual Host in order to provide a separate context root for these clients. For instructions see "Configuring SSO with Virtual Hosts" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal.

Follow the steps in "Configuring SSO for Microsoft Clients" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal to properly configure Windows authentication services.

10.11.2 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/rest

• http://WEBHOSTn:7777/pagelets

• http://WEBHOSTn:7777/portalTools

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

• http://WEBHOSTn:7777/owc_discussions

• http://WEBHOSTn:7777/activitygraph-engines/Login.jsp

• http://WEBHOSTn:7777/wcps/api/property/resourceIndex

Where WEBHOSTn specifies the name of each Oracle HTTP Server host (for example, WEBHOST1, WEBHOST2).

10.11.3 Validating Access Through the Load Balancer

Verify that you can access these URLs:

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

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

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

• https://wcp.mycompany.com/rest

• https://wcp.mycompany.com/pagelets

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

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

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

• https://wcp.mycompany.com/activitygraph-engines/Login.jsp

• https://wcp.mycompany.com/wcps/api/property/resourceIndex

10.12 Backing Up the WebCenter Portal Configuration

After you have verified that the extended domain is working, back up the domain configuration. This is a quick backup for the express purpose of immediate restore in case of failures in future procedures. Back up the configuration to the local disk. This backup can be discarded once you have completed the enterprise deployment. Once you have completed the enterprise deployment, you can initiate the regular deployment-specific backup and recovery process.

For information about backing up the environment, see "Backing Up Your Environment" in the Oracle Fusion Middleware Administrator's Guide. For information about recovering your information, see "Recovering Your Environment" in the Oracle Fusion Middleware Administrator's Guide.

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 domain configuration:

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 are located in the following directory:

   ORACLE_BASE/admin/domain_name
   

   To back up the Administration Server run the following command on SOHOST1:

   tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name