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:
Section 6.2, "Extending the Domain for WebCenter Components"
Section 6.4, "Disabling Host Name Verification for the WebCenter Managed Servers"
Section 6.6, "Propagating the Domain Changes to the Managed Server Domain Directory"
Section 6.8, "Starting the Node Manager on WCHOST1 and WCHOST2"
Section 6.9, "Starting the WLS_Spaces1, WLS_Portlet1, and WLS_Services1 Managed Servers on WCHOST1"
Section 6.10, "Validating the WLS_Spaces1, WLS_Portlet1, and WLS_Services1 Managed Servers"
Section 6.11, "Starting the WLS_Spaces2, WLS_Portlet2, and WLS_Services2 Managed Servers on WCHOST2"
Section 6.12, "Validating the WLS_Spaces2, WLS_Portlet2, and WLS_Services2 Managed Servers"
Section 6.16, "Validating Access Through Oracle HTTP Server"
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.
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 GuideChange directory to the location of the Configuration wizard. This is within the WebCenter home directory.
SOAHOST1> cd ORACLE_BASE/product/fmw/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 theCONFIG_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.
In the WebLogic Domain Directory screen, Select the WebLogic domain directory (ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>), and click Next.
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.
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.
In the Configure JDBC Data Sources screen, do the following:
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.
Select the check box next to all the component schemas.
Select Configure all datasources as RAC multi-datasources in the next panel.
Click Next.
Configure RAC Multi Data Sources screen
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.
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:
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.
The Configure Clusters screen should already include the WSM_PM Cluster in the list. Add the following three new 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.
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.
In the Configure Machines screen, click the Unix Machine tab. Make sure the following four entries exist:
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.
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.
In the Target Deployment to Clusters or Servers screen, click Next.
In the Review WebLogic Domain screen, click Next.
In the Extend WebLogic Domain 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.
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
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:
Expand the Environment node in the Oracle WebLogic Server Administration Console.
Select Servers. The Summary of Servers page appears.
Select WLS_Spaces1 (represented as a hyperlink) from the Names column of the table. The Settings page appears.
Select the SSL tab.
Expand the Advanced section of the page.
Set Hostname Verification to None.
Repeat these steps for the WLS_Spaces2, WLS_Portlet1, WLS_Portlet2, WLS_Services1, and WLS_Services2 managed servers.
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
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.
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
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
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
To propagate the domain configuration, complete these steps:
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
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 theunpack
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
Repeat the above steps for WCHOST1 and WCHOST2.
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
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.
Follow these steps to start the WLS_Spaces1, WLS_Portlet1, and WLS_Services1 managed servers:
Access the Administration Console at http://SOAHOST1VHN1:7001/console
.
Click Servers.
Open the Control tab.
Select WLS_Spaces1, WLS_Portlet1, and WLS_Services1.
Click Start.
Note:
SOAHOST1VHN1 is the virtual hostname that maps to the virtual IP where the Administration Server is listening (in SOAHOST1).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
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
.
Follow these steps to start the WLS_Spaces2, WLS_Portlet2, and WLS_Services2 managed servers:
Access the Administration Console at http://SOAHOST1VHN1:7001/console
.
Click Servers.
Open the Control tab.
Select WLS_Spaces2, WLS_Portlet2, and WLS_Services2.
Click Start.
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
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
.
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.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:
wls:/mydomain/serverConfig>execfile('MW_HOME/webcenter/scripts/configure-joc.py')
All the input parameters are prompted by the script. The script can be used to perform the following JOC configurations:
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
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).
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
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'.
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.
Create a directory on a shared drive. Let's call this /shared/owc_wiki
.
Create two directories under that: /attachments
and /templates
.
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
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
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.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
Verify that templates created on one node can be accessed from either node.
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.
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>
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>
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.
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
).
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
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>