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

SOAHOST1> cd MW_HOME/wc/common/bin

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.

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

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.

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

Repeat for each RAC instance.

Click Next.

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.

In the Advanced Configuration Screen, select the following:

Managed Servers, Clusters and Machines

Deployments and Services

Click Next.

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.

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.

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.

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

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.

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

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

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

In the Extending Domain screen, click Done.

6.3Restarting the Administration Server

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

Stop the Administration Server.

SOAHOST1> ./stopWebLogic.sh

Start the Administration Server:

SOAHOST1> ./startWebLogic.sh

6.4Disabling 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.

6.5Starting 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.6Propagating 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:

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

6.8Starting 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.

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:

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

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.11Starting 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:

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

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.13Setting 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

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.

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

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

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:

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

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.

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.

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

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

6.21Validating Access Through the Load Balancer

Verify that you can access these URLs:

https://wc.mycompany.com/webcenter

https://wc.mycompany.com/webcenterhelp

https://wc.mycompany.com/rss

https://wc.mycompany.com/portalTools

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

https://wc.mycompany.com/owc_discussions

6.22Backing 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:

Back up the web tier:

Shut down the instance using opmnctl.

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

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

tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME

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

tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE

Start the instance using opmnctl:

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

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.

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>

Scripting on this page enhances content navigation, but does not change the content in any way.