This chapter contains instructions for creating and upgrading a test environment, verifying the test environment, and then upgrading the active environment.
This chapter contains the following sections:
Before starting the upgrade procedure, ensure the following:
You have read Chapter 1, "About the WebCenter Sites Upgrade Process."
You have completed the pre-upgrade steps in Chapter 2, "Before You Upgrade to the Current Version of WebCenter Sites" as necessary for your environment.
You have verified that permissions to the Content Server or WebCenter Sites database are reset to the default values recommended in Oracle Fusion Middleware WebCenter Sites: Installing and Configuring Supporting Software. This is because the installer may require permissions that the running system does not. After the upgrade is completed, these permissions can be modified to include any customizations.
In a clustered environment, you will first upgrade the primary cluster member and then all the secondary cluster members. All members need to be upgraded before you verify the installation.
Also note: We strongly recommend that you first upgrade the test environment, because of the changes made to the interfaces in WebCenter Sites 11gR1 (11.1.1.8.0). If you attempt to upgrade only the active environment, you can expect extended downtime.
In this section, you will back up your active environment as a precaution. If you choose to create a test environment, you will do so by recovering the backup.
To back up your active environment
Back up all systems in the active environment. This includes all Content Server or WebCenter Sites instances, and all remote Satellite Servers.
Review the chapter "Backup and Recovery" in the Oracle Fusion Middleware WebCenter Sites Installation Guide for guidelines and specific instructions. Review backup and recovery instructions for your starting installation. Instructions are available in the following guides:
FatWire Content Server 7.6 Patch 2 Backup and Recovery Guide
Oracle WebCenter Sites 11gR1 (11.1.1.6.1) Backup and Recovery Guide
Synchronize all systems in the active environment by publishing the content of one system to another, as necessary (for example, from development to management to the delivery system).
Disable all publishing schedules and ensure that no publishing sessions are running. You will re-enable the publishing schedules once the active environment has been upgraded and verified.
Take note of customized elements:
For each basic asset type, take note of any custom code in the elements (in the ElementCatalog table).
If you are upgrading from Content Server 7.6 Patch 2, and you have customized any portion of the Content Server Advanced administrative interface, take note of the custom code, as existing customizations will not function after upgrade until they are modified.
If developers programmatically customized the Contributor interface for WebCenter Sites 11gR1 (11.1.1.6.1), the customizations are preserved during upgrade, but only if they were placed in the CustomElement path. Otherwise, they will be overwritten during the upgrade process. Developers will then have to re-create the customizations from the backed up installation.
Ensure that all events (including search events) are disabled. You can do this through Sites Explorer or CatalogManager. For information, see the Oracle Fusion Middleware WebCenter Sites Administrator's Guide.
Disable revision tracking for the following asset types:
ASSOCNAMED table
CSElement
Template
Page
Note:
If you are upgrading from Content Server 7.6 Patch 2:
Disable revision tracking for all asset types.
The Page asset type is upgraded to behave partially like a flex asset type. Therefore, after the upgrade, the Page asset type will also have a PageAttribute, PageDefinition, and PageFilter.
Take note of all the information about your existing installation, such as web server configuration, application server configuration, database configuration, and LDAP configuration. While these will not be changed during the upgrade, you might need to reference existing settings if changes are needed elsewhere (for instance tuning the new cache).
Note:
If you are upgrading from Content Server 7.6 Patch 2 or WebCenter Sites 11gR1 (11.1.1.6.x ), complete a trial upgrade on a test environment before upgrading the active environment. If a test environment is not available, then start by upgrading the development system first and expect extended downtime. We strongly recommend using a test environment, given the extent of changes made in WebCenter Sites.
When you are ready to create the test environment, recover the backup that you created in the previous step. For recovery guidelines, refer to the chapter "Backup and Recovery" in the guide that you used in step 1 of Section 3.2, "Backing Up Your Active Environment":
FatWire Content Server 7.6 Patch 2 Backup and Recovery Guide
Oracle WebCenter Sites 11gR1 (11.1.1.6.1) Backup and Recovery Guide
If your active environment is running remote Satellite Servers, duplicate at least one of them in the test environment.
Continue with the guidelines below to complete the test environment:
On Content Server or WebCenter Sites:
Copy Content Server or WebCenter Sites into the same location that it occupied on its previous host.
Clear out the SystemSatellite table entries except for the local system and a single remote Satellite Server on which you are going to test this upgrade.
Change the host name and IP address in the following files (Table 3-1) located in your ContentServer.ear and cs.war files:
Table 3-1 Files Located in ContentServer.ear and CS.war
| Change Host Name and IP Address | File | Directory |
|---|---|---|
|
Required |
|
|
|
Optional |
|
|
|
Optional |
|
|
Change the host name and IP address in the following property files (Table 3-2) located in the <cs_install_dir> directory:
If the WEM Framework was installed, then also edit the following files (Table 3-3):
Table 3-3 Files to be Edited if WEM Framework was Previously Installed
| Change Host Name and IP Address | File | Notes |
|---|---|---|
|
Required |
|
Search and replace values as required. |
On an application server:
Install the application server using the same paths that were used on the previous host.
Create a new DataSource, and update the relevant database properties in the futuretense.ini file with information about the new DataSource. Use database information for the restored database. (Database properties are listed on the Database tab of the Property Editor.)
Deploy the Content Server or WebCenter Sites application as required by your application server.
In this section you will use the Oracle WebCenter Sites Certification Matrix and current release notes to first upgrade the supporting software for your existing environment, which is either Content Server 7.6 Patch 2 or WebCenter Sites 11gR1 (11.1.1.6.x ).
Note:
For clustered environments. Stop all cluster members. Prepare only the primary member for upgrade. When you finish upgrading the primary member, you will also upgrade WebCenter Sites on the secondary members.
Upgrade supporting components for your existing environment to the versions that are listed in the Oracle WebCenter Sites Certification Matrix. Supporting components include:
The operating system
Application server
Java SDK
The Content Server or WebCenter Sites database
(Conditional). LDAP server and web server. If you are using LDAP and you decided to upgrade (or change) the LDAP server, manually migrate all of your LDAP data from the old server to the new one. Before continuing verify that the LDAP data has been migrated successfully.
Note:
For instructions on upgrading supporting components, see the respective vendor's documentation.
Verify that your installation is fully functional.
If existing instances are running with Oracle database, ensure that the following system privileges are assigned to the Oracle database user. These privileges are identical to the privileges that WebCenter Sites requires to operate:
GRANT UNLIMITED TABLESPACE TO <USER>;
GRANT CREATE SESSION TO <USER>;
GRANT CREATE TABLE TO <USER>;
GRANT CREATE VIEW TO <USER>;
Maintaining customizations throughout the upgrade.
Note:
In this step you will back up deployment customizations (if any), as the js/src folder in your deployment directory will be removed during the upgrade.
If you have deployed custom JARs or made configuration changes that are not reflected in the current copies of the cs.war and ContentServer.ear files (located in <cs_install_dir>/ominstallinfo/app), create clean cs.war and ContentServer.ear files from your currently deployed Content Server application as follows:
Back up cs.war and ContentServer.ear from ominstall/app.
If WEM Framework is installed, back up cas.war and cas.ear from the ominstall/ directory.
Locate the deployed and exploded cs.war file, compress this file (use the same version of JAR that will be used by the WebCenter Sites installer), and place it in the ominstall/app directory.
Explode the backed up ContentServer.ear file into its own directory.
Copy the new cs.war over the existing one in the exploded ContentServer.ear file and compress this file (use the same version of JAR as the one which will be used by the WebCenter Sites installer).
Place the newly compressed ContentServer.ear into the ominstall/app directory.
Note:
The WebCenter Sites installer is configured to detect the Content Server or WebCenter Sites application to be in the <cs_install_dir>/ominstallinfo/app directory. Neither cs.war nor ContentServer.ear files must be renamed or moved. If the installer cannot find the Content Server or WebCenter Sites application, the upgrade process will fail.
Back up all .ini files located in the <cs_install_dir> directory.
Using the Property Editor, note the values of the following properties in the futuretense.ini file:
secure.CatalogManager (Basic tab)
ft.sync (Cluster tab)
The installer will change their values during the upgrade process. You will need to restore them.
If you upgraded from Content Server 7.6 Patch 2 and your system is integrated with read-only LDAP, add and remove roles as follows:
Add the following roles (new in WebCenter Sites) for each intended user:
AdvancedUser: Allows users to log in to the WebCenter Sites Admin interface (formerly known as the Content Server Advanced administrative interface).
SitesUser: Allows users to log in to the WebCenter Sites Contributor interface. In LDAP, you will have to manually create the SitesUser role and assign it to all users who were assigned the DashUser role earlier.
MobileSitesDeveloper: Allows users to access Mobility components introduced in WebCenter Sites 11gR1 (11.1.1.8.0).
ConnectorAdmin: Allows access to the WCC Integration feature in the WebCenter Sites Admin interface.
Remove the DashUser role. This role allows users to log in to the Content Server Dash interface. As this interface has been removed, this role should also be removed from LDAP.
Note:
The DashUser role has been replaced with the SitesUser role for the following items:
Start menu
Tree tab
Workflow steps, process, assignment and functional privileges.
Saved searches
Publishing destination
Access permissions
If you are currently using inCache, the cache files located in the java temp directory should be removed manually. Possible directory names to remove are: cascache, cscache, linkedcache, and sscache.
In this step, you will ensure that the time zones of all database tables match the JVM time zone, as required in the upgrade process.
Note:
We recommend setting the JVM time zone to UTC (GMT) especially to standardize the time stamps of distributed data. For example, if content is published from Los Angeles to New York and both servers run on local time, the content publication times differ by three hours. Setting both servers to UTC (GMT) alleviates the ambiguity. Note also that log files will report data in UTC (GMT) time. The steps below use the UTC (GMT) setting. It is critical that all servers use the same time zone across the cluster. Complete the entire procedure.
When upgrading remote Satellite Server, you will set its JVM to use the WebCenter Sites JVM time zone.
If you need to change the WebCenter Sites JVM time zone, do the following (either now or at any time before starting the application server in the upgrade process):
-Duser.timezone=<TIMEZONE_ID>
where <TIMEZONE_ID> is recommended to be UTC.
Ensure that the time zone of revision tracking tables matches the time zone of the JVM. In case of mismatch, do the following:
Go to the misc directory of the extracted installer, extract the time zone utility (sites-timezone-util.zip), and open one of the following scripts in a text editor:
Windows: tzutil.bat
UNIX or Linux: ./tzutil.sh
Set the new time zone for revision tracking tables by specifying the database connection and <DATABASEJAR> file and setting the following variables in the java command:
... -r -d <DB_VENDOR> -o <TIMEZONE_ID> -n <TIMEZONE_ID> -p
Note:
The java command variables are defined in the script.
If the default time zone for revision tracking tables has never been changed, the value for -o <TIMEZONE_ID> is UTC.
Ensure the classpath and the required database drivers are placed properly in the script.
Run the script with the -p parameter and review the tzutil.log file for expected changes to the database.
Run the script without the -p parameter to update the database tables with the new time zone.
Ensure that the time zone of all database tables (other than revision tracking tables) matches the time zone of the JVM. In case of mismatch, edit your script as follows:
Set the new time zone by removing the -r parameter from the java command and setting the following variables:
... -d <DB VENDOR> -o <TIMEZONE_ID> -n <TIMEZONE_ID> -p
Run the script with the -p parameter and review the tzutil.log file for expected changes to the database.
Run the script without the -p parameter to update the database tables with the new time zone.
In this step, you will run the WebCenter Sites upgrade utility to log the pre-upgrade status of the database schema.You will run this utility again, after the upgrade to determine which changes were made to the database schema (and indexes) by the installer. For more information about the upgrade utility, refer to the ReadMe file located in misc\upgrade-util.zip.
To run the upgrade utility:
Go to the misc directory of the extracted installer, extract the upgrade utility, and open one of the following scripts:
Windows: cssystem.bat
UNIX or Linux: ./cssystem.sh
Edit the selected script by entering the following information about your system:
Specify WebCenter Sites database settings: driver, URL, user name and password.
Specify the DATABASEJAR file relevant to your database type.
Specify the path of the output file.
Specify the expected WebCenter Sites deployment path, using the -i parameter.
Run the selected script.
Running the script generates the Systeminfo.log file (in the \misc\ directory), which contains the expected WebCenter Sites database schema updates.
Note:
For more information about the usage of the upgrade utility, refer to the ReadMe.txt file in the \misc\upgrade-util.zip directory.
Undeploy the old WebCenter Sites and Content Server applications from the application server. For undeployment instructions, refer to the installation guide for your platform and WebCenter Sites version. If you are upgrading from Content Server 7.6 Patch 2 with WEM installed, or from WebCenter Sites 11gR1 (11.1.1.6.x ), then undeploy and delete CAS from the application server.
In this section, you will run the WebCenter Sites upgrade installer in the preferred mode (GUI or silent mode) on each instance of Content Server 7.6 Patch 2 or WebCenter Sites 11gR1 (11.1.1.6.x ).
Note:
Consider the following:
If you made major changes in Section 3.4, "Preparing Your Environment for Upgrade," back up your environment. Otherwise, if the upgrade fails, you will need to restart the upgrade procedure from Section 3.2, "Backing Up Your Active Environment."
For Content Server 7.6 Patch 2:
– If log4j was enabled, then the upgrade will continue to use log4j. If commons-logging.properties was used instead, you will have the opportunity to change it to log4j during the upgrade process.
– If the traditional page caching framework was enabled, its cache will be flushed and replaced with the inCache framework.
To upgrade a Content Server instance to WebCenter Sites, do one of the following:
Extract the WebCenter Sites installer archive into a temporary directory and run the installer script:
Windows: csinstall.bat
UNIX or Linux: ./csInstall.sh
Note:
Monitor the installer log (install_log.log), the WebCenter Sites application log, and application server logs during the upgrade process and during post-upgrade testing. If an error occurs, you can trace its source by reviewing the logs.
If your upgrade path begins from WebCenter Sites 11gR1 (11.1.1.6.x ), the logs will be located at <cs_install_dir>/logs/sites.log, by default.
As you proceed through the upgrade, bear in mind the following:
Most fields in the installer will be pre-populated with values that the installer detected from your original installation. Check the pre-populated values. If they are outdated, you will need to supply the current values. (Information such as passwords, you will have to enter manually.)
Fields whose values you are not permitted to change will be disabled (grayed out).
The installer provides online help at each screen, with detailed explanations of options available in the screen. If you experience problems during the upgrade process, consult the online help for possible causes and solutions.
Proceed to the installation guide for your platform and follow the instructions provided for installing WebCenter Sites. Once the installation is completed, return to this guide and continue.
Note:
At this point, it is assumed that the upgrade process has completed and you have a valid WebCenter Sites installation running. If the upgrade failed, review the previous steps and the logs and resolve any issues. Do not exit the installer, as that will require restoring the previous step and starting the process again.
Restart the WebCenter Sites and CAS applications.
Continue to Section 3.5.3, "Re-Running the Upgrade Utility."
In this section you will complete the following steps:
Copy the omii.ini file from <cs_install_dir>/ominstallinfo to a folder outside <cs_install_dir> and rename the copy as desired. The silent installer will use this copy during the upgrade.
If the default user name and/or password for the ContentServer user or SatelliteServer user was changed after FatWire Content Server 7.5, open the renamed omii.ini file and update the properties listed in Table 3-4. The silent installer authenticates by referring to the credentials specified in the properties. If the credentials are outdated, the installer fails.
Table 3-4 Properties in the Renamed omii.ini File
| Property | Description |
|---|---|
|
|
Provide the current user name for the The default value is |
|
|
Provide the encrypted password for the To get the encrypted password, use the Content Server (or WebCenter Sites) Property Editor:
|
|
|
Provide the encrypted password for the |
This step determines your logging system. Do one of the following:
If you want to migrate from your existing logging system to Apache log4j (recommended), add the ConvertToLog4J property to the renamed omii.ini file and set the property to true.
If log4j was already configured manually, or if you want to keep your existing logging system, do not add the ConvertToLog4J property to the omii.ini file.
To enable installation of WCC Integration on WebCenter Sites, add the WCCIntegration=true property to the omii.ini file.
This step applies to the WEM Framework (and FatWire Content Server Developer Tools, which require the WEM Framework). Do one of the following:
If you are upgrading from Content Server 7.6 Patch 2, add the properties in Table 3-5 to the renamed omii.ini file. The information you provide depends on whether you are installing or upgrading WEM Framework on a primary or secondary Content Server cluster member and whether you are clustering CAS.
For upgrades from WebCenter Sites 11gR1 (11.1.1.6.x ), ensure that the values in omii.ini for the properties in Table 3-5 are set correctly.
| Property | Description |
|---|---|
|
WEM |
Set this property to Note: Following this table is a set of examples showing you how to set the properties listed in this table. The examples are: - Section 3.5.2.1.1, "Sample Configurations for Installing WEM Framework" - Section 3.5.2.1.2, "Sample Configurations for Upgrading WEM Framework" |
|
IsPrimaryClusterMember |
If you are upgrading or installing WEM Framework on the primary Content Server cluster member, set this property to If you are upgrading or installing WEM Framework on a secondary cluster member, set this property to If you are working with a WebCenter Sites cluster member, the property is automatically set to the correct value. |
|
CASHostNameLocal |
Clustered CAS: Host name of the server running the internally accessible CAS load balancer. Non-clustered CAS: Internal host name of the server on which CAS will be deployed. |
|
CASPortNumberLocal |
Clustered CAS: Port number of the server running the internally accessible CAS load balancer. Non-clustered CAS: Internal port number of the server on which CAS will be deployed. |
|
CASHostName |
Clustered CAS: Host name of the server running the CAS load balancer. Non-clustered CAS: Host name of the server on which CAS will be deployed. |
|
CASPortNumber |
Clustered CAS: Port number of the server running the CAS load balancer. Non-clustered CAS: Port number of the server on which CAS will be deployed. |
|
CASHostNameActual |
Clustered/Non-Clustered CAS: Host name of the server on which CAS is actually deployed. |
Note:
When upgrading the primary cluster member, note the following:
If automatic deployment is in effect, the installer will deploy WebCenter Sites and CAS on the same server. Once the installation process is complete, you can manually redeploy CAS on a different server, as described in "Deploying the WebCenter Sites and CAS Web Applications" in the Oracle Fusion Middleware WebCenter Sites Installation Guide.
If manual deployment is in effect, you will deploy WebCenter Sites. You will also deploy CAS either on the same server, or on a separate server. Once the installation process is complete, and you decide to redeploy CAS on a different server, you can do so manually as described in "Deploying the WebCenter Sites and CAS Web Applications" in the Oracle Fusion Middleware WebCenter Sites Installation Guide.
If you are installing WEM Framework on the primary WebCenter Sites cluster member, use the sample configurations below as a reference. To continue the installation process, skip to step 5.
If CAS is clustered:
WEM=true IsPrimaryClusterMember=true CASHostName=<host name of server with load balancer> CASPortNumber=<port number of server with load balancer> CASHostNameLocal=<host name of the internally accessible server with load balancer> CASPortNumberLocal=<port number of the internally accessible server with load balancer> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
If CAS is not clustered:
WEM=true IsPrimaryClusterMember=true CASHostName=<host name of server on which CAS will be deployed> CASPortNumber=<port number of server on which CAS will be deployed> CASHostNameLocal=<internal host name of the server on which CAS will be deployed> CASPortNumberLocal=<internal port number of the server on which CAS will be deployed> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
If you are installing WEM Framework on a secondary WebCenter Sites cluster member, use the sample configurations below as a reference. To continue the installation process, skip to step 5.
If CAS is clustered:
WEM=true IsPrimaryClusterMember=false CASHostName=<host name of server on which CAS has been deployed> CASPortNumber=<port number of server on which CAS has been deployed> CASHostNameLocal=<internal host name of the server on which CAS will be deployed> CASPortNumberLocal=<internal port number of the server on which CAS will be deployed> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
If CAS is not clustered:
WEM=true IsPrimaryClusterMember=false CASHostName=<host name of server on which CAS has been deployed> CASPortNumber=<port number of server on which CAS has been deployed> CASHostNameLocal=<internal host name of the server on which CAS will be deployed> CASPortNumberLocal=<internal port number of the server on which CAS will be deployed> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
If you are upgrading WEM Framework on the primary WebCenter Sites cluster member, use the sample configurations below as a reference. To continue the installation process, skip to step 5.
If CAS is clustered:
WEM=true IsPrimaryClusterMember=true CASHostName=<host name of server with load balancer> CASPortNumber=<port number of server with load balancer> CASHostNameLocal=<host name of the internally accessible server with load balancer> CASPortNumberLocal=<port number of the internally accessible server with load balancer> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
If CAS is not clustered:
WEM=true IsPrimaryClusterMember=true CASHostName=<host name of server on which CAS will be deployed> CASPortNumber-<port number of server on which CAS with be deployed> CASHostNameLocal=<internal host name of the server on which CAS will be deployed> CASPortNumberLocal=<internal port number of the server on which CAS will be deployed> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
If you are upgrading WEM Framework on a secondary WebCenter Sites cluster member, use the sample configurations below as a reference.
If CAS is clustered:
WEM=true IsPrimaryClusterMember=false CASHostName=<host name of server with load balancer> CASPortNumber=<port number of server with load balancer> CASHostNameLocal=<host name of the internally accessible server with load balancer> CASPortNumberLocal=<port number of the internally accessible server with load balancer> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
If CAS is not clustered:
WEM=true IsPrimaryClusterMember=false CASHostName=<host name of server on which CAS has been deployed> CASPortNumber=<port number of server on which CAS has been deployed> CASHostNameLocal=<internal host name of the server on which CAS will be deployed> CASPortNumberLocal=<internal port number of the server on which CAS will be deployed> CASHostNameActual=<hostname of the server on which CAS is actually deployed>
Decompress the WebCenter Sites 11gR1 (11.1.1.8.0) installer file. The upgrade process will be automatically detected and invoked when you run the installer script.
Edit the install.ini file in the root of the extracted folder as follows:
Set the nodisplay property to true.
Set the loadfile property to <path and name of renamed omii.ini from step 1>.
Note:
Verify that you have correctly specified the file system path. For example, for Windows, the options are:
CSInstallDirectory=C\:/csinstall
- or-
c\:\\install
Run the silent installer:
Windows: csInstall.bat -silent
UNIX or Linux: csInstall.sh -silent
Proceed to the installation guide for your platform and follow the instructions provided for installing WebCenter Sites. Once the installation is completed, return to this guide and continue.
Note:
At this point, it is assumed that the upgrade process has completed and you have a valid WebCenter Sites installation running.
If the upgrade fails, review the previous steps and the logs and resolve any issues. Do not exit the installer, as that will require restoring the previous step and starting the process again.
Restart WebCenter Sites and CAS applications.
Continue to Section 3.5.3, "Re-Running the Upgrade Utility."
In this section, you will re-run the upgrade utility to ensure the database schema has been correctly deployed.
Re-run one of the following scripts, (which you configured and executed in step 8, when you prepared your instances for upgrade):
Windows: cssystem.bat
UNIX or Linux: cssystem.sh
Re-running the upgrade utility generates an updated systeminfo.log file. Compare this file to the systeminfo.log file that was generated in step 8 to ensure that the expected database schema changes were made.
Using the Property Editor, do the following:
Open the futuretense.ini file (in <cs_install_dir>) and reset the secure.CatalogManager, secure.CatalogManager, and ft.sync properties to their original values.
If customized property values in your Content Server installation were replaced with default values during the upgrade process, restore the custom values now.
Depending on the version of your starting installation, the following properties are added during upgrade:
If you upgraded from WebCenter Sites 11gR1 (11.1.1.6.0), a new property named timezoneattr is added to the futuretense_xcel.ini file. If you wish to change the value of this property, see the Oracle Fusion Middleware WebCenter Sites Property Files Reference.
If you upgraded from Content Server 7.6 Patch 2, new properties are added. They are listed in Table 3-6. If you need to change the values of these properties, see the Oracle Fusion Middleware WebCenter Sites Property Files Reference.
Table 3-6 New Properties Added During Upgrade from Fatwire Content Server
| Property | Property File |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If you upgraded from FatWire Content Server 7.6 Patch 2:
If you customized any portion of the FatWire Content Server Advanced administrative interface, re-apply the custom code.
After upgrade, attribute forms will display additional fields that are not seen on a fresh installation. To make the attribute forms consistent with those of a fresh installation, edit the gator.ini file by setting the mwb.externalattributes property to false (the gator.ini file is located in the <cs_install_folder>).
Optional. If upgrading to log4j, add any custom loggers previously found in the commons_logging.properties file to the log4j.properties file. Update the log4j.properties file as follows:
Add any custom loggers previously found in the commons_logging.properties file.
Add the following properties to your log4j.properties file:
log4j.logger.com.fatwire.logging.cs.file=INFO log4j.logger.com.fatwire.logging.cs.framework=INFO log4j.logger.com.fatwire.logging.cs.realtime=INFO log4j.logger.com.fatwire.logging.cs.sseed=INFO log4j.logger.com.fatwire.services=INFO log4j.logger.com.fatwire.services.dao=INFO log4j.logger.com.fatwire.services.time=INFO
Restart the application server.
Ensure that you can log in to WebCenter Sites as the general administrator.
The search engine is restarted automatically after the upgrade. However, to use the search engine, you must re-create the search indices. For information about forcing re-indexing using Lucene, see the Oracle Fusion Middleware WebCenter Sites Administrator's Guide.
If you plan to use multilingual assets and locale filtering on any site, create a default locale and assign it to all the assets on the site. For instructions, see the Oracle Fusion Middleware WebCenter Sites Developer's Guide.
For each basic asset type, re-register asset elements:
Log in to the content management site for which basic assets are enabled.
In the left-hand navigation tree, select the Admin tab.
Expand the Asset Types node.
Double-click Basic asset type.
In the right-hand pane, click Register Asset Elements.
On the confirmation screen, click Register Asset Elements.
For each basic asset type, re-apply the customizations to each element in the ElementCatalog table.
Enable Revision tracking for the following asset types if it was previously disabled:
ASSOCNAMED table
CSElement
Template
Page
Note:
If you are upgrading from Content Server 7.6 Patch 2:
Enable revision tracking for all asset types.
The Page asset type is upgraded to behave partially like a flex asset type. Therefore, after the upgrade, the Page asset type will also have PageAttribute, PageDefinition, and PageFilter.
Assign the WEM Admin application to AdminSite.
Site plans must now be published in order for placed pages to be viewed on the delivery system. To enable publishing of site plan assets to the delivery system, initialize the RealTime destination. Initialization creates the SitePlan asset type on delivery.
Assemble any notes that you might have taken while completing the previous steps. You can use the notes when upgrading the active environment.
Note:
Repeat the following steps for each remote Satellite Server you have deployed.
Back up your remote Satellite Server, making sure to keep track of any customizations made, as they will all be lost.
Undeploy and delete the home directory of SatelliteServer.
Install remote Satellite Server (see the Oracle Fusion Middleware WebCenter Sites Installation Guide).
Set Satellite Server's JVM time zone to match the WebCenter Sites JVM time zone.
Note:
Because caching has changed as of WebCenter Sites 11gR1 (11.1.1.6.0), adjustments to JVM Heap will be required.
In addition to the steps you will complete, this section contains steps that need to be completed by administrators, developers, or content contributors, depending on the step. Once the steps are successfully completed, the systems are ready for normal operation.
This section contains the following topics:
Section 3.7.2, "If Asset Type and Global Searches Were Configured"
Section 3.7.4, "If You Upgraded from FatWire Content Server"
Section 3.7.5, "If Your Developers Were Using Oracle WebCenter Sites: Developer Tools"
Section 3.7.6, "If Developers Enable Mobility Device Groups for Pre-existing Sites"
Section 3.7.7, "If You Upgraded from a Customized WebCenter Sites 11gR1 (11.1.1.6.1) System"
Section 3.7.8, "If Your Installation Was Running with Community, Gadgets, or Site Capture"
Section 3.7.9, "If You Need to Integrate WebCenter Sites with Oracle Access Manager"
If you changed the JVM time zone, ensure that scheduled events and code are synchronized to the JVM time zone. Complete the following steps:
Update the time pattern for scheduled events to match the current JVM time zone:
For example, if a server was operating on Pacific Standard Time with publishing scheduled to run at 3:00 PM, then after upgrade to UTC (GMT), the publishing schedule must be updated to 11:00 PM (GMT) to ensure that it will continue to run at 3:00 PM PST.
Update the publishing schedule with a time pattern in the context of the current JVM time zone. For instructions, see "Schedule Publish Events" in the Oracle Fusion Middleware WebCenter Sites Administrator's Guide.
Update the schedule of workflow events with a time pattern in the context of the current JVM time zone. For instructions, see "Setting Up the Timed Action Event" in the Oracle Fusion Middleware WebCenter Sites Administrator's Guide.
Ask developers to review any customized code and template code to ensure desired behavior is preserved. If any template code uses the default date formatter to render a date, developers may need to add a time zone parameter to the date formatter to preserve behavior. The following table shows how dates are rendered on the web site.
| Date Formatter | Before Upgrade, JVM Time Zone is PST | After Upgrade, JVM Time Zone is GMT |
|---|---|---|
|
Default date formatter |
3:00 PM PST |
11:00 PM GMT |
|
Date formatter with time zone set to PST |
3:00 PM PST |
3:00 PM |
Date formatter tags from the WebCenter Sites XML and JSP tags, Java API, and JSP JSTL all support the time zone parameter. For information about updating time zone aware templates, see "Coding Templates for In-Context and Presentation Editing" in the Oracle Fusion Middleware WebCenter Sites Developer's Guide.
If the Asset Type search was configured for any of the asset types before the upgrade, then the dates will not be displayed properly in the search results after the upgrade. Users will need to re-index the asset type in order to display dates properly. Global searches, as well, must be re-indexed after the upgrade process.
If SmartLists were created in the original installation, they were deleted when you completed Section 2.2, "Pre-Upgrade Steps." Content contributors must re-create their SmartLists as Saved Searches.
If you upgraded from Content Server 7.6 Patch 2, the Page asset type was upgraded as described in Section 1.4.5, "Page and Slot Asset Types." WebCenter Sites administrators must create start menus for PageAttribute, PageDefinition, and PageFilter to enable these asset types to be used.
If your developers were using Developer Tools prior to the WebCenter Sites upgrade, complete the steps in this section.
This section contains the following topics:
Due to changes that were made during the upgrade process, resources that were previously exported into the workspace must be re-exported into the workspace. Complete the following steps:
Back up all previously exported resources (such as sites, asset types, and assets).
Delete all resources from the existing workspace.
Re-export all the previously exported resources into the workspace.
If the resources are stored in a version control system, replace all previously exported resources with the re-exported resources.
If your developers were using Developer Tools prior to the WebCenter Sites upgrade, they must ensure that the Developer Tools plug-in is updated to the latest version. For instructions on updating the Developer Tools plug-in, refer your developers to the section "Updating Developer Tools" in the Oracle Fusion Middleware WebCenter Sites Developer's Guide.
When developers enable Mobility device groups for existing sites, Mobility preview functions are added to the assets on those sites. Developers must add the d parameter to the pagecriteria parameters in the preview templates. Otherwise, error messages might be recorded in the log file when the templates are used to preview the assets.
If you upgraded from WebCenter Sites 11gR1 (11.1.1.6.1) and developers have programmatically customized the Contributor interface, they will have to restore the customizations as shown in this section.
Note:
If custom elements were stored in a location other than customElements, they were overwritten during the upgrade process. Developers will have to re-create their custom elements as the new elements identified in this section.
If developers customized the search elements UI/Data/Search/ListAction, UI/Data/Search/ListJson, UI/Data/Search/ThumbnailAction, and/or UI/Data/Search/ThumbnailJson, and the elements were stored under customElements, they must port the changes to the new elements as follows:
From UI/Data/Search/ListAction to UI/Data/Search/SearchAction
From UI/Data/Search/ListJson to UI/Data/Search/SearchJson
From UI/Data/Search/ThumbnailAction to UI/Data/Search/BrowseAction
From UI/Data/Search/ThumbnailJson to UI/Data/Search/BrowseJson
If developers customized any of the following search elements:
UI/Layout/CenterPane/Search/View/ListViewHtml
UI/Layout/CenterPane/Search/View/DockedListViewHtml
UI/Layout/CenterPane/Search/View/ThumbnailViewHtml
UI/Layout/CenterPane/Search/View/DockedThumbnailViewHtml
they must change the custom element(s) to point as follows: From:
storeElement = "UI/Data/Search/List" or
storeElement = "UI/Data/Search/Thumbnail"
To:
storeElement = BooleanUtils.toBoolean(browse) ? "UI/Data/Search/Browse" : "UI/Data/Search/Search";
If developers customized or configured the search or dashboard context menu through UI/Layout/CenterPane/Search/View/ContextMenuConfig or UI/Layout/CenterPane/DashBoard/ContextMenuConfig, they must delete these customizations and customize the same elements on the client side. Client-side configuration procedures are available in the Oracle Fusion Middleware WebCenter Sites Developer's Guide.
If you upgraded an installation while also running the Community, Gadgets, and/or Site Capture applications, upgrade those applications. For instructions, see Part II, "Upgrading to Oracle WebCenter Sites: Community-Gadgets" and Part III, "Upgrading Oracle WebCenter Sites: Site Capture."
Procedures for integrating WebCenter Sites with Oracle Access Manager are available in Oracle Fusion Middleware WebCenter Sites: Installing and Configuring Supporting Software. If you have also upgraded Community-Gadgets and Site Capture, refer to the same guide for procedures on enabling Community-Gadgets and Site Capture to communicate with OAM-integrated WebCenter Sites.
Complete the following steps on each WebCenter Sites instance in the upgraded environment:
Note:
If you have a cluster, begin with the primary cluster member, then test each secondary cluster member. Finally, test the cluster via the load balancer.
Log in to WebCenter Sites as the general administrator.
Test the WebCenter Sites interfaces (Admin and Contributor) and all functions that are routinely used during normal operations. For example: Searching; creating and editing custom asset types; creating and editing assets; previewing sites; workflow; and approval and publishing. For information about the interfaces, see the Oracle Fusion Middleware WebCenter Sites Installation Guide.
When your environment is verified, do one of the following:
If you upgraded the test environment, continue to Section 3.9, "Upgrading the Active Environment."
If you upgraded the active environment, do the following:
Enable the publishing schedules.
Enable any events
Back up the upgraded environment.
Apply any tuning required by the new caching structure.
Clear Client Browser caches (as existing cached content may cause issues).
Resume work.
The following steps apply if you first upgraded your test environment:
Having verified the test environment, you will now upgrade the active environment:
Assuming the active environment continued to operate during the trial upgrade, synchronize its Content Server or WebCenter Sites systems (as necessary):
Publish from the development system to the content management system.
Publish from the content management system to the delivery system.
Upgrade the active environment by following the previous steps in this chapter and any notes that you may have created during the trial upgrade.
Back up the upgraded environment.
Resume work.