1. Enterprise Deployment Guide for Oracle WebCenter Portal
  2. Configuring the Enterprise Deployment
  3. Extending the Domain with Oracle WebCenter Portal

15 Extending the Domain with Oracle WebCenter Portal

The following topics describes how to extend the enterprise deployment domain with the Oracle WebCenter Portal software.

Parent topic: Configuring the Enterprise Deployment

Support for Dynamic Clusters in Oracle WebCenter Content

Oracle WebCenter Portal supports two different topologies: static clusters-based topology and dynamic clusters-based topology. When choosing the dynamic cluster topology, there are some differences with respect to the conventional static clusters configuration.

Static clusters, also called configured clusters, are conventional clusters where you manually configure and add each server instance. A dynamic cluster includes a new "server-template" object that is used to define a centralized configuration for all generated (dynamic) server instances. When you create a dynamic cluster, the dynamic servers are preconfigured and automatically generated for you. This feature enables you to scale up the number of server instances in the dynamic cluster when you need additional server capacity. You can simply start the dynamic servers without having to first manually configure and add them to the cluster.

The steps in this section include instructions to configure the domain for both static or dynamic topologies. The differences between the two types of configurations are listed below:

  • The Configuration Wizard process may differ for each case. For example, you should define server templates for dynamic clusters instead of servers.

  • For dynamic clusters, you should perform the server-specific configurations such as setting the listen address, configuring the upload and staging directories, or configuring the keystores in the server template instead of in the server.

  • Service migration is configured in a different way for dynamic clusters. Dynamic clusters do not use migratable targets, instead the JMS resources are targeted to the cluster. Specific procedure for configuring service migration for dynamic clusters is included in this guide.

Mixed clusters (clusters that contains both dynamic and configured server instances) are not supported in the Oracle WebCenter Portal enterprise deployment.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Variables Used When Extending the Domain for WebCenter Portal

As you perform the tasks in this chapter, you will be referencing the directory variables listed in this section.

The following directory variables, which are defined in File System and Directory Variables Used in This Guide.

  • ORACLE_HOME

  • ASERVER_HOME

  • APPLICATION_HOME

  • DEPLOY_HOME

  • WEB_CONFIG_DIR

  • JAVA_HOME

In addition, you'll be referencing the following virtual IP (VIP) addresses and host names defined in Physical and Virtual IP Addresses Required by the Enterprise Topology:

  • ADMINVHN

  • WCPHOST1

  • WCPHOST2

  • DBHOST1

  • DBHOST2

  • SCAN Address for the Oracle RAC Database (DB-SCAN.examle.com)

Parent topic: Extending the Domain with Oracle WebCenter Portal

Installing the Software for an Enterprise Deployment

The procedure to install the software for an enterprise deployment is explained in this section.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Starting the Oracle WebCenter Portal Installer on WCCHOST1

To start the installation program:

  1. Log in to WCCHOST1.
  2. Go to the directory where you downloaded the installation program.
  3. Launch the installation program by invoking the java executable from the JDK directory on your system, as shown in the example below.
    JAVA_HOME/bin/java -d64 -jar fmw_12.2.1.3.0_wcportal.jar

    Be sure to replace the JDK location in these examples with the actual JDK location on your system.

    For information about downloading the software and locating the actual installer file name for your product, see Identifying and Obtaining Software Distributions for an Enterprise Deployment.

When the installation program appears, you are ready to begin the installation.

Parent topic: Installing the Software for an Enterprise Deployment

Navigating the Installation Screens

The installation program displays a series of screens, in the order listed in the following table.

If you need additional help with any of the installation screens, click the screen name.

Screen Description

Welcome

This screen introduces you to the product installer.

Auto Updates

Use this screen to automatically search My Oracle Support for available patches or automatically search a local directory for patches that you’ve already downloaded for your organization.

Installation Location

Use this screen to specify the location of your Oracle home directory.

For more information about Oracle Fusion Middleware directory structure, see Selecting Directories for Installation and Configuration in Planning an Installation of Oracle Fusion Middleware.

Installation Type

Use this screen to select the type of installation and consequently, the products and feature sets you want to install.

Select WebCenter Portal, then click Next.

Notes:

  • WebCenter Portal Worklist integration requires that the BPEL Services provided by SOA Suite share the same WebTier, SSO, and Identity Store.

  • For this Enterprise Deployment Guide, SOA Suite is installed and configured in the same WebLogic Server Domain and included in the WebTier, SSO, and Directory configurations.

  • Whether the installation has SOA Suite installed in the same or separate ORACLE_HOME, the WebCenter Portal SOA Composites option is required as a separate installation. For instructions about that installation see, Installing the Oracle WebCenter Portal SOA Composites.

Prerequisite Checks

This screen verifies that your system meets the minimum necessary requirements.

If there are any warning or error messages, you can refer to one of the following documents in the Roadmap for Verifying Your System Environment section in Planning Your Oracle Fusion Middleware Infrastructure Installation.

Installation Summary

Use this screen to verify the installation options you selected.

Click Install to begin the installation.

Installation Progress

This screen allows you to see the progress of the installation.

Click Next when the progress bar reaches 100% complete.

Installation Complete

Review the information on this screen, then click Finish to dismiss the installer.

Parent topic: Installing the Software for an Enterprise Deployment

Installing Oracle WebCenter Portal on WCCHOST2

If you have followed the EDG shared storage recommendations, there is a separate shared storage volume for product installations mounted on the *HOST2 hosts. You must also install the software on to the second products volume. It is recommended to execute the installs consistently from the WCCHOSTn hosts. See Shared Storage Recommendations When Installing and Configuring an Enterprise Deployment.

Parent topic: Installing the Software for an Enterprise Deployment

Creating the Oracle WebCenter Portal Database Schemas

Before you can configure an Oracle WebCenter Portal domain, you must install the required schemas on a certified database for use with this release of Oracle Fusion Middleware.

The following topics describe how to install the required schemas.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Starting the Repository Creation Utility (RCU)

To start the Repository Creation Utility (RCU):

  1. Navigate to the ORACLE_HOME/oracle_common/bin directory on your system.
  2. Make sure that the JAVA_HOME environment variable is set to the location of a certified JDK on your system. The location should be up to but not including the bin directory. For example, if your JDK is located in /u01/oracle/products/jdk:

    On UNIX operating systems:

    export JAVA_HOME=/u01/oracle/products/jdk
  3. Start RCU:

    On UNIX operating systems:

    ./rcu

    Note:

    If your database has Transparent Data Encryption (TDE) enabled, and you want to encrypt your tablespaces that are created by the RCU, provide the -encryptTablespace true option when you start RCU.

    This defaults the appropriate RCU GUI Encrypt Tablespace checkbox selection on the Map Tablespaces screen without further effort during the RCU execution. See Encrypting Tablespaces in Creating Schemas with the Repository Creation Utility.

Parent topic: Creating the Oracle WebCenter Portal Database Schemas

Navigating the RCU Screens to Create the Schemas

Schema creation involves the following tasks.

Task 1   Introducing RCU

Click Next.

Task 2   Selecting a Method of Schema Creation

If you have the necessary permission and privileges to perform DBA activities on your database, select System Load and Product Load. This procedure assumes that you have the necessary privileges.

If you do not have the necessary permission or privileges to perform DBA activities in the database, you must select Prepare Scripts for System Load on this screen. This option will generate a SQL script, which can be provided to your database administrator. See "Understanding System Load and Product Load" in Creating Schemas with the Repository Creation Utility.

Task 3   Providing Database Connection Details

Provide the database connection details for RCU to connect to your database.

In the Host Name field, enter the SCAN address of the Oracle RAC Database.

Enter the DBMS/Service details.

Enter the Schema Owner and Schema Password details.

Click Next to proceed, then click OK on the dialog window confirming that connection to the database was successful.

Task 4   Specifying a Custom Prefix and Selecting Schemas

Select Select existing prefix, and then select the prefix you used when you created the initial domain in Creating the Initial Infrastructure Domain for an Enterprise Deployment.

From the list of schemas, select WebCenter Portal . This will automatically select the required WebCenter Portal schemas. In addition, the following dependent schemas have already been installed with the Infrastructure and are grayed out:

  • Metadata Services

  • Audit Services

  • Audit Services Append

  • Audit Services Viewer

  • Oracle Platform Security Services

  • User Messaging Service

The custom prefix is used to logically group these schemas together for use in this domain only; you must create a unique set of schemas for each domain as schema sharing across domains is not supported.

Tip:

For more information about custom prefixes, see "Understanding Custom Prefixes" in Creating Schemas with the Repository Creation Utility.

For more information about how to organize your schemas in a multi-domain environment, see "Planning Your Schema Creation" in Creating Schemas with the Repository Creation Utility.

Click Next to proceed, then click OK on the dialog window confirming that prerequisite checking for schema creation was successful.

Task 5   Specifying Schema Passwords

Specify how you want to set the schema passwords on your database, then specify and confirm your passwords.

Tip:

You must make a note of the passwords you set on this screen; you will need them later on during the domain creation process.

Task 6   Specifying Custom Variables

For an enterprise deployment, Oracle recommends that you enter “Y” to enable partitioning of the Analytics data.

This feature partitions the analytics data by month. In a partitioned environment, the recommended method for purging data is simply to drop the month-based partitions that are no longer required.

For information about partitioning analytics data, see "Partitioning Oracle WebCenter Portal's Analytics Data" in the Oracle Fusion Middleware Administrator's Guide.

Task 7   Verifying the Tablespaces for the Required Schemas

On the Map Tablespaces screen, review the information, and then click Next to accept the default values.

Click OK in the confirmation dialog box.

Task 8   Completing Schema Creation

Navigate through the remainder of the RCU screens to complete schema creation. When you reach the Completion Summary screen, click Close to dismiss RCU.

Task 9   Verifying the Schema Creation

To verify that the schemas were created successfully, and to verify the database connection details, use SQL*Plus or another utility to connect to the database, using the WCPINFRA schema name and the password you provided.

For example:

sqlplus  

SQL*Plus: Release 12.1.0.1.0 Production on Wed Aug 31 05:41:31 2016  

Copyright (c) 1982, 2013, Oracle. All rights reserved.  

Enter user-name: FMW1221_WEBCENTER 
Enter password: schema_password

Connected to: 
Oracle Database 11g Enterprise Edition Release 12.1.0.1.0 - 64bit Production 
With the Partitioning, OLAP, Data Mining and Real Application Testing options  

SQL>

Parent topic: Creating the Oracle WebCenter Portal Database Schemas

Extending the Enterprise Deployment Domain with Oracle WebCenter Portal

This section provides instructions for extending the existing enterprise deployment domain with the Oracle WebCenter Portal software.

Extending the domain involves the following:

Parent topic: Extending the Domain with Oracle WebCenter Portal

Starting the Configuration Wizard

Start the Configuration Wizard as the first step to extend the existing enterprise deployment domain.

Note:

If you added any customizations directly to the start scripts in the domain, those are overwritten by the configuration wizard. To customize server startup parameters that apply to all servers in a domain, you can create a file called setUserOverridesLate.sh and configure it, for example, add custom libraries to the WebLogic Server classpath, specify Additional JAVA command line options for running the servers, or specify additional environment variables. Any customizations you add to this file are preserved during domain upgrade operations, and are carried over to remote servers when using the pack and unpack commands.

For more information about using the setUserOverridesLate script with this Enterprise Deployment Guide, see Customizing Server Parameters with the setUserOverridesLate Script.

To start the Configuration Wizard:

  1. From the WebLogic Server Console, stop any managed servers that are modified by this domain extension. Managed Servers that are not effected can remain on-line.
  2. For any managed servers to be modified, verify that the managed server shutdown has completed.
  3. Stop the Administration Server once all managed servers are in a steady state.
  4. Navigate to the following directory and start the WebLogic Server Configuration Wizard.
    cd ORACLE_HOME/oracle_common/common/bin
./config.sh

Parent topic: Extending the Enterprise Deployment Domain with Oracle WebCenter Portal

Navigating the Configuration Wizard Screens to Extend the Domain with WebCenter Portal

Follow the instructions in the following sections to create and configure the domain for the topology, with static or dynamic clusters.

Parent topic: Extending the Enterprise Deployment Domain with Oracle WebCenter Portal

Extending the Domain with Static Clusters

Follow the instructions in this section to create and configure the domain for the topology with static clusters.

Note:

You can use the same procedure described in this section to extend an existing domain with static clusters. If your needs do not match the instructions given in the procedure, be sure to make your selections accordingly, or refer to the supporting documentation for additional details.

Domain creation and configuration includes the following tasks.

Task 1   Selecting the Domain Type and Domain Home Location

On the Configuration Type screen, select Update an existing domain.

In the Domain Location field, select the value of the ASERVER_HOME variable, which represents the complete path to the Administration Server domain home you created in Creating the Initial Infrastructure Domain for an Enterprise Deployment.

For more information about the directory location variables, see File System and Directory Variables Used in This Guide

Tip:

More information about the other options on this screen can be found in Configuration Type in Creating WebLogic Domains Using the Configuration Wizard.

Task 2   Selecting the Configuration Template

On the Templates screen, make sure Update Domain Using Product Templates is selected, then select the following templates:

  • Oracle WebCenter Portal – 12.2.1.3.0 [wcportal]

  • Oracle WebCenter Pagelet Producer – 12.2.1.3.0 [wcportal]

  • Oracle WebCenter Portlet Producers - 12.2.1.3.0 [wcportal]

  • Oracle WebCenter Analytics Collector - 12.2.1.3.0 [wcportal]

In addition, the following additional templates should already be selected, because they were used to create the initial domain in Creating the Initial Infrastructure Domain for an Enterprise Deployment:

  • Oracle Enterprise Manager - 12.2.1.3.0 [em]

  • Oracle WSM Policy Manager - 12.2.1.3.0 [oracle_common]

  • Oracle JRF - 12.2.1.3.0 [oracle_common]

  • WebLogic Coherence Cluster Extension - 12.2.1.3.0 [wlserver]

Tip:

More information about the options on this screen can be found in Templates in Creating WebLogic Domains Using the Configuration Wizard.

Task 3   Providing the GridLink Oracle RAC Database Connection Details for Custom Data Sources

The configuration wizard requires additional tasks if data sources have been added to the domain outside of the configuration wizard. This task and the next will appear if the Creating a GridLink Data Source for Leasing and Using Persistent Stores for TLOGs and JMS in an Enterprise Deployment have been completed at the end of the Extending the Domain with Oracle SOA Suite section.

Confirm the GridLink data source configuration details for the following data sources:  

  • Leasing

  • TLOG

  • JMS

Note:

The names of these data sources may have been customized during execution and may not match this example.

If the values for these data sources do not appear complete, see the Task 6, "Specifying JDBC Component Schema Information" section for more details.

Task 4   Testing the JDBC Connections for Custom Data Sources

Use the JDBC Component Schema Test screen to test the data source connections you have just configured.

A green check mark in the Status column indicates a successful test. If you encounter any issues, see the error message in the Connection Result Log section of the screen, fix the problem, then try to test the connection again.

Tip:

For more information about the other options on this screen, see Test Component Schema in Creating WebLogic Domains Using the Configuration Wizard.

Task 5   Specifying the Database Configuration Type

On the Database Configuration Type screen, select RCU Data.

All fields are pre-populated, because you already configured the domain to reference the Fusion Middleware schemas that are required for the Infrastructure domain.

Verify and ensure that credentials in all the fields are the same that you have provided while configuring Oracle Fusion Middleware Infrastructure.

Click Get RCU Configuration after you finish verifying the database connection information. The following output in the Connection Result Log indicates that the operation succeeded: 

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

Tip:

For more information about the RCU Data option, see Understanding the Service Table Schema in Creating Schemas with the Repository Creation Utility.

For more information about the other options on this screen, see Datasource Defaults in Creating WebLogic Domains Using the Configuration Wizard.

Task 6   Specifying JDBC Component Schema Information

On the JDBC Component Schema screen, select all the WebCenter Portal schemas in the table.

When you select the schemas, the fields on the page are activated and the database connection fields are populated automatically.

Click Convert to GridLink and click Next.

Task 7   Providing the GridLink Oracle RAC Database Connection Details

On the GridLink Oracle RAC Component Schema screen, provide the information required to connect to the RAC database and component schemas, as shown in the following table.

Table 15-1 Information to Connect to the RAC Database and Component Schemas

Element Description and Recommended Value

SCAN, Host Name, and Port

Select the SCAN check box.

In the Host Name field, enter the Single Client Access Name (SCAN) Address for the Oracle RAC database.

In the Port field, enter the SCAN listening port for the database (for example, 1521)

ONS Host and Port

In the ONS Host field, enter the SCAN address for the Oracle RAC database.

In the Port field, enter the ONS Remote port (typically, 6200).

Enable Fan

Select the Enable Fan check box to receive and process FAN events,

Task 8   Testing the JDBC Connections

Use the JDBC Component Schema Test screen to test the data source connections you have just configured.

A green check mark in the Status column indicates a successful test. If you encounter any issues, see the error message in the Connection Result Log section of the screen, fix the problem, then try to test the connection again.

Tip:

For more information about the other options on this screen, see Test Component Schema in Creating WebLogic Domains Using the Configuration Wizard

Task 9   Selecting Advanced Configuration

To complete domain configuration for the topology, select the following options on the Advanced Configuration screen:

  • Topology

  • Deployments and Services

Task 10   Configuring Managed Servers

On the Managed Servers screen, new Managed Servers for Oracle WebCenter Portal, Portlets, and Collaboration appear in the list of servers along with the other Managed Servers that were created earlier. These servers are created automatically by the Oracle WebCenter Portal configuration template you selected earlier in the Configuration Wizard session.

Perform the following tasks to modify the default Managed Servers and create a second Managed Server for each server type:

  1. Select WC_Portal and rename it to WC_Portal1.

  2. Select Clone to create another managed server. Rename the new server to WC_Portal2.

  3. Repeat the above two steps to edit and create WC_Portlet1 and WC_Portlet2.

Tip:

More information about the options on the Managed Server screen can be found in Managed Servers in Creating WebLogic Domains Using the Configuration Wizard.

Table 15-2 New Managed Server Properties

Server Name Listen Address Listen Port Enable SSL SSL Listen Port Server Groups

WC_Portal1

WCPHOST1

9001

No

Disabled

WebCenter Portal Managed Server

WebCenter Portal Analytics Managed Server

WC_Portal2

WCPHOST2

9001

No

Disabled

WebCenter Portal Managed Server

WebCenter Portal Analytics Managed Server

WC_Portlet1

WCPHOST1

9002

No

Disabled

WebCenter Portal Pagelet Producer Managed Server

WebCenter Portal Portlet Producer Managed Server

WC_Portlet2

WCPHOST2

9002

No

Disabled

WebCenter Portal Pagelet Producer Managed Server

WebCenter Portal Portlet Producer Managed Server
Task 11   Assign Servers to Clusters

Confirm that all static configured Managed Servers are assigned to the correct Clusters.

Note:

When configuring WebCenter Portal by using dynamic clusters, there will be no additional servers to assign here.

Click Next to proceed to the next screen.

Task 12   Configuring Clusters

In the Configure Clusters screen, add the following new clusters:

  • Portal_Cluster

  • Portlet_Cluster

For all three clusters, leave the default values for Cluster Address, Frontend Host, and Port.

Note:

By default, server instances in a cluster communicate with one another using unicast. If you want to change your cluster communications to use multicast, refer to Considerations for Choosing Unicast or Multicast in Administering Clusters for Oracle WebLogic Server.

Tip:

More information about the options on this screen can be found in Clusters in Creating WebLogic Domains Using the Configuration Wizard.

Task 13   Assigning Server Templates

Click Next to proceed to the next screen.

Task 14   Configuring Dynamic Servers
Verify that all dynamic server options are disabled for clusters that are to remain as static clusters.

  1. Confirm that the Dynamic Cluster, Calculated Listen Port, and Calculated Machine Names checkboxes on this screen are unchecked.

  2. Confirm the Server Template selection is Unspecified.

  3. Click Next.

Task 15   Assigning Managed Servers to the Cluster

Use the Assign Servers to Clusters screen to assign Managed Servers to their respective cluster:

  1. In the Clusters pane, select the cluster to which you want to assign the servers; in this case, Portal_Cluster.

  2. In the Servers pane, assign WC_Portal1 to Portal_Cluster by doing one of the following:

    • Click once on WC_Portal1 Managed Server to select it, then click on the right arrow to move it beneath the selected cluster in the Clusters pane.

    • Double-click on WC_Portal1 to move it beneath the selected cluster in the clusters pane.

  3. Repeat to assign WC_Portal2 to Portal_Cluster.

  4. Repeat steps 1-3 to assign WC_Portlet1 and WC_Portlet2 to Portlet_Cluster.

Tip:

More information about the options on this screen can be found in Assign Servers to Clusters in Creating WebLogic Domains Using the Configuration Wizard.

Task 16   Configuring Coherence Clusters

Use the Coherence Clusters screen to configure the Coherence cluster that is automatically added to the domain. Leave the port number value at 9991, as it was defined during the initial Infrastructure domain creation.

Note:

For Coherence licensing information, see Oracle Coherence Products in Oracle Fusion Middleware Licensing Information User Manual.

Task 17   Verifying the Existing Machines

Under the Unix Machine tab, verify the names of the machines you created when creating the initial Infrastructure domain.

Click Next to proceed.

Task 18   Assigning Servers to Machines

Use the Assign Servers to Machines screen to assign the Managed Servers you just created to the corresponding machines in the domain.

Assign WC_Portal1, WC_Portlet1 to WCPHOST1.

Assign WC_Portal2, WC_Portlet2 to WCPHOST2.

Tip:

More information about the options on this screen can be found in Assign Servers to Machines in Creating WebLogic Domains Using the Configuration Wizard.

Task 19   Configuring Virtual Targets

Click Next to proceed to the next screen.

Task 20   Configuring Partitions

Click Next to proceed to the next screen.

Task 21   Deployments Targeting

With the Oracle Web Services Manager Policy Manager deployed to a separate cluster, the default targeting of the WSM-PM application to the Portal and Portlet clusters should be removed.

For each of the Portal_Cluster and Portlet_Cluster in the Targets panel:

Select the wsm-pm application entry within the Application folder and click the left arrow button to remove it from the targets list.

Task 22   Services Targeting

With the Oracle Web Services Manager Policy Manager deployed to a separate cluster, the default targeting of the service resources needed by the WSM-PM application can be removed from the Portal and Portlet clusters.

For each of the Portal_Cluster and Portlet_Cluster in the Targets panel:

Select and remove the following resource from the targets list:

  • mds-owsm

Task 23   Reviewing Your Configuration Specifications and Configuring the Domain

The Configuration Summary screen contains the detailed configuration information for the domain you are about to create. Review the details of each item on the screen and verify that the information is correct.

You can go back to any previous screen if you need to make any changes, either by using the Back button or by selecting the screen in the navigation pane.

Click Update to execute the domain extension.

Tip:

More information about the options on this screen can be found in Configuration Summary in Creating WebLogic Domains Using the Configuration Wizard.

Task 24   Writing Down Your Domain Home and Administration Server URL

The Configuration Success screen will show the following items about the domain you just configured:

  • Domain Location

  • Administration Server URL

You must make a note of both items as you will need them later; the domain location is needed to access the scripts used to start the Node Manager and Administration Server, and the URL is needed to access the Administration Server.

Click Finish to dismiss the configuration wizard.

Task 25   Start the Administration Server

Start the Administration Server to ensure the changes you have made to the domain have been applied.

After you have completed extending the domain with static clusters, go to Propagating the Extended Domain to the Domain Directories and Machines.

Extending the Domain with Dynamic Clusters

Follow the instructions in this section to extend the domain for the topology with dynamic clusters.

Note:

This procedure assumes that you are extending an existing domain. If your needs do not match the instructions given in the procedure, ensure that you make your selections accordingly, or refer to the supporting documentation for additional details.

Domain extension and configuration includes the following tasks:

Task 1   Selecting the Domain Type and Domain Home Location

On the Configuration Type screen, select Update an existing domain.

In the Domain Location field, select the value of the ASERVER_HOME variable, which represents the complete path to the Administration domain home you created as part of the initial domain.

For more information about the directory location variables, see File System and Directory Variables Used in This Guide.

Tip:

More information about the other options on this screen can be found in Configuration Type in Creating WebLogic Domains Using the Configuration Wizard.

Task 2   Selecting the Configuration Template

On the Templates screen, make sure Update Domain Using Product Templates is selected, then select the following templates:

  • Oracle WebCenter Portal – 12.2.1.3.0 [wcportal]

  • Oracle WebCenter Pagelet Producer – 12.2.1.3.0 [wcportal]

  • Oracle WebCenter Portlet Producers - 12.2.1.3.0 [wcportal]

  • Oracle WebCenter Analytics Collector - 12.2.1.3.0 [wcportal]

In addition, the following additional templates should already be selected, because they were used to create the initial domain in Creating the Initial Infrastructure Domain for an Enterprise Deployment:

  • Oracle Enterprise Manager - 12.2.1.3.0 [em]

  • Oracle WSM Policy Manager - 12.2.1.3.0 [oracle_common]

  • Oracle JRF - 12.2.1.3.0 [oracle_common]

  • WebLogic Coherence Cluster Extension - 12.2.1.3.0 [wlserver]

Tip:

More information about the options on this screen can be found in Templates in Creating WebLogic Domains Using the Configuration Wizard.

Task 3   Providing the GridLink Oracle RAC Database Connection Details for Custom Data Sources

The configuration wizard may present additional tasks if data sources have been added to the domain outside of the configuration wizard. This task and the next will appear if the Creating a GridLink Data Source for Leasing and Using Persistent Stores for TLOGs and JMS in an Enterprise Deployment have been completed at the end of the Extending the Domain with Oracle SOA Suite section. If you have chosen the option to reuse the WLSSchemaDatasource for leasing and JMS/TLOG persistent stores, this step and the next step will not appear.

Confirm the GridLink data source configuration details for the following data sources:  

  • Leasing

  • TLOG

  • JMS

Note:

The names of these data sources may have been customized during execution and may not match this example.

If the values for these data sources do not appear complete, see the Task 6, "Specifying JDBC Component Schema Information" section for more details.

Task 4   Testing the JDBC Connections for Custom Data Sources

Use the JDBC Component Schema Test screen to test the data source connections you have just configured.

A green check mark in the Status column indicates a successful test. If you encounter any issues, see the error message in the Connection Result Log section of the screen, fix the problem, then try to test the connection again.

Tip:

For more information about the other options on this screen, see Test Component Schema in Creating WebLogic Domains Using the Configuration Wizard.

Task 5   Specifying the Database Configuration Type

On the Database Configuration Type screen, select RCU Data.

All fields are pre-populated, because you already configured the domain to reference the Fusion Middleware schemas that are required for the Infrastructure domain.

Verify and ensure that credentials in all the fields are the same that you have provided while configuring the Oracle Fusion Middleware Infrastructure.

Click Get RCU Configuration after you finish verifying the database connection information. The following output in the Connection Result Log indicates that the operating succeeded: 

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

Tip:

For more information about the RCU Data option, see Understanding the Service Table Schemain Creating Schemas with the Repository Creation Utility.

For more information about the other options on this screen, see Datasource Defaults in Creating WebLogic Domains Using the Configuration Wizard.

Task 6   Specifying JDBC Component Schema Information

On the JDBC Component Schema screen, select all of the new schemas (for WebCenter Portal components) in the table.

When you select the schemas, the fields on the page are activated and the database connection fields are populated automatically.

Click Convert to GridLink and click Next.

Task 7   Providing the GridLink Oracle RAC Database Connection Details

On the GridLink Oracle RAC Component Schema screen, provide the information that is required to connect to the RAC database and component schemas, as shown in the following table.

Element Description and Recommended Value

SCAN, Host Name, and Port

Select the SCAN check box.

In the Host Name field, enter the Single Client Access Name (SCAN) Address for the Oracle RAC database.

In the Port field, enter the SCAN listening port for the database (for example, 1521).

ONS Host and Port

In the ONS Host field, enter the SCAN address for the Oracle RAC database.

In the Port field, enter the ONS Remote port (typically, 6200).

These values are required when connecting to Oracle 11g databases but optional when connecting to Oracle database 12c and higher. If you are using an Oracle 12c database, the ONS list is automatically provided from the database to the driver.

Enable Fan

Verify that the Enable Fan check box is selected, so the database can receive and process FAN events.

Task 8   Testing the JDBC Connections

Use the JDBC Component Schema Test screen to test the data source connections you have just configured.

A green check mark in the Status column indicates a successful test. If you encounter any issues, see the error message in the Connection Result Log section of the screen, fix the problem, then try to test the connection again.

Tip:

For more information about the other options on this screen, see Test Component Schema in Creating WebLogic Domains Using the Configuration Wizard.

Task 9   Selecting Advanced Configuration

To complete domain configuration for the topology, select the following options on the Advanced Configuration screen:

  • Topology

  • Deployments and Services

Note:

JMS JDBC stores are recommended and were advised to be selected in the WebCenter Content Extension section Task 3, "Configuring High Availability Options" so there is no need to configure File Stores.

If you have chosen the JMS File Stores option in Task 3, "Configuring High Availability Options" during the initial domain extension for WebCenter Content, you have to select the File Stores option now to confirm the configuration of the file stores in a shared location at ORACLE_RUNTIME/domain_name/cluster_name/jms. A shared location is required if using file stores to resume JMS and HA in a failover scenario. If using JDBC stores, do not select the File Store advanced configuration option here.

Task 10   Configuring Managed Servers

On the Managed Servers screen, multiple new Managed Servers for Oracle WebCenter Portal and Portlet appear in the list of static configured Managed Servers along with the existing WebCenter Content IBR servers, if installed.

Static Managed Server definitions are not needed for dynamic cluster configurations.

Delete the default WC_Portlet and WC_Portal Managed Servers by completing the following steps:

  1. Click on the Server Name field for the Managed Server definition to be deleted.

  2. Click Delete.

  3. Repeat for each Managed Server to be removed.

  4. Click Next to proceed to the next screen.

Task 11   Configuring Clusters

In this task, you create multiple clusters to which you can target the Oracle WebCenter Portal software.

In the Configure Clusters screen, add the following new clusters with the corresponding Dynamic Server Groups:
Cluster Name Dynamic Server Group Selection

Portal_Cluster

PORTAL-ANALYTICS-DYN-CLUSTER

Portlet_Cluster

PORTLET-PAGELET-DYN-CLUSTER

  1. Click Add.

  2. Specify the Cluster Name field value appropriately.

  3. Leave the Cluster Address field and Frontend Host fields blank.

  4. Select the appropriate value from the Dynamic Server Groups drop-down list as indicated in the previous table.

    Note:

    By default, server instances in a cluster communicate with one another using unicast. If you want to change your cluster communications to use multicast, refer to Considerations for Choosing Unicast or Multicast in Administering Clusters for Oracle WebLogic Server.

    Tip:

    More information about the options on this screen can be found in Clusters in Creating WebLogic Domains Using the Configuration Wizard.

  5. Click Next to proceed to the next screen.

Task 12   Assigning Server Templates

Use the Server Templates screen to configure and assign the new server templates as indicated.

Note:

With Dynamic Clusters for product components that can scale-up and scale-out, it is important to assure that sufficient port ranges are reserved without overlap to allow a dynamic cluster to auto-calculate assigned listen ports for the maximum allowable number of dynamic managed servers needed. The Dynamic Clusters Calculated Listen Ports feature will increment the port number by one for each dynamic managed server. Adjust the ranges between the Listen Ports for the various services according to your scalability requirements with some room for growth. The first managed server will be assigned this designated listen port value +1.
In the Configure Clusters screen, add the following new clusters with the corresponding Dynamic Server Groups:
Name Listen Port SSL Listen Port Enable SSL

portal-server-template

9010

9110

unchecked

portlet-server-template

9020

9120

unchecked

  1. Update the listen port values per recommendations.

  2. Leave the Enable SSL option unchecked.

  3. Update the SSL Listen Port values accordingly to prevent overlapping configuration values.

  4. Click Next to proceed to the next screen once all values are correct.

Task 13   Configuring Dynamic Servers

Use the Dynamic Servers screen to configure properties controlling how the dynamic Managed Servers are created and scaled. See Dynamic Clusters in Administering Clusters for Oracle WebLogic Server.

Configure the new WebCenter Portal and Portlet cluster settings as follows:

  1. Verify that the Cluster Name values match as configured earlier.

  2. Verify that the Server Name Prefix values are as follows:

    • Portal Cluster: WC_Portal

    • Portlet_Cluster: WC_Portlet

  3. Verify that the correct Server Template is selected from the Server Template drop-down list:

    • Portal Cluster: portal-server-template

    • Portlet_Cluster: portlet-server-template

  4. Specify the Dynamic Cluster Size for the new clusters.

    At a minimum, set the size equal to the number of WCPHOSTn machines configured in the domain to achieve simple horizontal scale-out redundancy. For the baseline EDG topology, this would be a value of 2.

    Note:

    The cluster size can be tuned as necessary to meet the scalability needs, taking into account the available listen port range specified earlier, the number of WCPHOSTn machines available, and any hardware resource limitations.

    This setting effects the current size of the cluster and may not configure the Maximum Dynamic Server Count.

    If the Dynamic Cluster Size is set greater than the number of machines available that match the Machine Name Match Expression, then multiple managed servers will be created on the machines in a vertical scale-up topology.

    Scalability check: After extending the domain, confirm the Maximum Dynamic Server Count is no greater than the number of available listen ports as declared in the previous task, if the Calculated Listen Port option is selected for each cluster. If the Maximum Dynamic Server count is higher than the number of available ports between the cluster port ranges, problems can occur when scaling the cluster.

  5. Specify WCPHOST* in the Machine Name Match Expression field for the new clusters.

    Note:

    If you have customized your WebLogic Machine Name configurations, ensure that they have a unique and consistent prefix to use in the match expression.

  6. Select the Calculated Machine Names, Calculated Listen Ports, and Dynamic Cluster fields as follows:

    • Portal Cluster: check all the three fields

    • Portlet_Cluster: check all the three fields

  7. Confirm all settings for pre-existing clusters and fix any extra configuration selections that may have been changed unexpectedly by the Configuration Wizard.

    For example: Ensure that any static clusters, like IBR_Servers do not have the Calculated Listen Ports or Dynamic Cluster checkboxes selected.

  8. Click Next to proceed to the next screen.

Task 14   Assign Servers to Clusters

Confirm all static configured Managed Servers are assigned to the correct Clusters.

Note:

This screen will be presented only if there are static clusters or managed servers defined in the domain.

When configuring WebCenter Portal by using dynamic clusters, no managed servers are created during configuration to be assigned here. Only pre-existing managed servers will appear, and no changes are necessary.

Click Next to proceed to the next screen.

Task 15   Configuring Coherence Clusters

Use the Coherence Clusters screen to configure the Coherence cluster that is automatically added to the domain. Validate the port number is set as expected based on the initial domain creation, then click Next.

Note:

For Coherence licensing information, refer to Oracle Coherence in Oracle Fusion Middleware Licensing Information.

Task 16   Verifying the Existing Machines

Complete the following steps:

  1. Under the Unix Machine tab, verify the names of the machines you created when creating the initial Infrastructure domain.

    Table 15-3 Values to Use When Creating Unix Machines

    Name Node Manager Listen Address Node Manager Listen Port

    ADMINHOST

    Enter the value of the ADMINVHN variable.

    5556

    WCCHOST1

    The value of the WCCHOST1 host name variable. For example, WCCHOST1.example.com.

    5556

    WCCHOST2

    The value of the WCCHOST2 host name variable. For example, WCCHOST2.example.com.

    5556

    WCPHOST1

    The value of the WCPHOST1 host name variable. For example, WCPHOST1.example.com.

    5556

    WCPHOST2

    The value of the WCPHOST2 host name variable. For example, WCPHOST2.example.com.

    5556

  2. Click Next to proceed.

Task 17   Assigning Servers to Machines

Click Next to proceed to the next screen.

Task 18   Configuring Virtual Targets

Click Next to proceed to the next screen.

Task 19   Configuring Partitions

Click Next to proceed to the next screen.

Task 20   Deployments Targeting

With the Oracle Web Services Manager Policy Manager deployed to a separate cluster, the default targeting of the WSM-PM application to the Portal and Portlet clusters should be removed.

  1. In the Deployment Targets panel, scroll to locate the wsm-pm application deployment for the Portal_Cluster.

  2. Click on the wsm-pm application deployment for the Portal_Cluster.

  3. Click the left-arrow button to remove the wsm-pm application deployment from the Portal_Cluster in the Deployment Targets list.

  4. Repeat this procedure for the wsm-pm application deployment for the Portlet_Cluster.

Task 21   Services Targeting

With the Oracle Web Services Manager Policy Manager deployed to a separate cluster, the default targeting of the service resources needed by the WSM-PM application can be removed from the Portal and Portlet clusters.

  1. In the Deployment Targets panel, scroll to locate the mds-owsm JDBCSystemResource for the Portal_Cluster.

  2. Click on the mds-owsm resource for the Portal_Cluster.

  3. Click the left-arrow button to remove the mds-owsm resource deployment from the Portal_Cluster.

  4. Repeat this procedure for the mds-owsm JDBCSystemResource deployment for the Portlet_Cluster.

Task 22   Reviewing Your Configuration Specifications and Configuring the Domain

The Configuration Summary screen contains the detailed configuration information for the domain you are about to create. Review the details of each item on the screen and verify that the information is correct.

You can go back to any previous screen if you need to make any changes, either by using the Back button or by selecting the screen in the navigation pane.

Click Update to execute the domain extension.

Tip:

More information about the options on this screen can be found in Configuration Summary in Creating WebLogic Domains Using the Configuration Wizard.

Task 23   Writing Down Your Domain Home and Administration Server URL

The Configuration Success screen will show the following items about the domain you just configured:

  • Domain Location

  • Administration Server URL

You must make a note of both items as you will need them later; the domain location is needed to access the scripts used to start the Node Manager and Administration Server, and the URL is needed to access the Administration Server.

Click Finish to dismiss the configuration wizard.

Task 24   Start the Administration Server

Start the Administration Server, login, and then verify the clusters and servers views to ensure that the changes made to the domain have been applied.

Propagating the Extended Domain to the Domain Directories and Machines

After you have extended the domain with the Oracle WebCenter Portal instances, and you have started the Administration Server on WCCHOST1, you must then propagate the domain changes to the domain directories and machines.
  1. Make a backup copy of the Managed Server domain directory and the Managed Server applications directory.
  2. Run the following pack command on WCCHOST1 to create a template pack:
    cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true 
          -domain=ASERVER_HOME 
          -template=/full_path/wcpdomaintemplateExtWCP.jar 
          -template_name=wcpdomain_templateExtWCP

    In this example:

    • Replace ASERVER_HOME with the actual path to the domain directory you created on the shared storage device.

    • Replace full_path with the complete path to the location where you want to create the domain template jar file. You will need to reference this location when you copy or unpack the domain template jar file. It is recommended to choose a shared volume other than ORACLE_HOME, or write to /tmp/ and copy the files manually between servers.

      You must specify a full path for the template jar file as part of the -template argument to the pack command: 

      SHARED_CONFIG_DIR/domains/template_filename.jar

    • wcpdomaintemplateExtWCP.jar is a sample name for the JAR file you are creating, which will contain the domain configuration files, including the configuration files for the Oracle HTTP Server instances.

    • wcpdomain_templateExtWCP is the name assigned to the domain template file.

  3. Run the following unpack command on WCCHOST1 to propagate the template created in the preceding step to the MSERVER_HOME directory:
    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME 
            -template=/full_path/wcpdomaintemplateExtWCP.jar 
            -app_dir=APPLICATION_HOME 
            -overwrite_domain=true

    In this example:

    • Replace MSERVER_HOME with the complete path to the domain home to be created on the local storage disk. This is the location where the copy of the domain will be unpacked.

    • wcpdomaintemplateExtWCP.jar is the directory path and name of the template you created when you ran the pack command to pack up the domain on the shared storage device.

    • The -overwrite_domain=true argument is necessary when you are 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 restored after this unpack operation.

    • Replace APPLICATION_HOME with the complete path to the Application directory for the domain on local storage.

    Tip:

    For more information about the pack and unpack commands, see "Overview of the Pack and Unpack Commands" in Creating Templates and Domains Using the Pack and Unpack Commands.

  4. If the full path to the packed jar file is on a shared volume available to the other servers, skip this step, otherwise, run the following command on WCCHOST1 to copy the template pack created in step 1 to WCCHOST2, WCPHOST1, and WCPHOST2:
    scp /full_path/wcpdomaintemplateExtWCP.jar oracle@WCCHOST2:/full_path/
scp /full_path/wcpdomaintemplateExtWCP.jar oracle@WCPHOST1:/full_path/
scp /full_path/wcpdomaintemplateExtWCP.jar oracle@WCPHOST2:/full_path/
  5. Run the following unpack command on WCCHOST2, WCPHOST1, and WCPHOST2 to deploy the domain template copied in the preceding step to the local MSERVER_HOME domain directory: 
    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME 
            -template=/full_path/wcpdomaintemplateExtWCP.jar 
            -app_dir=APPLICATION_HOME 
            -overwrite_domain=true

    In this example:

    • Replace MSERVER_HOME with the complete path to the domain home to be created on the local storage disk. This is the location where the copy of the domain will be unpacked.

    • wcpdomaintemplateExtWCP.jar is the directory path and name of the template you created when you ran the pack command to pack up the domain on the shared storage device.

    • The -overwrite_domain=true argument is necessary when you are 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 restored after this unpack operation.

    • Replace APPLICATION_HOME with the complete path to the Application directory for the domain on local storage.

    Tip:

    For more information about the pack and unpack commands, see "Overview of the Pack and Unpack Commands" in Creating Templates and Domains Using the Pack and Unpack Commands.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Restoring customizations to setDomainEnv.sh after Unpacking the Domain

If any customizations have been made earlier to the setDomainEnv.sh files in ASERVER_HOME and MSERVER_HOME, then these customizations will need to be repeated after any domain extension.

Note:

Modifying the setDomainEnv script is not recommended. For more information, see Customizing Domain Wide Server Parameters in Administering Server Startup and Shutdown for Oracle WebLogic Server.

For WebCenter Enterprise Deployments, see Customizing Server Parameters with the setUserOverridesLate Script.

Verify that all customizations have been restored before starting NodeManager or WebLogic Server instances.

On WCCHOST1:

  1. Verify and update ASERVER_HOME/bin/setDomainEnv.sh.
  2. Verify and update MSERVER_HOME/bin/setDomainEnv.sh.
  3. Copy MSERVER_HOME/bin/setDomainEnv.sh to the other hosts (Example: WCCHOST2, WCPHOST1, and WCPHOST2).

    Note:

    There are unique differences in parameter values stored in the ASERVER_HOME and MSERVER_HOME setDomainEnv.sh configuration files. The same file cannot be copied into both locations and should be edited separately. MSERVER_HOME/bin/setDomainEnv.sh can be copied across the environment consistently.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Updating the NodeManager Configuration After Unpacking the Domain

When extending a domain, the nodemanager.properties file in MSERVER_HOME may be overwritten with some values from the nodemanager.properties file for ASERVER_HOME. Specifically, the ListenAddress and/or CustomIdentityAlias values can be reset.

Notes::

For the MSERVER_HOME/nodemanager/nodemanager.properties file on each host:
  1. Verify the correct ListenAddress parameter value and reset it, if required.
    grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties
  2. Confirm the list of configured Identity Aliases from the domain configuration file as a reference for the next command.
    grep server-private-key-alias ASERVER_HOME/config/config.xml | sort | uniq

    Note:

    When using Dynamic Clusters, this listing will present only the ADMINVHN and wildcard certificate identity aliases.

    Use the appropriate host-specific certificate identity aliases when updating the nodemanger.properties CustomIdentityAlias property in the next instruction.

  3. Verify the current nodemanager.properties CustomIdentityAlias parameter value matches the alias for the host.
    grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties
  4. Reset the CustomIdentityAlias parameter value to the correct alias string appropriate for the current host, if required.
  5. Restart the nodemanager process:
    kill `ps -eaf | grep weblogic.NodeManager | grep MSERVER_HOME | grep -v grep | awk '{print $2}' `
nohup MSERVER_HOME/bin/startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

Note:

For more information about the CustomIdentityAlias parameter, see Configuring Node Manager to Use the Custom Keystores.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Restarting and Validating Pre-existing Managed Servers

Restart the managed servers for the pre-existing components now that the domain has been extended and unpacked to the MSERVER_HOME directories on all of the servers.
  1. From the WebLogic Server Console, restart the WLS_WSMn Managed Servers for the WebServices Manager Policy Manager.
  2. From another browser window, verify the WSM-PM application is responding by successfully loading the URL:
    http://wcpinternal.example.com/wsm-pm/validator
  3. Restart all other pre-existing managed servers before continuing. This can be done in a rolling manner as necessary to avoid application outages.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Modifying the Upload and Stage Directories to an Absolute Path in an Enterprise Deployment

After you configure the domain and unpack it to the Managed Server domain directories on all the hosts, verify and update the upload and stage directories for Managed Servers in the new clusters. Also, update the upload directory for the AdminServer to have the same absolute path instead of relative, otherwise deployment issues can occur. If you implement dynamic clusters, the configuration of the server template assigned to each newly added cluster should be verified and updated, otherwise, verify and update every statically-defined Managed Server for the newly added clusters.

This step is necessary to avoid potential issues when you perform remote deployments and for deployments that require the stage mode.

To update the directory paths for the Deployment Stage and Upload locations, complete the following steps:

  1. Log in to the Oracle WebLogic Server Administration Console.

  2. In the left navigation tree, expand Domain, and then Environment.

  3. Click Lock & Edit.

  4. Navigate to and edit the appropriate objects for your cluster type.

    1. For Static Clusters, navigate to Servers and click the name of the Managed Server you want to edit.

    2. For Dynamic Clusters, navigate to Clusters > Server Templates, and click on the name of the server template to be edited.

  5. For each new Managed Server or Server Template to be edited:

    1. Click the Configuration tab, and then click the Deployment tab.

    2. Verify that the Staging Directory Name is set to the following: 

      MSERVER_HOME/servers/server_or_template_name/stage

      Replace MSERVER_HOME with the full path for the MSERVER_HOME directory.

      If you use static clusters, update with the correct name of the Managed Server that you are editing.

      If you use dynamic clusters, leave the template name intact. For example: /u02/oracle/config/domains/wcpedg_domain/servers/XYZ-server-template/stage

    3. Update the Upload Directory Name to the following value: 

      ASERVER_HOME/servers/AdminServer/upload

      Replace ASERVER_HOME with the directory path for the ASERVER_HOME directory.

    4. Click Save.

    5. Return to the Summary of Servers or Summary of Server Templates screen as applicable.

  6. Repeat the previous steps for each of the new managed servers or dynamic cluster server templates.

  7. Navigate to and update the Upload Directory Name value for the AdminServer:

    1. Navigate to Servers, and select the AdminServer.

    2. Click the Configuration tab, and then click the Deployment Tab.

    3. Verify that the Staging Directory Name is set to the following absolute path:

      ASERVER_HOME/servers/AdminServer/stage

    4. Update the Upload Directory Name to the following absolute path:

      ASERVER_HOME/servers/AdminServer/upload

      Replace ASERVER_HOME with the directory path for the ASERVER_HOME directory.

    5. Click Save.

  8. When you have modified all the appropriate objects, click Activate Changes.

Note:

If you continue directly with further domain configurations, a restart to enable the stage and upload directory changes is not strictly necessary at this time.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Configuring Listen Addresses When Using Dynamic Clusters

The default configuration for dynamic managed servers in dynamic clusters is to listen on all available network interfaces. In most cases, the default configuration may be undesirable. To limit the listen address to a specific address when you use dynamic clusters, see Configuring Listen Addresses in Dynamic Cluster Server Templates. Reverify the test URLs that are provided in the previous sections after you change the listen address and restart the clustered managed servers.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Starting the Node Manager on WCPHOST1

After you unpack the extended domain on WCPHOST1, you can start the Node Manager from the Managed Server directory on WCPHOST1.

  1. Navigate to the following directory on WCPHOST1:
    MSERVER_HOME/bin
  2. Use the following command to start the Node Manager:
    nohup ./startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

For information about additional Node Manager configuration options, see Administering Node Manager for Oracle WebLogic Server.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Starting the Node Manager on WCPHOST2

After you have propagated the domain configuration to WCPHOST2, you can start the Node Manager for the MSERVER_HOME domain directory.

  1. If you haven’t already, log in to WCPHOST2.
  2. Change directory to the following location:

    MSERVER_HOME/bin

  3. Use the following command to start the Node Manager on WCPHOST2:
    nohup ./startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

    For more information about additional Node Manager configuration options, see Administering Node Manager for Oracle WebLogic Server.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Starting and Validating the WC_Portal1 and WC_Portlet1 Managed Servers

Now that you have extended the domain, restarted the Administration Server, and propagated the domain to the other hosts, you can start the newly configured Oracle WebCenter Portal servers.

This process involves three tasks:

Parent topic: Extending the Domain with Oracle WebCenter Portal

Starting the Managed Servers on WCPHOST1

To start the WC_Portal1 Managed Server:

  1. Enter the following URL into a browser to display the Fusion Middleware Control login screen:
    http://ADMINVHN:7001/em
  2. Sign-in to the Fusion Middleware Control by using the administrator's account. For example: weblogic_wcp.
  3. In the Target Navigation pane, expand the domain to view the Managed Servers in the domain.
  4. Select only the WC_Portal1 Managed Server and click Start Up on the Oracle WebLogic Server toolbar.

    Note:

    WebCenter Portal Servers depend on the policy access service to be functional. This implies that the WSM-PM Managed Servers in the domain need to be up and running and reachable before the WebCenter Portal servers are started.

  5. When the startup operation is complete, navigate to the Domain home page and verify that the WC_Portal1 Managed Server is up and running.
  6. Repeat the above steps to start the WC_Portlet1 Managed Server on WCPHOST1.

Parent topic: Starting and Validating the WC_Portal1 and WC_Portlet1 Managed Servers

Adding the WCPAdmin Role to the Portal Administrators Group

Before you validate the Oracle WebCenter Portal configuration on WC_Portal1 Managed Server, grant the WebCenter Portal administrator role to the WCPAdministrators LDAP group.

To perform this task, refer to Configuring Roles for Administration of Oracle WebCenter Portal Products.

Parent topic: Starting and Validating the WC_Portal1 and WC_Portlet1 Managed Servers

Granting the Administrator Role for WebCenter Portal Using WLST

This section describes how to grant WebCenter Portal's Administrator role using WLST.

To grant the WebCenter Portal Administrator role using WLST:
  1. Create a group in the LDAP store named WCPAdministrators.

    This group will be assigned the Administrator role in WebCenter Portal.

    For more information on how to create a user, see Provisioning an Enterprise Deployment Administration User and Group and Adding the Administration Role to the New Administration Group.

  2. Navigate to your WebCenter Portal Oracle home directory and invoke the WLST script:
    (UNIX) ORACLE_HOME/wcportal/common/bin/wlst.sh

(Windows) ORACLE_HOME\wcportal\common\bin\wlst.cmd
  3. Connect to the Administration Server for the target domain with the following command:
    wls:/offline>connect("user_name","password", "host_name:port_number")
  4. Grant the WebCenter Portal Administrator application role to the WCPAdministrators group in LDAP using the grantAppRole command.
    grantAppRole(appStripe="webcenter", appRoleName="s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator", principalClass="weblogic.security.principal.WLSGroupImpl", principalName="WCPAdministrators")

    Where WCPAdministrators is the name of the portal administration group you created earlier.

  5. Restart the WC_Portal1 Managed Server.
    shutdown('WC_Portal1', block='true', force='true')
start('WC_Portal1', block='true')
  6. To test the new account, log in to WebCenter Portal using the new account name.

    Open WebCenter Portal in your browser using http://WCPHOST1:9001/webcenter. After logging in, the Administration link should appear, and you should be able to perform all administrative operations.

Granting the Administrator Role for WebCenter Portal Using Fusion Middleware Control

This section describes how to grant WebCenter Portal's Administrator role to a user account other than the default weblogic account.

To grant WebCenter Portal's Administrator role using Fusion Middleware Control:
  1. Sign-in to the Fusion Middleware Control by using the administrator's account. For example: weblogic_wcp.
  2. From the WebLogic Domain menu, select Security, and then Application Roles.
  3. Search for WebCenter Portal's Administrator role:

    1. Select the webcenter Application Stripe.

    2. Change the search form's Role Name option from Starts With to Includes.

    3. In the text box next to the Includes option, enter #Administrator, then click the Search Application Roles icon Search icon.

  4. Click the returned row to select the Administrators role.
  5. Click the Edit icon Application Role Edit icon to open the Edit Application Role view.
  6. Click the Add icon Application Role Add icon.
    The form to add members is displayed.
  7. Change the search type from Application Role to Group.
  8. Use the Search function to search for the WCPAdministrators LDAP group created earlier in Provisioning an Enterprise Deployment Administration User and Group.
  9. Click to select the correct row of search results for the WCPAdministrators group.
  10. Click OK to add the selected group to the role.
  11. On the Edit Application Role page, verify the updated list of members includes the newly added group.
  12. Click OK to save the changes to the Application Role.
  13. Restart the WC_Portal1 Managed Server.
    When you log in to WebCenter Portal as a member of the WCPAdministrators group, the Administration link should appear and you should be able to perform all administrative operations.

Validating WebCenter Portal on WCPHOST1

Once the Portal and Portlet managed servers are started on WCPHOST1, validate that the web applications respond using following application URLs:

Notes:

  • Authenticate as weblogic_wcp as necessary.

  • Update port numbers accordingly if using Dynamic Clustering with the Calculated Listen Port feature enabled. See the WebCenter Portal Listen Port Summary by Cluster Type table for example port assignments.

Table 15-4 WebCenter Portal Listen Port Summary by Cluster type

Managed Server Listen Port Static Cluster Listen Port Dynamic Cluster
WC_Portal1 9001 9011
WC_Portal2 9001 9012
WC_Portlet1 9002 9021
WC_Portlet2 9002 9022

Parent topic: Starting and Validating the WC_Portal1 and WC_Portlet1 Managed Servers

Starting and Validating the Managed Servers on WCPHOST2

After you have validated the successful configuration and startup of the Managed Servers on WCPHOST1, you can then start and validate the new Managed Servers on WCPHOST2, using the procedure in Starting and Validating the WC_Portal1 and WC_Portlet1 Managed Servers.

Note:

  • Authenticate as weblogic_wcp as necessary.

  • Update port numbers accordingly if using Dynamic Clustering with the Calculated Listen Port feature enabled. See the WebCenter Portal Listen Port Summary by Cluster Type table for example port assignments.

Once the Portal and Portlet managed servers are started on WCPHOST2, validate that the web applications respond using following application URLs:

Parent topic: Starting and Validating the WC_Portal1 and WC_Portlet1 Managed Servers

Enabling SSL Communication Between the WebCenter Portal and Portlet Managed Servers and the Hardware Load Balancer

After you extend the domain with Oracle WebCenter Portal, ensure that the Administration Server and Managed Servers can access the front-end, SSL URL of the hardware load balancer.

This allows applications and web services to invoke callbacks and other communications with the front-end, secure URL.

See Enabling SSL Communication Between the Middle Tier and the Hardware Load Balancer.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Configuring Session Persistence for WebCenter Portal

Applications that are deployed to a cluster in WebLogic Server can optionally take advantage of HTTP session persistence and replication to provide high-availability for the user's experience (their session data) in case of the loss or outage of one or more application server instances within the cluster. This additional session state replication between server instances incurs a performance penalty for the application.

By default, the HTTP session persistence is disabled in WebCenter Portal, and can be enabled if required.

For technical reference, see Using Sessions and Session Persistence in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server, and HTTP State Replication in Administering Clusters for Oracle WebLogic Server.

To enable HTTP session persistence for WebCenter Portal, configure and apply a customized deployment plan as follows:

  1. Create a new deployment plan XML file for the webcenter portal application. The deployment plan should be in DEPLOY_PLAN_HOME on the shared filesystem available to all hosts. Set the example path/filename to:

    DEPLOY_PLAN_HOME/DOMAIN_NAME/webcenterPlan.xml

    Note:

    Substitute the full path to DEPLOY_PLAN_HOME and DOMAIN_NAME in the <config-root> element value. 
    <?xml version='1.0' encoding='UTF-8'?>
<deployment-plan xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-deployment-plan.xsd" global-variables="false">
<application-name>webcenter</application-name>
<variable-definition>
    <variable>
      <name>addPersistentStore</name>
      <value>replicated_if_clustered</value>
    </variable>
  </variable-definition>
 
<module-override>
     <module-name>spaces.war</module-name>
     <module-type>war</module-type>
     <module-descriptor external="false">
        <root-element>weblogic-web-app</root-element>
        <uri>WEB-INF/weblogic.xml</uri>
        <variable-assignment>
            <name>addPersistentStore</name>
            <xpath>/weblogic-web-app/session-descriptor/persistent-store-type</xpath>
            <operation>add</operation>
        </variable-assignment>
     </module-descriptor>
</module-override>
<config-root>DEPLOY_PLAN_HOME/DOMAIN_NAME/webcenterPlan.xml</config-root>
</deployment-plan>

    Note:

    DEPLOY_PLAN_HOME and DOMAIN_NAME are placeholder substitution values. Provide the actual paths or names as required.

    The DEPLOY_PLAN_HOME value should be replaced with the full path to a shared filesystem directory as specified in Shared Storage Recommendations When Installing and Configuring an Enterprise Deployment.

  2. Sign in to the WebLogic Server Console as an administrative user. For example: weblogic_wcp.

  3. Click Deployments in the Domain Structure panel.

  4. Click Lock & Edit.

  5. Select the checkbox for the webcenter application.

  6. Click Update.

  7. Observe the current Deployment Plan Path value as (no value specified).

    Note:

    If a custom deployment plan has previously been specified, then integrate the differences based on the code in step 1 into the existing deployment plan file instead to preserve any pre-existing deployment customizations.

  8. Click Change Path associated with the Deployment plan path field.

  9. Enter the full and complete path to the custom deployment plan XML file, and click Next. 
    DEPLOY_PLAN_HOME/DOMAIN_NAME/webcenterPlan.xml

  10. Click Finish. The WebCenter Portal application deployment must be redeployed and cannot be updated in-place. Do not change the selection of the redeploy option.

  11. Click Activate Changes in the Change Center panel.

  12. Restart all managed servers in the Portal_Cluster.

  13. Validate the updated plan enhancements are listed in the webcenter application deployment section of ASERVER_HOME/config/config.xml. Look for the <plan-dir> and <plan-path> elements.

    For example:
    <app-deployment>
    <name>webcenter</name>
    <target>WC_Portal</target>
    <module-type>ear</module-type>
    <source-path>/u01/oracle/products/fmw/wcportal/archives/applications/webcenter.ear</source-path>
    <deployment-order>400</deployment-order>
    <plan-dir xsi:nil="true"></plan-dir>
    <plan-path>/u01/oracle/config/wcpedg_domain/webcenterPlan.xml</plan-path>
    <security-dd-model>DDOnly</security-dd-model>
    <staging-mode>nostage</staging-mode>
    <parallel-deploy-modules>false</parallel-deploy-modules>
  </app-deployment>

Parent topic: Extending the Domain with Oracle WebCenter Portal

Configuring Analytics

In the enterprise deployment reference architecture, analytics collectors are usually configured to communicate with the local WebCenter Portal application in a 1-1 relationship (the collectors listen on localhost on the default port). Additional analytics collector configuration is required if the Portal_Cluster will be scaled-up vertically with multiple managed servers per WCPHOST, either manually with traditional cluster configuration or through the use of the WebLogic Server Dynamic Clustering features.

While multiple collectors on the same host can be configured to avoid port conflicts to allow vertical scale-up of Portal and analytics services, there can be only one active common Analytics collector registration in the portal. This active registration can reference only a single hostname and port combination. As such, it remains recommended to configure the WebCenter Portal applications to send event messages to localhost with the default analytics collector port.

Note:

Clustered analytics collectors are not supported for collecting WebCenter Portal events.

Additional configuration to avoid analytics collector port conflicts would be required if scaling-up more than one portal managed server per host. In this case, for more information about configuring collector maximum port values, see Configuring Analytics Collector Settings in the Administering Oracle WebCenter Portal guide.

Portal run-time configuration only supports a single active Analytics collector service registration with a single port. Only the collector started per host using the port matching the portal registration will collect data. If that collector or managed server is down, Analytics event collection will not occur for any of the remaining portal servers on that host.

Use of the local hardware load balancer to centrally distribute analytics traffic across co-located collectors in scale-up scenarios has not been validated as of this Enterprise Deployment Guide release. Use of this potential topology option should be thoroughly tested in a non-production environment before finalizing your architecture in this regard.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Registering a Default Analytics Connection for WebCenter Portal

Connect the WebCenter Portal application to the analytics collector.

To connect the WebCenter Portal application to the analytics collector, complete the following steps:

  1. Connect to the Administration Server for the domain using WLST as the weblogic_wcp user, for example:
    ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "t3://ADMINVHN:7001")
  2. Create a connection between the WebCenter Portal application and the analytics collector and make it the default connection (default=1).

    Note:

    The commands in this section need to be executed only once for the clustered Webcenter application, even though there is a specific server name listed for the connection. When this configuration is set, it applies to all servers.

    For example:

    createAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1", connectionName="Collector31314", collectorPort=31314, isEnabled=1, default=1, isUnicast=1, collectorHost="localhost", timeout=30)

    See also, the createAnalyticsCollectorConnection section in the WebLogic Scripting Tool Command Reference.

  3. Verify the changes made:
    listDefaultAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1")
    For example: 
    wls:/wcedg_domain/serverConfig/> listDefaultAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1") 
--------------
Collector31314 
-------------- 
Cluster Name / Host Name: localhost 
Port: 31314 
Timeout: 30 
Unicast: true 
Enabled: true

    See also the listDefaultAnalyticsCollectorConnection section in the WebLogic Scripting Tool Command Reference.

Parent topic: Configuring Analytics

Configuring Analytics to Support Scale-Up of the Portal Managed Servers

Additional configuration and management processes may be needed for Analytics if Portal managed servers are to be scaled-up beyond one managed server per host. Scale-up operations may be manual in the case of traditional static clusters. Scale-up may be manual or elastic (policy-based) when using Dynamic Cluster features of the WebLogic Server.

Note:

This section applies only when there are multiple portal managed servers per host.

If the topology follows the default enterprise deployment guide reference architecture with only one portal managed server per host, or is enhanced to include only horizontal scale-out scenarios, then this section does not apply and can be skipped.

Two additional configurations must be addressed to support scale-up:

  1. The Analytics Collector Port range must be set to allow multiple collector services to run on a single host and listen on separate unique ports.

  2. WebCenter Portal registrations for the additional collectors will need to be added. These registrations can be quickly activated later and portal servers restarted if the Analytics Collector on the default port is unavailable. Once restarted, the portal servers will attempt to use the newly activated collector registration.

The requirements for reliable Analytics high-availability, are as follows:

  • There must be an Analytics collector process listening on the port specified in the default and active registration within the portal.

  • There must be an Analytics collector process available on each port within the configured Analytics Collector port range on every WCPHOST.

  • Every WCPHOST must have an identical number of scaled-up portal managed servers, otherwise some portal servers may not find the collector on the currently default/active port on localhost for the selected registration.

The following sections advise on the additional configuration required for analytics when accommodating for scale-up:

  • Configuring the Analytics Collector Port Range
    The Analytics collector settings are environment-wide and cannot be customized on a server-by-server basis. The maxPort parameter provides an effective range above the defaultPort for multiple Analytics Collector instances to use unique ports on a per-host basis. If a collector process cannot bind to the default port, it retries every port number until it reaches the maxPort value. If no ports are available, the portal managed server will not start correctly.
  • Registering additional Analytics Collectors in WebCenter Portal
    For each port in the configured Analytics Collector port range, register additional non-default collectors with unique connection names and ports based on the port-range assigned in the Analytics Collector configuration. This will allow for a simplified maintenance process to swap collector registrations in a persistent, well-qualified manner.
  • Failing-over the Portal's Default Analytics Registration
    In the case of a failure of a portal managed server that includes the Analytics Collector service listening on the default port, an alternate analytics connection should be selected in the portal configuration as the default connection and the surviving portal servers restarted as soon as possible.

Parent topic: Configuring Analytics

Configuring the Analytics Collector Port Range

The Analytics collector settings are environment-wide and cannot be customized on a server-by-server basis. The maxPort parameter provides an effective range above the defaultPort for multiple Analytics Collector instances to use unique ports on a per-host basis. If a collector process cannot bind to the default port, it retries every port number until it reaches the maxPort value. If no ports are available, the portal managed server will not start correctly.

To update the Analytics maxPort value, use the following WLST method when connected to the administration server for the domain:

  1. Connect to the Administration Server for the domain using WLST, for example:
    ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "t3://ADMINVHN:7001")
  2. List the current Analytics Collector configuration with the following WLST command:
    listAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1')

    Note:

    • Verify the Collector Default Port and the Collector Maximum Port assignments. Out-of-the-box, they should be the same port number.

    • Cluster values should be ignored.

    • Analytics clustering is not supported and can cause faults.

    For example:
    wls:/wcedg_domain/serverConfig/> listAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1')
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root MBean.
For more help, use help('domainRuntime')

Collector Hostname = localhost 
Collector Default Port = 31314 
Collector Maximum Port = 31314 
Broadcast Type = Multicast 
Collector Heartbeat Frequency = 10 
Cluster Enabled? = 0 
Cluster Name =
  3. Calculate the required new Collector Maximum Port number.

    Consider the number of portal managed servers that you decide are needed for scalability, Then round up that number to an even multiple of the number of WCPHOSTn machines you have assigned in the environment. This value is the total number of possible collector instances per WCPHOST. The actual number of portal managed servers with collectors may be less than this. In this case, the maximum port number must still accommodate the highest number of co-located Analytics collectors or portal managed servers. Subtract one from this multiple and add to the Analytics Collector Default Port number to calculate the Analytics Collector maxPort parameter value.

    Example Scenario:

    • Environmental Requirements/Facts:

      • SLA allows for degraded performance (fewer servers) upon host failure

      • Number of Portal managed servers needed for scalability/performance: 5

      • Number of WCPHOST machines purchased: 2

      • Default Analytics Collector port not changed (31314)

      • Portal and Analytics Collector deployed to same managed server (WCP 12.2.1 out-of-box topology)

    • Analysis:

      • Derive max servers per host by evenly rounding up the number of servers needed divided by number of hosts:

        ROUNDUP(5/2) = 3 servers per host (max @ required scalability)

      • Must support an analytics collector port range of 3 collectors per WCPHOST.

      • Analytics Collector maxPort: 31316

        defaultPort +(#ofPortalSvrsPerHost) - 1 = (31314+3-1)

  4. Update the Collector configuration settings to set the maxPort value.

    The maxPort value is the incremented port number greater than or equal to the Collector Default Port.

    Note:

    The commands in this section need to be executed only once for the clustered WebCenter application, even though there is a specific server name listed for the connection. When this configuration is set, it applies to all servers.
    For example: 
    setAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1', maxPort=31316)

    See also, the createAnalyticsCollectorConnection section in the WebLogic Scripting Tool Command Reference.

  5. Verify the change to the Collector Maximum Port value using the listAnalyticsCollectorConfig() WLST method.
    For example: 
    listAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1')

Collector Hostname  =  localhost
Collector Default Port  =  31314
Collector Maximum Port  =  31316
Broadcast Type  =  Multicast
Collector Heartbeat Frequency  =  10
Cluster Enabled?  =  0
Cluster Name  =

    See also, the listDefaultAnalyticsCollectorConnection section in the WebLogic Scripting Tool Command Reference.

  6. Restart the portal servers after completing Registering additional Analytics Collectors in WebCenter Portal.
Registering additional Analytics Collectors in WebCenter Portal

For each port in the configured Analytics Collector port range, register additional non-default collectors with unique connection names and ports based on the port-range assigned in the Analytics Collector configuration. This will allow for a simplified maintenance process to swap collector registrations in a persistent, well-qualified manner.

For example: 
createAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1", connectionName="NAME", collectorPort=PORTNUMBER, isEnabled=1, default=0, isUnicast=1, collectorHost="localhost", timeout=30)

Complete the following steps:

  1. Connect to the Administration Server for the domain using WLST, for example:
    ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "t3://ADMINVHN:7001")
  2. List the current Analytics Collector configuration with the following WLST command:
    listAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1')
    For example:
    Collector Hostname  =  localhost
Collector Default Port  =  31314
Collector Maximum Port  =  31316
Broadcast Type  =  Multicast
Collector Heartbeat Frequency  =  10
Cluster Enabled?  =  0
Cluster Name  =

    Note:

    You will need to repeat the next step for every port number within the default-to-maximum port range, including the maximum port number. The registration for the default port should have already been completed earlier.
  3. Add registrations through WLST for each port above the default port up to the maximum port number, changing the connectionName and collectorPort values for each registration.
    For example:
    createAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1", connectionName="Collector31315", collectorPort=31315, isEnabled=1, default=0, isUnicast=1, collectorHost="localhost", timeout=30)

createAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1", connectionName="Collector31316", collectorPort=31316, isEnabled=1, default=0, isUnicast=1, collectorHost="localhost", timeout=30)
  4. List and verify the details for all of the Analytics registrations by using WLST.
    listAnalyticsCollectorConnections(appName="webcenter", server="WC_Portal1")

------------------
Collector31314
------------------
Cluster Name / Host Name: localhost
Port: 31314
Timeout: 30
Unicast: true
Enabled: true
------------------
Collector31315
------------------
Cluster Name / Host Name: localhost
Port: 31315
Timeout: 30
Unicast: true
Enabled: true
------------------
Collector31316
------------------
Cluster Name / Host Name: localhost
Port: 31316
Timeout: 30
Unicast: true
Enabled: true
  5. List the details for the default (currently active) Analytics registrations by using WLST.
    For example: 
    listDefaultAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1")

------------------
Collector31314
------------------
Cluster Name / Host Name: localhost
Port: 31314
Timeout: 30
Unicast: true
Enabled: true

    Note:

    This example indicates Port: 31314, the default port. Multiple registrations have been made, but the portal's Analytics registration has not been failed-over to an alternate connection/port yet. The first portal managed server to be started per machine will have the Analyics Collector listening on the default port.
  6. Restart all WC_Portaln managed servers for the changes to take effect. This can be all-at-once or done in a rolling fashion.
    Example - all at once:
    shutdown('Portal_Cluster', 'Cluster', force='true', block='true')
start('Portal_Cluster',  'Cluster', block='true')
    Example - rolling, no outage:
    shutdown('WC_Portal1', force='true', block='true')
start('WC_Portal1', block='true')

shutdown('WC_Portal2', force='true', block='true')
start('WC_Portal2', block='true')
Failing-over the Portal's Default Analytics Registration

In the case of a failure of a portal managed server that includes the Analytics Collector service listening on the default port, an alternate analytics connection should be selected in the portal configuration as the default connection and the surviving portal servers restarted as soon as possible.

Until this occurs, analytics collection for the remaining portal instances on that machine will not be able to contact the collector on the default port to log analytics metrics. Only one registration is default and actively used at a time.

The fail-over of the default analytics registration is a manual process. The change will be environment-wide but will only take effect when each portal server instance is restarted.

Note:

This section is applicable only when there are multiple portal managed servers per host.

This sections is not applicable if the topology follows the default enterprise deployment guide reference architecture with only one portal managed server per host or is enhanced to include only horizontal scale-out scenarios.

To change the default Analytics registration, complete the following steps:

  1. Connect to the Administration Server for the domain using WLST, for example:
    ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "t3://ADMINVHN:7001")
  2. List the details for the default (currently active) Analytics registrations by using WLST:
    listDefaultAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1")

------------------
Collector31314
------------------
Cluster Name / Host Name: localhost
Port: 31314
Timeout: 30
Unicast: true
Enabled: true
  3. List the available Analytics registrations via WLST, and choose a different collector name to set as default.
    listAnalyticsCollectorConnections(appName="webcenter", server="WC_Portal1")

------------------
Collector31314
------------------
Cluster Name / Host Name: localhost
Port: 31314
Timeout: 30
Unicast: true
Enabled: true
------------------
Collector31315
------------------
Cluster Name / Host Name: localhost
Port: 31315
Timeout: 30
Unicast: true
Enabled: true
------------------
Collector31316
------------------
Cluster Name / Host Name: localhost
Port: 31316
Timeout: 30
Unicast: true
Enabled: true
  4. Update the default Analytics registration by using WLST.
    setDefaultAnalyticsCollectorConnection(appName="webcenter", name="Collector31315", server="WC_Portal1")
  5. Restart all WC_Portaln managed servers for the changes to take effect. This can be all-at-once or done in a rolling fashion.
    Example - all at once:
    shutdown('Portal_Cluster', 'Cluster', force='true', block='true') 
start('Portal_Cluster', 'Cluster', block='true')
    Example - rolling, no outage:
    shutdown('WC_Portal1', force='true', block='true') 
start('WC_Portal1', block='true')  

shutdown('WC_Portal2', force='true', block='true') 
start('WC_Portal2', block='true')

Confirming REST API Configuration

This section describes the procedure to configure REST APIs.

With release 12.2.1.0, the WebCenter REST APIs are pre-configured with the credential map configuration.

If you want to confirm the seed entries in the credential store that enable the REST security tokens to function properly, run the following WLST commands:

Note:

If the credential maps already exist, JPS-01007 exceptions messages will be returned. This confirms the configuration.
  1. Connect to the Administration Server using the command-line Oracle WebLogic Scripting Tool (WLST), for example:
    ORACLE_COMMON_HOME/common/bin/wlst.sh
connect('weblogic_admin_username','weblogic_admin_pwd','t3://ADMINVHN:7001')
  2. Run the following WLST commands to configure the credential store:
    createCred(map="o.webcenter.jf.csf.map", key="keygen.algorithm", 
     user="keygen.algorithm", password="AES") 
createCred(map="o.webcenter.jf.csf.map", key="cipher.transformation", 
     user="cipher.transformation", password="AES/CBC/PKCS5Padding")

Parent topic: Extending the Domain with Oracle WebCenter Portal

Configuring Oracle HTTP Server for the Extended Domain

The following sections describe how to configure the Oracle HTTP Server instances so they route requests for both public and internal URLs to the proper clusters in the enterprise topology.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Configuring Oracle HTTP Server for the Oracle WebCenter Portal Clusters

To configure the Oracle HTTP Server instances in the Web tier so they route requests correctly to the Oracle WebCenter Portal clusters, use the following procedure to create an additional Oracle HTTP Server configuration file that creates and defines the parameters of the wcp.example.com virtual server.

This procedure assumes you performed the Oracle HTTP Server configuration tasks described in Configuring Oracle HTTP Server to Route Requests to the Application Tier.

Complete the following steps to update the virtual host configuration file so that requests are routed properly:

  1. Log in to WEBHOST1 and change directory to the configuration directory for the first Oracle HTTP Server instance (OHS1):
    cd WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/
  2. Edit the wcp_vh.conf file and add the following directives near the end of the file just above the last line: <VirtualHost>:

    Note:

    Configure the port numbers appropriately as assigned for your static or dynamic cluster. Dynamic clusters with the Calculate Listen Port option selected will have incremental port numbers for each dynamic managed server created.

    The WebLogicCluster directive needs only a sufficient number of redundant server:port combinations to guarantee initial contact in case of a partial outage. The actual total list of cluster members is retrieved automatically upon first contact with any given node. 

    # WebCenter Portal Application (previously called Spaces) 
<Location /webcenter>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /webcenterhelp>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /rss>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /rest>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /portalTools>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /wsrp-tools> 
    WLSRequest ON
    WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

</VirtualHost>
  3. Copy the wcp_vh.conf file into the configuration directory for the second Oracle HTTP Server instance (ohs2) on WEBHOST2:
    scp WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/wcp_vh.conf \
WEBHOST2:/WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/wcp_vh.conf
  4. Log in to WEBHOST2 and change directory to the configuration directory for the second Oracle HTTP Server instance (ohs2):
    cd WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/
  5. Edit the wcp_vh.conf and change any references to WEBHOST1 to WEBHOST2 in the <VirtualHost> directives.
  6. Restart both Oracle HTTP servers.

Parent topic: Configuring Oracle HTTP Server for the Extended Domain

Validating the Oracle WebCenter Portal Public Services URLs Through the Load Balancer

To validate the configuration of the Oracle HTTP Server virtual hosts and to verify that the hardware load balancer can route public service requests through the Oracle HTTP Server instances to the application tier:

  1. Verify that the server status is reported as Running in the Administration Console.

    If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported (such as Admin or Failed), check the server output log files for errors.

  2. Verify that you can access these URLs:

Parent topic: Configuring Oracle HTTP Server for the Extended Domain

Configuring HTTP Server for Internal WebCenter Services

To configure the Oracle HTTP Server instances in the Web tier so they route requests correctly to the internal Oracle WebCenter services, use the following procedure to edit existing wcpinternal_vh.conf file.

This procedure assumes you performed the Oracle HTTP Server configuration tasks described in Configuring Oracle HTTP Server to Route Requests to the Application Tier.

Complete the following steps to update the virtual host configuration file so that requests are routed properly:

  1. Log in to WEBHOST1 and change directory to the configuration directory for the first Oracle HTTP Server instance (ohs1):
    cd WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/
  2. Edit the wcpinternal_vh.conf file and add the following directives near the end of the file just above the last line: </VirtualHost>

    Note:

    Configure the port numbers appropriately as assigned for your static or dynamic cluster. Dynamic clusters with the Calculate Listen Port option selected will have incremental port numbers for each dynamic managed server created.

    The WebLogicCluster directive needs only a sufficient number of redundant server:port combinations to guarantee initial contact in case of a partial outage. The actual total list of cluster members is retrieve automatically upon first contact with any given node. 

    # WebCenter Portal Application Services

<Location /webcenter>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF 
</Location>  

<Location /webcenterhelp>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /rss>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /rsscrawl>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /sesUserAuth>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /rest>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Portlets
<Location /pagelets>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /portalTools>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /wsrp-tools>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Collector
<Location /collector>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

</VirtualHost>
  3. Copy the wcpinternal_vh.conf file into the configuration directory for the second Oracle HTTP Server instance (ohs2) on WEBHOST2:
    scp WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/wcpinternal_vh.conf \
WEBHOST2:/WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/wcpinternal_vh.conf
  4. Log in to WEBHOST2 and change directory to the configuration directory for the second Oracle HTTP Server instance (ohs2):
    cd WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/
  5. Edit the wcpinternal_vh.conf file and change any references from WEBHOST1 to WEBHOST2 in the <VirtualHost> directives.
  6. Restart both Oracle HTTP servers.

Parent topic: Configuring Oracle HTTP Server for the Extended Domain

Validating the Oracle WebCenter Portal Internal Services URLs Through the Load Balancer

To validate the configuration of the Oracle HTTP Server virtual hosts and to verify that the hardware load balancer can route internal service requests through the Oracle HTTP Server instances to the application tier:

  1. Verify that the server status is reported as Running in the Administration Console.

    If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported (such as Admin or Failed), check the server output log files for errors.

  2. Verify that you can access these URLs:

Parent topic: Configuring Oracle HTTP Server for the Extended Domain

Configuring WebCenter Portal for External Services

This section describes how to configure external tools and services for WebCenter Portal applications by using Fusion Middleware Control or WLST commands. For most external services, you must set up a connection between the WebCenter Portal application and the backend server.

Each of the following service configurations require various Managed Servers to be restarted for the changes take effect. Some of the restarts are required at the point during the process as indicated. Other restarts may be optionally delayed to the end of the section if completing this section from start-to-finish, otherwise all restarts should be done within the individual subtopics. Restarts that may be delayed to the end of the service configurations section are mentioned as a note.

Parent topic: Extending the Domain with Oracle WebCenter Portal

Configuring Default Web Service Policies for WebCenter Portlet Producer Applications

After installing Oracle WebCenter Portal, you must attach the default Oracle Web Services Manager (OWSM) security policy to the following:

  • WSRP Tools Producer (wsrp-tools)

These steps are required because security policies for these Web service end points are not configured out-of-the-box.

To attach the default Web service security policy:
  1. Ensure that WC_Portal1, WC_Portal2, WC_Portlet1, and WC_Portlet2 managed servers are up and running.
  2. Start the WebLogic Scripting Tool:
    WCPHOST1> ORACLE_COMMON_HOME/common/bin/wlst.sh
  3. Connect to the Administration Server as an administrator.

    For example

    connect("weblogic_wcp","admin password","t3://ADMINVHN:7001")

    For information, see the Running Oracle WebLogic Scripting Tool (WLST) Commands section in Administering Oracle WebCenter Portal.

  4. Run WLST commands to attach the default OWSM security policy (oracle/wss10_saml_token_service_policy) to each of the following:

    • WSRP Tools Producer (wsrp-tools)

    Note:

    In the examples in this topic, configure the application parameter value with the domain name and managed server names for your environment.

    For more information on attaching WebService policies, see Web Services Custom WLST Commands in Oracle Fusion Middleware WLST Command Reference for Infrastructure Components.

    1. Run the following WLST commands to attach the default OWSM security policy to the WSRP Tools Producer's Web service end point. One execution will configure the policy for all servers in the cluster (execute against WC_Portlet1). Set your domain name accordingly in the following command:
      attachWebServicePolicy(application='/domain_name/WC_Portlet1/wsrp-tools', moduleName='wsrp-tools', moduleType='web', serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service', policyURI='oracle/wss10_saml_token_service_policy')

      For more information on attaching WebService policies, see Web Services Custom WLST Commands in Oracle Fusion Middleware WLST Command Reference for Infrastructure Components the link directly to the attachWebServicePolicy() reference.

      For more information on which WS-Security policy to choose here, see WSRP Producer Security Connection Parameters in Administering Oracle WebCenter Portal . The same token policy attached here will also need to be used consistently in the next section when registering the portlet producers.

  5. Restart all managed servers in the Portal and Portlet clusters.

    Note:

    These restarts should be completed now, before the service connections are configured.

Parent topic: Configuring WebCenter Portal for External Services

Registering Portlet Producers

Several out-of-the-box portlet producers can be registered with the WebCenter Portal application. In the WebCenter Portal Enterprise Deployment, the required producer URLs are as follows:

  • WSRP Producer URL: http://wcpinternal.example.com/wsrp-tools/portlets/wsrp2?WSDL

  • WebClipping Producer URL: http://wcpinternal.example.com/portalTools/webClipping/providers

  • OmniPortlet Producer URL: http://wcpinternal.example.com/portalTools/omniPortlet/providers

You can register portlet producers using Fusion Middleware Control or WLST commands.

Parent topic: Configuring WebCenter Portal for External Services

Registering Out-of-the-Box Portlet Producers using Fusion Middleware Control

For details on how to register portlet producers using Fusion Middleware Control, see Managing Portlet Producers in Administering Oracle WebCenter Portal.

Registering Out-of-the-Box Portlet Producers Using WLST
To register out-of-the-box portlet producers using WLST:
  1. Start the WebLogic Scripting Tool:
    WCPHOST1> ORACLE_HOME/oracle_common/common/bin/wlst.sh
  2. In WLST, connect as the administrator.

    For example:

    connect("weblogic_wcp","admin password","t3://ADMINVHN:7001",server="WC_Portal1")
  3. Register the out-of-the-box OmniPortlet and WSRP portlet producers.

    For example:

    registerOOTBProducers(producerHost='wcpinternal.example.com',producerPort=80, appName='webcenter', server='WC_Portal1')
    Where:

    • The producerHost value is set to the internal load-balancer fully-qualified domain name.

    • The server value is the name of the first portal managed server.

    • The appName value is webcenter, the name of the WebCenter Portal application.

    See also, registerOOTBProducers in the WebCenter WLST Command Reference.

  4. List the new WSRP Producer to display the WSDL URL needed for the next step.
    listWSRPProducers(appName='webcenter', server='WC_Portal1')
  5. Configure the WSRP Producer service for the WS-Security Policy attached earlier in the Configuring Default Web Service Policies for WebCenter Portlet Producer Applications.

    • Update the url parameter based on the WSRP URL displayed in the previous step.

    • Update the tokenType parameter with the appropriate value for the needed policy as provided for the setWSRPProducer() tokenType details in WebCenter WLST Command Reference.
      setWSRPProducer(appName='webcenter', server='WC_Portal1', name='wc-WSRPTools', url='http://wcpinternal.exaple.com:80/wsrp-tools/portlets/wsrp2?WSDL', enforcePolicyURI='1', tokenType='WSS10_SAML_TOKEN_ONLY')

      Note:

      The tokenType parameter value must be the appropriate match with the WS-Security policy attached in the previous section.
  6. List the WSRP Producer to confirm updated TokenType configuration.
    listWSRPProducers(appName='webcenter', server='WC_Portal1')
  7. Restart all servers in the Portal_Cluster.

    Note:

    If additional services are being configured, the portal restart can be done once at the end of the section.

Registering the Pagelet Producer

If you want to expose WSRP and Oracle JPDK portlets and OpenSocial gadgets as pagelets in WebCenter Portal, you must register the pagelet producer. In the WebCenter Portal Enterprise Deployment, the required pagelet producer URL is:

http://wcpinternal.example.com/pagelets

You can register the pagelet producer using Fusion Middleware Control or WLST commands.

Parent topic: Configuring WebCenter Portal for External Services

Registering Pagelet Producer Using Fusion Middleware Control

To register Pagelet Producer using Fusion Middleware Control:

  1. Sign-in to the Fusion Middleware Control by using the administrator's account (for example: weblogic_wcp), and navigate to the WebCenter Portal home page.

    Note:

    When administering WebCenter resources in the Enterprise Manager Fusion Middleware Control, it is recommended to use the WebCenter-specific administrative user created in the remote LDAP authenticator (for example, weblogic_wcp). See Configuring Roles for Administration of an Enterprise Deployment.

    See Navigating to the Home page for WebCenter Portal in Administering Oracle WebCenter Portal .

  2. From the WebCenter Portal menu, select Register Producer.

  3. Enter connection details for Pagelet Producer, as shown in the following table.

    Field Description

    Connection Name

    A unique name to identify this Pagelet Producer instance within the application. The name must be unique across all WebCenter Portal connection types. The name specified here appears in Composer under the UI Components > Pagelet Producers folder (by default).

    Producer Type

    Select Pagelet Producer.

    Server URL

    The URL to Pagelet Producer. The URL must include a fully-qualified domain name. Use the following syntax:

    <protocol>://<host_name>:<port_number>/pagelets/

    For example:

    http://wcpinternal.example.com/pagelets/

    If pagelets contain secure data, the registered URL must use the https protocol. For example:

    https://wcp.example.com/pagelets/

    The context root can be changed from /pagelets/ if necessary; for details, see “Redeploying Pagelet Producer to a Different Context” in Administering Oracle WebCenter Portal.

    Note: In WebCenter Portal, if the Pagelet Producer URL is protected by OAM, the URL to the pagelet catalog must be excluded (mapped directly without access control), or the catalog will appear to be empty when using REST. The pagelet catalog URL is http://<host_name>:<port_number>/ pagelets/api/v2/ensemble/pagelets

  4. Click OK. The new producer appears in the connection table.

Registering Pagelet Producer Using WLST

To register out-of-the-box pagelet producers using WLST:

  1. Start the WebLogic Scripting Tool:

    WCPHOST1> ORACLE_COMMON_HOME/common/bin/wlst.sh

  2. In WLST, connect as the administrator.

    For example,

    connect("weblogic_wcp","admin password","t3://ADMINVHN:7001",server="WC_Portal1")

  3. Register the pagelet producer by entering the following command.

    registerPageletProducer(appName='webcenter', name='PageletProducer', url='http://wcpinternal.example.com/pagelets', server='WC_Portal1')

For command syntax and examples, see registerPageletProducer in WebCenter WLST Command Reference.

You can also use WLST to list or edit the current connection details.

For information on how to run WLST commands, see Running Oracle WebLogic Scripting Tool (WLST) Commands in Administering Oracle WebCenter Portal.

Configuring Search Services

You can configure Oracle Secure Enterprise Search (Oracle SES) services and crawlers using procedures in the Managing Oracle Secure Enterprise Search in WebCenter Portal section in Administering Oracle WebCenter Portal.

Note:

WebCenter Portal provides basic integration with Elasticsearch. The configuration of a robust highly-available Elasticsearch deployment with the WebCenter Enterprise Deployment topology has not been fully tested as of this release. For basic configuration, see Managing Search in WebCenter Portal with Elasticsearch in Administering Oracle WebCenter Portal. Significant additional analysis and configuration related to clustering, HA, and security/accessibility is needed for use a WebCenter Enterprise Deployment Guide topology.

Ensure that:

  • Oracle Secure Enterprise Search is registered with Oracle Internet Directory and the WebCenter Portal application is configured as an Oracle SES trusted entity, as described in the Managing Oracle Secure Enterprise Search in WebCenter Portal section in Administering Oracle WebCenter Portal.

  • Connection exists between the WebCenter Portal application and Oracle Secure Enterprise Search, as described in the Setting Up Oracle SES Connections section in Administering Oracle WebCenter Portal.

Add the following additional URL location paths for the wcpinternal.example.com virtual host in the wcinternal_vh.conf file, and then restart each OHS service. 

<Location /rsscrawl>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

<Location /sesUserAuth>
    WLSRequest ON
    WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

Parent topic: Configuring WebCenter Portal for External Services

Configuring Oracle WebCenter Portal Notifications for the SMTP Mail Server

In a WebCenter Portal Enterprise Deployment, if you choose to send notifications using mail, you must configure a connection to your corporate mail server and specify several unique parameters for the sent emails to appear correctly.

To ensure sufficient configuration for your mail server and business requirements, before completing this task, review Managing Mail in Administering Oracle WebCenter Portal for details on the required and optional configurations and parameters.

You can register a mail server using Fusion Middleware Control or WLST commands:

Parent topic: Configuring WebCenter Portal for External Services

Registering Mail Servers Using Fusion Middleware Control

For details on how to register a mail server using Fusion Middleware Control, see Registering Mail Servers Using Fusion Middleware Control in Administering Oracle WebCenter Portal.

Registering Mail Servers Using WLST

Use the WLST command createMailConnection to create a mail server connection.
  1. Start the WebLogic Scripting Tool:
    ORACLE_HOME/oracle_common/common/bin/wlst.sh
  2. Connect to the Administration Server.

    For example:

    connect('weblogic_wcp','admin password','t3://ADMINVHN:7001')
  3. Register an External Application Connection for the mail server:
    createMailExtAppConnection(appName='webcenter', name='CorpMailServer', displayName='Corporate Mail Server', server='WC_Portal1')

    Note:

    Ignore the warning: Another application named "webcenter" exists....
  4. Register a Mail Server Connection:
    createMailConnection(appName='webcenter', name='NotificationSharedConn', smtpHost='mail.example.com', smtpPort=25, smtpSecured=0, 
timeout=10, default=1,appId='CorpMailServer', server='WC_Portal1')

    Note:

    Additional capabilities are available and might be required depending on your mail server and business needs, such as the ability to notify distribution lists. See Managing Mail in Administering Oracle WebCenter Portal.

  5. Set the required mail server connection properties.

    These properties ensure that a specific mail address is the same in the external application and in the mail server. These properties are added to the mail connection and are used by mail for the From, Display Name, and Reply To fields.

    For example:

    setMailConnectionProperty(appName='webcenter', name='NotificationSharedConn', key='mail.user.emailAddress', value='john.doe@example.com')

setMailConnectionProperty(appName='webcenter', name='NotificationSharedConn', key='mail.user.displayName', value='John Doe')

setMailConnectionProperty(appName='webcenter', name='NotificationSharedConn', key='mail.user.replyToAddress', value='feedback@example.com')
  6. For Exchange 2007 only, create a universal distribution list. To do this, you must update the value of the mail.exchange.dl.group.type property from 2 (default value) to 8.

    Specify a value of 8 for the mail.exchange.dl.group.type mail property, as follows: 

    setMailServiceProperty(appName='webcenter', property='mail.exchange.dl.group.type', value='8')

    If your application offers a self-registration page with the facility to mail user ID information on request, then you must ensure that public credentials are configured for the external application selected here. If public credentials are not defined, then mail cannot be sent to users on their request. WebCenter Portal offers this feature on its default self-registration page.

  7. Restart all servers in the Portal_Cluster.

    Note:

    If additional services are being configured, the portal restart can be done once at the end of the section.

Configuring the Content Server Connection

Oracle WebCenter Portal supports content management and storage capabilities, including file upload, file and folder creation and management, file check out, and versioning.

To provide content integration in WebCenter Portal, you must configure at least one WebCenter Content Server connection and mark it as the default connection (sometimes referred to as the active or primary connection). For more information on the requirements, see the Oracle WebCenter Content Server Requirements section in the Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Portal guide.

Additional configuration is needed to assure high-availablity for the WebCenter Portal Content Manager component file uploads.

Parent topic: Configuring WebCenter Portal for External Services

Registering Oracle WebCenter Content with the WebCenter Portal Application

Provides steps to register Oracle WebCenter Content Server with the WebCenter Portal application.

Note:

For more information about Content Server registration, see the Configuring Back-end Data Repositories for Tools and Services section in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal.

Complete the following steps:
  1. Sign-in to the Fusion Middleware Control by using the administrator's account (for example: weblogic_wcp), and navigate to the home page for your application.

    For example, to navigate to the home page for WebCenter Portal, expand WebCenter > Portal > Server > WebCenter Portal (WC_Portal1).

    Note:

    Multiple WebCenter Portal entries will appear, one for each WebLogic Managed Server. Choose any one. The application registration in this section will apply to the entire portal.
  2. From the WebCenter Portal menu, select Settings, and then Service Configuration.
  3. From the list of services on the WebCenter Service Configuration page, select Content Repository.
  4. To connect to a new content repository, click Add.
  5. Enter a unique name for this connection, specify the content repository type, and indicate whether this connection is the active (or default) connection for the application.

    • Connection Name

      Enter a name for this content repository connection.

      • Name must be unique across all connection types within the WebCenter Portal application.

      • Name should be consistent between portal environments in order to maintain references when exporting or importing portals and content folders, and so on.

    • Repository Type

      Select the type of repository to which you want to connect: Oracle Content Server.

    • Active Connection

      Select this checkbox.

      You must designate one content repository registration as the active connection to serve as the default repository to use for WebCenter Portal functionality.

      You can connect your WebCenter Portal to multiple content repositories. All connections will be used, however one must be designated the active connection to serve as a default selection.

  6. Enter the following additional content repository details after selecting the Active Connection checkbox. These values are required on the default repository connection:

    Note:

    The WebCenter Portal application will re-configure the default/active WebCenter Content repository upon the next restart based on these settings to support proper Portal functionality.

    • Content Administrator

      The default value of sysadmin is recommended. If you wish to customize this value, configure a valid WCC administrative user name here. Administrative privileges are required for this connection so that operations can be performed on behalf of WebCenter Portal users, including creating and maintaining folders for WebCenter Portal content and managing content access rights.

    • Portal Server Identifier

      Enter the root folder under which all WebCenter Portal content is stored. Specify a content repository folder that does not yet exist and use the format: /foldername. For example: /MyWebCenterPortal. The Root Folder cannot be /, the root itself, and it must be unique across applications. The folder specified is created for you when the application starts up. Invalid entries include: /, /foldername/, /foldername/subfolder.

    • Security Group

      Enter a unique name for this WebCenter Portal application within this content repository. For example: MyWebCenterPortalApp

      The name must begin with an alphabetical character, followed by any combination of alphanumeric characters or the underscore character. The string must be less than or equal to fourteen characters.

      This name is used to separate data when multiple WebCenter Portal applications share the same content repository and should be unique across applications. It is also used to name document-related workflows, the security group in which all data created in that Portals application is stored, security roles, as well as to stripe user permissions and default attributes for a particular WebCenter Portal instance.

  7. Enter connection details for the content repository:

    • RIDC Socket Type

      Select Socket - Use an intradoc socket connection to connect to Content Server.

      The client IP address must be added to the list of authorized addresses in the Content Server. In this case, the client is the machine on which Oracle WebCenter Portal is running.

    • Server Host

      Enter the Load Balancer address, wcpinternal.example.com, so that requests to /cs use any available Content Server node.

      The IP address for the virtual host configured on the load balancer and the Self-IP of the load balancer must be added to the Content Server's Incoming Socket Connection Address Security Filter.

      Note:

      If you have not done so already, add a rule to your Load Balancer that specifies how to route WebCenter Content Remote Intradoc Client (RIDC) API traffic, for example: 

      (LBR)10.110.10.135:6300 -> 10.110.10.23:4444 (WCCHOST1) & 10.110.10.24:4444 (WCCHOST2)

    • Server Port

      Enter the port on which the Content Server listens: 6300

    • Connection Timeout (ms)

      Specify the length of time allowed to log in to Content Server (in milliseconds) before issuing a connection timeout message. If no timeout is set, there is no time limit for the login operation. Select a reasonable timeout depending on your environment. For example: 60000.

    • Authentication Method

      Select Identity Propagation - In this enterprise deployment, Content Server and the WebCenter Portal application both use the same identity store to authenticate users.

    • Web Context Root

      Enter /cs as the Web server context root for Content Server.

    • Administrator User Name

      Enter a user name with administrative rights for this Oracle Content Server instance. This user will be used to fetch content type information based on profiles and track document changes for WebCenter Portal cache invalidation. The default value of sysadmin can be used as-is.

    • Administrator Password

      Leave Empty. An Administrator Password value is only required when the socketType is set to web.

  8. Click OK to save this connection.
  9. Restart all servers in the Portal_Cluster.

    Note:

    If additional services are being configured, the portal restart can be done once at the end of the section.
Configure WebCenter Portal Content Manager MBeans for High Availability

The WebCenter Portal Content Manager component and task flows utilize the WebCenter Content remote UI (RUI) APIs to provide content integration capabilities. While these libraries are directly included with the Portal installation, specific MBean configuration settings need to be modified for fail-safe runtime within a High Availability architecture.

Modify and validate the following attributes for the ADFConfig:WccAdfConfiguration and ADFConfig:ADFcConfig application-defined MBeans on the webcenter application:

  • Application: webcenter:

    • ADFConfig: ADFcConfig

      • AdfScopeHaSupport

    • ADFConfig:WccAdfConfiguration:

      • ClusterCompatible

      • TemporayDirectory

The upload temporary directory specified must be configured to a common directory location on a shared disk volume across all portal nodes when the portal is clustered in a High Availability environment.

  1. Create a unique folder on the ORACLE_RUNTIME shared volume for the Portal Content Manager component upload location.
    mkdir -p ORACLE_RUNTIME/DOMAIN_NAME/Portal_Cluster/wccAdfUpload

    For example,

    mkdir -p /u01/oracle/runtime/wcedg/Portal_Cluster/wccAdfUpload
  2. Sign-in to the Fusion Middleware Control by using the administrator's account. For example: weblogic_wcp.
  3. From the WebLogic Domain menu, select System MBean Browser.
  4. Click the green search filter icon on the System MBean Browser navigation menu and search for the following MBean:
    oracle.adf.share.config:ApplicationName=webcenter,Location=WC_Portal1,name=WccAdfConfiguration,type=ADFConfig,Application=webcenter,ADFConfig=ADFConfig

    Note:

    Update the Location value with your first portal Managed Server name if different than WC_Portal1.
  5. Verify the ClusterCompatible attribute has a value of: true.
  6. Set the Temporary Directory attribute to the directory created above on shared storage.

    The Temporary Directory attribute must be set to a directory so that the uploaded files stored under that directory can be accessed by both WCPHOST1 and WCPHOST2.

    For example,

    /u01/oracle/runtime/wcedg/Portal_Cluster/wccAdfUpload
  7. Click Apply.
  8. Wait for the following confirmation message:
    Attributes "TemporaryDirectory" have been updated successfully.
  9. Click the green search filter icon on the System MBean Browser navigation menu and search for the following MBean.

    Note:

    Update the Location value with your first portal Managed Server name if different than WC_Portal1. 
    oracle.adf.share.config:ApplicationName=webcenter,Location=WC_Portal1,name=ADFcConfiguration,type=ADFConfig,Application=webcenter,ADFConfig=ADFConfig
  10. Verify the AdfScopeHASupport attribute value is set to true, update if necessary.
  11. If the value was updated, click Apply, then verify that a confirmation message appears at the top of the page.
  12. Click the green search filter icon on the System MBean Browser navigation menu and search for the following MBean:

    Note:

    Update the location value with your first portal Managed Server name if different than WC_Portal1. 
    oracle.adf.share.config:ApplicationName=webcenter,Location=WC_Portal1,name=ADFConfig,type=ADFConfig,Application=webcenter
  13. Click the Operations tab.
  14. Click on the save link in the Name column on the Operations tab view.
  15. On the Operation:save page, click Invoke to commit all the MBean changes made since the last save operation.
  16. Verify a confirmation message appears at the top of the page, then click Return.
  17. Restart the portal server used in the location for the MBean configuration in prior steps. This server must be the first to restart for the MBean change to take effect properly.
    For example, restart WC_Portal1 based on the MBean search example above.
  18. Restart all other managed servers in the Portal_Cluster.

    Note:

    If additional services are being configured, the remaining portal restarts can be done at the end of the section. With these MBean modifications, WC_Portal1 server should be restarted first to assure the saved MBean attribute settings are consistently applied.

Restarting the Portal Managed Servers to Activate all Service Configuration Changes

If the optional restarts in the sections above have been deferred, restart the portal managed servers now.

Use the WLST to stop and start the Portal Cluster:
  1. Start the WebLogic Scripting Tool:
    ORACLE_HOME/oracle_common/common/bin/wlst.sh
  2. Connect to the Administration Server.

    For example:

    connect('weblogic_wcp','admin password','t3://ADMINVHN:7001")
  3. Stop the Portal Cluster and wait for it to shutdown.
    shutdown('Portal_Cluster', 'Cluster', force='true', block='true')
  4. Start the Portal Cluster and wait for it to reach a RUNNING state.
    start('Portal_Cluster', 'Cluster', block='true')
  5. Confirm the Portal_Cluster has fully started.
    state('Portal_Cluster', 'Cluster')
  6. Exit the WLST session.
    exit()

Parent topic: Configuring WebCenter Portal for External Services

Backing Up the Configuration

It is an Oracle best practices recommendation to create a backup after you successfully extended a domain or at another logical point. Create a backup after you verify that the installation so far is successful. This is a quick backup for the express purpose of immediate restoration in case of problems in later steps.

The backup destination is the local disk. You can discard this backup when the enterprise deployment setup is complete. After the enterprise deployment setup is complete, you can initiate the regular deployment-specific Backup and Recovery process.

For information about backing up your configuration, see Performing Backups and Recoveries for an Enterprise Deployment.

Parent topic: Extending the Domain with Oracle WebCenter Portal