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 ORACLE_BASE/product/fmw/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:

      • WebCenter Portlet Producers

      • WebCenter Discussion Server

      • Wiki and Blog Server

      • WebCenter Spaces

      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

      mds-SpacesDS

      wcedg_mds

      WebCenterDS

      wcedg_webcenter

      PortletDS

      wcedg_portlet

      DiscussionDS

      wcedg_discussions

      OWCWikiDS

      wcedg_wiki


    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

    WLS_Spaces1

    WCHOST1

    9000

    n/a

    No

    WLS_Spaces2

    WCHOST2

    9000

    n/a

    No

    WLS_Portlet1

    WCHOST1

    9001

    n/a

    No

    WLS_Portlet2

    WCHOST2

    9001

    n/a

    No

    WLS_Services1

    WCHOST1

    9002

    n/a

    No

    WLS_Services2

    WCHOST2

    9002

    n/a

    No


    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.

    Services_Cluster

    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:

      • WLS_Spaces1

      • WLS_Spaces2

    • Portlet_Cluster:

      • WLS_Portlet1

      • WLS_Portlet2

    • Services_Cluster:

      • WLS_Services1

      • WLS_Services2

    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

    SOAHOST1VHN2

    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

    SOAHOST2VHN1

    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:

      • WLS_Spaces1

      • WLS_Portlet1

      • WLS_Services1

    • WCHOST2:

      • WLS_Spaces2

      • WLS_Portlet2

      • WLS_Services2

    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 WLS_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 WLS_Spaces2, WLS_Portlet1, WLS_Portlet2, WLS_Services1, and WLS_Services2 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 ORACLE_BASE/product/fmw/wlserver_10.3/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 ORACLE_BASE/product/fmw/wc/common/bin
    
    SOAHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/ -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 -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:ORACLE_BASE/product/fmw/wc/common/bin
    
    SOAHOST1> scp wcdomaintemplate.jar
           oracle@WCHOST1:ORACLE_BASE/product/fmw/wc/common/bin
    
    SOAHOST1> scp wcdomaintemplate.jar
           oracle@WCHOST2:ORACLE_BASE/product/fmw/wc/common/bin
    
  2. Run the unpack command on SOAHOST2, WCHOST1, and WCHOST2 to unpack the propagated template.

    Note:

    Ensure that the domain directory does not exist when you run the unpack command; if the directory exists, the command will fail. The unpack command will create a new domain directory for you.

    This means that if you have made any configuration changes specific to the managed servers (such as WLS_WSM2) running on the node (SOAHOST2) where you are running the unpack command, you will have to redo the configuration changes.

    SOAHOST2> cd ORACLE_BASE/product/fmw/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

  1. Set the JAVA_OPTIONS environment variable to define the StartScriptEnabled property before starting Node Manager. On WCHOST1 and WCHOST2, run the following command:

    WCHOST1> export JAVA_OPTIONS=-DStartScriptEnabled=true
    WCHOST2> export JAVA_OPTIONS=-DStartScriptEnabled=true
    
  2. Start Node Manager:

    WCHOST1> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
    WCHOST1> ./startNodeManager.sh
    
    WCHOST2> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
    WCHOST2> ./startNodeManager.sh
    

After you have started Node Manager for the first time, you can edit the nodemanager.properties file to set the StartScriptEnabled property. The nodemanager.properties file does not exist until Node Manager is started for the first time.

To set the StartScriptEnabled property in the nodemanager.properties file:

  • Add the following line to the ORACLE_BASE/product/fmw/wlserver_10.3/common/nodemanager/nodemanager.properties file:

    StartScriptEnabled=true
    

When this property is set in the nodemanager.properties file, you no longer need to define it in the JAVA_OPTIONS environment variable.

6.9 Starting the WLS_Spaces1, WLS_Portlet1, and WLS_Services1 Managed Servers on WCHOST1

Follow these steps to start the WLS_Spaces1, WLS_Portlet1, and WLS_Services1 managed servers:

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

  2. Click Servers.

  3. Open the Control tab.

  4. Select WLS_Spaces1, WLS_Portlet1, and WLS_Services1.

  5. Click Start.

Note:

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

6.10 Validating the WLS_Spaces1, WLS_Portlet1, and WLS_Services1 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_wiki

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

    • http://WCHOST1:9001/richtextportlet

    • http://WCHOST1:9002/owc_discussions

  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 WLS_Spaces2, WLS_Portlet2, and WLS_Services2 Managed Servers on WCHOST2

Follow these steps to start the WLS_Spaces2, WLS_Portlet2, and WLS_Services2 managed servers:

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

  2. Click Servers.

  3. Open the Control tab.

  4. Select WLS_Spaces2, WLS_Portlet2, and WLS_Services2.

  5. Click Start.

6.12 Validating the WLS_Spaces2, WLS_Portlet2, and WLS_Services2 Managed Servers

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

    • http://WCHOST2:9000/webcenter

    • http://WCHOST2:9001/portalTools

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

    • http://WCHOST2:9002/owc_wiki

    • http://WCHOST2:9002/owc_discussions

  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/webcenter/scripts/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 Admin 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('MW_HOME/webcenter/scripts/configure-joc.py')
    
  3. All the input parameters are prompted by the script. The script can be used to perform the following JOC configurations:

    1. 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 : 9999
      
    2. 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 WLS_Spaces1:9999, WLS_Spaces2:9999) : WLS_Spaces1:9999,WLS_Spaces2:9999
      

      This example configures JOC only for the specified managed server (that is, WLS_Spaces1 & WLS_Spaces2). The discover port is specified with the managed server (for example, WLS_Spaces1:2222).

    3. 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) : WLS_Spaces1,WLS_Spaces3
      
    4. 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'.

6.14 Configuring Wiki Server

These are the required configuration steps when creating a cluster of Oracle WebCenter Wiki Servers. The reason for this is that Wiki stores some (but not all) of its configuration in its local deployment directory. This is fine for a single-node installation. However, for a clustered configuration, all members of the Oracle Wiki cluster must access the same configuration information.

To allow other members of a cluster to access the configuration of the first Wiki Server, a couple of its deployment directories must be available on shared drive.

On WCHOST1:

  1. Create a directory on a shared drive. Let's call this /shared/owc_wiki.

  2. Create two directories under that: /attachments and /templates.

  3. Copy the contents of the wiki deployment directories to the shared directories:

    $ cp -r <DOMAIN_HOME>/servers/WLS_Services/stage/owc_wiki/11.1.1.1.0/owc_wiki/attachments/* /shared/owc_wiki/attachments
    $ cp -r <DOMAIN_HOME>/servers/WLS_Services/stage/owc_wiki/11.1.1.1.0/owc_wiki/templates/* /shared/owc_wiki/templates
    
  4. Create a symbolic link from the deployment directory to the shared directory:

    $ rm -rf <DOMAIN_HOME>/servers/WLS_Services/stage/owc_wiki/11.1.1.1.0/owc_wiki/attachments
    $ rm -rf <DOMAIN_HOME>/servers/WLS_Services/stage/owc_wiki/11.1.1.1.0/owc_wiki/templates
    $ ln -s /shared/owc_wiki/attachments <DOMAIN_HOME>/servers/WLS_Services/stage/owc_wiki/11.1.1.1.0/owc_wiki/attachments
    $ ln -s /shared/owc_wiki/templates <DOMAIN_HOME>/servers/WLS_Services/stage/owc_wiki/11.1.1.1.0/owc_wiki/templates
    

On WCHOST2:

Note:

Ensure that the managed servers on WCHOST2 have been started at least once, so that the initial deployment directories have been created. The managed servers, however, should be down before proceeding with the next step.
  1. Create a symbolic link from the templates and attachments directory to the shared directory:

    $ rm -rf <DOMAIN_HOME>/servers/WLS_Services/stage/owc_wiki/11.1.1.1.0/owc_wiki/ attachments
    $ rm -rf <DOMAIN_HOME>/servers/WLS_Services/stage/owc_wiki/11.1.1.1.0/owc_wiki/ templates
    $ ln -s /shared/owc_wiki/attachments <DOMAIN_HOME>/servers/WLS_Services/stage/owc_wiki/11.1.1.1.0/owc_wiki/attachments
    $ ln -s /shared/owc_wiki/templates <DOMAIN_HOME>/servers/WLS_Services/stage/owc_wiki/11.1.1.1.0/owc_wiki/templates
    
  2. Verify that templates created on one node can be accessed from either node.

6.15 Configuring Oracle HTTP Server for the WLS_Spacesn, WLS_Portletn, and WLS_Servicesn Managed Servers on WCHOST2

To enable Oracle HTTP Server to route to the Spaces_Cluster, Portlet_Cluster, and Services_Cluster, which contain the WLS_Spacesn, WLS_Portletn, and WLS_Servicesn managed servers, you must set the WebLogicCluster parameter to the list of nodes in the cluster.

  1. Add the following lines to the OHS_HOME/instances/ohs_instance1/config/OHS/ ohs1/mod_wl_ohs.conf file:

    # Spaces
    
    <Location /webcenter>
        WebLogicCluster wchost1.com:9000,wchost2.com:9000
        SetHandler weblogic-handler
    </Location>
    
    <Location /webcenterhelp>
        WebLogicCluster wchost1.com:9000,wchost2.com:9000
        SetHandler weblogic-handler
    </Location>
    
    <Location /rss>
        WebLogicCluster wchost1.com:9000,wchost2.com:9000
        SetHandler weblogic-handler
    </Location>
    
    # Portlet
    
    <Location /portalTools>
        WebLogicCluster wchost1.com:9001,wchost2.com:9001
        SetHandler weblogic-handler
    </Location>
    
    <Location /wsrp-tools>
        WebLogicCluster wchost1.com:9001,wchost2.com:9001
        SetHandler weblogic-handler
    </Location>
    
    # WSM
    
    <Location /wsm-pm>
        WebLogicCluster soahost1.com:7010,soahost2.com:7010
        SetHandler weblogic-handler
    </Location>
    
    # Discussions and Wiki
    
    <Location /owc_discussions>
        WebLogicCluster wchost1.com:9002,wchost2.com:9002
        SetHandler weblogic-handler
    </Location>
    
    <Location /owc_wiki>
        WebLogicCluster wchost1.com:9002,wchost2.com:9002
        SetHandler weblogic-handler
    </Location>
    
  2. Add the following lines to the httpd.conf file (located in the same directory as the mod_wl_ohs file):

    NameVirtualHost *:7777
    <VirtualHost *:7777>
        ServerName https://wc.mycompany.com:443
        ServerAdmin you@your.address
        RewriteEngine On
        RewriteOptions inherit
    </VirtualHost>
    
    NameVirtualHost *:7777
    <VirtualHost *:7777>
        ServerName admin.mycompany.com:80
        ServerAdmin you@your.address
        RewriteEngine On
        RewriteOptions inherit
    </VirtualHost>
    
    NameVirtualHost *:7777
    <VirtualHost *:7777>
        ServerName wcinternal.mycompany.com:80
        ServerAdmin you@your.address
        RewriteEngine On
        RewriteOptions inherit
    </VirtualHost>
    
  3. Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2:

    WEBHOST1> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs1
    WEBHOST2> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs1
    

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.

6.16 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_wiki

  • http://webhostN:7777/owc_discussions

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

6.17 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

  • http://wcinternal.mycompany.com/owc_wiki

  • http://wcinternal.mycompany.com/owc_discussions

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