5 Upgrading WebCenter Sites from 11g to 12c

Upgrading from 11g to 12c is an out-of-place migration. This includes using the Upgrade Assistant to migrate data tables and platform configuration.

The valid 11g starting point for upgrading WebCenter Sites to 12.2.1.3.0 is WebCenter Sites 11.1.1.8.0 and 11.1.1.8.0 Patch 12+. This is an out-of-place migration.

Note:

There are two approaches that you can consider while upgrading depending on your requirement:

  1. You can upgrade the delivery environment and clone it after the upgrade to create development and management environments.

    If you consider this approach, synchronization is required. You must publish the contents from your development and management environments in to the delivery environment before the upgrade. You can then clone your upgraded delivery environment to create development and management environments.

  2. Alternatively, you can upgrade each environments individually.

    If you consider this approach, synchronization is not required.

Note:

If you are upgrading from 11.1.1.6.x, you must upgrade to release 11.1.1.8 using WebCenter Sites 11g upgrade procedure documented in About the WebCenter Sites Upgrade Process, Fusion Middleware WebCenter Sites Upgrade Guide.

To upgrade WebCenter Sites from 11g to 12c, complete the following tasks:

About the WebCenter Sites Upgrade Process from 11g to 12c

Review the flowchart and the roadmap for an overview of the upgrade process for Oracle WebCenter Sites.

Figure 5-1 Upgrade Process Flowchart for WebCenter Sites from 11g to 12c Release

Description of Figure 5-1 follows
Description of "Figure 5-1 Upgrade Process Flowchart for WebCenter Sites from 11g to 12c Release"

Table 5-1 provides a roadmap for tasks that you must perform to upgrade WebCenter Sites from 11g to 12c.

Table 5-1 Tasks for Upgrading WebCenter Sites from 11g to 12c Release

Task Description

Required

If you have not done so already, review the introductory topics in this guide and complete the required pre-upgrade tasks.

The pre-upgrade tasks include cloning your production environment, verifying system requirements and certifications, purging unused data, and creating non-SYSDBA user.

For a complete list of pre-upgrade tasks, see Pre-Upgrade Tasks for Oracle WebCenter Components.

Required

Download and install the 12c (12.2.1.3.0) Oracle Fusion Middleware Infrastructure and Oracle WebCenter Sites distributions.

The Infrastructure distribution packs the WebLogic Server and the Java Required Files (JRF) that are required to set up the foundation to install other Fusion Middleware products.

As per the upgrade topology defined in this guide, you must install the Infrastructure in a new Oracle home.

You must install the Oracle WebCenter Sites distribution in the Oracle home that is created when you install the 12.2.1.3.0 Infrastructure. To install the product distributions, follow the procedure described in Installing the Product Distribution.

Required

Create the required schemas.

If you are upgrading from WebCenter Sites 11g, you must create the required 12c schemas before you begin the upgrade. The schemas required for WebCenter Sites are: Oracle Platform Security Services (OPSS), Audit Services (IAU), and WebCenter Sites.

Create the schemas with the Repository Creation Utility (RCU) as described in Creating the Required 12c Schemas with the RCU.

Required

Configure the WebCenter Sites domain.

Upgrade from 11g to 12c is an out-of-place upgrade. Therefore, configure the WebCenter Sites 12c (12.2.1.3.0) domain by following the procedure described in Configuring the WebCenter Sites Domain

Required

Configure the WebCenter Sites instance.

Configure a WebCenter Sites instance by completing the browser-based WebCenter Sites Configurator by following the procedure described in Configuring WebCenter Sites Instance.

Required

Complete the post-configuration tasks.

The post-configuration tasks include configuring the 12c (12.2.1.3.0) domain with LDAP-based or OAM-based authentication, verifying the directory structure, signing in and accessing the Sites UI, and restarting the managed servers.

These tasks are listed in Post-Configuration Tasks.

Required

Complete the required tasks before running the Upgrade Assistant.

The pre-upgrade tasks are a set of tasks that you must complete before starting the upgrade process with the Upgrade Assistant.

These tasks are listed in Before Running the Upgrade Assistant.

Required

Upgrade the schemas.

Upgrade the schemas components that are available for upgrade with the Upgrade Assistant by following the procedure described in Upgrading Product Schemas.

Required

Upgrade the Sites configuration.

Upgrade the Sites configurations contained in your 11g (11.1.1.8) domain with the Upgrade Assistant by following the procedure described in Upgrading Sites Configuration Using the Upgrade Assistant.

Required

Complete the post-upgrade validation tasks.

Oracle has provided validation scripts that you can run on your newly upgraded domain to ensure data integrity after a successful schema and configuration upgrade. You can review the validation summary report for any inconsistencies in data that may have occurred during the schema and configuration upgrade processes.

To use the validation script, see Post-Upgrade Validation Tasks.

Required

Complete the other post-upgrade tasks.

Other post-upgrade tasks include restoring any custom settings, starting Administration Server and Managed Servers, reconfiguring passwords, and other administrative tasks listed in Post-Upgrade Tasks.

Installing the Product Distribution

Before beginning your upgrade, download the 12c (12.2.1.3.0) Oracle Fusion Middleware Infrastructure and Oracle WebCenter Sites distributions on the target system and install them using Oracle Universal Installer.

Note:

When Infrastructure is required for the upgrade, you must install the Oracle Fusion Middleware distribution first before you install other Fusion Middleware products.

Make sure that you download and install all the Oracle products that are part of your domain, for example Oracle HTTP Server. You must install the 12.2.1.3.0 binaries into a new Oracle home. It should be on the same host as the existing Oracle home.

To install the 12c (12.2.1.3.0) distributions:
  1. Sign in to the target system.
  2. Download the following from Oracle Technology Network or Oracle Software Delivery Cloud to your target system:
    • Oracle Fusion Middleware Infrastructure (fmw_12.2.1.3.0_infrastructure_generic.jar)
    • Oracle WebCenter Sites (fmw_12.2.1.3.0_wcsites_generic.jar)
  3. Change to the directory where you downloaded the 12c (12.2.1.3.0) product distribution.
  4. Start the installation program for Oracle Fusion Middleware Infrastructure:
    • (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
    • (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
  5. On UNIX operating systems, the Installation Inventory Setup screen appears if this is the first time you are installing an Oracle product on this host.
    Specify the location where you want to create your central inventory. Make sure that the operating system group name selected on this screen has write permissions to the central inventory location, and click Next.

    Note:

    The Installation Inventory Setup screen does not appear on Windows operating systems.
  6. On the Welcome screen, review the information to make sure that you have met all the prerequisites. Click Next.
  7. On the Auto Updates screen, select an option:
    • Skip Auto Updates: If you do not want your system to check for software updates at this time.

    • Select patches from directory: To navigate to a local directory if you downloaded patch files.

    • Search My Oracle Support for Updates: To automatically download software updates if you have a My Oracle Support account. You must enter Oracle Support credentials then click Search. To configure a proxy server for the installer to access My Oracle Support, click Proxy Settings. Click Test Connection to test the connection.

    Click Next.
  8. On the Installation Location screen, specify the location for the Oracle home directory and click Next.
    For more information about Oracle Fusion Middleware directory structure, see Understanding Directories for Installation and Configuration in Oracle Fusion Middleware Planning an Installation of Oracle Fusion Middleware.
  9. On the Installation Type screen, select the following:
    • For Infrastructure, select Fusion Middleware Infrastructure
    • For Oracle WebCenter Sites, select WebCenter Sites

      Note:

      Ensure that you select WebCenter Sites and not WebCenter Sites with Examples.

    Click Next.
  10. The Prerequisite Checks screen analyzes the host computer to ensure that the specific operating system prerequisites have been met.
    To view the list of tasks that are verified, select View Successful Tasks. To view log details, select View Log. If any prerequisite check fails, then an error message appears at the bottom of the screen. Fix the error and click Rerun to try again. To ignore the error or the warning message and continue with the installation, click Skip (not recommended).
  11. On the Installation Summary screen, verify the installation options that you selected.
    If you want to save these options to a response file, click Save Response File and enter the response file location and name. The response file collects and stores all the information that you have entered, and enables you to perform a silent installation (from the command line) at a later time.

    Click Install to begin the installation.

  12. On the Installation Progress screen, when the progress bar displays 100%, click Finish to dismiss the installer, or click Next to see a summary.
  13. The Installation Complete screen displays the Installation Location and the Feature Sets that are installed. Review this information and click Finish to close the installer.
  14. After you have installed Oracle Fusion Middleware Infrastructure, enter the following command to start the installer for your product distribution and repeat the steps above to navigate through the installer screens:
    (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.3.0_wcsites_generic.jar
    (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.3.0_wcsites_generic.jar

Creating the Required 12c Schemas with the RCU

When upgrading from 11g, you must create the required 12c schemas. You can use the Repository Creation Utility (RCU) to create customized schemas or, optionally, you can use the Upgrade Assistant to create schemas using the default schema settings. This procedure describes how to create schemas using the RCU. Information about using the Upgrade Assistant to create schemas is covered in the upgrade procedures.

Note:

If you are upgrading from a previous 12c release of Oracle Fusion Middleware, you do not need to re-create these schemas if they already exist. Refer to the steps below to identify the existing schemas in your domain.

The following schemas must exist before you upgrade to 12c. If you are upgrading from 11g, and you are not sure which schemas you currently have, refer to the steps below to identify the existing schemas in your domain. You do not need to re-create these schemas if they already exist.

  • Service Table schema (prefix_STB). This schema is new in 12c and is required for domain-based upgrades. It stores basic schema configuration information (for example, schema prefixes and passwords) that can be accessed and used by other Oracle Fusion Middleware components during the domain creation. This schema is automatically created when you run the Repository Creation Utility (RCU), where you specify the existing schema owner prefix that you used for your other 11g schemas.

    Note:

    If the Service Table schema does not exist, you may encounter the error message UPGAST-00328 : The schema version registry table does not exist on this database. If that happens it is necessary to create the service table schema in order to run Upgrade Assistant

  • Oracle Platform Security Services (OPSS) schema (prefix_OPSS). This schema is required if you are using an OID-based security store in 11g. This schema is automatically created when you run the Repository Creation Utility (RCU). The only supported LDAP-based OPSS security store is Oracle Internet Directory (OID). An LDAP-based policy store is typically used in production environments. You do not need to reassociate an OID-based security store before upgrade. While the Upgrade Assistant is running, you can select the OPSS schema. The Upgrade Assistant upgrades the OID-based security store automatically.

    Note:

    The 12c OPSS database schema is required so that you can reference the 12c schema during the reconfiguration of the domain. Your domain continues to use the OID-based security store after the upgrade is complete.

  • Audit Services (IAU)

  • WebCenter Sites

To create the 12c schemas with the RCU:
  1. (Optional) If you are upgrading from 11g, and you wish to confirm the schemas which are present in your existing domain, then connect to the database as a user with DBA privileges, and run the following code from SQL*Plus:
    SET LINE 120
    COLUMN MRC_NAME FORMAT A14
    COLUMN COMP_ID FORMAT A20
    COLUMN VERSION FORMAT A12
    COLUMN STATUS FORMAT A9
    COLUMN UPGRADED FORMAT A8
    SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;
    
  2. Verify that a certified JDK already exists on your system by running java -version from the command line. For 12c (12.2.1.3.0), the certified JDK is 1.8.0_131 and later.
    Ensure that the JAVA_HOME environment variable is set to the location of the certified JDK. For example:
    • (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_131
    • (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_131
    Add $JAVA_HOME/bin to $PATH.
  3. Go to the oracle_common/bin directory:
    • (UNIX) NEW_ORACLE_HOME/oracle_common/bin
    • (Windows) NEW_ORACLE_HOME\oracle_common\bin
  4. Start the RCU:
    • (UNIX) ./rcu
    • (Windows) rcu.bat
  5. On the Welcome screen, click Next.
  6. On the Create Repository screen, select Create Repository and then select System Load and Product Load.
    If you do not have DBA privileges, select Prepare Scripts for System Load. This will generate a SQL script containing all the same SQL statements and blocks that would have been called if the RCU were to execute the actions for the selected components. After the script is generated, a user with the necessary SYS or SYSDBA privileges can execute the script to complete the system load phase.

    Click Next.

  7. On the Database Connection Details screen, select the Database Type and enter the connection information for the database that hosts the 11g schemas. See the pertinent table below.

    Table 5-2 Connection Credentials for Oracle Databases and Oracle Databases with Edition-Based Redefinition

    Option Description and Example
    Host Name

    Specify the name of the server where your database is running in the following format:

    examplehost.exampledomain.com

    For Oracle RAC databases, specify the VIP name or one of the node names in this field.

    Port

    Specify the port number for your database. The default port number for Oracle databases is 1521.

    Service Name

    Specify the service name for the database. Typically, the service name is the same as the global database name.

    For Oracle RAC databases, specify the service name of one of the nodes in this field. For example:

    examplehost.exampledomain.com

    Username Enter the user name for your database. The default user name is SYS.
    Password Enter the password for your database user.
    Role

    Select the database user's role from the drop-down list:

    Normal or SYSDBA

    Table 5-3 Connection Credentials for MySQL Databases

    Option Description and Example
    Host Name

    Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.

    Port

    Specify the port number for your database.

    Database Name

    Specify the name of your database.

    Username Specify the name of a user with administrator privileges.
    Password Enter the password for your database user.

    Table 5-4 Connection Credentials for Microsoft SQL Server Databases

    Option Description and Example
    Unicode Support

    Select Yes or No from the drop-down list.

    Server Name Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.

    MSSQL named instances: A named instance is identified by the network name of the computer and the instance name that you specify during installation. The client must specify both the server name and the instance name when connecting.

    Port

    Specify the port number for your database.

    Database Name

    Specify the name of your database.

    Username Specify the name of a user with administrator privileges.
    Password Enter the password for your database user.

    Table 5-5 Connection Credentials for IBM DB2 Databases

    Option Description and Example
    Server Name Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.
    Port

    Specify the port number for your database.

    Database Name

    Specify the name of your database.

    Username Specify the name of a user with DB Owner privileges. The default user name for IBM DB2 databases is db2admin.
    Password Enter the password for your database user.
    If the prerequisite check is successful, click OK to continue to the next screen. If the check fails, review the details you entered and try again.
  8. On the Select Components screen, select Select existing prefix and select the prefix that was used to create the existing 11g schemas from the drop-down menu (for example, DEV11G). This prefix is used to logically group schemas together for use in this domain.

    Select the following schemas:
    • Audit Services

    • Audit Services Append

    • Audit Services Viewers

    • WebCenter Sites

    • WebCenter Sites-Visitor Services

    • Metadata Services (_MDS)

    • User Messaging Service (_UMS)

    • WebLogic Server (_WLS)

    Note:

    The Common Infrastructure Services (prefix_STB) and Oracle Platform Security Services (prefix_OPSS) schemas are selected by default if they have not yet been created.

    Make a note of the prefix and schema names for the components you are installing as you will need this information when you configure the installation. Click Next.
  9. In the Checking Prerequisites dialog, verify that the prerequisites check is successful, then click OK.
  10. On the Schema Passwords screen, specify the passwords for your schema owners.
    Make a note of the passwords you enter on this screen as you will need this information while configuring your product installation.
  11. On the Map Tablespaces screen, configure the required tablespace mapping for the schemas you want to create.
    Click Next, then click OK in the confirmation dialog. When the progress dialog shows the tablespace creation is complete, click OK.
    You see the Encrypt Tablespace check box only if you have enabled Transparent Data Encryption (TDE) in the database (Oracle or Oracle EBR) when you start the RCU. Select the Encrypt Tablespace check box on the Map Tablespaces screen to encrypt all new tablespaces that the RCU creates.
  12. Verify the information on the Summary screen and click Create to begin schema creation.
    This screen contains information about the log files that were created from this RCU operation. Click on the name of a particular log file to view the contents of that file.
  13. Review the information on the Completion Summary screen to verify that the operation is completed successfully. Click Close to complete the schema creation.

Configuring the WebCenter Sites Domain

If you are upgrading from WebCenter Sites 11g to 12c, then you must configure the WebCenter Sites domain using the Configuration Wizard.

To configure the WebCenter Sites domain:
  1. Change directory to the following:
    (UNIX) NEW_ORACLE_HOME/oracle_common/common/bin
    (Windows) NEW_ORACLE_HOME\oracle_common\common\bin
  2. Start the configuration wizard by entering the following command:
    (UNIX) ./config.sh
    (Windows) config.cmd
  3. On the Configuration Type screen, select Create a new domain.
    In the Domain Location field, specify the Domain home directory and click Next.
    Oracle recommends you to select the domain directory location outside the Oracle home directory, which is where the Fusion Middleware products are installed. To learn more about the recommended directory structure, see What Are the Key Oracle Fusion Middleware Directories? in Oracle Fusion Middleware Understanding Oracle Fusion Middleware.
  4. On the Templates screen, select Create Domain Using Product Templates:
    Select the following from the Templates Category drop-down list:
    • Oracle WebCenter Sites - 12.2.1.3.0 [wcsites]
    • Oracle JRF - 12.2.1.3.0 [oracle_common]
    • Oracle Enterprise Manager - 12.2.1.3.0 [em]
    • WebLogic Coherence Cluster Extension - 12.2.1.3.0 [wlserver]

    Note:

    The list of Oracle WebCenter Sites templates available in this screen depends on your selection of template while installing the WebCenter Sites binaries. During the 11g to 12c upgrade process, Oracle recommends you to select only Oracle WebCenter Sites (with or without WebCenter Sites – With Examples).

    Click Next.
  5. On the Application Location screen, specify the Application Location to store applications associated with your domain by entering the path or by clicking Browse to use the navigation tree. The Application Location is also known as the Application home directory.
    Oracle recommends you to select the application location outside the Oracle home directory, which is where the Fusion Middleware products are installed. To learn more about the recommended directory structure, see What Are the Key Oracle Fusion Middleware Directories? in Oracle Fusion Middleware Understanding Oracle Fusion Middleware.
    Click Next.
  6. On the Administrator Account screen, specify the user name and password you provided for the 11.1.1.8 WebCenter Sites domain click Next.
    These account details are used to boot and connect to the WebCenter Sites domain’s Administrator Server.
  7. On the Domain Mode and JDK screen, select Production and Oracle HotSpot JDK from the Domain Mode and JDK sections respectively and click Next.
  8. On the Database Configuration Type screen, specify details about the database and database schema.
    Select RCU Data. This option instructs the Configuration Wizard to connect to the database and Service Table (STB) schema to automatically retrieve schema information for schemas needed to configure the domain.
    If you select Manual Configuration on this screen, you must manually fill in parameters for your schema on the JDBC Component Schema screen.
    Specify the connection details in the following fields:

    Note:

    Make sure that the 11g schema and the 12c schema collocate on the same database.

    Table 5-6 Field Descriptions for the Database Configuration Type Screen

    Field Description
    DBMS/Service

    Enter the database DBMS name, or service name if you selected a service type driver.

    Example: orcl.exampledomain.com

    Host Name

    Enter the name of the server hosting the database.

    Example: examplehost.exampledomain.com

    Port

    Enter the port number on which the database listens.

    Example: 1521

    Schema Owner and Schema Password

    Enter the username and password for connecting to the database's Service Table schema that you specified when you created the schemas using the RCU.

    The default username is prefix_STB, where prefix is the custom prefix that you defined in RCU.

    Click Get RCU Configuration.
    The following output in the Connection Result Log indicates that the operation succeeded. Click OK to go to the next screen.
    Connecting to the database server...OK
    Retrieving schema data from database server...OK
    Binding local schema components with retrieved data...OK
    
    Successfully Done.
  9. On the JDBC Component Schema screen, verify or specify the details about the database schemas.
    Verify that the values are correct for all schemas. If you selected RCU Data on the Database Configuration Type screen, the schema table should already be populated appropriately.
    Click Next.
  10. The JDBC Component Schema Test screen is used to test the data source connections.
    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 by clicking Test Selected Connections.
    By default, the schema password for each schema component is the password you specified while creating your schemas. If you want different passwords for different schema components, manually edit them on the previous screen (JDBC Component Schema) by entering the password you want in the Schema Password column, against each row. After specifying the passwords, select the check box corresponding to the schemas that you changed the password in and test the connection again.
    Click Next.
  11. The Advanced Configuration screen is used to complete the domain configuration. Select the options for which you want to perform advanced configuration and click Next:

    Table 5-7 Advanced Configuration Screen Options

    Option Description
    Administration Server Required to properly configure the listen address of the Administration Server.
    Node Manager Required to configure Node Manager.
    Topology Required to configure the WebCenter Sites Managed Server.
  12. On the Administration Server screen, specify a server name in the ServerName field.
    Select the IP address of the host from the Listen Address drop-down list where you want the Administration Server to reside. Do not select All Local Addresses.
    You can retain the default value in the Listen Port field or specify a number between 1 and 65535. The custom value must be different from SSL listen port and coherence port.
    Do not specify any Server Groups for the Administration Server.
    Click Next.
  13. On the Node Manager screen, select the type of Node Manager you want to configure, along with the Node Manager credentials.
    For the Node Manager Type, select Per Domain Default Location.
    Specify the user name and the password in the Node Manager Credentials field.
  14. On the Managed Servers screen, you can Add, Clone, or Delete the Managed Servers and also assign a server group (if available) to a Managed Server.
    1. In the Listen Address drop-down list, select the IP address of the host you want the Managed Server to reside on. You can also specify the system name or DNS name that maps to a single IP address. Do not select All Local Addresses.
    2. Click Enable SSL to enable security.
    The Configuration Wizard automatically populated the default Server Groups for each Managed Server added by default. If you add additional servers, select WCSITES-MGD-SERVER from the Server Groups drop-down list.
    Server Groups target Fusion Middleware applications and services to one or more servers by mapping defined application service groups to each defined server group. A given application service group can be mapped to multiple server groups if needed. Any application services that map to a given server group are automatically targeted to all servers that are assigned to that group.
    Click Help to learn more about adding, cloning, or deleting a Managed Server.
    When finished, click Next.
  15. On the Clusters screen, click Add to create a new cluster.
    A cluster is a group of WebLogic Server instances that work together to provide scalability and high-availability for applications. By creating clusters, you can group Managed Servers such that they operate as a single unit for hosting applications and resources.
    Specify a name for your cluster in the Cluster Name field., such as wcs_cluster_1. Leave the Cluster Address field blank.
    Repeat and add one more cluster, namely, wcs_cluster_2, and click Next.
    For more information about this screen, click Help.

    Note:

    You can also create clusters using Enterprise Manager Fusion Middleware Control.
  16. On the Assign Servers to Clusters screen, assign Managed Servers to the new cluster.
    1. In the Clusters pane, select the cluster to which you want to assign the Managed Servers. For example, wcs_cluster_1.
    2. In the Servers pane, assign a server to a cluster by doing one of the following:
      • Single-click a server from the Servers pane and click the right-arrow button (>) to move it under the selected cluster.

      • Double-click a server from the Servers pane to move it under the selected cluster.

    3. Repeat this procedure to assign all the Servers to the Clusters.

    Note:

    Only Managed Servers are displayed under the Server pane. The Administration Server is not listed because you cannot assign it to a cluster.
    Click Next.
  17. The Coherence Clusters screen is displayed only if you have included Coherence during the Infrastructure installation.
    Specify a name for the Coherence Cluster in the Cluster Name field. You can also retain the default name.
    Leave the default port number 0 as the Cluster Listen Port and click Next. After configuration, the Coherence cluster is automatically added to the domain.
  18. On the Machines screen, create new machines in the domain. A machine is required so that you can use the Node Manager to start and stop servers.
    Select the Machine tab (for Windows) or the UNIX Machine tab (for UNIX), then click Add to create a new machine.
    Specify a name for the machine in the Name field. For example, wcs_machine_1.
    In the Node Manager Listen Address field, select the IP address of the machine in which you have configured the Managed Servers.
    You must select a specific interface and not localhost. This allows Coherence cluster addresses to be dynamically calculated.

    Note:

    If you are extending an existing domain, you can assign servers to any existing machine. It is not necessary to create a new machine unless your situation requires it.
    Click Next.
  19. On the Assign Servers to Machines screen, assign the Administration Server and Managed Servers to the new machine you created on the Machines screen.
    1. In the Machines pane, select the machine to which you want to assign the Administration Server and the Managed Servers. For example, wcs_machine_1.
    2. In the Servers pane, assign each server to a machine by doing one of the following:
      • Single-click a server from the Servers pane and click the right-arrow button (>) to move it under the selected machine.

      • Double-click a server from the Servers pane to move it under the selected machine.

    3. Repeat this procedure to assign all the Servers to the Machine.
    Click Next.
  20. On the Virtual Targets screen, click Next.
  21. On the Partitions screen, click Next.
  22. The Configuration Summary screen has detailed configuration information for the domain you are about to create.
    Review each item on the screen and verify that the information is correct and click Create to create the domain.
    You can limit the items that are displayed in the summary pane by selecting a filter option from the View drop-down list.
    To make any changes, go back to a screen by clicking Back or by selecting the screen in the navigation pane. Domain creation does not start until you click Create.
  23. The Configuration Progress screen displays the progress of the domain creation process.
    If the domain creation is successful, click Next.
    If the domain creation fails, review the errors and try again. If you cannot troubleshoot the errors, contact My Oracle Support for further assistance.
  24. The End of Configuration screen displays the domain location and the Admin Server URL for the domain you created.
    Note the values for further operations.

Note:

For IBM DB2, WebCenter Sites does not support the default data source created by the Fusion Middleware Configuration Wizard. To create new data source with a driver that DB2 supports:
  1. Add the IBM DB2 Driver JAR files to the class path for the WebCenter Sites domain:

    1. Stop the WebLogic Server Administration Server.

    2. Copy the db2jcc.jar and db2jcc_license_cu.jar files from DB2 to a location that you can add to the domain class path.

    3. Edit NEW_DOMAIN_HOME/bin/setDomainEnv.sh and add the following line after # ADD EXTENSIONS TO CLASSPATHS:

      PRE_CLASSPATH="path_to_db2jcc.jar:path_to_db2jcc_license_cu.jar:${PRE_CLASSPATH}"

    4. Start the Administration Server.

  2. Create a new data source using the preceding DB2 driver.

Configuring WebCenter Sites Instance

After you configure the Oracle WebCenter Sites domain, you can configure a WebCenter Sites instance by completing the browser-based WebCenter SitesConfigurator. WebCenter Sites runtime consists of WebCenter Sites and CAS web applications (WAR files) and the following components shared across cluster members: a config directory, a data directory, and a database instance.

The following topics describe how to configure WebCenter Sites:

Prerequisites for Configuring WebCenter Sites Instance

Several prerequisite tasks must be done before you use the WebCenter Sites Configurator. These tasks include granting permissions for OPSS access, modifying cache files, and setting property values for your environment.

Before configuring WebCenter Sites, ensure that you complete the following tasks:
  1. Ensure that the Administration Server is running. Grant read, write, and delete permissions for accessing the Oracle Platform Security Services credential store to NEW_ORACLE_HOME/wcsites/wcsites_common/lib/sites-security.jar by executing the following script:
    (UNIX) DOMAIN_HOME/wcsites/bin/grant-opss-permission.sh
    (Windows) DOMAIN_HOME\wcsites\bin\grant-opss-permission.bat

    Use the WebLogic Server Administrator user name and password, when prompted by the script.

    If a domain home other than the default (ORACLE_HOME/user_projects/domains/domain_name) was specified in the Fusion Middleware Configuration Wizard, make sure grant-opss-permission.sh or grant-opss-permission.bat contains the specified domain name before running it. If necessary, edit the file and update the domain name.

  2. In the WebCenter Sites config directory, modify the files cs-cache.xml, ss-cache.xml, linked-cache.xml, and cas-cache.xml as follows:
    1. Locate the following section:
      <cacheManagerPeerProviderFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" properties="peerDiscovery=automatic, multicastGroupAddress=230.0.0.0, multicastGroupPort=4444, timeToLive=0" />
    2. Change the value of the peerDiscovery property to manual.
    3. Save and close the file.
  3. Start the Node Manager before you start the WebCenter Sites Managed Server.

Configuring WebCenter Sites with the Configurator

The WebCenter Sites Configurator populates the database with tables and data necessary for WebCenter Sites to function. The Configurator also creates the necessary user accounts and sets the required permissions on the database objects.

Note:

If you are configuring WebCenter Sites over a slow network, increase the setting of the StuckThreadMaxTime property to 1000 seconds per thread before starting the WebCenter Sites Configurator. The default value is 600 seconds.

In certain environments that potentially have network-related issues, the sample sites import process could take more than 600 seconds per thread during the WebCenter Sites configuration setup process. This can cause the import process or install to fail, and multiple exceptions in the log file. Oracle recommends increasing the setting to 1000 seconds to complete a successful installation of the sample sites.

To change the value of StuckThreadMaxTime, in the WebLogic Server Administration Console for the domain, go to Servers and click wcsites_server1. Under Configuration, click Tuning.

To run the browser-based WebCenter Sites Configurator after the corresponding WebLogic domain has been successfully set up:
  1. To configure WebCenter Sites over a web server, increase the web server timeout value to 300 sec before starting the WebCenter Sites configuration.
    1. (Optional) To run the Configurator in silent mode:
      1. Edit the wcs_properties_bootstrap.ini file that is located in the NEW_DOMAIN_HOME/wcsites/wcsites/config directory and complete the online instructions.

      2. Start the WebCenter Sites Managed Server.

      3. Initiate the WebCenter Sites configuration process with the following command:
        • On UNIX operating systems: xdg-open http://sites-host:sites-port/sites/sitesconfig

        • On Windows operating systems: start http://sites-host:sites-port/sites/sitesconfig

    2. (Optional) Set the values of the following properties as appropriate for your environment, using the Property Management Tool in the Admin interface. Set these properties for a cluster that uses the NIO database-based file system. If you would like files stored in locations other than the default (individual folders under NEW_DOMAIN_HOME/wcsites/wcsites/config), specify the locations as property values because they cannot be changed once WebCenter Sites is up and running.
      Properties Description
      xcelerate.transformpath

      Directory where Microsoft Word files are stored before WebCenter Sites transforms those files into assets.

      cs.pgcachefolder

      Deprecated. Only set if instructed to do so by Oracle Support.

      cs.xmlfolder

      Working directory for HTML rendering.

      cs.pgexportfolder

      Base export directory for the HTML files that are created when assets are published with the Export to Disk delivery type.

      vis.path

      Directory where WebCenter Sites is installed. You must include the trailing slash.

      mwb.path

      Directory where WebCenter Sites is installed. You must include the trailing slash.

      contentserver.installation.folder

      Directory where WebCenter Sites is installed. You must include the trailing slash. Applies to installations in which Satellite Server and WebCenter Sites are running in the same web application and must therefore share the user's session. Specifying this enables Satellite Server to access WebCenter Sites resources.

      cs.csdtfolder

      Directory where WebCenter Sites Developer Tools imports are stored.

      For more information on the preceding properties, see Oracle Fusion Middleware Property Files Reference for Oracle WebCenter Sites.

  2. Start the Managed Server for the WebCenter Sites primary cluster node.
  3. In a web browser, access this URL: http://sites-host:sites-port/sites/sitesconfigsetup.
  4. On the WebCenter Sites Configurator screen, click Begin.
  5. On the Database Parameters screen, specify the JNDI Datasource name for the WebCenter Sites database repository This must be the repository you created using the Repository Creation Utility while setting up the WebLogic domain.
  6. On the Web Application Parameters screen, select Yes if you are installing over a secure connection, leave all the parameters at their default (prepopulated) values, and click Next.
  7. On the CAS Deployment Information screen, leave all parameters at their default (prepopulated) values and click Next. If using a cluster and a front-end web server for load balancing, adjust these values as appropriate for your environment.
  8. On the WebCenter Sites Administrator Accounts screen, specify the credentials you want, and then click Next.
  9. (Optional) If you chose the WebCenter Sites with Examples installation option when installing WebCenter Sites, the Sample Sites screen appears. On this screen, select the desired sample sites and click Next.
  10. On the Configuration Summary screen, click Test and verify that all tests are successful. Then click Start and wait for the configuration process to complete.
  11. Restart the Managed Server for the WebCenter Sites application.
  12. Verify that WebCenter Sites is up and running by accessing the following URL in a web browser and logging in: http://sites-host:sites-port/sites.

Note:

The default location for cas.log is NEW_DOMAIN_HOME/servers/wcsites_server1/logs/.
To get XMLPost and Bulkloader up and running, set the following directories in the CLASSPATH environment variable:
NEW_ORACLE_HOME\wcsites\webcentersites\sites-home\lib\*
ORACLE_HOME\oracle_common\modules\clients\*

For information about how to configure additional cluster nodes, see Setting Up a Cluster.

For information about how to configure an external LDAP authentication provider, see Switching to Authentication Against an LDAP Directory.

For information about how to configure Oracle Access Manager integration, see Switching to Authentication Against Oracle Access Manager.

For information about how to use the WebCenter Sites Configuration Import/Export Utility, see Using the Property Management Tool in Oracle Fusion Middleware Property Files Reference for Oracle WebCenter Sites.

Post-Configuration Tasks

After configuring the WebCenter Sites 12c, complete the tasks listed in this topic.

  1. If the existing Sites 11.1.1.8 environment is configured with LDAP-based or OAM-based authentication, configure the same for your 12.2.1.3.0 environment as well.

    To switch to LDAP-based authentication, see Switching to Authentication Against an LDAP Directory.
    To switch to LDAP-based authentication, see Switching to Authentication Against Oracle Access Manager.

  2. Verify the directory structure. You must have Oracle Home (containing product binaries), Sites Home (domain and config data), and Sites Shared directories created after you configure WebCenter Sites.
  3. Sign in to the Sites UI using your Administrator credentials.
  4. Restart Managed Servers and access WebCenter Sites.

Switching to Authentication Against an LDAP Directory

This topic describes how to switch WebCenter Sites to authentication against an external LDAP authentication provider directory. This is a recommended solution for production environments if integration with Oracle Access Management is not viable.

Before you change your authentication provider, install and configure WebCenter Sites.
To switch WebCenter Sites to authentication against an external LDAP directory:
  1. (Optional) Modify ldap.caseAware property value to true, if the LDAP server you are using is case sensitive.
    By default the value of ldap.caseAware is set to false. Sign in will fail if you are using a case-sensitive LDAP server and this property is set to false. To modify the ldap.caseAware value to True follow the steps:
    • Sign in to the WebCenter Sites Admin interface and navigate to Admin tree tab>System Tools>Property Management option.

    • Search for ldap and change the value from False to True.

    • Restart the Managed server.

    Note:

    During the integration of Sites with LDAP, if the users data in LDAP is separated by a comma the data does not get fetched. for example: test,user. To retrieve the data, you need to change the syntax in the dir.ini file located at ..sites/install directory from "syntax.escape=\\ to syntax.escape=\#".
  2. Access the LDAP Configurator at http://sites-host:sites-port/sites-context/ldapconfig, follow the instructions on the screen, and enter the values for your environment.
  3. For LDAP rollback, restart the WebCenter Sites Managed Server, and go to the same LDAP Configurator URL.

    Now there is only manual LDAP integration. Nothing is written to your LDAP Server, only an LDIF file is created under the DOMAIN_HOME/wcsites/wcsites/config/ldap folder (This is the default install location of WebCenter Sites application. All customizations and path modifications should be made after successful LDAP integration). The peopleparent, groupparent, username, and other fields are not prepopulated, as in the previous release.

  4. (Optional) Modify the LDIF file located in NEW_DOMAIN_HOME/wcsites/wcsites/config/ with values appropriate for your environment.

    Because the fields are not prepopulated, follow this example for ORACLEDIR :

    ldap server type -- ORACLEDIR
    ldap DSN -- dc=oracle,dc=com
    ldap host -- localhost
    ldap port -- 389
    ldap username -- cn=orcladmin
    ldap password -- password
    ldap peopleParent -- cn=Users,dc=oracle,dc=com
    ldap groupparent -- cn=Groups,dc=oracle,dc=com
  5. If you choose Oracle Virtual Directory as your LDAP authentication provider, WebCenter Sites generates an LDIF file, which you can import to your Oracle Internet Directory server and then create an adaptar in Oracle Virtual Directory to connect to the Oracle Internet Directory server.

    You cannot import an LDIF file directly to an Oracle Virtual Directory LDAP server because it does not have a storage of its own.

  6. Import the LDIF file into the external LDAP authentication provider.
  7. Restart the WebLogic Managed Server running this WebCenter Sites instance.

Switching to Authentication Against Oracle Access Manager

You can configureWebCenter Sites for authentication against Oracle Access Manager. This solution is recommended for production environments.

It is assumed that customer already has OAM Server running. This OAM integration would require configuration in the OAM Server using oamconsole and some configuration changes in the Sites.
WebCenter Sites integration is supported for Oracle Access Manager 11.1.2.2.0 and 11.1.2.3.0.
To switchWebCenter Sites to authentication against Oracle Access Manager:
  1. Sign in to Oracle Access Manager Server through oamconsole, for example: http://<oam_host:oam_port>/<oam console>/ and configure a WebGate.
  2. Deploy the oamlogin.war and oamtoken.war application files located under NEW_ORACLE_HOME/wcsites/webcentersites/sites-home on the WebLogic domain containing the targetWebCenter Sites instance.
  3. Create the wemsites_settings.properties property file under DOMAIN_HOME/wcsites/wcsites/config/.
  4. Enter the values in the wemsites_settings.properties file as follows:
    Elements Properties
    oamredirect http://oam_server_host:oam_port/oam/server/auth_cred_submit
    oamlogout oamlogout=http://oam_server_host:oam_port/oam/server/logout
    forgotpassword helpdesk-email-address
  5. Set the following properties in NEW_DOMAIN_HOME/wcsites/wcsites/config/SSOConfig.xml. See Step 12 of Integration Steps.
    Elements Properties
    serviceUrl http://{ohs_server_host}:{ohs_port}/{sites_context_root}/REST
    ticketUrl http://{oamtoken_server_host}:{oamtoken_port}/oamtoken
    signoutURL

    http://{oam_server_host}:{oam_port}/oam/server/logout?end_url={end_url}

    Use this URL when invokingWebCenter Sites logout. It includes the encoded URL where the browser will return after all logout processing has been completed by Oracle Access Manager.
    end_url

    For test (staging) and production (delivery) environments: http%3A%2F%2F{ohs_server_host}%3A{ohs_port}%2F{sites_context_root}%2Fwem%2Ffatwire%2Fwem%2FWelcome

    dbUsername Name of theWebCenter Sites general Administrator user account.
    dbPassword Password for the WebCenter Sites general Administrator user account.

    Note:

    The ohs_server host and ohs_port can be WebLogic host and port or any other HTTP server host and port depending on your configuration. For more information on OHS configuration, see Step 2 to Step 9 of Integration Steps. Add the below example for configuration in OAM OHS, mod_wl_ohs.conf file.
    <IfModule weblogic_module>
        <Location /oamlogin>
         SetHandler weblogic-handler
           WebLogicHost SITES_HOST       
    WebLogicPort SITES_PORT   
    </Location> 
    </IfModule>
      <IfModule weblogic_module>
     <Location /sites>
           SetHandler weblogic-handler
           WebLogicHost SITES_HOST
           WebLogicPort SITES_PORT
     </Location>
     </IfModule>
  6. Copy the obAccsessClient.xml and cwallet.sso files from your Oracle Access Manager instance into the NEW_DOMAIN_HOME/wcsites/wcsites/config/oblix/lib/ directory on the targetWebCenter Sites instance.

    Note:

    These files are auto-generated after the WebGate is configured.
  7. Edit the oamtoken.xml file in the sites-config directory by setting the compatibility mode and oblix path. The compatibility mode should be set to 11g and the oblix path to the sites-config folder under which you have the oblix/lib folder.
  8. In the Oracle Access Manager configuration for WebCenter Sites, update the protected, public, and excluded resources as follows:

    Figure 5-2 List of Protected, Public, and Excluded Resources for WebCenter Sites

    Description of Figure 5-2 follows
    Description of "Figure 5-2 List of Protected, Public, and Excluded Resources for WebCenter Sites"
  9. To integrate the OAMSDK Client with WebLogic Server as the oamtoken.war application, edit the jps-config.xml file for the WebCenter Sites domain. By default, the WebLogic domain runs with this file, which is part of the WebLogic Server 12 c startup script:

    -Doracle.security.jps.config=NEW_ORACLE_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/jps-config.xml

    1. Add a service instance, as the following example shows, next to existing service instances in the existing jsp-config.xml file:
      <serviceInstance name="credstore.oamtoken" provider="credstoressp" location="./oamtoken">
      <description>File Based Credential Store Service Instance</description>
      <property name="location" value="./oamtoken"/>
      </serviceInstance>
      location is the path to the directory that contains the cwallet.sso file. The preceding example sets this path with reference to the current jsp-config.xml file. Make sure the omtoken folder is created with respect to the current directory and the cwallet.sso file is placed there. The location value can also be an absolute path to where the cwallet.sso file is placed
    2. Add <serviceInstanceRef ref="credstore.oamtoken"/> under <jpsContext name="default">.
    3. Add following <jpsContext> element under <jpsContexts default="default">:
      <jpsContext name="OAMASDK">
      <serviceInstanceRef ref="credstore.oamtoken"/>
      </jpsContext>
  10. Add permissions so that code in oamtoken.war can be used.
    The WebGate instance created in Oracle Access Manager is accessed by the client. You need to add the credential to the WebCenter Sites domain so that the security restriction can be taken care of.
    1. Launch the WebLogic Scripting Tool with the wlst.sh script:
      cd NEW_ORACLE_HOME/oracle_common/common/bin/./wlst.sh
    2. Connect to the Administration Server for the WebCenter Sites domain:
      connect('user-name','password','sites-host:admin-port')
    3. Grant the permissions:
      grantPermission(codeBaseURL="file:/scratch/idc/newoam/rend/Oracle_Home/user_projects/domains/renddomain/servers/wcsites_server1/tmp/_WL_user/oamtoken/-", permClass="oracle.security.jps.service.credstore.CredentialAccessPermission",permTarget="context=SYSTEM,mapName=OAMAgent,keyName=*",permActions="*")
      The preceding path is basically the path where WebLogic Server has deployed the oamtoken.war application.
    4. Restart the target WebCenter Sites Managed Server.
  11. (Optional) If trust betweenWebCenter Sites and Oracle Access Manager has not been established, modify the configuration of theWebCenter Sites web tier as follows:
    1. Sign in to the Oracle Access Manager Console.
    2. In the WebGate authorization policy (under the protected resource policy), go to the Responses tab.
    3. Enable (select) the Identity Assertion check box.
    4. Click Apply to save your changes.
  12. (Optional) If WebCenter Sites is deployed on a cluster is using OAM Integration. Following steps are required to be replicated on oamticketcache cache.
    1. In the config directory, we have cas-cache.xml where oamticketcache is configured by default.
    2. Uncomment the commented section in the cache named oamticketcache the section appear as:
      <cacheEventListenerFactory
      class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"  
      properties="replicateAsynchronously=true, replicatePuts=true,
      replicateUpdates=true,
      	replicateUpdatesViaCopy=false, replicateRemovals=true"/>
      <bootstrapCacheLoaderFactory 
      class="net.sf.ehcache.distribution.RMIBootstrapCacheLoaderFactory"
      		properties="bootstrapAsynchronously=false,
      			maximumChunkSizeBytes=5000000"
      		propertySeparator="," />
    3. Change the cacheManagerPeerProviderFactory as follows, make sure port is unique. 
      <cacheManagerPeerProviderFactory
      class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
      	properties="peerDiscovery=automatic,
      multicastGroupAddress=230.0.0.8,
      		multicastGroupPort=40002, timeToLive=1" />
    4. The port should be different for cacheManagerPeerProviderFactory and cacheManagerPeerListenerFactory as specified in the earlier steps.
    5. All the cluster nodes should have same port for both the properties.
  13. For working on the SSOConfig.xml file, follow the steps:
    1. Modify the SSOConfig.xml file of theWebCenter Sites deployment. This file controls the loaded authentication classes and the properties that are required by those classes.
    2. Shutdown the Sites server.
    3. Backup the SSOConfig.xml file located in the WEB-INF/classes directory of the deployed WebCenter Sites application.
      For example: /u01/software/Apps/OraMiddleware/user_projects/domains/OAMSitesDomain/wcsites/wcsites/config/SSOConfig.xml.
    4. Modify SSOConfig.xml as follows: 

      Note:

      Further steps explains on setting properties for the following: serviceUrl, ticketUrl, signoutURL, dbUsername, and dbPassword. See Step 5.
    5. The signoutUrl property specifies the URL to be used when invoking WebCenter Sites logout. It includes the encoded URL where the browser will return after all logout processing has been completed by OAM.
    6. For Sites management, use the following value for end_url: http%3A%2F%2F{ohs_server_host}%3A{ohs_port}%2F{sites_context_root}%2Fwem%2Ffatwire%2Fwem%2FWelcome 
    7. For Sites delivery, use the following value for end_url:  http%3A%2F%2F{ohs_server_host}%3A{ohs_port}%2F{sites_context_root}%2Fwem%2Ffatwire%2Fwem%2FWelcome
      For the dbUsername and dbPassword properties, you can enter the credentials of the WebCenter Sites general administrator, which by default is fwadmin/xceladmin. The values for these properties will be encrypted on startup of the WebCenter Sites application.

      Note:

      In the code example below, you will set the following properties: csServerUrl, serviceUrl, ticketUrl, signoutURL, dbUsername, dbPassword. See Step 5.
      <?xml version="1.0" encoding="UTF-8"?>
      <!--
      
          Copyright (c) 2010 FatWire Corporation. All Rights Reserved.
          Title, ownership rights, and intellectual property rights in and
          to this software remain with FatWire Corporation. This  software
          is protected by international copyright laws and treaties, and
          may be protected by other law.  Violation of copyright laws may
          result in civil liability and criminal penalties.
      
      -->
      
      <beans xmlns="http://www.springframework.org/schema/beans"
      	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jdbc="http://www.springframework.org/schema/jdbc"
      	xmlns:p="http://www.springframework.org/schema/p" xmlns:context="http://www.springframework.org/schema/context"
      	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
      	http://www.springframework.org/schema/jdbc http://www.springframework.org/schema/jdbc/spring-jdbc-3.1.xsd
      	http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">
      
      	<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" />
      	<!-- Root Context: defines shared resources visible to all other web components -->
      	
      	<jdbc:initialize-database data-source="dataSource"	enabled="true" ignore-failures="ALL">		
      		<!-- For installer the first jdbc:script will opened. Installer will configure it automatically -->
      		<jdbc:script location="classpath:crawler_oracle_db.sql" />
      		<!--jdbc:script location="classpath:crawler_hsql_db.sql" /-->
      		<!--jdbc:script location="classpath:crawler_sql_server_db.sql" /-->
      		<!--jdbc:script location="classpath:crawler_oracle_db.sql" /-->
      		<!--jdbc:script location="classpath:crawler_db2_db.sql" /-->
      	</jdbc:initialize-database>
      	
      	<!-- Section# 1 Installer will consume below configuration to configure a datasource name created on the appservers -->
      	<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
      		<property name="jndiName" value="wcsitesDS"/>
      	</bean>
      	
      	<!-- Single Sign On provider -->
      	<bean id="ssoprovider" class="com.fatwire.wem.sso.oam.OAMProvider">
      		<property name="config" ref="ssoconfig" />
      	</bean>
      	<!--It is invoked by the OAM filter to resolve an OAM authenticated user against a remote Site CS instance.--> 
      	<bean id="oamIdentity" class="com.fatwire.auth.identity.RemoteUsernameResolver" >
      		<property name="csServerUrl" value="http://{ohs_server_host}:{ohs_port}/{sites_context_root}/custom/customCsResolver.jsp"/>
      	</bean>
        
      	<!-- Single Sign On filter -->
      	<bean id="ssofilter" class="com.fatwire.wem.sso.oam.filter.OAMFilter">
      		<property name="config" ref="ssoconfig" />
      		<property name="provider" ref="ssoprovider" />
      		<property name="identityResolver" ref="oamIdentity" />
      		
      		<!-- Set "trustConfigured" to "true" in case of trust relationship configured between WebGate and WLS.
      		It will turn off check for OAM_ASSERTION header. -->
      		<property name="trustConfigured" value="false" />
      	</bean>
        
      
      	<!-- Single Sign On listener -->
      	<bean id="ssolistener" class="com.fatwire.wem.sso.oam.listener.OAMListener">
      	</bean>
      	
      	<!-- Single Sign On configuration -->
      	<bean id="ssoconfig" class="com.fatwire.wem.sso.oam.conf.OAMConfig">
      		<!-- URL prefix for REST service endpoint -->
      		<property name="serviceUrl" value="http://{ohs_server_host}:{ohs_port}/{sites_context_root}/REST" />
      		
      		<!-- URL prefix for Token Service servlet -->
      		<property name="ticketUrl" value="http://{oamtoken_server_host}:{oamtoken_port}/oamtoken" />
      		
      		<!-- URL to be called when WEM logout is required. -->
      		<property name="signoutUrl" value="http://{oam_server_host}:{oam_port}/oam/server/logout?end_url=http%3A%2F%2F{ohs_server_host}%3A{ohs_port}%2F{sites_context_root}%2Fwem%2Ffatwire%2Fwem%2FWelcome"/>
      		
      		<!-- Do not proxy tickets, tt's the last server in thecall chain -->
      		<property name="proxyTickets" value="false" />
      		
      		<!-- Database Credentials needed by user lookup inOAMFilter -->
      		<property name="dbUsername" value="fwadmin" />
      		<property name="dbPassword" value="xceladmin"/>
      		
      		<!-- Your application protected resources (relative to applicationUrl) -->
      		<property name="protectedMappingIncludes">
      			<list>
      				<value>/__admin</value>
      				<value>/__admin/**</value>
      			</list>
      		</property>
      		
      		<!-- Your application protected resources excludes (relative to applicationUrl) -->
      		<property name="protectedMappingExcludes">
      			<list>
      				<value>/__admin/layout</value>
      			</list>
      		</property>
      		<property name="applicationProxyCallbackPath" value="/sso/proxycallback" />
      		<property name="gateway" value="false" />
      	</bean>
      	
      	<context:component-scan base-package="com.fatwire.crawler.remote.dao" />
      	<context:component-scan base-package="com.fatwire.crawler.remote.support" />
      	<context:component-scan base-package="com.fatwire.crawler.remote.di" />
      	<context:component-scan base-package="com.fatwire.crawler.remote.resources.support" />
      
      </beans>
After you authenticate OAM, you need to perform the following integrations:
SiteCapture integrating with OAM

This topics covers steps to integrate the SiteCapture with OAM.

Oracle Access Manager integration for SiteCapture you need to follow the steps:
  1. Integrate Oracle WebCenter Sites with Oracle Access Manager. For more information see, Integrating Oracle WebCenter Sites with OAM .
  2. Additional configuration required for Oracle Access Manager for SiteCapture.
    1. Create additional resource definitions (see table below) for the WebCenter Sites application domain.
      Resource URL Protection level Authentication Authorization
      /<sites-context>/REST/roles

      Unprotected

      Public

      All Allowed

      /<sites-context>/custom/customCsResolver.jsp

      Unprotected

      Public

      All Allowed

      /resources/.../*

      Excluded

      NA

      NA

      /__admin/.../*

      Protected

      Protected

      Protected

    2. Configure the Protected Resource Policy as follows:
    1. Click Application Domains and click the Open icon.
    2. Click Search and select WCSitesWebGate.
    3. Click the Authentication Policies tab and select Authentication Policies . For Authentication Scheme, select LDAPWemScheme, the authentication scheme previously created.
    4. Click Responses tab.
    5. Select the Identity Assertion checkbox.
    6. When an Authentication policy is satisfied, it can create responses. The responses are required by the WebCenter Sites HTTP filter to recognize LDAP attributes and provide information about the authenticated user. In the following steps, you will create these responses.
    7. Click the Add (+) icon. and enter the following:
    1. For Name: Enter FATGATE_CSTIMEOUT
    2. For Type: Select Header
    3. For Value: Enter 30
  3. SiteCapture Application Installation. During installation process of SiteCapture use parameters that are mentioned below:
    Property Description Property Value
    Content server host name or IP

    fw.cs.hostname

    {ohs_host}

    Content server app server port

    fw.cs.port

    {ohs_port}

    Content server context

    fw.cs.context

    {sites_context_root}

    Content server protocol (http or https)

    fw.cs.protocol

    {sites.protocol}

    Content Server user name having RESTADMIN role

    fw.cs.username

    {username}

    Content server user password

    fw.cs.password

    {password}

    SiteCapture server hostname or IP

    fw.sc.hostname

    {sc_host}

    SiteCapture app server port

    fw.sc.port

    {sc_port}

    SiteCapture protocol (http or https)

    fw.sc.protocol

    {sc.protocol}

    CAS server hostname

    fw.cas.host

    {ohs_host} in installer. Or

    Empty in sitecapture.properties

    CAS server port

    fw.cas.port

    {ohs_port} in installer. Or

    Empty in sitecapture.properties

    CAS server context

    fw.cas.context

    cas in installer. Or

    Empty in sitecapture.properties

  4. Adjust the root-context.xml file in SiteCapture Application. SiteCapture shipped with two files:
    1. root-context.xml
      Backup root-context.xml file and rename to root-context.xml.bak file.
    2. oam_root-context.xml
      Rename oam_root-context.xml file to root-context.xml file.
      <?xml version="1.0" encoding="UTF-8"?>
      <!--
      
          Copyright (c) 2010 FatWire Corporation. All Rights Reserved.
          Title, ownership rights, and intellectual property rights in and
          to this software remain with FatWire Corporation. This  software
          is protected by international copyright laws and treaties, and
          may be protected by other law.  Violation of copyright laws may
          result in civil liability and criminal penalties.
      
      -->
      
      <beans xmlns="http://www.springframework.org/schema/beans"
      	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jdbc="http://www.springframework.org/schema/jdbc"
      	xmlns:p="http://www.springframework.org/schema/p" xmlns:context="http://www.springframework.org/schema/context"
      	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
      	http://www.springframework.org/schema/jdbc http://www.springframework.org/schema/jdbc/spring-jdbc-3.1.xsd
      	http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">
      
      	<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" />
      	<!-- Root Context: defines shared resources visible to all other web components -->
      	
      	<jdbc:initialize-database data-source="dataSource"	enabled="true" ignore-failures="ALL">		
      		<!-- For installer the first jdbc:script will opened. Installer will configure it automatically -->
      		<jdbc:script location="classpath:crawler_oracle_db.sql" />
      		<!--jdbc:script location="classpath:crawler_hsql_db.sql" /-->
      		<!--jdbc:script location="classpath:crawler_sql_server_db.sql" /-->
      		<!--jdbc:script location="classpath:crawler_oracle_db.sql" /-->
      		<!--jdbc:script location="classpath:crawler_db2_db.sql" /-->
      	</jdbc:initialize-database>
      	
      	<!-- Section# 1 Installer will consume below configuration to configure a datasource name created on the appservers -->
      	<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
      		<property name="jndiName" value="wcsitesDS"/>
      	</bean>
      	
      	<!-- Single Sign On provider -->
      	<bean id="ssoprovider" class="com.fatwire.wem.sso.oam.OAMProvider">
      		<property name="config" ref="ssoconfig" />
      	</bean>
      	<!--It is invoked by the OAM filter to resolve an OAM authenticated user against a remote Site CS instance.--> 
      	<bean id="oamIdentity" class="com.fatwire.auth.identity.RemoteUsernameResolver" >
      		<property name="csServerUrl" value="http://{ohs_server_host}:{ohs_port}/{sites_context_root}/custom/customCsResolver.jsp"/>
      	</bean>
        
      	<!-- Single Sign On filter -->
      	<bean id="ssofilter" class="com.fatwire.wem.sso.oam.filter.OAMFilter">
      		<property name="config" ref="ssoconfig" />
      		<property name="provider" ref="ssoprovider" />
      		<property name="identityResolver" ref="oamIdentity" />
      		
      		<!-- Set "trustConfigured" to "true" in case of trust relationship configured between WebGate and WLS.
      		It will turn off check for OAM_ASSERTION header. -->
      		<property name="trustConfigured" value="false" />
      	</bean>
        
      
      	<!-- Single Sign On listener -->
      	<bean id="ssolistener" class="com.fatwire.wem.sso.oam.listener.OAMListener">
      	</bean>
      	
      	<!-- Single Sign On configuration -->
      	<bean id="ssoconfig" class="com.fatwire.wem.sso.oam.conf.OAMConfig">
      		<!-- URL prefix for REST service endpoint -->
      		<property name="serviceUrl" value="http://{ohs_server_host}:{ohs_port}/{sites_context_root}/REST" />
      		
      		<!-- URL prefix for Token Service servlet -->
      		<property name="ticketUrl" value="http://{oamtoken_server_host}:{oamtoken_port}/oamtoken" />
      		
      		<!-- URL to be called when WEM logout is required. -->
      		<property name="signoutUrl" value="http://{oam_server_host}:{oam_port}/oam/server/logout?end_url=http%3A%2F%2F{ohs_server_host}%3A{ohs_port}%2F{sites_context_root}%2Fwem%2Ffatwire%2Fwem%2FWelcome"/>
      		
      		<!-- Do not proxy tickets, tt's the last server in thecall chain -->
      		<property name="proxyTickets" value="false" />
      		
      		<!-- Database Credentials needed by user lookup inOAMFilter -->
      		<property name="dbUsername" value="fwadmin" />
      		<property name="dbPassword" value="xceladmin"/>
      		
      		<!-- Your application protected resources (relative to applicationUrl) -->
      		<property name="protectedMappingIncludes">
      			<list>
      				<value>/__admin</value>
      				<value>/__admin/**</value>
      			</list>
      		</property>
      		
      		<!-- Your application protected resources excludes (relative to applicationUrl) -->
      		<property name="protectedMappingExcludes">
      			<list>
      				<value>/__admin/layout</value>
      			</list>
      		</property>
      		<property name="applicationProxyCallbackPath" value="/sso/proxycallback" />
      		<property name="gateway" value="false" />
      	</bean>
      	
      	<context:component-scan base-package="com.fatwire.crawler.remote.dao" />
      	<context:component-scan base-package="com.fatwire.crawler.remote.support" />
      	<context:component-scan base-package="com.fatwire.crawler.remote.di" />
      	<context:component-scan base-package="com.fatwire.crawler.remote.resources.support" />
      
      </beans>

      Note:

      To update mod_wl_ohs.conf file the following code has to be included:
      <IfModule weblogic_module>
      <Location /__admin>
      		SetHandler weblogic-handler
      		WebLogicHost SITECAPTURE_HOST
      	WebLogicPort SITECAPTURE_HOST 
      </Location>
      </IfModule>
       
Integrating OAM with Oracle WebCenter Sites: Satellite Server

This topics covers steps to integrate OAM with Oracle WebCenter Sites: Satellite Server.

Configuring a Satellite Server for Oracle Access Manager integration is a simpler procedure than for WebCenter Sites. For more information on Integrating OAM with WebCenter Sites using Satellite Server, see Integrating OAM with Oracle WebCenter Sites: Satellite Server

Note:

The code example below gives the RSS configuration in OAM OHS, and mod_wl_ohs.conf file.
<IfModule weblogic_module>
 <Location /ss>
       SetHandler weblogic-handler
       WebLogicHost SATELLITESERVER_HOST
     WebLogicPort SATELLITESERVER_HOST
 </Location>
 </IfModule>
Integrating OAM with Visitor Services

This topic covers steps to integrate OAM with Visitor Services.

Before performing steps described in this section, ensure that you have configured the OAMIdentityProvider provided with Visitor Services.  The OAM identity provider enables Visitor Services to communicate with OAM. For more information on Integrating OAM with Visitor Services, see Oracle Fusion Middleware Developing with Oracle WebCenter Sites.

Note:

The code example below gives the Visitor configuration in OAM OHS, and mod_wl_ohs.conf file.
<IfModule weblogic_module>
    <Location /oamlogin>
      SetHandler weblogic-handler
       WebLogicHost SITES_HOST
       WebLogicPort SITES_PORT
   </Location>
 </IfModule>
 <IfModule weblogic_module>
 <Location /visitors-webapp>
   SetHandler weblogic-handler       
	WebLogicHost VISITORSERVICES_HOST    
	WebLogicPort VISITORSERVICES_HOST
 </Location>
 </IfModule>

Before Running the Upgrade Assistant

Before running the Upgrade Assistant to upgrade from 11.1.1.8, complete the tasks listed in this topic.

Before running the Upgrade Assistant:
  1. If your existing Sites 11.1.1.8 environment is a clustered configuration, you can either upgrade the primary node to 12.2.1.3.0 and reconfigure the cluster setup on target, or you can upgrade all cluster members.
    To upgrade all cluster members, register the cluster nodes by completing the following steps:
    1. Sign in to Sites Admin Server URL.
    2. Go to Admin and click Cluster Node Management under System Tools.
    3. Configure node names for each cluster as per the source environment.
      The nodes configured in this step are eventually mapped to the corresponding 11.1.1.8 nodes during the upgrade process.
  2. Shut down the source (11.1.1.8) and the target (12.2.1.3.0) Admin Server and Managed Server instances.
  3. If the source (11.1.1.8) and target (12.2.1.3.0) are on different physical machines, then Oracle recommends that you migrate the following source install directories on to the target machine before starting the upgrade process.
    Migrating the source install directories on to the target machine helps to reduce the process time during upgrade.
    • Sites 11.1.1.8.0 Sites Install/Home
    • Sites 11.1.1.8.0 Sites Shared
    • Sites 11.1.1.8.0 web apps path of deployed Sites war
  4. If your existing Sites 11.1.1.8 environment is a clustered environment, migrate the nodes from source machine to target machine.
    You can migrate the source instance directories in any order. Following is a sample example:
    If the source environment is a two-node cluster setup, create two directories with name which you gave while registering the nodes during Cluster Node Management. For example, if node names given while registering the nodes are NodeA and NodeB, then create two directories: NodeA and NodeB on target machine.
    Copy the source data on the target machine in the following format:
    NodeA (Primary node)
    		Sites-install/Home
    		Sites-Shared
    		Location of deployed sites war
    NodeB (Secondary node)
    		Sites-install/Home
    		Location of deployed sites war

    Note:

    You don’t need to copy Sites-Shared per node.
  5.  Ensure that the source schema (11g) and target schema (12c) collocate on the same database server.
    Oracle
    <Single DB Instance>
    11g schema
    12c schema
    MS SQL Server
    <Single DB Instance>
    11g schema
    12c schema
    DB2
    <Single DB Instance>
    11g schema
    12c schema
  6. If you are an Oracle user, you must create a Non-SYSDBA user for performing the upgrade. To create a Non-SYSDBA user, see Creating a Non-SYSDBA User to Run the Upgrade Assistant.
  7. If you are a DB2 user, consider the following before starting the upgrade:
    • Import the Sites 11.1.1.8.0 schema from source database to target database (where 12.2.1.3.0 Sites schema is setup) before initiating schema upgrade. For a detailed procedure, see Copying 11.1.1.8 Schema from a DB2 Source to a New Target Database.

    • Import the DB2 database on the same machine to make sure that your existing Sites 11.1.1.8 runtime is not affected during upgrade process.

    • Because the source schema and target schema reside on single DB instance, specify the target database instance details along with the schema details during the schema upgrade process.

  8. Ensure that the 12.2.1.3.0 target schema tablespace size has enough capacity to complete the successful data migration from the 11g source schema. The default target schema size is set to 5 GB by the RCU. You can adjust the tablespace size according to the size of the source schema.
  9. Typically, Sites uses the time zone setting of the WebLogic JVM. However, if you want to use a different time zone, ensure that you change it immediately after you install Sites, that is, before you create any data in the target (12.2.1.3.0) environment.

Creating a Non-SYSDBA User to Run the Upgrade Assistant

Oracle recommends that you create a non-SYSDBA user called FMW to run the Upgrade Assistant. This user has the privileges required to modify schemas, but does not have full administrator privileges.

SYSDBA is an administrative privilege that is required to perform high-level administrative operations such as creating, starting up, shutting down, backing up, or recovering the database. The SYSDBA system privilege is for a fully empowered database administrator. When you connect with the SYSDBA privilege, you connect with a default schema and not with the schema that is generally associated with your user name. For SYSDBA, this schema is SYS. Access to a default schema can be a very powerful privilege. For example, when you connect as user SYS, you have unlimited privileges on data dictionary tables. Therefore, Oracle recommends that you create a non-SYSDBA user to upgrade the schemas. The privileges listed below must be granted to user FMW before starting the Upgrade Assistant.

Notes:

The non-SYSDBA user FMW is created solely for the purpose of running the Upgrade Assistant. After this step is complete, drop the FMW user. Note that privileges required for running the Upgrade Assistant may change from release to release. 
By default, the v$xatrans$ table does not exist. You must run the XAVIEW.SQL script to create this table before creating the user. Moreover, the grant select privilege on thev$xatrans$ table is required only by Oracle Identity Manager . If you do not require Oracle Identity Manager for configuration, or if you do not have the v$xatrans$ table, then remove the following line from the script:
   grant select on v$xatrans$ to FMW with grant option;
In the example below, password is the password that you set for the FMW user. When granting privileges, make sure that you specify your actual password.
create user FMW identified by password;
grant dba to FMW;
grant execute on DBMS_LOB to FMW with grant option;
grant execute on DBMS_OUTPUT to FMW with grant option;
grant execute on DBMS_STATS to FMW with grant option;
grant execute on sys.dbms_aqadm to FMW with grant option;
grant execute on sys.dbms_aqin to FMW with grant option;
grant execute on sys.dbms_aqjms to FMW with grant option;
grant execute on sys.dbms_aq to FMW with grant option;
grant execute on utl_file to FMW with grant option;
grant execute on dbms_lock to FMW with grant option;
grant select on sys.V_$INSTANCE to FMW with grant option;
grant select on sys.GV_$INSTANCE to FMW with grant option;
grant select on sys.V_$SESSION to FMW with grant option;
grant select on sys.GV_$SESSION to FMW with grant option;
grant select on dba_scheduler_jobs to FMW with grant option;
grant select on dba_scheduler_job_run_details to FMW with grant option;
grant select on dba_scheduler_running_jobs to FMW with grant option;
grant select on dba_aq_agents to FMW with grant option;
grant execute on sys.DBMS_SHARED_POOL to FMW with grant option;
grant select on dba_2pc_pending to FMW with grant option;
grant select on dba_pending_transactions to FMW with grant option;
grant execute on DBMS_FLASHBACK to FMW with grant option;
grant execute on dbms_crypto to FMW with grant option;
grant execute on DBMS_REPUTIL to FMW with grant option;
grant execute on dbms_job to FMW with grant option;
grant select on pending_trans$ to FMW with grant option;
grant select on dba_scheduler_job_classes to fmw with grant option;
grant select on SYS.DBA_DATA_FILES to FMW with grant option;
grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option;
grant select on v$xatrans$ to FMW with grant option;
grant execute on sys.dbms_system to FMW with grant option;
grant execute on DBMS_SCHEDULER to FMW with grant option;
grant select on dba_data_files to FMW with grant option;
grant execute on UTL_RAW to FMW with grant option;
grant execute on DBMS_XMLDOM to FMW with grant option;
grant execute on DBMS_APPLICATION_INFO to FMW with grant option;
grant execute on DBMS_UTILITY to FMW with grant option;
grant execute on DBMS_SESSION to FMW with grant option;
grant execute on DBMS_METADATA to FMW with grant option;
grant execute on DBMS_XMLGEN to FMW with grant option;
grant execute on DBMS_DATAPUMP to FMW with grant option;
grant execute on DBMS_MVIEW to FMW with grant option;
grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option;
grant select on dba_queue_subscribers to FMW with grant option; 
grant execute on SYS.DBMS_ASSERT to FMW with grant option;
grant select on dba_subscr_registrations to FMW with grant option;
grant manage scheduler to FMW;

If you are upgrading Oracle Identity Manager (OIM) schema, ensure that the FMW user has the following additional privileges:

grant execute on SYS.DBMS_FLASHBACK to fmw with grant option;
grant execute on sys.DBMS_SHARED_POOL to fmw with grant option;
grant execute on SYS.DBMS_XMLGEN to FMW with grant option;
grant execute on SYS.DBMS_DB_VERSION to FMW with grant option;
grant execute on SYS.DBMS_SCHEDULER to FMW with grant option;
grant execute on SYS.DBMS_SQL to FMW with grant option;
grant execute on SYS.DBMS_UTILITY to FMW with grant option;
grant ctxapp to FMW with admin option;
grant execute on SYS.DBMS_FLASHBACK TO FMW with grant option;
grant create MATERIALIZED VIEW to FMW with admin option;
grant all on SCHEMA_VERSION_REGISTRY TO FMW with grant option;
grant create SYNONYM to FMW with admin option;
grant execute on CTXSYS.CTX_ADM to FMW with grant option;
grant execute on CTXSYS.CTX_CLS TO FMW with grant option;
grant execute on CTXSYS.CTX_DDL TO FMW with grant option;
grant execute on CTXSYS.CTX_DOC TO FMW with grant option;
grant execute on CTXSYS.CTX_OUTPUT TO FMW with grant option;
grant execute on CTXSYS.CTX_QUERY TO FMW with grant option;
grant execute on CTXSYS.CTX_REPORT TO FMW with grant option;
grant execute on CTXSYS.CTX_THES TO FMW with grant option;
grant execute on CTXSYS.CTX_ULEXER TO FMW with grant option;
grant create JOB to FMW with admin option;

Copying 11.1.1.8 Schema from a DB2 Source to a New Target Database

You must import the Sites 11.1.1.8 schema from source DB2 database to target database (where 12.2.1.3.0 Sites schema is setup) before upgrading the schemas.

Consider the following criteria to make sure that the import operation is successful:

Note:

This task is applicable only if your database is on DB2. You can skip this task for Oracle or MS SQL Server databases.

  • Ensure the user performing the database import has the required privileges on the target database.
  • Set the APPLHEAPSZ of the target database to an appropriate value depending on your schema size.
To copy the Sites 11.1.1.8 schema from source database to target database:
  1. Enter the following command from the location where you created the database directories:
    db2move <old_db> COPY -sn <schemaname> -co TARGET_DB <targetDB> user <username> using <password>

    Table 5-8 DatabaseMovement Command Parameters

    Parameter Description
    db2move Database movement tool command. It is used to move the tables within the DB2 database from the source system to the target system.
    old_db Specify the name of the database existing on the source system.
    COPY Indicates the database movement tool to perform a copy operation.
    schemaname Specify the schema name for the database existing on the source system.
    targetDB Specify the name of the target database.
    username Specify the user name.
    password Specify the password.
    For example:
    db2move dot8db COPY -sn dot8schema -co TARGET_DB 12cdb user dot8user using test1234
  2. Verify that the copy operation is successful by performing the following steps:
    1. Sign in to the DB2 console.
    2. Connect to the new (target) database.
    3. List and query the tables to make sure that data is copied properly.
  3. Grant the necessary privileges for the DB_SITE (RCU 12c Sites user) before upgrading.

Upgrading Product Schemas

After stopping servers and processes, use the Upgrade Assistant to upgrade supported product schemas to the current release of Oracle Fusion Middleware.

The Upgrade Assistant allows you to upgrade individually selected schemas or all schemas associated with a domain. The option you select determines which Upgrade Assistant screens you will use.

Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.3.0). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

Note:

Before you start the Upgrade Assistant, make sure that the JVM character encoding is set to UTF-8 for the platform on which the Upgrade Assistant is running. If the character encoding is not set to UTF-8, then you will not be able to download files containing Unicode characters in their names. This can cause the upgrade to fail.

  1. Go to the oracle_common/upgrade/bin directory:
    • (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin
  2. Start the Upgrade Assistant:
    • (UNIX) ./ua
    • (Windows) ua.bat

For information about other parameters that you can specify on the command line, such as logging parameters, see:

Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 5-9 Upgrade Assistant Command-Line Parameters

Parameter Required or Optional Description

-readiness

Required for readiness checks

Note: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

  • TRACE

  • NOTIFICATION

  • WARNING

  • ERROR

  • INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant creates log files and temporary files.

The default locations are:

(UNIX)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

NEW_ORACLE_HOME\oracle_common\upgrade\logs
NEW_ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command-line options.

Upgrading Product Schemas Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.

To upgrade the 11g schemas:
  1. On the Welcome screen, review the introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

    Note:

    For more information about any Upgrade Assistant screen, click Help on the screen.
  2. On the Selected Schemas screen, select Individually Selected Schemas and click Next.
    The Upgrade Assistant identifies the components that are available for a schema upgrade thus allowing you to select the schemas you want to include in the upgrade.
  3. If you selected Individually Selected Schemas: On the Available Components screen, select the components for which you want to upgrade schemas. When you select a component, the schemas and any dependencies are automatically selected.
    Select Oracle WebCenter Sites and click Next.
  4. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

    Note:

    The Upgrade Assistant does not verify whether the prerequisites have been met.
  5. On the WebCenter Sites Source Version screen, select 11.1.1.8.0 and click Next. This is the starting point of your upgrade.
  6. On the WebCenter Sites Location screen, specify the complete location of the existing Sites home and Sites shared directory, and location of the 12c configuration file: wcs_properties.json.
    Click Next.
  7. On the WebCenter Sites Source Schema screen, select the database type from the Database Type drop-down list.
    Specify the database connect string in the Database Connect String field in the following format:
    • (Oracle Database) host:port/service or host:port:SID or TNS connect string
    • (Microsoft SQL Server) //host:port;DatabaseName=dbname
    • (IBM DB2) //host:port;DatabaseName=dbname

    Specify the user name with DBA privileges in the DBA User Name field. For example, non-SYSDBA user ‘fmw’. See Creating a Non-SYSDBA User to Run the Upgrade Assistant.

    Specify the DBA password in the DBA Password field.

    Specify the user name and password for the schema in the Schema User Name and Schema Password fields respectively.
    If you are using Oracle database:
    1. Enter the details of the 12c Schema for WCSITES Schema page.
    2. Select the Schema user name from the drop-down list.
    3. Enter password and proceed.
    4. Enter the details of the Sites 11.1.1.8.0 schema for "WCSITES_SOURCE Schema" page.
    5. Update Schema user name and password for the Schema having 11.1.1.8.0 tables.
    If you are using SQL Server:
    1. Enter the details of the 12c Schema for "WCSITES Schema" page.
    2. Select the Schema user name in the drop-down list. Only the RCU created WebCenter Sites Schemas will be listed in the drop-down list.
    3. Enter password and proceed.
    4. Enter the details of the Sites 11.1.1.8.0 schema for "WCSITES_SOURCE Schema" page. You need to provide a dba user and the Sites User.
    5. Enter the default prefix being used for the Schemas in Sites 11.1.1.8.0 in the "WCSITES SourceSchema prefix" page. For example, use "dbo" if that is the prefix.
  8. On the Examine screen, review the status of the Upgrade Assistant as it examines each schema, verifying that the schema is ready for upgrade. If the status is Examine finished, click Next.
    If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Oracle Fusion Middleware Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

    Note:

    • If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before you start the Upgrade Assistant again.

    • Canceling the examination process has no effect on the schemas or configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

  9. The Upgrade Summary screen lists the schemas that will be upgraded and/or created.
    Verify that the correct Source and Target Versions are listed for each schema that you intend to upgrade.
    If you want to save these options to a response file to run the Upgrade Assistant again later in response (or silent) mode, click Save Response File and provide the location and the name of the response file. A silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again.
    Click Next.
  10. On the Upgrade Progress screen, monitor the status of the upgrade.

    Caution:

    Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.
    If any schemas are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

    Note:

    The progress bar on this screen displays the progress of the current upgrade procedure. It does not indicate the time remaining for the upgrade.

    Click Next.

  11. If the schema upgrade is successful, a summary file is generated at the following location:
    NEW_ORACLE_HOME/oracle_common/upgrade/logs/wcsites_upgrade/schema/Source Version/Database Type/summary.txt
    Where, Source Version is 11.1.1.8.0 in this case and Database Type is the database which you are using.
    If the schema upgrade fails, you can review the logs for possible errors. The log file is generated at the following location:
    NEW_ORACLE_HOME/oracle_common/upgrade/logs
    Click Close to close the Upgrade Assistant.

Verifying the Schema Upgrade

After completing all the upgrade steps, verify that the upgrade was successful by checking that the schema version in schema_version_registry has been properly updated.

If you are using an Oracle database, connect to the database as a user having Oracle DBA privileges, and run the following from SQL*Plus to get the current version numbers:

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

In the query result:

  • Check that the number in the VERSION column matches the latest version number for that schema. For example, verify that the schema version number is 12.2.1.3.0.

    Note:

    However, that not all schema versions will be updated. Some schemas do not require an upgrade to this release and will retain their pre-upgrade version number.

  • The STATUS field will be either UPGRADING or UPGRADED during the schema patching operation, and will become VALID when the operation is completed.

  • If the status appears as INVALID, the schema update failed. You should examine the logs files to determine the reason for the failure.

  • Synonym objects owned by IAU_APPEND and IAU_VIEWER will appear as INVALID, but that does not indicate a failure.

    They become invalid because the target object changes after the creation of the synonym. The synonyms objects will become valid when they are accessed. You can safely ignore these INVALID objects.

Upgrading Domain Component Configurations

After you upgrade the product schemas, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.3.0). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

Note:

Before you start the Upgrade Assistant, make sure that the JVM character encoding is set to UTF-8 for the platform on which the Upgrade Assistant is running. If the character encoding is not set to UTF-8, then you will not be able to download files containing Unicode characters in their names. This can cause the upgrade to fail.

  1. Go to the oracle_common/upgrade/bin directory:
    • (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin
  2. Start the Upgrade Assistant:
    • (UNIX) ./ua
    • (Windows) ua.bat

For information about other parameters that you can specify on the command line, such as logging parameters, see:

Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 5-10 Upgrade Assistant Command-Line Parameters

Parameter Required or Optional Description

-readiness

Required for readiness checks

Note: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

  • TRACE

  • NOTIFICATION

  • WARNING

  • ERROR

  • INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant creates log files and temporary files.

The default locations are:

(UNIX)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

NEW_ORACLE_HOME\oracle_common\upgrade\logs
NEW_ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command-line options.

Upgrading Sites Configuration Using the Upgrade Assistant

You must upgrade the Sites configuration using the Upgrade Assistant.

Configuration upgrade is supported for Apache Tomcat and IBM WebSphere servers as well for 11g starting point.

Following are the supported databases for the 11g starting point:
  • Oracle

  • Microsoft SQL

  • DB2

Following are the supported application servers for the 11g starting point:
  • Oracle WebLogic Server

  • Apache Tomcat

  • IBM WebSphere

Note:

Readiness Check for the Configuration upgrade is not available for 11g starting point.
To upgrade the 11g domain:
  1. Go to the oracle_common/upgrade/bin directory:
    • (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin
  2. Start the Upgrade Assistant:
    • (UNIX) ./ua
    • (Windows) ua.bat
  3. On the Welcome screen, review an introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

    Note:

    For more information about any Upgrade Assistant screen, click Help on the screen.
  4. On the All Configurations screen, select All Configurations Used by a Domain and specify the 12.2.1.3.0 domain location in the Domain Directory field by entering it directly or by clicking Browse to use a navigation tree to select a valid domain directory. Click Next.
  5. On the Component List screen, verify that the list includes all the components for which you want to upgrade configurations and click Next.
    If you do not see the components you want to upgrade, click Back to go to the previous screen and specify a different domain.
  6. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

    Note:

    The Upgrade Assistant does not verify whether the prerequisites have been met.
  7. On the WebCenter Sites Source Version screen, select 11.1.1.8.0. This is the starting point of your upgrade.

    In addition, specify the path of the 12c config directory, the complete path of the 12c wcs_properties.json file, and the 11.1.1.8.0 shared directory.

    Click Next.

  8. Depending on the source type (whether a single-server environment or a clustered environment), specify the required details:
    1. (Single-server environment) The WebCenter Sites Source Details screen is displayed if your source is a single-server environment.
      On the WebCenter Sites Source Cluster Details screen, specify the complete path of the Source 11.1.1.8.0 Sites install directory and Source 11.1.1.8.0 Sites deployment directory location and click Upgrade.
      Following are examples of the Sites Deployment Directory:
      • (Tomcat) TOMCAT_HOME/webapps/sites

      • (WebSphere) WAS_HOME/installableApps/sites

      • (WebLogic) DOMAIN_HOME/manual/sites

      You can also click Browse to select a particular directory using the navigation tree.
    2. (Clustered environment) The WebCenter Sites Source Details screen is displayed if your source is a clustered environment.

      Note:

      Ensure that you run the Upgrade Assistant on the machine where the Admin Server is deployed.

      Specify the Sites Install and Sites deployment directory for each node in the Source 11.1.1.8.0 Sites install directory and Source 11.1.1.8.0 Sites deployment directory fields, respectively.
      You can also click Browse to select a particular directory using the navigation tree.
      After specifying the 11.1.1.8.0 directories, click Upgrade.

      Note:

      The node names listed in the Upgrade Assistant are the names that you provided while registering the nodes in the Cluster Node Management screen.
  9. On the Examine screen, review the status of the Upgrade Assistant as it examines each component, verifying that the component configuration is ready for upgrade. If the status is Examine finished, click Next.
    If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Oracle Fusion Middleware Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

    Note:

    • If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.

    • Canceling the examination process has no effect on the configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

  10. On the Upgrade Summary screen, review the summary of the options you have selected for component configuration upgrade.
    The response file collects and stores all the information that you have entered, and enables you to perform a silent upgrade at a later time. The silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again. If you want to save these options to a response file, click Save Response File and provide the location and name of the response file.
    Click Upgrade to start the upgrade process.
  11. On the Upgrade Progress screen, monitor the status of the upgrade.

    Caution:

    Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.
    If any components are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

    Note:

    The progress bar on this screen displays the progress of the current upgrade procedure. It does not indicate the time remaining for the upgrade.

    Click Next.

  12. If the configuration upgrade is successful, summary files are generated at the following location:
    NEW_ORACLE_HOME/oracle_common/upgrade/logs/wcsites_upgrade/config<timestamp>/11.1.1.8.0/
    If the source (11.1.1.8.0) is a clustered environment, the summary details are generated for each cluster as follows:
    NEW_ORACLE_HOME/oracle_common/upgrade/logs/wcsites_upgrade/config<timestamp>/11.1.1.8.0/
    If the source (11.1.1.8.0) is a single-server environment, the following three summary files are generated:
    • PropertyMigration_Summary.txt for Property Migration Summary
    • HomeMigration_Summary.txt for Site Home Migration Summary
    • SharedMigration_Summary.txt for Sites Shared Migration Summary
    If the schema upgrade fails, you can review the logs for possible errors. The log file is generated at the following location:
    NEW_ORACLE_HOME/oracle_common/upgrade/logs
    Click Close to close the Upgrade Assistant.

Verifying the Domain-Specific-Component Configurations Upgrade

To verify that the domain-specific-component configurations upgrade was successful, sign in to the Administration console and the Oracle Enterprise Manager Fusion Middleware Control and verify that the version numbers for each component is 12.2.1.3.0.

To sign in to the Administration Console, go to: http://administration_server_host:administration_server_port/console

To sign in to Oracle Enterprise Manager Fusion Middleware Control Console, go to: http://administration_server_host:administration_server_port/em

Note:

After upgrade, make sure you run the administration tools from the new 12c Oracle home directory and not from the previous Oracle home directory.

During the upgrade process, some OWSM documents, including policy sets and predefined documents such as policies and assertion templates, may need to be upgraded. If a policy set or a predefined document is upgraded, its version number is incremented by 1.

Post-Upgrade Validation Tasks

Oracle has provided validation scripts that you can run on your newly upgraded domain to ensure data integrity after a successful schema and configuration upgrade. You can review the validation summary report for any inconsistencies in data that may have occurred during the schema and configuration upgrade processes.

To run the validation script:
  1. The validation script is available at the following location:
    (UNIX) NEW_Oracle_Home/wcsites/plugins/upgrade/
    (UNIX) ./validation.sh
    (Windows) NEW_Oracle_Home\wcsites\plugins\upgrade\
    (Windows) validation.bat
  2. When the validation check is complete, validation summary report: Validation.txt is generated. Save it at any location on your system.
  3. Review the validation summary report to check if there is any inconsistency in the data between your existing domain and the newly configured 12.2.1.3.0 domain.

    Note:

     If your source (11.1.1.8) environment is using Patch 12 or above, comparison report for web.xml displays differences that are available on the target (12.2.1.3.0) environment. You can ignore any changes mentioned in summary report that are available on the target (12.2.1.3.0) environment.

Post-Upgrade Tasks

The post-upgrade tasks include restoring any custom settings, starting Administration Server and Managed Servers, reconfiguring passwords, and other administrative tasks listed in this topic.

After upgrading to WebCenter Sites 12.2.1.3.0:
  1. Restore or re-deploy the custom settings from your existing environment to your 12.2.1.3.0 environment.
    These include custom changes made to Java libraries, static web resources, or element changes.
    To restore changes made to the Java libraries or static web pages, see Migrating Custom Java Libraries or Static Web Resources.

    Note:

    • WebCenter Sites 12c uses ODL logging framework and any custom Log4j log levels set on 11g environment are not migrated to ODL logging. You can reset these levels after the upgrade.

    • Any customizations (example : WURFL services) done on 11g MobilityService.xml has to be ported manually to 12.2.1.3.0 xml.

  2. Start Administration Server and Managed Servers. See Starting Servers and Processes.

    Note:

    Before you start the Administration Server and Managed Servers, clear the cached images and files in the browser.

  3. Reconfigure passwords for the publishing process.
    1. Sign in to the Administration Server URL as the Administrator.
    2. Go to Admin menu and click Destinations under Publishing.
    3. Update the publishing destination URL, Port, Username, and Password.
  4. If external WebRoots are configured, update WebRoots from Sites Admin user interface.
  5. If your source was a clustered environment, copy the config directory xml file settings from your source environment on which you run the Upgrade Assistant, to all other nodes on your upgraded environment.
    These include the following:
    • cs-cahe.xml
    • cas-cache.xml
    • ss-cache.xml
    • linked-cache.xml
    • MobilityServices.xml
    • Custom/RestResources.xml
    • wcs_properties_bootstrap.ini

      Note:

      Lucene search indexes are re-enabled during the upgrade process. Search results in Contributor UI will likely be delayed until the indexes are completely rebuilt post upgrade process.
  6. (Applicable only if you are using SQL server) Fusion Middleware Infrastructure Release 12c requires the SQL Server database to be configured in a case sensitive mode. As a result, ics:sql jsp tag provided by WebCenter Sites require the table value to be in the same case as stated in the database.
    Following is the syntax of the ics:sql statement:
    <ics:sql
          sql="sql commands"
          listname="list name"
          table="name of table"
          [limit="max number of results"]/>

    You must provide the name of the table in the same case as specified in the SQL Server database.

  7. The following properties are reset to the application Admin user account values provided during Sites Configuration Setup process:
    • xcelerate.batchuser and password
    • cs.emailpassword
    You must update these properties with their appropriate values using the Property Management Tool.
  8. After WCC integration, reset the wcc.server.password in WCC Configuration to view all the mapped rules.
  9. If the instance is delivery and has any of the Sample Sites published, then you must republish the Sample Sites to the delivery instance from upgraded development instance.
  10. (If you are upgrading from a previous 12c release only and if Sites is installed with RSS and Site Capture on same domain)
    1. If you are upgrading Sites with RSS and Site Capture to 12c (12.2.1.3.0) from 12.2.1.0 or a later release, you must create a new domain and install RSS and Site Capture again.
    2. If you are not installing Site Capture on the same port, perform the following:
      1. Change the Site Capture port in the FW_View and FW_Application tables for Site Capture in Sites

      2. Change the port number in the valid.urls property

      3. Change the port number in other properties under the SiteCapture category

    3. After installing RSS, change the RSS port in the SystemSatellite table, unless RSS is installed on same port.

Starting Servers and Processes

After a successful upgrade, restart all processes and servers, including the Administration Server and any Managed Servers.

The components may be dependent on each other so they must be started in the correct order.

Note:

The procedures in this section describe how to start servers and process using the WLST command line or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.

To start your Fusion Middleware environment, follow the steps below:

Step 1: Start the Administration Server

When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.

To start the Administration Server, use the startWebLogic script:

  • (UNIX) NEW_DOMAIN_HOME/bin/startWebLogic.sh

  • (Windows) NEW_DOMAIN_HOME\bin\startWebLogic.cmd

When prompted, enter your user name, password, and the URL of the Administration Server.

Step 2: Start Node Manager

To start Node Manager, use the startNodeManager script:

  • (UNIX) NEW_DOMAIN_HOME/bin/startNodeManager.sh

  • (Windows) NEW_DOMAIN_HOME\bin\startNodeManager.cmd

Step 3: Start Oracle Identity Management Components

Start any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:
  • (UNIX) NEW_DOMAIN_HOME/bin/startComponent.sh component_name

  • (Windows) NEW_DOMAIN_HOME\bin\startComponent.cmd component_name

Step 4: Start the Managed Servers

To start a WebLogic Server Managed Server, use the startManagedWebLogic script:

  • (UNIX) NEW_DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

  • (Windows) NEW_DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

When prompted, enter your user name and password.

Note:

The startup of a Managed Server will typically start the applications that are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.

Step 5: Start System Components

To start system components, such as Oracle HTTP Server, use the startComponent script:

  • (UNIX) NEW_DOMAIN_HOME/bin/startComponent.sh component_name

  • (Windows) NEW_DOMAIN_HOME\bin\startComponent.cmd component_name

You can start system components in any order.

If the Existing Instance is a Delivery Instance...

If you are upgrading from 11g to the latest 12c release, and if your existing instance is a delivery instance, then you must manually reassign Apps for the User Published Sites.

To reassign Apps for User Published Sites:
  1. Sign in to the AdminSite as an Administrator.
  2. To add Admin App to User Published Sites:
    1. Go to WEM Admin under AdminSite.
    2. Click Apps. Then click Manage App under Admin App.
    3. Click Assign to Sites. Click Select Sites and then click Continue.
    4. Select Advanced User role and save the change.
  3. To add Contributor App to User Published Sites:
    1. Go to WEM Admin under AdminSite.
    2. Click Apps. Then click Manage App under Admin App.
    3. Click Assign to Sites. Click Select Sites and then click Continue.
    4. Select Sites User role and save the change.
  4. To add Other Apps, follow the similar path and assign required roles.

Migrating Custom Java Libraries or Static Web Resources

Perform this optional step only if custom Java libraries or static web resources were added to the web application in your pre-upgrade environment and you want to continue to use them in the upgraded environment.

If the web application includes custom Java libraries (jar files) or custom static web resources, such as css, js, or images, then you will have to manually migrate them to the upgraded environment after the upgrade. If you do not migrate these resources, you will not be able to access the functionality in the upgraded environment.

The WebCenter Sites web application is shipped as a WAR file. The web application is deployed during Config Wizard process initially and can be redeployed multiple times during the application lifecycle. Oracle recommends that you do not include any implementation-specific customizations to the Sites WAR file as the changes will be overwritten during the upgrade process.

When extending the WebLogic Server Shared Libraries framework, Sites provides extend.sites.webapp-lib.war as a shared library. This file is located in NEW_ORACLE_HOME/wcsites/webcentersites/sites-home/ directory. Any implementation-specific customizations, such as static web resources or JAVA libraries, can be included in this WAR file. This shared library gets deployed during application lifecycle and shares the same context root as sites (/sites/). The contents of this shared library will not be overwritten during patching process.

Additionally, if the Sites UI has been customized, the code changes must also be migrated to the upgraded environment.