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 includes the following topics:
Overview of Extending the Domain for WebCenter Portal Components
Extending the Domain for WebCenter Portal Components Using the Configuration Wizard
Propagating the Domain Configuration to SOAHOST2, WCPHOST1, and WCPHOST2
Extend the WebLogic Server 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 Server 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. |
|
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 the other hosts. |
|
Configure Java object caching |
Configure the Java Object Cache to increase the performance of the WebCenter Portal application. |
Section 10.5, "Configuring the Java Object Cache for Spaces_Cluster" |
Configure tools and services for WebCenter Portal |
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" |
Configure the Oracle HTTP Server with the extended domain |
Configure the Oracle HTTP Server with the Managed Servers, and validate access. |
|
Back up the WebCenter Portal configuration |
Back up the newly extended domain configuration. |
Section 10.12, "Backing Up the WebCenter Portal Configuration" |
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 can use the backup to recover in case any errors are made in the domain extension. For more information, see the "Backing Up Your Environment" chapter in the Oracle Fusion Middleware Administrator's Guide.To extend the domain using the Configuration Wizard:
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.
Shut down the Administration Server and all Managed Servers in the domain.
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
Start the Configuration Wizard.
./config.sh
In the Welcome screen, select Extend an existing WebLogic domain, and click Next.
In the WebLogic Domain Directory screen, select the WebLogic Server domain directory:
ORACLE_BASE/admin/domain_name/aserver/domain_name
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:
Oracle WebCenter Spaces Foot 1
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 the domain (Section 8.3) or extended it for Oracle SOA Suite components (Section 9.3).
Basic WebLogic Server Domain
Oracle SOA Suite
Oracle Enterprise Manager
Oracle WSM Policy Manager
Oracle JRF
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 Component Schema screen, do the following:
Ensure that the following component schemas appear on the screen. The schema owner names shown in Table 10-2 assume that wcpedg
was used as prefix for schema creation from RCU.
Table 10-2 Values for Component Schemas
Component Schema | Schema Owner |
---|---|
WebCenterDS Schema |
|
ActivitiesDS Schema |
|
DiscussionDS Schema |
|
PersonalizationDS Schema |
|
PortletDS Schema |
|
Portlet-ServicesProducerDS Schema |
|
WC-ServicesProducerDS |
|
WebCenterMDS Schema |
|
PersonalizationMDS Schema |
|
mds-PageletProducerDS Schema |
|
mds-ServicesProducerDS Schema |
|
Select the check box next to all the component schemas shown in Table 10-2.
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.
Click Next.
In the Configure GridLink RAC Component Schema screen:
Select all 11 data source schemas, listed in Table 10-2.
Enter values for all of the fields except Username, 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.example.com
.
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.example.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.example.com (Port 1521)
and
custdbhost2-vip.example.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@CUSTDBHOST1 ~]$ 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.example.com (Port 6200)
and
custdbhost2.example.com (Port 6200)
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.
Click Next.
Username: Select each of the 11 data sources, one by one, and enter the complete user name for the database schema owner (including the prefix). For the user names in Table 10-2, wcpedg
was the prefix for schema creation through RCU.
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.
In the Select Optional Configuration screen, select the following items:
Managed Servers, Clusters and Machines
Deployments and Services
Click Next.
In the Configure Managed Servers screen, modify the Managed Servers as listed in Table 10-3.
Note:
The Managed Servers listed in this table (WC_Spacesn, WC_Collaborationn, WC_Utilitiesn, and WC_Portletn) may display in a different order on your screen.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 |
Notes:
Managed Servers may be renamed but DO NOT DELETE any of the original Managed Servers on this page.
Providing the listen address is mandatory if the cluster mode is 'unicast'.
Click Next.
In the Configure Clusters screen, add four new clusters (Table 10-4).
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. |
Note:
WSM-PM_Cluster
and SOA_Cluster
should already display in the list.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 and ensure that the five entries in Table 10-5 exist.
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." |
ADMINHOST |
localhost |
WCPHOST1 |
WCPHOST1 |
WCPHOST2 |
WCPHOST2 |
Leave all other fields to their default values.
Click Next.
In the Assign Servers to Machines screen, assign servers to machines as follows:
ADMINHOST:
AdminServer
SOAHOST1:
WLS_SOA1
WLS_WSM1
SOAHOST2:
WLS_SOA2
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.
In the Target Deployment to Clusters or Servers screen, ensure the following targets:
The wsm-pm application must be targeted to WSM-PM_Cluster.
If you plan to deploy Web Services Manager to SOA_Cluster, make sure the wsm-pm application is targeted to SOA_Cluster as well.
Remove the wsm-pm application targeting from all clusters specific to WebCenter Portal.
Click Next.
In the Target Services to Clusters or Servers screen:
mds-owsm must be targeted to WSM-PM_Cluster and AdminServer.
(You can optionally target mds-owsm to other clusters/servers, if any).
Click Next.
In the Configuration Summary screen, click Extend.
In the Extending Domain screen, click Done.
You must start the Administration Server for this configuration to take effect.
Start the Administration Server using the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."
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.3, "Propagating the Domain Changes to the Managed Server Domain Directory"
For the enterprise deployment described 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. You must disable the host name verification for the WebCenter Portal Managed Servers (WC_Spacesn, WC_Portletn, WC_Collaborationn, WC_Utilitiesn) to avoid errors when managing the different WebLogic Servers. For more information, see Section 8.4.8, "Disabling Host Name Verification."
You enable host name verification again once the enterprise deployment topology configuration is complete. For more information, see Section 11.3, "Enabling Host Name Verification Certificates for Node Manager."
Use the startNodeManager.sh
script to restart Node Manager.
To restart Node Manager on SOAHOST1:
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
Start Node Manager:
cd WL_HOME/server/bin ./startNodeManager.sh
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:
Back up the Managed Server domain directory and the Managed Server applications directory:
tar -cpzf BACKUP_LOCATION/edg10.3.3-doman_name.tgz ORACLE_BASE/admin/domain_name
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=wcpdomaintemplateExtWCP.jar -template_name=wcpdomaintemplateExtWCP
Note:
If the specified template packjar
file exists from previous pack/unpack operations, choose another name (such as wcpdomaintemplateExtWCP2.jar
).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=wcpdomaintemplateExtWCP.jar -overwrite_domain=true -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
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.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.2, "Modify the Upload and Stage Directories to an Absolute Path"
Section 10.4.3, "Starting Node Manager on WCPHOST1 and WCPHOST2"
Section 10.4.5, "Verifying GridLink Data Source Configuration and ONS for WebCenter Portal"
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:
Run the following commands on SOAHOST1 to copy the template file created earlier to SOAHOST2, WCPHOST1, and WCPHOST:
scp wcpdomaintemplateExtWCP.jar oracle@SOAHOST2:ORACLE_COMMON_HOME/common/bin
scp wcpdomaintemplateExtWCP.jar oracle@WCPHOST1:ORACLE_COMMON_HOME/common/bin
scp wcpdomaintemplateExtWCP.jar oracle@WCPHOST2:ORACLE_COMMON_HOME/common/bin
Copy the required application deployment files from the Administration Server to SOAHOST2, WCPHOST1, and WCPHOST2.
Note:
Paths inconfig.xml
created by the Administration Server need to be available on every machine, regardless of whether the Administration Server is mounted or dismounted. This is accomplished by copying the missing folders, files, or both from the primary domain to the new node's local file system.Create the required directory structure on SOAHOST2, WCPHOST1, and WCPHOST2
mkdir -p ORACLE_BASE/admin/domain_name/aserver/applications/domain_name
Transfer the required files from the Administration Server from SOAHOST1.
cd ORACLE_BASE/admin/domain_name/aserver/applications/domain_name
scp -r oracle@SOAHOST1:ORACLE_BASE/admin/domainname/aserver/applications/domain_name
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=wcpdomaintemplateExtWCP.jar -overwrite_domain=true -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
Repeat the preceding steps for WCPHOST1 and WCPHOST2.
After propagating domain changes, update the upload and stage directories. For detailed steps, see Section 8.5.2, "Modifying the Upload and Stage Directories to an Absolute Path".
Use the startNodeManager.sh
script to start Node Manager.
To start Node Manager on WCPHOST1 and WCPHOST2:
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 tosetNMProps.sh
again, and Node Manager is already running on SOAHOST1 and SOAHOST2.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
To start the WC_Spaces1, WC_Portlet1, WC_Utilities1, and WC_Collaboration1 Managed Servers on WCPHOST1:
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).
Expand the Environment node in the Domain Structure window.
Click Servers.
Open the Control tab.
Select WLS_WSM1 and WLS_WSM2.
Click Start.
Verify that the WLS_WSM1 and WLS_WSM2 Managed Servers are running.
Select WC_Spaces1, WC_Portlet1, WC_Utilities1, and WC_Collaboration1.
Click Start.
Before starting WC_Spaces2, WC_Portlet2, WC_Utilities2, and WC_Collaboration2 on WCPHOST2, 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:
Log in to the WebLogic Server Administration Console.
In the Domain Structure tree, expand Services, then select Data Sources.
On the Data Sources page (Figure 10-1), click the name of a GridLink data source that was created.
On the Test Data Source Page (Figure 10-2), click Monitoring and then the Testing tab, select one of the WebCenter Portal Managed Servers, such as WC_Spaces1, and then click Test Data Source.
The test should be successful if the configuration is correct.
Repeat the test for each WebCenter Portal Managed Server running on WCPHOST1 that uses the GridLink data source.
Click the Monitoring tab, and click the name of one of the servers.
Click the ONS tab and then the Testing tab.
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@CUSTDBHOST1 ~]$ srvctl status scan_listener SCAN Listener LISTENER_SCAN1 is enabled SCAN listener LISTENER_SCAN1 is running on node CUSTDBHOST1 SCAN Listener LISTENER_SCAN2 is enabled SCAN listener LISTENER_SCAN2 is running on node CUSTDBHOST2 SCAN Listener LISTENER_SCAN3 is enabled SCAN listener LISTENER_SCAN3 is running on node CUSTDBHOST2 [orcl@CUSTDBHOST1 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016 [orcl@CUSTDBHOST1 ~]$ srvctl status nodeapps | grep ONS ONS is enabled ONS daemon is running on node: CUSTDBHOST1 ONS daemon is running on node: CUSTDBHOST2
Repeat the ONS test for each WebCenter Portal Managed Server that uses the GridLink data source.
To validate that all the WebCenter Portal Managed Servers on WCPHOST1 are up and running:
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: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
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
To start the WC_Spaces2, WC_Portlet2, WC_Utilities2, and WC_Collaboration2 Managed Servers using the Administration Console:
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).
Expand the Environment node in the Domain Structure window.
Click Servers.
Open the Control tab.
Select WC_Spaces2, WC_Portlet2, WC_Utilities2, and WC_Collaboration2.
Click Start.
To validate that all the WebCenter Portal Managed Servers on WCPHOST2 are up and running:
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
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
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 WebCenter Portal 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 the "Getting Started Using the Oracle WebLogic Scripting Tool (WLST)" section in the 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:
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.
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")
Configure the 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 forDiscover 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
Verify the JOC configuration using the CacheWatcher utility. For more information, see the "Configuring the Distributed Java Object Cache" appendix in the Oracle Fusion Middleware High Availability Guide.
To convert discussions (on all Managed Servers in the Collab_Cluster) from multicast to unicast, add the relevant startup parameters:
In the Oracle WebLogic Server Administration Console, select Servers, WC_Collaboration1, Configuration, and then Server Start.
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
WCPHOST1
is the host on which WC_Collaboration1
is running.
Port 8089 is a port reserved for WebCenter Coherence communications.
Repeat steps 1 and 2 for WC_Collaboration2 with the exact same parameter values.
-Dtangosol.coherence.wka1=WCPHOST1 -Dtangosol.coherence.wka2=WCPHOST2 -Dtangosol.coherence.localhost=WCPHOST2 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.localport=8089
Restart the WC_Collaboration servers.
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:
Log in to the discussions server's Administration Console for each member of the cluster at:
http://WCPHOSTn:9002/owc_discussions/admin
Select Cache Settings.
In the Cache Features section (Figure 10-4), ensure that Clustering is set to Enabled.
As servers join the cluster they appear at the top of the screen.
Note:
Updates to discussion content do not refresh immediately when clustered caching is enabled. Users can click the Refresh icon to force a manual refresh at any time.In the Tool section (Figure 10-5), select Reset All Cluster Members and the Start Cache WarmUp Task. Repeat the cache warm up task on all members of the cluster.
Repeat steps 1 through 4 for all members of the cluster.
As servers join the cluster they appear at the top of the screen.
Out-of-the box, analytics collectors are configured to communicate with the local WebCenter Portal application in a 1-1 relationship (the collectors listen on localhost
). No additional analytics collector configuration is required.
However, you must configure the WebCenter Portal applications to send event messages to localhost
:
To connect the WebCenter Portal application to the analytics collector:
Connect to the Managed Server where the WebCenter Portal 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.
Create a connection between the WebCenter Portal application and the analytics collector and make it the default connection (default=1
).
For example:
createAnalyticsCollectorConnection(appName="webcenter", connectionName="HAConn1", isUnicast=1, collectorHost="localhost", collectorPort=31314, isEnabled=1, timeout=30, default=1)
See also, the "createAnalyticsCollectorConnection" section in WebLogic Scripting Tool Command Reference.
Verify the changes made:
listDefaultAnalyticsCollectorConnection(appName="webcenter")
See also the "listDefaultAnalyticsCollectorConnection" section in the WebLogic Scripting Tool Command Reference.
The activity graph engines must have run at least once for analytics task flows to display data. For details, see Section 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:
Log in to the Administration Console.
Shut down WC_Spacesn, WC_Portletn, WC_Collaborationn, and WC_Utilitiesn servers.
Select Deployments
Click Lock & Edit.
Alter the targets for each of these deployments:
activitygraph-engines (11.1.1.4.0)
oracle.webcenter.activitygraph.enginelib (11.1.1,11.1.1)
oracle.webcenter.activitygraph.lib (11.1.1,11.1.1)
Select the deployment.
Select the Targets tab.
For an enterprise application, select the checkbox for Enterprise Application.
Click Change Targets.
Change the targeting for Utilities_Cluster from All servers in the cluster to only the WC_Utilities1 Managed Server. Do not change any other targeting details.
Click Yes to save the changes.
When finished with all three deployments, click Activate all Changes.
Start up WC_Spacesn, WC_Portletn, WC_Collaborationn, and WC_Utilitiesn servers.
The activity graph engines must have run at least once before activity graph can start to make recommendations and for analytics task flows to display data.
Log in as the WebLogic admin user to activity graph at: http://WCPHOST1:9003/activitygraph-engines
To access this page, you must be a member of the Administrators
group.
Click Start/Run to begin gathering statistics.
See also the "Preparing Data for the Activity Graph" section in the Administering Oracle WebCenter Portal.
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".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:
Connect to the Administration Server using the command-line Oracle WebLogic Scripting Tool (WLST), for example:
MW_HOME/wc/common/bin/wlst.sh
connect()
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 Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.
This section includes the following topics:
To enable Oracle HTTP Server to route to WebCenter Portal clusters, you must set the WebLogicCluster
parameter to the list of nodes in the cluster:
On WEBHOST1 and WEBHOST2, add directives to the wcp_vh.conf
and wcpinternal_vh.conf
files located in the following directory:
ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf
Note that this assumes you created the wcp_vh.conf
and wcpinternal_vh.conf
files using the instructions in Section 7.6, "Defining Virtual Hosts".
Note:
Keep any previous configuration for the Oracle SOA Suite.Add the directives highlighted in bold (Example 10-1) to the wcp_vh.conf
file within the <VirtualHost>
tag:
The wcp_vh.conf
file will appear as it does in Example 10-1.
<VirtualHost *:7777> ServerName https://wcp.example.com:443 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit <Location /soa-infra> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # SOA inspection.wsil <Location /inspection.wsil> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # UMS prefs <Location /sdpmessaging/userprefs-ui> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # Default to-do taskflow <Location /DefaultToDoTaskFlow> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # Workflow <Location /workflow> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> #Required if attachments are added for workflow tasks <Location /ADFAttachmentHelper> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # SOA composer application <Location /soa/composer> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # WebCenter Portal Application (previously called Spaces) <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/admin> WebLogicCluster WCPHOST1:9002,WCPHOST2:9002 SetHandler weblogic-handler WLProxySSL ON WLProxySSLPassThrough ON </Location> <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 <Location /activitygraph-engines> WebLogicCluster WCPHOST1:9003 SetHandler weblogic-handler WLProxySSL ON WLProxySSLPassThrough ON </Location> </VirtualHost>
Note:
An additional virtual host is required if your enterprise deployment requires Microsoft Office integration or access to a Microsoft SharePoint server. For more information, see "Managing Microsoft Office Integration" in Administering Oracle WebCenter Portal.Add the directives highlighted in bold (Example 10-2) to the wcpinternal_vh.conf
file:
The wcpinternal_vh.conf
file will appear as it does in Example 10-2.
Example 10-2 wcpinternal_vh.conf file
<VirtualHost *:7777> ServerName wcpinternal.example.com:80 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit # WSM-PM <Location /wsm-pm> SetHandler weblogic-handler WebLogicCluster SOAHOST1:7010,SOAHOST2:7010 </Location> # Worklist <Location /integration> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 </Location> # Workflow <Location /workflow> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 </Location> # 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:9002,WCPHOST2:9002 SetHandler weblogic-handler </Location> </VirtualHost>
Restart Oracle HTTP Server on 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=ohs2
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 follow:
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 Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server.
To accommodate Microsoft Clients, refer to the overview and detailed steps outlined in the Administering 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 the "Configuring SSO with Virtual Hosts" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal.
Follow the steps in the "Configuring SSO for Microsoft Clients" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal to properly configure Windows authentication services.
Verify these load balancer URLs to ensure that appropriate routing and failover is working from Oracle HTTP Server to the WebCenter Portal clusters:
https://wcp.example.com/webcenter
https://wcp.example.com/webcenterhelp
https://wcp.example.com/rss
https://wcp.example.com/rest/api/resourceIndex
https://wcp.example.com/pagelets
https://wcp.example.com/portalTools
https://wcp.example.com/wsrp-tools
https://wcp.example.com/owc_discussions
https://wcp.example.com/wcps/api/property/resourceIndex
https://wcp.example.com/activitygraph-engines/Login.jsp
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 the "Backing Up Your Environment" section in Oracle Fusion Middleware Administrator's Guide. For information about recovering your information, see the "Recovering Your Environment" section in Oracle Fusion Middleware Administrator's Guide.
For information about Oracle HTTP Server data that must be backed up, refer to the "Backup and Recovery Recommendations for Oracle HTTP Server" section in Oracle Fusion Middleware Administrator's Guide. For information on how to recover components, see "Recovering Components" and "Recovering After Loss of Component Host" and for recommendations specific to recovering from the loss of a host, see the "Recovering Oracle HTTP Server to a Different Host" section in Oracle Fusion Middleware Administrator's Guide.
Also refer to Oracle Database Backup and Recovery User's Guide for information on database backup.
To back up the domain configuration:
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 are located in the following directory:
ORACLE_BASE/admin/domain_name
To back up the Administration Server run the following command on SOAHOST1:
tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
Footnote Legend
Footnote 1: In previous releases, the out-of-the-box application WebCenter Portal was called "Spaces". Some screens in the Configuration Wizard refer to the previous name.