Oracle® Fusion Middleware

WebCenter Sites Upgrade Guide

11g Release 1 (11.1.1.8.0)

E35831-02

January 2014

Oracle Fusion Middleware WebCenter Sites Upgrade Guide, 11g Release 1 (11.1.1.8.0)

E35831-02

Copyright © 2011, 2014, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate failsafe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Contents

Preface

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

Part I Upgrading to Oracle WebCenter Sites 11gR1 (11.1.1.8.0)

1 About the WebCenter Sites Upgrade Process

- 1.1 Upgrade Paths

- 1.2 New in This Release

- 1.3 About Changes During Upgrade

- 1.4 Changes During Upgrade from FatWire Content Server 7.6 Patch 2

- 1.4.1 Overall Changes

- 1.4.2 Summary of WEM Framework Changes

- 1.4.3 Interfaces and Applications

- 1.4.4 Roles

- 1.4.5 Page and Slot Asset Types

- 1.4.6 Attribute Editors

- 1.4.7 Apache Log4j

- 1.4.8 Caching Framework

- 1.4.9 Custom Elements

- 1.4.10 Revision Tracking

- 1.4.11 Database Tables

- 1.4.12 Web Application Changes

- 1.4.13 Changes to Tags

- 1.4.14 Miscellaneous Changes

- 1.4.15 Additional Changes

- 1.5 Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.0)

- 1.5.1 Changes to Developer Tools

- 1.5.2 Changes to Database Tables

- 1.5.3 New Properties

- 1.5.4 Additional Changes

- 1.6 Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.1)

- 1.6.1 Changes to Interfaces and Applications

- 1.6.2 Changes to Property Values

- 1.6.3 Changes to Database Tables

- 1.6.4 New Roles

- 1.6.5 New Configuration Files

- 1.6.6 New Asset Types

- 1.6.7 Changes to Tags

- 1.6.8 Changes to Site Plan

- 1.6.9 Changes to the Navigation Tree in the Admin Interface

- 1.6.10 Changes to Search-Related Elements

- 1.6.11 Changes to Context Menu Configuration

- 1.6.12 Changes to Security

- 1.6.13 Language Packs

2 Before You Upgrade to the Current Version of WebCenter Sites

- 2.1 Planning the Upgrade Process

- 2.2 Pre-Upgrade Steps

- 2.3 Pre-Upgrade Decisions

- 2.4 Planning the Post-Upgrade Steps

3 Upgrading to the Current Version of WebCenter Sites

- 3.1 Notes About the Upgrade Process

- 3.2 Backing Up Your Active Environment

- 3.3 Creating the Test Environment

- 3.4 Preparing Your Environment for Upgrade

- 3.4.1 Step 1: Upgrading the Supporting Components

- 3.4.2 Step 2: Preparing Your Existing Instances

- 3.5 Upgrading Instances to WebCenter Sites 11gR1 (11.1.1.8.0)

- 3.5.1 Upgrading Graphically

- 3.5.2 Upgrading Silently

- 3.5.2.1 Configuring the omii.ini File

- 3.5.2.1.1 Sample Configurations for Installing WEM Framework

- 3.5.2.1.2 Sample Configurations for Upgrading WEM Framework

- 3.5.2.2 Running the Silent Installer

- 3.5.3 Re-Running the Upgrade Utility

- 3.5.4 Completing the Upgrade

- 3.6 Upgrading Remote Satellite Servers

- 3.7 Post-Upgrade Steps

- 3.7.1 If You Changed the JVM Time Zone

- 3.7.2 If Asset Type and Global Searches Were Configured

- 3.7.3 If SmartLists Were Created

- 3.7.4 If You Upgraded from FatWire Content Server

- 3.7.5 If Your Developers Were Using Oracle WebCenter Sites: Developer Tools

- 3.7.5.1 Re-exporting Resources

- 3.7.5.2 Updating Developer Tools Plug-Ins

- 3.7.6 If Developers Enable Mobility Device Groups for Pre-existing Sites

- 3.7.7 If You Upgraded from a Customized WebCenter Sites 11gR1 (11.1.1.6.1) System

- 3.7.8 If Your Installation Was Running with Community, Gadgets, or Site Capture

- 3.7.9 If You Need to Integrate WebCenter Sites with Oracle Access Manager

- 3.8 Verifying the Upgraded Environment

- 3.9 Upgrading the Active Environment

Part II Upgrading to Oracle WebCenter Sites: Community-Gadgets

4 About the Community and Gadgets Upgrade Process

- 4.1 Upgrade Path

- 4.2 New in This Release

- 4.3 Changes Made During Upgrade

- 4.3.1 Roles

- 4.3.2 Application Deployment

- 4.3.3 Application Registration in WEM

- 4.3.4 Changes to the Gadgets Application

- 4.3.5 Changes to Database Structure

- 4.3.5.1 Changes from Community 11gR1 (11.1.1.6.x)

- 4.3.5.2 Changes from Gadgets 11gR1 (11.1.1.6.x)

5 Before You Upgrade to Community-Gadgets

- 5.1 Planning the Upgrade Process

- 5.2 Pre-Upgrade Steps

6 Upgrading to Community-Gadgets

- 6.1 Summary of Steps for the Community-Gadgets Upgrade Process

- 6.2 Upgrading Community and Gadgets to Community-Gadgets

- 6.2.1 Step 1: Exporting Community and Gadgets Data

- 6.2.1.1 Exporting Community Data

- 6.2.1.2 Exporting Gadgets Data

- 6.2.2 Step 2: Upgrading WebCenter Sites and Deleting the Community and Gadgets Applications

- 6.2.3 Step 3: Install and Verify the Community-Gadgets Web Application

- 6.2.4 Step 4: Importing Community and Gadgets Data to Community-Gadgets

- 6.2.4.1 Importing Community Data to Community-Gadgets

- 6.2.4.2 Importing Gadgets Data to Community-Gadgets

- 6.2.5 Step 5: Clearing the Community-Gadgets Application Server Cache

- 6.2.6 Step 6: Migrating Templates, Custom Skins, and Client-Side Deployment Tags

- 6.2.7 Step 7: Integrating with Oracle Access Manager (OAM)

- 6.3 Post-Upgrade Steps

- 6.3.1 If You Were Running WebCenter Sites with the Community Blogs Module

- 6.3.2 Integrating Community-Gadgets with the Contributor Interface

- 6.3.3 Integrating with Oracle Social Access Services

- 6.4 Implementing Security

Part III Upgrading Oracle WebCenter Sites: Site Capture

7 Before You Upgrade Site Capture

- 7.1 Upgrade Paths

- 7.2 Planning the Upgrade Process

- 7.3 Pre-Upgrade Steps

8 Upgrading Site Capture

- 8.1 Upgrading the Test Environment

- 8.1.1 Backing Up Your FatWire Site Capture 1.1 or WebCenter Sites: Site Capture 11gR1 (11.1.1.6.x) Environment

- 8.1.2 Creating the Test Environment

- 8.1.3 Upgrading Site Capture Instances to Version 11gR1 (11.1.1.8.0)

- 8.1.3.1 Interactive Upgrade

- 8.1.3.2 Silent Upgrade

- 8.1.4 Verifying the Upgraded Environment

- 8.2 Upgrading the Active Environment

- 8.3 Upgrading Custom Implementations and Integrating with the Publishing System

- 8.3.1 Custom Implementations

- 8.3.2 Integrating with the Publishing System

9 Reference: Site Capture Backup and Recovery

- 9.1 Prerequisites for Backing Up and Recovering

- 9.2 Backup and Recovery Guidelines

- 9.2.1 Site Capture Installation Directory

- 9.2.1.1 Backup

- 9.2.1.2 Recovery

- 9.2.2 Web Application

- 9.2.3 Non-Exploded Files Backup

- 9.2.4 Non-Exploded Files Recovery

- 9.2.5 Exploded Files Backup

- 9.2.6 Exploded Files Recovery

- 9.2.7 WebCenter Sites Database

- 9.2.7.1 Backup of Oracle, Microsoft SQL Server, and IBM DB2 Databases

- 9.2.7.2 Recovery of Oracle, Microsoft SQL Server, and IBM DB2 Databases

- 9.2.8 Running the Recovered Application

Preface

This guide describes the process of upgrading to Oracle WebCenter Sites 11g Release 1 (11.1.1.8.0), and to the same versions of Oracle WebCenter Sites: Community-Gadgets, and Oracle WebCenter Sites: Site Capture.

Audience

This guide is intended for installation engineers with experience installing and configuring enterprise-level software such as databases, application servers, and content management products.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related Documents

For more information, see the following documents:

- Oracle Fusion Middleware WebCenter Sites Installation Guide

- Oracle Fusion Middleware WebCenter Sites: Installing and Configuring Supporting Software

- Oracle Fusion Middleware WebCenter Sites Property Files Reference

- Oracle Fusion Middleware WebCenter Sites Developer's Guide

- Oracle Fusion Middleware WebCenter Sites Administrator's Guide

- Oracle Fusion Middleware WebCenter Sites User's Guide

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

Part I

Upgrading to Oracle WebCenter Sites 11gR1 (11.1.1.8.0)

This part contains information about upgrading to Oracle WebCenter Sites 11gR1 (11.1.1.8.0). Your starting installations are FatWire Content Server 7.6 Patch 2, or Oracle WebCenter Sites 11gR1 (11.1.1.6.0) or Oracle WebCenter Sites 11gR1 (11.1.1.6.1).

This part contains the following chapters:

- Chapter 1, "About the WebCenter Sites Upgrade Process"

- Chapter 2, "Before You Upgrade to the Current Version of WebCenter Sites"

- Chapter 3, "Upgrading to the Current Version of WebCenter Sites"

1 About the WebCenter Sites Upgrade Process

Before upgrading to Oracle WebCenter Sites 11gR1 (11.1.1.8.0), read this chapter for information about the upgrade paths, new features provided in the current release, and the types of changes that will be made to your starting installation during the upgrade process.

This chapter contains the following sections:

- Section 1.1, "Upgrade Paths"

- Section 1.2, "New in This Release"

- Section 1.3, "About Changes During Upgrade"

- Section 1.4, "Changes During Upgrade from FatWire Content Server 7.6 Patch 2"

- Section 1.5, "Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.0)"

- Section 1.6, "Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.1)"

1.1 Upgrade Paths

The following installations can be upgraded directly to WebCenter Sites 11gR1 (11.1.1.8.0):

- FatWire Content Server 7.6 Patch 2

- Oracle WebCenter Sites 11gR1 (11.1.1.6.0)

- Oracle WebCenter Sites 11gR1 (11.1.1.6.1) Bundled Patch 1

Note:

If you upgrade your existing installation to the current version of WebCenter Sites, and any of the following applications are installed – Community, Gadgets, or Site Capture, then you must upgrade those applications, as well. Procedures are available in Part II, "Upgrading to Oracle WebCenter Sites: Community-Gadgets" and Part III, "Upgrading Oracle WebCenter Sites: Site Capture."

1.2 New in This Release

Upgrading to WebCenter Sites 11gR1 (11.1.1.8.0) provides users with the following new features and capabilities:

- WebCenter Content (WCC) Integration. This feature enables administrators to integrate selected content from WebCenter Content Server into WebCenter Sites. The WCC Integration feature can be added during the upgrade process or at a later time, depending on your requirements.

- Mobility framework. This feature enables content contributors to create sites for mobile phones and tablets. This feature is installed by default during the upgrade process.

- Support for Vanity URLs. This feature enables its users to define simple, short, and meaningful URLs directly from the WebCenter Sites interfaces and assign them to assets. Developers can code template to use the assigned URLs.

- Oracle WebCenter Sites: Engage displays a new set of content entry forms for creating and managing segments, promotions, and recommendations.

- Widgets and gadgets configured in the Community-Gadgets application can be integrated into WebCenter Sites and deployed directly from the Contributor interface. Integration of external asset types from third-party source systems is also supported.

- The Community and Gadgets applications are now distributed as a single web application called "Community-Gadgets" for simpler maintenance. They remain as WEM Framework applications that continue to have their own application icons and interfaces.

1.3 About Changes During Upgrade

The upgrade process makes a number of changes to your existing installation. For information about which changes are made to your installation, read this chapter as follows:

- If you are upgrading from FatWire Content Server 7.6 Patch 2, read the following sections to determine the total extent of changes:

- Section 1.4, "Changes During Upgrade from FatWire Content Server 7.6 Patch 2"

- Section 1.5, "Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.0)"

- Section 1.6, "Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.1)"

- If you are upgrading from WebCenter Sites 11gR1 (11.1.1.6.0), read the following sections to determine the total extent of changes:

- Section 1.5, "Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.0)"

- Section 1.6, "Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.1)"

- If you are upgrading from WebCenter Sites 11gR1 (11.1.1.6.1), read the following section to determine the total extent of changes:

- Section 1.6, "Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.1)"

If you have questions about the changes described in any of the sections, contact technical support before starting the upgrade.

1.4 Changes During Upgrade from FatWire Content Server 7.6 Patch 2

Upgrading a Content Server 7.6 Patch 2 installation results in a number of changes to the installation. For information about the changes, read the following sections:

- Section 1.4.1, "Overall Changes"

- Section 1.4.2, "Summary of WEM Framework Changes"

- Section 1.4.3, "Interfaces and Applications"

- Section 1.4.4, "Roles"

- Section 1.4.5, "Page and Slot Asset Types"

- Section 1.4.6, "Attribute Editors"

- Section 1.4.7, "Apache Log4j"

- Section 1.4.8, "Caching Framework"

- Section 1.4.9, "Custom Elements"

- Section 1.4.10, "Revision Tracking"

- Section 1.4.11, "Database Tables"

- Section 1.4.12, "Web Application Changes"

- Section 1.4.13, "Changes to Tags"

- Section 1.4.14, "Miscellaneous Changes"

- Section 1.4.15, "Additional Changes"

1.4.1 Overall Changes

If you are upgrading from FatWire Content Server 7.6 Patch 2, the following features, once optional, are deployed, installed, or upgraded by default during the upgrade process to function as standard features:

- Central Authentication Service (CAS) is deployed. The CAS web application is deployed during the upgrade process. Like Content Server 7.6 Patch 2, WebCenter Sites supports CAS clustering to balance the load of user authentications. Secondary members of a CAS cluster are deployed manually during the post-upgrade process.

Note:

After the upgrade process is complete, you can replace CAS with Oracle Access Manager (OAM).

- The inCache framework is installed. Our implementation of Terracotta's Ehcache open source product is available under the Apache license. The inCache framework provides significant performance improvements over the traditional page caching method. It also provides asset caching and resultset caching capabilities. The inCache framework is installed and configured by default. Information about inCache page, asset, and resultset caching is available in the Oracle Fusion Middleware WebCenter Sites Administrator's Guide. Additional information about resultset caching is available in the Oracle Fusion Middleware WebCenter Sites Developer's Guide.

- WEM Framework is installed (or upgraded, if already installed). The WEM login page becomes the new WebCenter Sites login page, which affects the way WebCenter Sites interfaces are accessed. WEM Framework consists of the following components:

- REST API – Enables developers to communicate with WebCenter Sites for the purpose of building and implementing applications on the WEM Framework.

- Universal UI Container – Provides a single interface for accessing custom-built applications integrated with WebCenter Sites via the WEM Framework. It also enables rendering of the application interfaces.

- WEM Admin Interface – Enables the coupling of users to applications running on the WEM Framework and provides for centralized user management. The WEM Admin interface is not installed on delivery systems.

- REST Security Model – Enables administrators to control access to the resources of applications running on the WEM Framework.

- Single Sign-On – Enables WebCenter Sites users to access all applications they are authorized to access during the session without having to sign in to each application.

During upgrade, the WEM Framework requires CAS, which can be clustered or non-clustered. OAM-integration is a post-upgrade option.

- Clarkii Online Image Editor (OIE) from InDis Baltic is installed on development and content management systems. Clarkii can be enabled in the WebCenter Sites Contributor (editorial) interface, in place of your current Online Image Editor. However, it is not supported in Web Mode of the Contributor interface. For information about Clarkii OIE, see the Oracle Fusion Middleware WebCenter Sites Developer's Guide and Oracle Fusion Middleware WebCenter Sites User's Guide.

You also have the following upgrade and post-upgrade options:

- During upgrade, you can switch to the Apache log4j logging system, which allows for dynamic updating of loggers from the WebCenter Sites Admin interface.

- After upgrade, you can integrate with Oracle Access Manager (OAM). Integration procedures are available in Oracle Fusion Middleware WebCenter Sites: Installing and Configuring Supporting Software.

1.4.2 Summary of WEM Framework Changes

If you are upgrading from a Content Server 7.6 Patch 2 installation that is not running the WEM Framework:

- WEM Framework is installed.

- The CAS Single Sign-On web application is deployed during the upgrade process.

- CAS may be installed alongside WebCenter Sites or on a separate cluster.

- URLs are CAS-protected.

- The REST servlet is installed. REST security is discussed in the Oracle Fusion Middleware WebCenter Sites Developer's Guide and Oracle Fusion Middleware WebCenter Sites Administrator's Guide.

- A new content management site, named AdminSite, is created.

- The existing login page is replaced with the WebCenter Sites login page.

1.4.3 Interfaces and Applications

If you are upgrading from Content Server 7.6 Patch 2:

- The Content Server Advanced interface is replaced by the WebCenter Sites Admin interface. By default, it is no longer used as an editorial interface. However, editorial features can be re-enabled in the post-upgrade process by setting the property advancedUI.enableAssetForms in the futuretense_xcel.ini file to true). For more information, see the Oracle Fusion Middleware WebCenter Sites Property Files Reference.

- Customizations to the Advancedadministrative interface will not work after the upgrade. Therefore, you will back up all customizations stored in the database, installation folder, shared folder, and web application. You will then reapply customizations from this backup after the upgrade to WebCenter Sites is complete.

- The WebCenter Sites Contributor interface is installed. For information about the interface, see the Oracle Fusion Middleware WebCenter Sites User's Guide.

- The Content Server Dash interface is completely removed. Customizations made to the Dash interface in Patch 2 will not apply on upgrade.

- The Content Server InSite interface is completely removed. Customizations made to the InSite interface in Patch 2 will not apply on upgrade.

- If you are upgrading from an installation that does not contain the WEM Framework, the AdminSite is installed. The general administrator is assigned to AdminSite.

1.4.4 Roles

If you are upgrading from Content Server 7.6 Patch 2:

- The SitesUser role is added to provide users with access to the WebCenter Sites Contributor interface.

- The DashUser role is removed.

- If you are upgrading from an installation that is not running the WEM Framework, the SiteAdmin role is assigned to the general administrator. The general administrator is also added to the RestAdmin group.

1.4.5 Page and Slot Asset Types

If you are upgrading from Content Server 7.6 Patch 2, the Page asset type is upgraded to be an extensible Page asset type, which now includes an attribute, filter, and definition (similar to that of a flex asset). Subtypes are changed to definitions. Additionally, external templates are changed to the new "Layout" type of template. For more information, see the Oracle Fusion Middleware WebCenter Sites Developer's Guide.

Note:

After the upgrade, administrators must create start menus for PageAttribute, PageDefinition, and PageFilter to enable these asset types to be used.

1.4.6 Attribute Editors

If you are upgrading from Content Server 7.6 Patch 2:

- RememberME is deprecated and not supported.

- PickOrderAsset is deprecated not supported.

- All multi-valued attributes are now enabled for re-ordering.

- CKEditor is updated to the currently supported version and lazyloaded by default in all interfaces. Developers can still use the pre-existing FCKEditor attribute definitions for both flex and basic assets.

Note:

It is recommended to change the attribute editor from FCKEditor to CKEditor after the upgrade.

- New attribute editors are installed:

- TypeAhead

- Uploader

- The URL attribute is replaced by BLOB. However, the existing URL attribute will continue to function after the upgrade.

1.4.7 Apache Log4j

If you are upgrading from Content Server 7.6 Patch 2, you have the option to switch to Apache log4j, which enables you to modify log levels from within the WebCenter Sites Admin interface by using its System Tools.

1.4.8 Caching Framework

If you are upgrading from a Content Server 7.6 Patch 2 installation that uses traditional page caching:

- Content Server's existing caches (database-based and hash-based) are replaced with inCache, a memory-centric cache that is based on Ehcache by Terracotta. For more information, see the Oracle Fusion Middleware WebCenter Sites Administrator's Guide.

- As a result of switching caches, it will be necessary to retune caching.

- Because inCache is memory-based, additional JVM heap will be required.

1.4.9 Custom Elements

If you are upgrading from a Content Server 7.6 Patch 2 installation:

- All elements in the AssetStubElementCatalog table are overwritten with native WebCenter Sites 11gR1 code.

- Customized elements of the Advanced administrative interface are overwritten with native WebCenter Sites 11gR1 code.

1.4.10 Revision Tracking

If you are upgrading from a Content Server 7.6 Patch 2 installation, revision tracking is modified. For the new revision tracking behavior to take effect, you must disable revision tracking on all asset types, and then re-enable revision tracking. For information, see the Oracle Fusion Middleware WebCenter Sites User's Guide.

1.4.11 Database Tables

If you are upgrading from a Content Server 7.6 Patch 2 installation, the following changes may be made to database tables during the upgrade process. Only changes that apply to your database type are made:

- For DB2 and Microsoft SQL Server, StringValue is changed from 255 to 2000.

- In the _Mungo tables, StringValue is changed to 2000.

- In the _TGROUP table of asset types, the Ordinal column is added.

- In the ApprovalQueue table, the cs_target column is added.

- In the ApprovedAssets table, the changedby column is added.

- In the AssetPublistList table, the tag column is added.

- Upgrade creates the txRTInfo table. Drop this table manually after the upgrade.

- In the IndexSourceMetaDataConfig table, the fieldescriptor column is changed to urlfielddescriptor, and its value is changed from 2048 to 255.

- In the Mimetype table, the size of the mimetype column is changed from 64 to 128.

- In the FW_PUBDATASTORE table, the size of the encoding column is changed to 255.

- In the SAVESEARCH table, the spostpage column is changed to be nullable.

- The editorid column is added to all the attribute asset types.

- The Flex Definition asset type and Parent definition asset are changed to have the cs_ordinal column in Mungo tables.

- In the Page table, the flextemplateid column is added.

- In the Publication table, the cs_wrapperasset column is added.

- In the PubTarget table, the size of the FACTORS column is changed to 1000.

- In the RTInfo table, the newerformat column is added.

- In the Template_Subtypes table, the size of the subtype column is changed to 64.

- In tables Workflow_DlgA, WorkflowGroups_Dlock, WorkflowRoutes_Comp, WorkflowRoutes_Cond, WorkflowRoutes_Dead, the Ordinal column is added.

- The AssetEditPane table is removed. If it still exists after the upgrade, it must be manually deleted.

- The tables listed in Table 1-1 are added.

Table 1-1 Database Tables Added During Upgrade from FatWire Content Server

Added Tables

Added Tables

FW_Tag

Page_Definition_Publish

Page_Mungo

Page_Definition_TAttr

Page_Publish

Page_Definition_TFilter

Page_Ratings

Page_Filter

Page_Attribute

Page_Filter_Args

Page_AttributeArgs

Page_Filter_Dim

Page_Attribute_Dim

Page_Filter_Dim_P

Page_Attribute_DimP

Page_Filter_Publish

Page_Attribute_Extension

PublishedTags

Page_Attribute_Publish

Slots

Page_Attribute_Subtypes

Slots_Dim

Page_Definition

Slots_DimP

Page_Definition_Dim

Slots_Publish

Page_Definition_DimP

- The ASSETTYPE_Rtgs table is added to all flex or parent asset types. Definition or attribute asset types are ignored. The same table is also added for basic asset types, except for some special core asset types.

- The ASSETTYPE_SubTypes table is added to all the attribute asset types (for example, MEDIA_A_SUBTYPES).

1.4.12 Web Application Changes

If you are upgrading from a Content Server 7.6 Patch 2 installation, the Dash interface is removed from the WebCenter Sites web application, resulting in the following changes:

- In the web.xml file:

- csRedirect, trinidad, adfFaces filters are removed.

- org.apache.myfaces.webapp.StartupServletContextListener listener is removed.

- FacesServlet and faces servlets are removed.

- In the WEB-INF folder, all files except web.xml, weblogic.xml (if applicable) and applicationContext.xml are removed.

- The ReqAuthConfig.xml file is added to the application server's WEB-INF/classes folder. This file enables you to specify the URLs that will be either included in or excluded from Cross-Site Request Forgery (CSRF) protection.

1.4.13 Changes to Tags

If you are upgrading from a Content Server 7.6 Patch 2 installation, the following tags are added:

- insite:list

- insite:slotlist

- insite:ifedit

For more information about the tags, see the Oracle WebCenter Sites Tag Reference.

1.4.14 Miscellaneous Changes

If you are upgrading from a Content Server 7.6 Patch 2 installation:

- By default, WebCenter Sites will use milliseconds in date and timestamps.

- After the upgrade, attribute forms will display additional fields which are not seen on a fresh installation. To make the attribute forms consistent with those of a fresh installation, you will edit the gator.ini file by setting the mwb.externalattributes property to false (the gator.ini file is located in the <cs_install_folder>).

- If the Asset Type search is 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, will have to be re-indexed after the upgrade process.

- In the futuretense_xcel.ini file, the value of the xcelerate.ewebeditpro property is removed, as eWebEditPro is not supported.

- Layout templates:
Templates of usage type "Element defines a whole HTML page and can be called externally" are converted by the installer to usage type "Element is used as Layout." Templates of all other usage types are not converted. When assets using such templates are edited, they must be assigned a layout template.

- Publishing of approved assets will not function correctly until the upgrade utility is run. As of WebCenter Sites 11gR1 (11.1.1.6.0), dates are managed with millisecond accuracy. Since FatWire Content Server did not provide millisecond accuracy for approval related data, it is possible that data may be incorrectly interpreted after the upgrade. To avoid this condition, the upgrade utility adds millisecond accuracy to approval tables and ensures that the approval state is correctly preserved after the upgrade. Entries in the ApprovedAssets, ApprovedAssetDeps, and PublishAssets tables are affected by this utility.

1.4.15 Additional Changes

If you are upgrading from a Content Server 7.6 Patch 2 installation, read the following sections for additional changes that are applied to Content Server 7.6 Patch 2:

- Section 1.5, "Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.0)"

- Section 1.6, "Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.1)"

1.5 Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.0)

Upgrading a WebCenter Sites 11gR1 (11.1.1.6.0) installation results in a number of changes to the installation. For information about the changes, read the following sections:

- Section 1.5.1, "Changes to Developer Tools"

- Section 1.5.2, "Changes to Database Tables"

- Section 1.5.3, "New Properties"

- Section 1.5.4, "Additional Changes"

1.5.1 Changes to Developer Tools

If you are upgrading from WebCenter Sites 11gR1 (11.1.1.6.0), the Developer Tools feature is enhanced with support for remote connections.

1.5.2 Changes to Database Tables

If you are upgrading from WebCenter Sites 11gR1 (11.1.1.6.0), database tables are changed as follows:

- All ASSETTYPE_Ratings tables are renamed to ASSETTYPE_Rtgs.

- The TempObjects table is removed. The table is re-created with a new column named createddate.

- The following asset type tables are removed: FW_UIConfiguration and FW_AttributeEditor, along with their related tables:

FW_AttributeEditor_Config, FW_AttributeEditor_ConfigVals,
FW_AttributeEditor_Dim, FW_AttributeEditor_DimP,
FW_AttributeEditor_Publish, FW_UIConfiguration,
FW_UIConfiguration_Dim, FW_UIConfiguration_DimP

- The following tables are upgraded: FW_MSGBUS, FW_PUBDATASTORE, and PUBSESSION

1.5.3 New Properties

If you are upgrading from WebCenter Sites 11gR1 (11.1.1.6.0), a new property named timezoneattr is added to the futuretense_xcel.ini file. For information about this property, see the Oracle Fusion Middleware WebCenter Sites Property Files Reference.

1.5.4 Additional Changes

If you are upgrading from a WebCenter Sites 11gR1 (11.1.1.6.0) installation, read the following section for additional changes that are applied to WebCenter Sites 11gR1 (11.1.1.6.0):

- Section 1.6, "Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.1)"

1.6 Changes During Upgrade from FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.1)

Upgrading a WebCenter Sites 11gR1 (11.1.1.6.1) installation results in a number of changes to the installation. For information about the changes, read the following sections:

- Section 1.6.1, "Changes to Interfaces and Applications"

- Section 1.6.2, "Changes to Property Values"

- Section 1.6.3, "Changes to Database Tables"

- Section 1.6.4, "New Roles"

- Section 1.6.5, "New Configuration Files"

- Section 1.6.6, "New Asset Types"

- Section 1.6.7, "Changes to Tags"

- Section 1.6.8, "Changes to Site Plan"

- Section 1.6.9, "Changes to the Navigation Tree in the Admin Interface"

- Section 1.6.12, "Changes to Security"

- Section 1.6.13, "Language Packs"

- Note:
The same sections apply to FatWire Content Server 7.6 Patch 2 and WebCenter Sites 11gR1 (11.1.1.6.0).

1.6.1 Changes to Interfaces and Applications

If the WEM Admin application was assigned to any sites other than AdminSite, it is unassigned. After the upgrade process, it must be manually reassigned to sites other than AdminSite.

1.6.2 Changes to Property Values

- Custom values for default properties are overridden by the upgrade installer and replaced with default values.

- Custom values for custom properties are unaffected by the upgrade process.

1.6.3 Changes to Database Tables

- If upgrade is performed from WebCenter Sites 11gR1 (11.1.1.6.x), then in the PageAttribute table, the editorid column is removed.

- In the SYSTEMUSERS table, the size of the password column is changed from 40 to 256.

- The tables listed in Table 1-2 are added to WebCenter Sites 11gR1 (11.1.1.8.0).

Table 1-2 New Database Tables

New Tables

New Tables

CONTENTQUERY

DEVICEGROUP

CONTENTQUERY_DIM

DEVICEGROUP_DIM

CONTENTQUERY_DIMP

DEVICEGROUP_DIMP

CONTENTQUERY_RTGS

DEVICEIMAGE

SITEPLAN

DEVICEIMAGE_DIM

SITEPLAN_DIM

DEVICEIMAGE_DIMP

SITEPLAN_DIMP

WCCBATCH

WEBREFERENCES

WCCORPHAN

WEBREFERENCESPATTERNS

WCCPOLLER

WEBROOT

WCCSIGNALS

WEBROOT_DIM

WEBROOT_RTGS

WEBROOT_DIMP

SYSTEMUSERPREFERENCES

1.6.4 New Roles

The following roles are added to WebCenter Sites 11gR1 (11.1.1.8.0):

- The ConnectorAdmin role is added for WCC Integration.

- The MobileSitesDeveloper role is added for the Mobility feature.

1.6.5 New Configuration Files

The following configuration files are added to WebCenter Sites 11gR1 (11.1.1.8.0) to support the Mobility framework, Vanity URLs, Community-Gadgets, and tighter security:

- ESAPI.properties

- MobilityService.xml

- SitesSecurityWrapper.xml

- validation.properties

- webreference.xml

- cg.tld

- device.tld

- proxy.tld

- customBeans.xml

Note:

The customBeans.xml file is present as of WebCenter Sites 11gR1 (11.1.1.6.1), but it is empty by default. This file is used to list URLs that can directly access CAS.

1.6.6 New Asset Types

The following new asset types are added to WebCenter Sites 11gR1 (11.1.1.8.0) to support the Mobility feature, Vanity URLs, and ContentQuery assets:

- CONTENTQUERY

- DeviceGroup

- DeviceImage

- SitePlan

- WebRoot

1.6.7 Changes to Tags

The tags shown in Table 1-3 are added to, updated in, and removed from WebCenter Sites 11gR1 (11.1.1.8.0) during the upgrade process. For more information about the tags, see the Oracle WebCenter Sites Tag Reference.

Table 1-3 New, Updated, and Removed Tags

Type of Tag

Type of Change

Tag

External Asset

New

New

New

New

proxy:create store

proxy:register

proxy:addstoreitem

proxy:tojson

Mobility

New

New

New

New

device:capability

device:get

device:hascapability

device:load

RealTime Decisions

New

Updated

commercecontext:inform

commercecontext:getrecommendations

insite

Updated

Removed

Removed

Removed

Removed

Removed

Removed

Removed

Removed

Removed

insite:list

insite:slotlist

insite:addvalue

insite:beginlist

insite:endlist

insite:beginref

insite:addref

insite:endref

insite:createasset

insite:editasset

Miscellaneous

Updated

Updated

Updated

Updated

Updated

Updated

Updated

Updated

ccuser:gettimezone

ccuser:settimezone

insite:calltemplate

render:calltemplate

render:getpageurl

render:gettemplateurl

render:gettemplateurlparameters

satellite:cookie

1.6.8 Changes to Site Plan

The Placed Pages site plan is renamed Default site plan. All assets previously under Placed Pages are now under the Default site plan.

1.6.9 Changes to the Navigation Tree in the Admin Interface

The navigation tree in the WebCenter Sites Admin interface is re-organized and supplemented with additional tabs and nodes as follows:

- Mobility and Connector Admin tabs are added to the tree.

- The User Access Management node is created in the Admin tab. It contains the following sub-nodes:

- Users

- Roles

- ACLs

- User Profiles

- REST Security

- Management Tools and Sources nodes are removed from the Admin tab.

- The Workflow tab now contains the following nodes (States and Processes nodes remain; the nodes listed below were moved from the Admin tab):

- Actions (renamed from Workflow Actions)

- Timed Action Event

- Emails

- Clear Assignments

1.6.10 Changes to Search-Related Elements

Search-related elements are replaced as follows:

- UI/Data/Search/ListAction is replaced by UI/Data/Search/SearchAction.

- UI/Data/Search/ListJson is replaced by UI/Data/Search/SearchJson.

- UI/Data/Search/ThumbnailAction is replaced by UI/Data/Search/BrowseAction.

- UI/Data/Search/ThumbnailJson is replaced by UI/Data/Search/BrowseJson.

If any of the original elements have been customized, the changes must be ported to the new elements, as indicated in Chapter 3, "Upgrading to the Current Version of WebCenter Sites."

1.6.11 Changes to Context Menu Configuration

The context menu configuration is moved to the client side. If the search or dashboard context menu has been customized through the element UI/Layout/CenterPane/Search/View/ContextMenuConfig or UI/Layout/CenterPane/DashBoard/ContextMenuConfig, the element must be deleted and re-customized on the client side, as indicated in Chapter 3, "Upgrading to the Current Version of WebCenter Sites."

1.6.12 Changes to Security

The password encryption format of WebCenter Sites users is updated after upgrade. For custom users, the passwords are updated to the new encryption format once the users log in. The encryption format for passwords is also updated in INI files. For more information, see the Oracle Fusion Middleware WebCenter Sites Administrator's Guide.

1.6.13 Language Packs

The following language packs are installed by default during the upgrade process:

- Chinese (Simplified)

- Chinese (Traditional)

- English (United States)

- French (France)

- German (Germany)

- Italian (Italy)

- Japanese (Japan)

- Korean (Korea)

- Portuguese (Brazilian)

- Spanish (Spain)

2 Before You Upgrade to the Current Version of WebCenter Sites

Before upgrading to Oracle WebCenter Sites 11gR1 (11.1.1.8.0), read this chapter to gain an understanding of the upgrade strategy and the prerequisite steps.

This chapter contains the following sections:

- Section 2.1, "Planning the Upgrade Process"

- Section 2.2, "Pre-Upgrade Steps"

- Section 2.3, "Pre-Upgrade Decisions"

- Section 2.4, "Planning the Post-Upgrade Steps"

2.1 Planning the Upgrade Process

In a production environment, upgrades disrupt the operation of active systems and may result in extended downtime. To minimize such disruptions, Oracle highly recommends adopting the upgrade strategy outlined in this section, that is to start by updating a test environment.

Note:

The term "active" is used to denote any development, management, or delivery system that is currently serving content and whose unexpected downtime will affect business and productivity of the organization.

An enterprise-level environment typically consists of at least three different WebCenter Sites-powered systems: development, management, and delivery, as shown in Figure 2-1. Each system runs on its own database and interacts with the other systems typically through publishing or Oracle WebCenter Sites: Developer Tools.

Before upgrading an active environment, it is critical to perform a trial upgrade on a duplicate environment. The trial upgrade will help you detect and document system-specific issues and correct them in advance of the actual upgrade.

Note:

A trial upgrade is critical, as customizations made to the FatWire Content Server 7.6 Patch 2 Advanced user and Dash interfaces will not work on WebCenter Sites 11gR1 (11.1.1.8.0). Therefore, due diligence is required to replace such customizations with those designed for the new Contributor interface before attempting to upgrade an active system.

If a duplicate environment is not available, start by upgrading the development system in order to minimize interruptions to the management and delivery systems. This approach is highly risky, and it should not be attempted unless extended downtime is deemed acceptable.

Figure 2-1 WebCenter Sites Environment

2.2 Pre-Upgrade Steps

This guide is written for experienced WebCenter Sites installation engineers. Before upgrading to WebCenter Sites 11gR1 (11.1.1.8.0), complete the following steps:

- Read the WebCenter Sites release notes and the Oracle WebCenter Sites Certification Matrix available here: http://www.oracle.com/technetwork/middleware/webcenter/sites/downloads/index.html

- Read the rest of this guide to familiarize yourself with the upgrade procedures, changes that will be made by the upgrade installer, and the post-upgrade steps.

- Start with one of the following installations:
FatWire Content Server 7.6 Patch 2, or WebCenter Sites 11gR1 (11.1.1.6.x )

- You will run the WebCenter Sites 11gR1 (11.1.1.8.0) installer on all Content Server or WebCenter Sites 11gR1 (11.1.1.6.x ) systems in your environment. There are three system types: development, content management, and delivery. Development systems and content management systems are typically of the same type, but are used for different purposes.
The WebCenter Sites 11gR1 (11.1.1.8.0) installer detects and reuses both the system type (development, content management, or delivery) and the deployment mode (automatic or manual) that were selected during the Content Server 7.6 Patch 2 or WebCenter Sites 11gR1 (11.1.1.6.x ) installation process. For example, if Content Server 7.6 Patch 2 or WebCenter Sites 11gR1 (11.1.1.6.x ) was installed as a delivery system and deployed automatically, the WebCenter Sites 11gR1 (11.1.1.8.0) installer continues to treat the system as a delivery system and deploys automatically.

Note:

- System type and deployment mode cannot be changed during upgrades.

- A primary WebCenter Sites cluster member cannot be reconfigured as a secondary cluster member, and vice versa, during upgrades.

- If you are upgrading from WebCenter Sites 11gR1 (11.1.1.6.x ) and you have the Site Capture, Community, and/or Gadgets applications running with your WebCenter Sites system, you will have to upgrade those applications. Instructions are provided in this guide.

- If your current platform is not supported by WebCenter Sites 11gR1 (11.1.1.8.0), re-install on a platform that is supported by WebCenter Sites 11gR1 (11.1.1.8.0) and then publish all content and customizations to this environment before continuing the upgrade.

- If you upgrade your application server, set the following properties to point to the new application server:
cs.jsproot in futuretense.ini

csjsproot in ominstallinfo/omii.ini

This must be done before starting the upgrade installer; otherwise, the installer will fail after the midpoint of the installation process.

- If your current Content Server or WebCenter Sites application was modified since it was first deployed (most likely it was), do the following:

- Back up your current Content Server or WebCenter Sites application by creating cs.war and then ContentServer.ear files. Also back up the installation directory, shared directory, and database. For detailed instructions, see the chapter "Backup and Recovery" in the Oracle Fusion Middleware WebCenter Sites Installation Guide.
In the post-upgrade process, you will use the backed up installation directory, shared directory, and database to reapply the customizations they may contain

- If customizations were made to your current Content Server or WebCenter Sites 11gR1 (11.1.1.6.x ) application after it was first deployed, and those customizations are not reflected in the cs.war and ContentServer.ear files located in <cs_install_dir>/ominstallinfo/app, do the following: Remove the files, and copy the .war and .ear files for your currently deployed WebCenter Sites application to the same directory.
During the upgrade, the existing cs.war file is archived as cs-date-time.war. In the post-upgrade process, you will use the archived version to reapply customizations where necessary.

- If custom indexes were added to the tables, back up these indexes and reapply them after the upgrade process is complete.

- If you are upgrading from Content Server 7.6 Patch 2 or WebCenter Sites 11gR1 (11.1.1.6.x ), keep in mind the following:

- Customizations to the Admin interface will not work after the upgrade. Therefore, back up all customizations stored in the database, installation folder, shared folder, and web application. Reapply customizations from this backup after the upgrade is complete.

- Any SmartLists (now called Saved Searches) that were created in the Contributor interface will not work after the upgrade. SmartLists must be deleted before upgrade (after upgrade they need to be recreated.

- Ensure that all external data feeds and events (including search events) are disabled. (Remember to enable the external data feeds and events after the upgrade is completed.)

- Disable revision tracking for the following asset types:

- ASSOCNAMED table

- CSElement

- Template

- Page

- For JDK 1.6, copy the jaxb-impl-2.1.12.jar file in the installer's Sun/lib directory to the following location: <PATH_TO_JDK_FOLDER>/jre/lib/endorsed.

Note:

Do not use the jaxb-impl that ships with JDK 1.6 or JDK 1.7. WebCenter Sites 11gR1 relies on the latest version of jaxb-impl, which is provided in the location specified above. The latest JAR file must be used in order to resolve a runtime conflict with WebLogic Server (which ships with JDK 1.6).

- On all application servers, do the following:

- Update the startup script:

- Set the max PermGen parameter in the range of 128MB–196MB. For example: -XX:MaxPermSize=196m

- Set -Dcs.useJavaURLDecoder to false. This step ensures that the Apache URLCodec is used to decode URL characters.

- Update the CLASSPATH environment variable: Add the path to the WebCenter Sites-modified version of the Microsoft XML Parser (MSXML.jar in the WEB-INF/lib directory). If the class path refers to another version of the Microsoft XML Parser, WebCenter Sites will fail when parsing XML.

Note:

If the class path and library path are not set properly, CAS will fail to start, making access to the system impossible. If you are using OAM, the upgrade reverts to CAS.

- If the password of the ContentServer user (the system-defined user) contains special characters or is composed solely of numeric characters, replace it with an alphanumeric password that does not contain special characters. The upgrade installer does not accept special characters in password fields, nor does it accept passwords that contain only numeric characters. The original password can be used once all upgrades are completed.

- Optional on Tomcat application servers: If you receive errors related to the data source, place the following JAR files in the <app_server_home>/lib directory to ensure that the data source is correctly initialized when WebCenter Sites is first started:

- commons-dbcp-1.3.jar
You can download this file from: http://commons.apache.org/dbcp/

- commons-pool-1.5.5.jar
You can download this file from: http://commons.apache.org/pool/

- If your current system is WebCenter Sites 11gR1 (11.1.1.6.x ) or Content Server 7.6 Patch 2 running the WEM Framework, do the following:

1. Undeploy and delete the previous CAS installation before starting the upgrade.

2. If you plan to install silently, modify the omii.ini file for all Content Server cluster members by setting the values of CASHostName and CASPortNumber fields as shown in Table 2-1.

Table 2-1 CAS-Related Fields

Field

CAS

Value

CASHostName

Clustered

Host name of the server running the load balancer.

CASHostName

Non-clustered

Host name of the server on which CAS will be deployed.

CASPortNumber

Clustered

Port number of the server running the load balancer.

CASPortNumber

Non-clustered

Port number of the server on which CAS will be deployed.

CASHostNameLocal

Clustered

Host name of the server running the internally accessible CAS load balancer.

CASHostNameLocal

Non-clustered

Internal host name of the server on which CAS will be deployed.

CASPortNumberLocal

Clustered

Port number of the server running the internally accessible CAS load balancer.

CASPortNumberLocal

Non-clustered

Internal port number of the server on which CAS will be deployed.

CASHostNameActual

Clustered/Non-clustered

Hostname/IP address of the server on which CAS is deployed.

- If you are using FatWire Content Server Developer Tools or WebCenter Sites: Developer Tools before the upgrade, ensure that the Developer Tools plug-ins are updated to the latest versions provided with the WebCenter Sites installer.

- Ensure that Oracle WebCenter Sites: Sites Explorer is updated to the latest version, as it contains a number of changes.

2.3 Pre-Upgrade Decisions

- Whether to run the GUI installer or the silent installer
The GUI installer provides access to extensive online help to guide you through the upgrade process. The silent installer allows you to perform an automated upgrade based on the configuration information provided in the omii.ini file. For more information about these upgrade procedures, see Section 3.5.1, "Upgrading Graphically" and Section 3.5.2, "Upgrading Silently."

- What changes to make to single sign-on (SSO)
SSO is part of the WEM Framework. For SSO, you must provide Central Authentication Service (CAS) deployment information during the upgrade process.

Note:

If you are using OAM, WebCenter Sites is reset to using CAS during upgrade. You can restore OAM after the upgrade is complete.

The CAS deployment information required during upgrade depends on the deployment mode – automatic or manual – which is inherited from the Content Server 7.6 Patch 2 or WebCenter Sites 11gR1 (11.1.1.6.x ) installation.

How does the inherited deployment mode determine the CAS deployment process?

- If you are running the installer on the primary Content Server cluster member, deployment scenarios for installing or upgrading the WEM Framework are as follows:

- If automatic deployment is in effect, the installer will deploy WebCenter Sites and CAS on the same server. Once the automatic deployment process is complete, if you want to move CAS to a different server, you must manually redeploy CAS as part of the post-upgrade process.

- If the installer detects the deployment mode to be manual, you will deploy WebCenter Sites manually. You will also deploy CAS manually.

- If you are running the installer on the secondary CAS cluster members deployed, you will provide CAS deployment information for the secondary CAS cluster members. You will configure and deploy those members manually, as described in the chapter "Deploying the WebCenter Sites and CAS Web Applications" in the Oracle Fusion Middleware WebCenter Sites Installation Guide.

- How to determine your logging system

- If you are upgrading from Content Server 7.6 Patch 2, do you want to migrate from the existing logging system to Apache log4j? (Recommended)
If you want to migrate to Apache log4j, you must select the log4j migration option during the upgrade process. If you do not migrate to log4j during the upgrade process, you can switch to log4j at a later time, as described in the Oracle Fusion Middleware WebCenter Sites Administrator's Guide.

- If you are upgrading from WebCenter Sites 11gR1 (11.1.1.6.x ), do you have the option to select your logging system during the upgrade process?
If your current installation is using Apache log4j, then Apache log4j is automatically selected and installed during the upgrade process.

If your current installation is not using log4j, you can either migrate to log4j during the upgrade process, or you can continue using your current logging system and switch at a later time, as described in the Oracle Fusion Middleware WebCenter Sites Administrator's Guide.

2.4 Planning the Post-Upgrade Steps

Once WebCenter Sites 11gR1 (11.1.1.8.0) is upgraded, you will reapply customizations, and upgrade remote Satellite Server by re-installing Satellite Server. After you verify your upgraded installation, you will complete a set of steps that also involve developers and content contributors, depending on how they worked with their original installation. For additional information, see Section 3.7, "Post-Upgrade Steps" in Chapter 3, "Upgrading to the Current Version of WebCenter Sites."

3 Upgrading to the Current Version of WebCenter Sites

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:

- Section 3.1, "Notes About the Upgrade Process"

- Section 3.2, "Backing Up Your Active Environment"

- Section 3.3, "Creating the Test Environment"

- Section 3.4, "Preparing Your Environment for Upgrade"

- Section 3.5, "Upgrading Instances to WebCenter Sites 11gR1 (11.1.1.8.0)"

- Section 3.6, "Upgrading Remote Satellite Servers"

- Section 3.7, "Post-Upgrade Steps"

- Section 3.8, "Verifying the Upgraded Environment"

- Section 3.9, "Upgrading the Active Environment"

3.1 Notes About the Upgrade Process

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.

3.2 Backing Up Your Active Environment

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

1. 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

2. 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).

3. 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.

4. Take note of customized elements:

1. For each basic asset type, take note of any custom code in the elements (in the ElementCatalog table).

2. 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.

3. 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.

5. 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.

6. 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.

7. 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).

3.3 Creating the Test Environment

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.

1. 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

2. If your active environment is running remote Satellite Servers, duplicate at least one of them in the test environment.

3. Continue with the guidelines below to complete the test environment:
On Content Server or WebCenter Sites:

1. Copy Content Server or WebCenter Sites into the same location that it occupied on its previous host.

2. 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.

3. 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

satellite.properties (host)

<deploy_dir>/WEB-INF/classes

Optional

SampleSites.html

<deploy_dir>/Xcelerate

Optional

AssetSet.wsdl

AssetType.wsdl

Asset.wsdl

Miscellaneous.wsdl

SitePlan.wsdl

<deploy_dir>/Xcelerate/wsdl

4. Change the host name and IP address in the following property files (Table 3-2) located in the <cs_install_dir> directory:

Table 3-2 Property Files Located in <cs_install_dir>

Change Host Name and IP Address

Property File

Property

Required

futuretense.ini

databaseloader.ini

futuretense_xcel.ini

cs.eventhost

db1.loginurl

xcelerate.batchhost

5. 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

<cshome>/Bin/jbossTicketCacheReplicationConfig.xml

<cshome>/bin/cas.properties

<cshome>/Bin/host.properties

CS/WEB-INF/classes/SSOConfig.xml

CAS/WEB-INF/deployerConfigContext.xml

Search and replace values as required.

On an application server:

1. Install the application server using the same paths that were used on the previous host.

2. 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.)

3. Deploy the Content Server or WebCenter Sites application as required by your application server.

3.4 Preparing Your Environment for Upgrade

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 ).

3.4.1 Step 1: Upgrading the Supporting Components

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.

1. 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.

2. Verify that your installation is fully functional.

3.4.2 Step 2: Preparing Your Existing Instances

1. 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>;

2. 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:

1. Back up cs.war and ContentServer.ear from ominstall/app.

2. If WEM Framework is installed, back up cas.war and cas.ear from the ominstall/ directory.

3. 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.

4. Explode the backed up ContentServer.ear file into its own directory.

5. 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).

6. 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.

3. Back up all .ini files located in the <cs_install_dir> directory.

4. 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.

5. 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:

1. 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.

2. 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

6. 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.

7. 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.

1. 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.

2. 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.

3. 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.

8. 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:

1. 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

2. 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.

3. 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.

9. 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.

3.5 Upgrading Instances to WebCenter Sites 11gR1 (11.1.1.8.0)

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:

- Section 3.5.1, "Upgrading Graphically"

- Section 3.5.2, "Upgrading Silently"

3.5.1 Upgrading Graphically

1. 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.

2. 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.

3. Restart the WebCenter Sites and CAS applications.

4. Continue to Section 3.5.3, "Re-Running the Upgrade Utility."

3.5.2 Upgrading Silently

In this section you will complete the following steps:

- Section 3.5.2.1, "Configuring the omii.ini File"

- Section 3.5.2.2, "Running the Silent Installer"

3.5.2.1 Configuring the omii.ini File

1. 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.

2. 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

CSInstallAccountName

Provide the current user name for the ContentServer user.

The default value is ContentServer.

CSInstallAccountPassword

Provide the encrypted password for the ContentServer user.

To get the encrypted password, use the Content Server (or WebCenter Sites) Property Editor:

1. Open the futuretense.ini file in the Property Editor.

2. Search for the cs.mirrorpassword property. If it is populated, store its value temporarily in a text file.

3. Replace the cs.mirrorpassword property value with the password you wish to encrypt.

4. Save the property file to have your password encrypted.

5. Copy the encrypted password to the omii.ini file.

6. Restore the value of cs.mirrorpassword if it was populated.

SSUserPassword

Provide the encrypted password for the SatelliteServer user. To get the encrypted password, use the procedure described above for CSInstallAccountPassword.

3. 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.

4. 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.

Table 3-5 WEM Properties

Property

Description

WEM

Set this property to true to install or upgrade WEM Framework.

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 true.

If you are upgrading or installing WEM Framework on a secondary cluster member, set this property to false.

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.

3.5.2.1.1 Sample Configurations for Installing WEM Framework

1. 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>

2. 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>

3.5.2.1.2 Sample Configurations for Upgrading WEM Framework

1. 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>

2. 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>

3.5.2.2 Running the Silent Installer

1. 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.

2. Edit the install.ini file in the root of the extracted folder as follows:

1. Set the nodisplay property to true.

2. 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

3. Run the silent installer:

- Windows:       csInstall.bat -silent

- UNIX or Linux:  csInstall.sh -silent

4. 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.

5. Restart WebCenter Sites and CAS applications.

6. Continue to Section 3.5.3, "Re-Running the Upgrade Utility."

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.

1. 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

2. 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.

3.5.4 Completing the Upgrade

1. 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

advancedUI.enableAssetForms

futuretense_xcel.ini

cc.BlobServerTimeout

futuretense.ini

cc.BlobServerCacheCSz

futuretense.ini

cs.HTTP_HOST

futuretense.ini

com.fatwire.logging.cs.realtime

commons-logging.properties

xcelerate.timezoneattr

futuretense_xcel.ini

xcelerate.imageeditor.clarkii.basepath

futuretense_xcel.ini

2. If you upgraded from FatWire Content Server 7.6 Patch 2:

1. If you customized any portion of the FatWire Content Server Advanced administrative interface, re-apply the custom code.

2. 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>).

3. 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:

1. Add any custom loggers previously found in the commons_logging.properties file.

2. 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

4. Restart the application server.

5. Ensure that you can log in to WebCenter Sites as the general administrator.

6. 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.

7. 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.

8. For each basic asset type, re-register asset elements:

1. Log in to the content management site for which basic assets are enabled.

2. In the left-hand navigation tree, select the Admin tab.

3. Expand the Asset Types node.

4. Double-click Basic asset type.

5. In the right-hand pane, click Register Asset Elements.

6. On the confirmation screen, click Register Asset Elements.

7. For each basic asset type, re-apply the customizations to each element in the ElementCatalog table.

9. 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.

10. Assign the WEM Admin application to AdminSite.

11. 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.

12. Assemble any notes that you might have taken while completing the previous steps. You can use the notes when upgrading the active environment.

3.6 Upgrading Remote Satellite Servers

Note:

Repeat the following steps for each remote Satellite Server you have deployed.

1. Back up your remote Satellite Server, making sure to keep track of any customizations made, as they will all be lost.

2. Undeploy and delete the home directory of SatelliteServer.

3. Install remote Satellite Server (see the Oracle Fusion Middleware WebCenter Sites Installation Guide).

4. 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.

3.7 Post-Upgrade Steps

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.1, "If You Changed the JVM Time Zone"

- Section 3.7.2, "If Asset Type and Global Searches Were Configured"

- Section 3.7.3, "If SmartLists Were Created"

- 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"

3.7.1 If You Changed the JVM Time Zone

If you changed the JVM time zone, ensure that scheduled events and code are synchronized to the JVM time zone. Complete the following steps:

1. 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.

1. 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.

2. 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.

2. 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.

3.7.2 If Asset Type and Global Searches Were Configured

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.

3.7.3 If SmartLists Were Created

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.

3.7.4 If You Upgraded from FatWire Content Server

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.

3.7.5 If Your Developers Were Using Oracle WebCenter Sites: Developer Tools

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:

- Section 3.7.5.1, "Re-exporting Resources"

- Section 3.7.5.2, "Updating Developer Tools Plug-Ins"

3.7.5.1 Re-exporting Resources

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:

1. Back up all previously exported resources (such as sites, asset types, and assets).

2. Delete all resources from the existing workspace.

3. Re-export all the previously exported resources into the workspace.

4. If the resources are stored in a version control system, replace all previously exported resources with the re-exported resources.

3.7.5.2 Updating Developer Tools Plug-Ins

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.

3.7.6 If Developers Enable Mobility Device Groups for Pre-existing Sites

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.

3.7.7 If You Upgraded from a Customized WebCenter Sites 11gR1 (11.1.1.6.1) System

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.

3.7.8 If Your Installation Was Running with Community, Gadgets, or Site Capture

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."

3.7.9 If You Need to Integrate WebCenter Sites with Oracle Access Manager

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.

3.8 Verifying the Upgraded Environment

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.

1. Log in to WebCenter Sites as the general administrator.

2. 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.

3. 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:

1. Enable the publishing schedules.

2. Enable any events

3. Back up the upgraded environment.

4. Apply any tuning required by the new caching structure.

5. Clear Client Browser caches (as existing cached content may cause issues).

6. Resume work.

3.9 Upgrading the Active Environment

The following steps apply if you first upgraded your test environment:

1. Having verified the test environment, you will now upgrade the active environment:

1. 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.

2. Upgrade the active environment by following the previous steps in this chapter and any notes that you may have created during the trial upgrade.

2. Back up the upgraded environment.

3. Resume work.

Part II

Upgrading to Oracle WebCenter Sites: Community-Gadgets

This part contains the following chapters:

- Chapter 4, "About the Community and Gadgets Upgrade Process"

- Chapter 5, "Before You Upgrade to Community-Gadgets"

- Chapter 6, "Upgrading to Community-Gadgets"

4 About the Community and Gadgets Upgrade Process

Before upgrading to Oracle WebCenter Sites: Community-Gadgets, read this chapter for information about the upgrade path, new features provided in the current release, and the type of changes that will be made to your starting installation during the upgrade process.

This chapter contains the following sections:

- Section 4.1, "Upgrade Path"

- Section 4.2, "New in This Release"

- Section 4.3, "Changes Made During Upgrade"

4.1 Upgrade Path

In this release, you will be upgrading your Community and Gadgets applications to Community-Gadgets. The following installations can be upgraded directly to Community-Gadgets 11gR1 (11.1.1.8.0):

Note:

If you do not upgrade your Oracle WebCenter Sites installation to 11gR1 (11.1.1.8.0), do not upgrade the Community and Gadgets applications. Community-Gadgets is supported only on WebCenter Sites 11gR1 (11.1.1.8.0).

- Oracle WebCenter Sites: Community 11gR1 (11.1.1.6.x), which includes the following versions:

- Oracle WebCenter Sites: Community 11gR1 (11.1.1.6.0) running on FatWire Content Server 7.6 Patch 2.

- Oracle WebCenter Sites: Community 11gR1 (11.1.1.6.0) Patch 1 running on Oracle WebCenter Sites 11gR1 (11.1.1.6.0).

- Oracle WebCenter Sites: Community 11gR1 (11.1.1.6.1) Bundled Patch 1 running on Oracle WebCenter Sites 11gR1 (11.1.1.6.1) Bundled Patch 1.

- Oracle WebCenter Sites: Gadgets 11gR1 (11.1.1.6.x), which includes the following versions:

- Oracle WebCenter Site: Gadgets 11gR1 (11.1.1.6.0) running on FatWire Content Server 7.6 Patch 2.

- Oracle WebCenter Sites: Gadgets 11gR1 (11.1.1.6.0) Patch 1 running on Oracle WebCenter Sites 11gR1 (11.1.1.6.0).

- Oracle WebCenter Sites: Gadgets 11gR1 (11.1.1.6.1) Bundled Patch 1 running on Oracle WebCenter Sites 11gR1 (11.1.1.6.1) Bundled Patch 1.

4.2 New in This Release

Upgrading to Community-Gadgets combines the Community and Gadgets applications into one product and delivers them as the Community-Gadgets 11gR1 (11.1.1.8.0) web application. Although Community-Gadgets is installed as a single product, it provides two separate Web Experience Management (WEM) applications on the Management side – the Community WEM application and the Gadgets WEM application. On the Production side, Community-Gadgets is installed as a single application.

The merging of these two products helps to avoid maintaining separate applications for the Gadgets application, which provided kernel functionality that was consumed by both Community 11gR1 (11.1.1.6.x) and Gadgets 11gR1 (11.1.1.6.x).

4.3 Changes Made During Upgrade

Upgrading the Community 11gR1 (11.1.1.6.x) and Gadgets 11gR1 (11.1.1.6.x) applications to Community-Gadgets results in a number of changes to the following functionality in the installation:

- Section 4.3.1, "Roles"

- Section 4.3.2, "Application Deployment"

- Section 4.3.3, "Application Registration in WEM"

- Section 4.3.4, "Changes to the Gadgets Application"

- Section 4.3.5, "Changes to Database Structure"

4.3.1 Roles

The following changes are made to the Community and Gadgets roles during the upgrade process to Community-Gadgets:

- The GeneralAdmin role is added because it is required by the Gadgets application for a user to work with the Global Gadget Catalog interface. This role is the same as the SiteAdmin role for the Community application, and has the same set of permissions in both applications.

- The menu bar in the Gadgets User interface now contains the Login Bar menu which is displayed to users assigned one of the following roles: GeneralAdmin, SiteAdmin, or Designer.

- The default page for the Designer role is changed from "All Comments" to "All Polls."

Figure 4-1 identifies the roles that have permissions to Community interface functions. Figure 4-2 identifies the roles that have permissions to the Gadgets interfaces.

Figure 4-1 Roles and permissions in the Community interface

Figure 4-2 Roles and permissions in the Gadgets interfaces

4.3.2 Application Deployment

Community-Gadgets contains a changed set of web applications that need to be deployed on the server to provide the full functionality of the product.

- Management Community-Gadgets contains two web applications:

- cg – Community-Gadgets web application.

- shindig – Shindig web application that contains the functionality for rendering gadgets.

- Production Community-Gadgets contains three web applications:

- cg – Community-Gadgets web application.

- shindig – Shindig web application that contains the functionality for rendering gadgets.

- cas – CAS web application needed for visitor authentication.

Note:

The CAS application is needed only on the production side as it is the visitor authentication module. For the management side, the WebCenter Sites CAS or OAM authentication module is used.

4.3.3 Application Registration in WEM

The Community and Gadgets applications are registered automatically with WebCenter Sites on Community-Gadgets server startup.

Note:

If an application with the same name is already registered with WebCenter Sites, the upgraded applications will not be created. For more information, see Section 6.2.2, "Step 2: Upgrading WebCenter Sites and Deleting the Community and Gadgets Applications" and the Oracle Fusion Middleware WebCenter Sites Installation Guide.

After the applications are successfully created, the administrator assigns them to the desired sites. This functionality supports single mode and clustering; first node you start will be responsible for the creation of the applications.

4.3.4 Changes to the Gadgets Application

As part of Community-Gadgets, the Gadgets WEM application inherits part of the functionality of the Community WEM application. In this release, the Gadgets WEM application has proxy support and a Shindig module on both the management and production sides.

In this release, administrators can configure the Community-Gadgets (cg) and Shindig modules separately, using the setup_proxy.properties configuration file for each application. In this configuration file, the administrator can set a different proxy server for each type of connection.

Note:

For more information, see the Oracle Fusion Middleware WebCenter Sites Developer's Guide.

4.3.5 Changes to Database Structure

This section contains information about the changes that are made to the database during the upgrade process.

- Section 4.3.5.1, "Changes from Community 11gR1 (11.1.1.6.x)"

- Section 4.3.5.2, "Changes from Gadgets 11gR1 (11.1.1.6.x)"

Note:

For more information about the full structure of the database, see the Oracle Fusion Middleware WebCenter Sites Developer's Guide.

4.3.5.1 Changes from Community 11gR1 (11.1.1.6.x)

The following tables are changed by the upgrade process, as described below:

- USER table:

- cos_hidden column is removed.

- cos_us_date_created column is removed.

- cos_us_date_modified column is removed.

- COMMENT_FEED table:

- cos_posting_status column is added.

- USER_ID table:

- cos_password column encryption type changed from blowfish to SHA-256.

- cos_encryption_type column content was changed from blowfish to SHA-256.

- REVIEW_FEED table

- cos_posting_status column is added.

4.3.5.2 Changes from Gadgets 11gR1 (11.1.1.6.x)

The following tables are changed by the upgrade process, as described below:

- US_ID table:

- Table is renamed to USER_ID.

- extsitename column is removed.

- cos_ prefix is added to all columns.

- US_ACCOUNT_LINK table:

- Table renamed to USER_LINK.

- extsitename column is removed.

- cos_ prefix is added to all columns.

- US_ACCOUNT table:

- Table renamed to USER.

- extsitename column is removed.

- packed_personas column is removed.

- BLOB table:

- extsitename column is removed.

- GADGETSET table:

- extsitename column is removed.

- GADGET table:

- local_oauth column is removed.

- consumer_key column is removed.

- consumer_secret column is removed.

- consumer_signature_method column is removed.

- extsitename column is renamed to site_id.

- gadgetset_extid column is renamed to gadgetset_id.

- OS_DESCRIPROR table:

- extsitename column is removed.

- opensocial_descriptor column is removed.

- SINGLE_GADGET_DATA table:

- extsitename column is renamed to site_id.

- SITE table:

- extsitename column is removed.

- ST_SCHEMA table:

- Table is completely transformed to table ST_LOCATOR.

- ST_VALUE table:

- cos_typeid column is removed.

- cos_schemaid column is removed.

- cos_siteid column is removed.

- cos_itemid column is removed.

- cos_text column is added.

- cos_value column is renamed to cos_varchar.

- extsitename column is renamed to cos_siteid.

Note:

In this release, the Community and Gadgets applications use the same database tables to store data. For more information about the database schema for Community-Gadgets, see the Oracle Fusion Middleware WebCenter Sites Developer's Guide.

5 Before You Upgrade to Community-Gadgets

Before upgrading to Oracle WebCenter Sites: Community-Gadgets, read this chapter to gain an understanding of the upgrade strategy and the prerequisite steps.

This chapter contains the following sections:

- Section 5.1, "Planning the Upgrade Process"

- Section 5.2, "Pre-Upgrade Steps"

5.1 Planning the Upgrade Process

In a production environment, upgrades disrupt the operation of active systems and may result in extended downtime. To minimize such disruptions, Oracle highly recommends adopting the strategy outlined in this section when upgrading.

Note:

This guide uses the term "active" to denote any management and production servers that are currently serving widgets and whose unexpected downtime will affect business and productivity of the organization.

Before upgrading active Community and Gadgets environments, it is critical to perform a trial upgrade on a duplicate environment. The trial upgrade will help you detect and document system-specific issues and correct them in advance of the actual upgrade. If a duplicate environment is not available, start by upgrading the management and delivery (production) systems. Note that this approach is highly risky; it should not be attempted unless extended downtime is deemed acceptable.

5.2 Pre-Upgrade Steps

Before upgrading to Community-Gadgets, stop all application servers and back up your Community 11gR1 (11.1.1.6.x), Gadgets 11gR1 (11.1.1.6.x), and WebCenter Sites 11gR1 (11.1.1.6.x) environments, as follows:

Note:

If you do not upgrade your Oracle WebCenter Sites installation to 11gR1 (11.1.1.8.0), do not upgrade the Community and Gadgets applications. Community-Gadgets is supported only on WebCenter Sites 11gR1 (11.1.1.8.0).

- Back up your current Community management and production cos.war or cos.ear files, and cas.war or cas.ear files.

- Back up your current Gadgets management and production gas-admin.war, gas-os.war, gas-service.war, gas-client.war, and user-service.war files.

- Back up the Community installation directory, the Gadgets installation directory, and the WebCenter Sites database (if it is not already backed up). In the post-upgrade process, you will use the backed-up installation directories and database to reapply the customizations they may contain.

6 Upgrading to Community-Gadgets

This chapter contains instructions for upgrading Oracle WebCenter Sites: Community 11gR1 (11.1.1.6.x) and Oracle WebCenter Sites: Gadgets 11gR1 (11.1.1.6.x) to Oracle WebCenter Sites: Community-Gadgets, which provides the Community and Gadgets WEM applications.

This chapter contains the following sections:

- Section 6.1, "Summary of Steps for the Community-Gadgets Upgrade Process"

- Section 6.2, "Upgrading Community and Gadgets to Community-Gadgets"

- Section 6.3, "Post-Upgrade Steps"

- Section 6.4, "Implementing Security"

6.1 Summary of Steps for the Community-Gadgets Upgrade Process

This section provides a summary of the steps for upgrading to Community-Gadgets:

1. Export data from the Community 11gR1 (11.1.1.6.x) and Gadgets 11gR1 (11.1.1.6.x) applications to a specified location.

Note:

Ensure that WebCenter Sites is running during the export process.

2. Upgrade WebCenter Sites 11gR1 (11.1.1.6.x) to version 11gR1 (11.1.1.8.0), and then delete the FW_View and FW_Application assets specific to Community 11gR1 (11.1.1.6.x) and Gadgets 11gR1 (11.1.1.6.x).

3. Install and verify the Community-Gadgets web application. For instructions, see the Oracle Fusion Middleware WebCenter Sites Installation Guide.

4. Import the Community and Gadgets data to Community-Gadgets and then verify the imported data.

Note:

For better performance, run the migration tool on the production WebCenter Sites instance to reduce the time for the import process.

5. Manually merge all templates and client-side tags from Community 11gR1 (11.1.1.6.x) and Gadgets 11gR1 (11.1.1.6.x) with the new functionality supported by Community-Gadgets.

6.2 Upgrading Community and Gadgets to Community-Gadgets

The steps in this section provide instructions for upgrading to Community-Gadgets:

- Section 6.2.1, "Step 1: Exporting Community and Gadgets Data"

- Section 6.2.2, "Step 2: Upgrading WebCenter Sites and Deleting the Community and Gadgets Applications"

- Section 6.2.3, "Step 3: Install and Verify the Community-Gadgets Web Application"

- Section 6.2.4, "Step 4: Importing Community and Gadgets Data to Community-Gadgets"

- Section 6.2.5, "Step 5: Clearing the Community-Gadgets Application Server Cache"

- Section 6.2.6, "Step 6: Migrating Templates, Custom Skins, and Client-Side Deployment Tags"

- Section 6.2.7, "Step 7: Integrating with Oracle Access Manager (OAM)"

6.2.1 Step 1: Exporting Community and Gadgets Data

In this section you will first export data from Community 11gR1 (11.1.1.6.x), and then export data from Gadgets 11gR1 (11.1.1.6.x) to the location specified in the <config>.properties file. To do so, you will run the export (migration) tool on the production (delivery) system where WebCenter Sites is installed.

This section contains the following topics:

- Section 6.2.1.1, "Exporting Community Data"

- Section 6.2.1.2, "Exporting Gadgets Data"

6.2.1.1 Exporting Community Data

1. Prepare to export the data from Community 11gR1 (11.1.1.6.x):

1. In the WCS_CommunityGadgets_MigrationTools.zip archive, extract Community_11.1.1.6_MigrationTool into a temporary directory.

2. Go to the Community_11.1.1.6_MigrationTool directory (created in step a) and execute run.bat for Windows (run.sh for Linux), as shown in Figure 6-1.
On the first run of the migration tool, a new configuration file (<config>.properties) is generated in the specified directory (by default, it is the folder containing the run.bat/run.sh file used to start the migration tool).

Figure 6-1 Migration Tool Running in Command Line

3. Open the generated <config>.properties file and specify the following properties:

- folder: Folder where all files and logs containing data from the database will be stored.

- sitesToProcess: Comma-separated list of sites that need to be migrated.

- processAdminSite: If the AdminSite needs to be processed, set this property to true.

- adminSiteName: Name of the content management site used for storing visitor data in the production database. The default value is AdminSite.

- casUrl: WebCenter Sites Production CAS URL.

- restUrl: WebCenter Sites Production REST URL.

- username: SiteAdmin user name.

- password: SiteAdmin user password.

- importNamespace: During the export process, this property is ignored.

- exportNamespace: Community namespace for export.

Note:

The value of the export property specifies whether Community data will be exported. The value of the cleanExportNamespace property specifies whether the database tables in the namespace specified in the exportNamespace property will be deleted after the export process has completed.

The way in which you set values for the export and cleanExportNamespace properties determines how Community data will be exported (if at all). You can set these properties in one of the following ways:

- To export Community data only: Set export to true and cleanExportNamespace to false.
The Community data will be exported, but the database tables in the namespace specified in the exportNamespace property are not deleted.

- To export Community data and delete the database tables in the namespace specified in the exportNamespace property: Set export to true and cleanExportNamespace to true.

- To delete the database tables in the namespace specified in the exportNamespace property only: Set export to false and cleanExportNamespace to true.
The data will not be exported, however, the database tables in the namespace specified in the cleanExportNamespace property are deleted.

- export: See the above note for information about setting this property.

- cleanExportNamespace: See the above note for information about setting this property.

4. Save the file and continue with the export process.

2. Start the export process by pressing Enter (Figure 6-2).

Figure 6-2 Export Process Started

3. Verify the results of the export process:

1. Verify that no errors have occurred by viewing the log file created in the folder specified in the configuration file.

2. Verify that the following sub-folders are in the folder that contains the configuration file:

- Sub-folder for each site specified in the configuration file.

- Log file.

- BlobStorage folder containing all blobs.

4. Continue to Section 6.2.1.2, "Exporting Gadgets Data."

6.2.1.2 Exporting Gadgets Data

1. Prepare to export the data from Gadgets 11gR1 (11.1.1.6.x):

1. In the WCS_CommunityGadgets_MigrationTools.zip archive, extract Gadgets_11.1.1.6_MigrationTool into a temporary directory.

2. Go to the Gadgets_11.1.1.6_MigrationTool directory (created in step a) and copy the following .jar files from the additional folder to the libs folder. The .jar files you need to move are determined by your current version of Gadgets, described in Table 6-1.

Note:

The libs folder must not contain both versions of the .jar files at the same time.

Table 6-1 Gadgets .jar files

Gadgets Version

Files to Copy

Gadgets 11gR1 (11.1.1.6.0)

- gas-core-11.1.1.6.0.jar

- cos-core-11.1.1.6.0-gas.jar

Gadgets 11gR1 (11.1.1.6.0) Bundled Patch 1

- gas-core-11.1.1.6.1.jar

- cos-core-11.1.1.6.1-gas.jar

Gadgets 11gR1 (11.1.1.6.1)

- gas-core-11.1.1.6.1.jar

- cos-core-11.1.1.6.1-gas.jar

3. In the Gadgets_11.1.1.6_MigrationTool directory, execute run.bat for Windows (run.sh for Linux).
On the first run of the migration tool, a new configuration file (<config>.properties) is generated in the selected directory (by default, it is the folder containing the run.bat/run.sh file used to start the migration tool).

4. In the Export Tool, specify your current version of Gadgets (the version from which you are exporting data), as shown in Figure 6-3.

Figure 6-3 Gadgets Version

5. Open the configuration file (<config>.properties) and specify the following properties:

- folder: Folder where all files and logs containing data from the database will be stored.

- sitesToProcess: Comma-separated list of sites that need to be migrated.

- processAdminSite: If the AdminSite needs to be processed, set this property to true.

- adminSiteName: Name of the content management site used for storing visitor data in the database. The default value is AdminSite.

- casUrl: WebCenter Sites Production CAS URL.

- restUrl: WebCenter Sites Production REST URL.

- username: SiteAdmin user name.

- password: SiteAdmin user password.

- importNamespace: Gadgets namespace for import. During the export process, this property is ignored.

- exportNamespace: Gadgets namespace for export.

Note:

The value of the export property specifies whether Gadgets data will be exported. The value of the cleanExportNamespace property specifies whether the database tables in the namespace specified in the exportNamespace property will be deleted after the export process has completed.

The way in which you set values for the export and cleanExportNamespace properties determines how Gadgets data will be exported (if at all). You can set these properties in one of the following ways:

- To export Gadgets data only: Set export to true and cleanExportNamespace to false.
The Gadgets data will be exported, but the database tables in the namespace specified in the exportNamespace property are not deleted.

- To export Gadgets data and delete the database tables in the namespace specified in the exportNamespace property: Set export to true and cleanExportNamespace to true.

- To delete the database tables in the namespace specified in the exportNamespace property only: Set export to false and cleanExportNamespace to true.
The data will not be exported, however, the database tables in the namespace specified in the cleanExportNamespace property are deleted.

- export: See the above note for information about setting this property.

- cleanExportNamespace: See the above note for information about setting this property.

6. Save the file and continue with the export process.

2. Start the export process by pressing Enter.

The export process starts.

3. Verify the results of the export process:

1. Verify that no errors have occurred by viewing the log file created in the folder specified in the configuration file.

2. Verify that the following sub-folders are in the folder that contains the configuration file:

- Sub-folder for each site specified in the configuration file.

- Log file.

- BlobStorage folder containing all blobs.

6.2.2 Step 2: Upgrading WebCenter Sites and Deleting the Community and Gadgets Applications

After you have successfully exported all Community 11gR1 (11.1.1.6.x) and Gadgets 11gR1 (11.1.1.6.x) data, complete the steps outlined below:

1. Upgrade your current version of WebCenter Sites to WebCenter Sites 11gR1 (11.1.1.8.0). For instruction on upgrading to WebCenter Sites 11gR1 (11.1.1.8.0), see Part I, "Upgrading to Oracle WebCenter Sites 11gR1 (11.1.1.8.0)."

2. Delete the FW_Application and FW_View assets for Community 11gR1 (11.1.1.6.x) and Gadgets 11gR1 (11.1.1.6.x). This enables the upgraded Community and Gadgets applications to be registered automatically to WebCenter Sites. For more information about FW_Application and FW_View assets, see the Oracle Fusion Middleware WebCenter Sites Developer's Guide.

6.2.3 Step 3: Install and Verify the Community-Gadgets Web Application

The basic steps for installing and verifying the Community-Gadgets web application are as follows:

1. Install the Community-Gadgets web application. For instructions, see the Oracle Fusion Middleware WebCenter Sites Installation Guide.

2. Verify that the Community and Gadgets WEM applications have been installed successfully:

1. Start the Community and Gadgets WEM applications (provided by Community-Gadgets).

2. Test the Community and Gadgets interfaces:

- To test the Community interface, log in to WebCenter Sites as an administrator, select the site on which the Community application is enabled, and then select the Community icon. (The Community application initializes all the necessary data on the first run). Repeat this step for all sites on which the Community interface is enabled.

- To test the Global Gadget Catalog interface, log in to WebCenter Sites as a general administrator, select the site on which the Global Gadget Catalog interface is enabled (AdminSite by default), and then select the Gadgets icon. Ensure that you see the "Global Catalog." (The Gadgets application initializes all the necessary data on the first run).

- To test the Gadgets User interface, log in to WebCenter Sites as an administrator, select the site on which the Gadgets User interface is enabled, and then select the Gadgets icon. (The Gadgets application initializes all the necessary data on the first run). Repeat this step for all sites on which the Gadgets User interface is enabled.

For detailed instructions, see the Oracle Fusion Middleware WebCenter Sites Installation Guide.

6.2.4 Step 4: Importing Community and Gadgets Data to Community-Gadgets

In this section, you will first import the data from Community 11gR1 (11.1.1.6.x), and then import the data from Gadgets 11gR1 (11.1.1.6.x) into Community-Gadgtes. To do so, you will run the import (migration) tools on the production (delivery) system where WebCenter Sites is installed.

Note:

For the import process to be successful, you must first import Community data and then import Gadgets data.

This section contains instructions for the following steps:

- Section 6.2.4.1, "Importing Community Data to Community-Gadgets"

- Section 6.2.4.2, "Importing Gadgets Data to Community-Gadgets"

6.2.4.1 Importing Community Data to Community-Gadgets

1. Prepare to import the data from Community 11gR1 (11.1.1.6.x) into Community-Gadgets:

1. In the WCS_CommunityGadgets_MigrationTools.zip archive, extract CG_11.1.1.8_MigrationTool into a temporary directory.

2. Go to the CG_11.1.1.8_MigrationTool directory and execute run.bat for Windows (run.sh for Linux).

3. Open the generated configuration file (config.properties) and specify the following properties:

- folder: The folder that contains all the exported data from the database (created in step 2 of Section 6.2.1.1).

- sitesToProcess: Comma-separated list of sites that need to be migrated.

- processAdminSite: If the AdminSite needs to be processed, set this property to true.

- adminSiteName: Name of the content management site used for storing visitor data in the production database. The default value is AdminSite.

- casUrl: WebCenter Sites Production CAS URL.

- restUrl: WebCenter Sites Production REST URL.

- username: SiteAdmin user name.

- password: SiteAdmin user password.

- importNamespace: Community namespace for import.

- exportNamespace: During the import process, this property is ignored.

- export: During the import process, this property is ignored.

- cleanExportNamespace: During the import process, this property is ignored.

4. Save the file and continue with the upgrade process.

2. Start the import process by selecting the Import task in the migration tool (Figure 6-4).

Figure 6-4 Import Process Started

The import process starts.

3. When the import process has completed, verify that no errors have occurred by reviewing the log file that was created in the folder specified in the configuration file.

4. Continue to Section 6.2.4.2, "Importing Gadgets Data to Community-Gadgets."

6.2.4.2 Importing Gadgets Data to Community-Gadgets

1. Prepare to import data into Community-Gadgets.

1. In the WCS_CommunityGadgets_MigrationTool.zip archive, extract CG_11.1.1.8_MigrationTool into a temporary directory.

2. Go to the CG_11.1.1.8_MigrationTool directory and execute run.bat for Windows (run.sh for Linux).

3. Open the generated configuration file and specify the following properties:

- folder: The folder that contains all the exported data from the database (created in step 2 of Section 6.2.1.2).

- sitesToProcess: Comma-separated list of sites that need to be migrated.

- processAdminSite: If the AdminSite needs to be processed, set the value of this property to true.

- adminSiteName: Name of the content management site used for storing visitor data in the database. The default value is AdminSite.

- casUrl: WebCenter Sites Production CAS URL.

- restUrl: WebCenter Sites Production REST URL.

- username: SiteAdmin user name.

- password: SiteAdmin user password.

- importNamespace: Gadgets namespace for import.

- exportNamespace: During the import process, this property is ignored.

- export: During the import process, this property is ignored.

- cleanExportNamespace: During the import process, this property is ignored.

4. Save the file and continue with the upgrade process.

2. Start the import process by selecting the import task in the migration tool.
The import process starts.

3. When the import process has completed, verify that no errors have occurred by reviewing the log file that was created in the folder specified in the configuration file.

4. Continue to Section 6.2.5, "Step 5: Clearing the Community-Gadgets Application Server Cache."

6.2.5 Step 5: Clearing the Community-Gadgets Application Server Cache

After the import process, clear the management and production caches for the Community-Gadgets application servers. Then, restart the Community-Gadgets application servers.

6.2.6 Step 6: Migrating Templates, Custom Skins, and Client-Side Deployment Tags

The migration tool migrates all custom skins that were uploaded to the Community interface and the Gadgets User interface (in the "Appearance" screen for the comments widgets, reviews widgets, and gadgets) and stored in the WebCenter Sites database. However, Community-Gadgets supports new functionality that must be manually merged with the custom skins that were migrated from 11gR1 (11.1.1.6.x).

This section provides basic steps for manually merging the new functionality provided by Community-Gadgets with the custom skin files, templates, and client-side tags that were migrated from 11gR1 (11.1.1.6.x):

1. Merge all custom skins for the comments widgets, reviews widgets, and gadgets that are stored in the WebCenter Sites database with the new skins (CSS files) provided by Community-Gadgets.

2. Merge all custom widget templates (SHTML files) and skins (CSS files) that were stored on the file system with a default template or skin provided by Community-Gadgets. This enables the custom skin to support the new functionality provided by Community-Gadgets.

Note:

If you wish to use the default templates provided by Community-Gadgets instead of your custom templates, change the widgets.developing.attrs.template_prefix property in the setup_cos.properties file to a value that is different from the prefix under which the custom templates are store. By default, the prefix uses cos.

3. All widget deployment tags from Community 11gR1 (11.1.1.6.x) are supported by Community-Gadgets. Therefore, community widgets do not need to be re-deployed. However, keep in mind that the Community-Gadgets web application root (cos by default), host name, and port number must be the same as they were for Community 11gR1 (11.1.1.6.x). In other cases, those values must be changed manually so widgets deployed on a page can connect to Community-Gadgets.
For example:

<div id="comments_container"></div>
<script type="text/javascript">
...
script.src = 'http://localhost:80/cg/wsdk/widget/'
+ cos.pageScripts.join(':') + '.js?site_
id=FirstSiteII';
...
</script>

If you wish to re-use the deployment tags from Community 11gR1 (11.1.1.6.x) in the upgraded Community application, use the same context root for Community-Gadgets as was used for Community 11gR1 (11.1.1.6.x).

Note:

In Community-Gadgets, the view of the Top Ranked Reviews widget has changed. The Top Ranked Reviews widget lists and provides links to the highest rated topics on the website.

In Community 11gR1 (11.1.1.6.x), the average rating of each topic included in this list is displayed next to the topic as numbers. In Community-Gadgets, the average rating of each topic included in the list is displayed next to the topic as either a "Stars" rating or a "Thumbs Up/Down" rating. For more information about the Top Ranked Reviews widget, see the Oracle Fusion Middleware WebCenter Sites User's Guide.

4. All gadgets registered to the Global Gadget Catalog and site gadget catalogs in Gadgets 11gR1 (11.1.1.6.x) are automatically registered to the Global Gadget Catalog and the appropriate site gadget catalogs in Community-Gadgets. However, you must manually re-deploy each gadget for it to be rendered on the website after the upgrade process has completed successfully.

Note:

OAuth is not supported in Community-Gadgets. If you deployed gadgets with OAuth support on your website, the message "Unsupported feature: [oauthpopup]" will be displayed in place of the gadget.

6.2.7 Step 7: Integrating with Oracle Access Manager (OAM)

If the management WebCenter Sites is integrated with Oracle Access Manager (OAM), Community-Gadgets must be enabled to communicate with that WebCenter Sites through its OAM. For information about enabling communications with OAM-integrated WebCenter Sites, see Oracle Fusion Middleware WebCenter Sites: Installing and Configuring Supporting Software.

6.3 Post-Upgrade Steps

This section contains information about the steps you need to take after successfully migrating all Community and Gadgets 11gR1 (11.1.1.6.x) data to Community-Gadgets.

This section contains information about the following topics:

- Section 6.3.1, "If You Were Running WebCenter Sites with the Community Blogs Module"

- Section 6.3.2, "Integrating Community-Gadgets with the Contributor Interface"

- Section 6.3.3, "Integrating with Oracle Social Access Services"

6.3.1 If You Were Running WebCenter Sites with the Community Blogs Module

If you upgraded WebCenter Sites 11gR1 (11.1.1.6.x) and it was running with the Community Blogs module, there will be two duplicate GetRecentBlogs Page assets in the WebCenter Sites Contributor interface. One GetRecentBlogs Page asset has a unique identifier of 1270137813575 and the other Page asset has a unique identifier of 112844596316. Delete the Page asset with the ID of 112844596316.

In addition, if your developers were using the default blog templates prior to the upgrade to Community-Gadgets, change the resource IDs of those blog templates to make each template unique. For information about the default blog templates, see the Oracle Fusion Middleware WebCenter Sites Developer's Guide.

6.3.2 Integrating Community-Gadgets with the Contributor Interface

Integrating Community-Gadgets with WebCenter Sites creates a Community-Gadgets tree in the Contributor interface (see Figure 6-5). Users can then access and deploy widgets and gadgets directly from the Contributor interface.

Figure 6-5 'Community-Gadgets' tree in Contributor interface

For information about integrating Community-Gadgets with WebCenter Sites, see the Oracle Fusion Middleware WebCenter Sites Installation Guide. For more information about using the Community-Gadgets tree, see the Oracle Fusion Middleware WebCenter Sites User's Guide.

6.3.3 Integrating with Oracle Social Access Services

The production Community-Gadgets application can be integrated with external identity providers, which enables website visitors to log in through the following social networks: Facebook, Twitter, LinkedIn, Google, and Yahoo.

Social Access Services become available when the production Community-Gadgets is integrated with Oracle Mobile and Social Access Services (the mobile component is not used). For more information about Social Access Services, see the Oracle Fusion Middleware WebCenter Sites Developer's Guide.

6.4 Implementing Security

In Community-Gadgets, security settings are shared with WebCenter Sites and can be customized in the SitesSecurityContext.xml file.

Note:

If the SitesSecurityContext.xml file, is customized for one instance of WebCenter Sites, the same changes must be made on all other instances of WebCenter Sites.

For more information about security, see the Oracle Fusion Middleware WebCenter Sites Administrator's Guide.

Part III

Upgrading Oracle WebCenter Sites: Site Capture

This part is written for experienced installation engineers. Before upgrading, read the rest of this part to familiarize yourself with the upgrade strategy and prerequisites, upgrade procedures, changes that will be made by the installer, and the post-upgrade steps.

This part contains the following chapters:

- Chapter 7, "Before You Upgrade Site Capture"

- Chapter 8, "Upgrading Site Capture"

- Chapter 9, "Reference: Site Capture Backup and Recovery"

7 Before You Upgrade Site Capture

This chapter includes the following sections:

- Section 7.1, "Upgrade Paths"

- Section 7.2, "Planning the Upgrade Process"

- Section 7.3, "Pre-Upgrade Steps"

7.1 Upgrade Paths

The following Site Capture installations can be upgraded directly to version 11g R1 (11.1.1.8.0):

- FatWire Site Capture 1.1

- Oracle WebCenter Sites: Site Capture 11g R1 (11.1.1.6.0)

- Oracle WebCenter Sites: Site Capture 11g R1 (11.1.1.6.1) Bundled Patch 1

Note:

If your WebCenter Sites installation will not be upgraded to 11g R1 (11.1.1.8.0), do not upgrade the Site Capture application. The upgraded version runs on WebCenter Sites 11g R1 (11.1.1.8.0).

Providing upgrade feature inside the Site Capture installer enables:

- Adding new features and bug fixes to your existing Site Capture installation

- Ensuring integrity of data in your existing Site Capture installation

- Ensuring the generation of an application war file with all new features in your existing Site Capture installation directory

7.2 Planning the Upgrade Process

Upgrades disrupt the operation of active systems and may result in extended downtime. To minimize such disruptions, Oracle highly recommends adopting the strategy outlined in this section, when upgrading to Site Capture 11g R1 (11.1.1.8.0).

Note:

The term "active" is used to denote any system that is currently running Site Capture and whose unexpected downtime will affect business and productivity of the organization.

Site Capture runs on its own database and interacts with WebCenter Sites through the Web Experience Management (WEM) framework. Before upgrading an active Site Capture environment, it is critical to perform a trial upgrade on a duplicate environment. The trial upgrade will help you detect and document system-specific issues and correct them in advance of the actual upgrade.

If a duplicate environment is not available, then start by upgrading your active Site Capture 1.1 or Site Capture 11g R1 (11.1.1.6.x) environment. Note that this approach is highly risky; it should not be attempted unless extended downtime is deemed acceptable.

7.3 Pre-Upgrade Steps

Before upgrading, complete the following steps:

- Read the rest of this guide to familiarize yourself with the upgrade prerequisites and procedures.

- Read the following documentation, available at http://docs.oracle.com:

- WebCenter Sites Certification Matrix

- WebCenter Sites Release Notes

- Upgrade your Content Server 7.6 Patch 2 or WebCenter Sites 11gR1 (11.1.1.6.x ) environment to WebCenter Sites 11g R1 (11.1.1.8.0). For instructions, see Part I, "Upgrading to Oracle WebCenter Sites 11gR1 (11.1.1.8.0)."
After successfully upgrading to WebCenter Sites 11g R1 (11.1.1.8.0), you will upgrade Site Capture 1.1 or Site Capture 11g R1 to version 11g R1 (11.1.1.8.0) by running the Site Capture 11g R1 (11.1.1.8.0) installer on all Site Capture systems in your environment.

The Site Capture 11g R1 (11.1.1.8.0) installer detects and reuses the mode (single or cluster) that was selected during the Site Capture 1.1 or Site Capture 11g R1 (11.1.1.6.x) installation process. For example, if Site Capture 1.1 was installed in cluster mode and deployed, the Site Capture 11g R1 (11.1.1.8.0) installer continues to treat the system as a cluster and deploys it.

Note:

The mode of a Site Capture system (single or cluster) cannot be changed during upgrade.

- If your current Site Capture application was modified since it was first deployed (most likely it was), back up your current Site Capture application by backing up the installation directory and database. For detailed instructions, see Chapter 9, "Reference: Site Capture Backup and Recovery."

Note:

In the post-upgrade process, you will use the backed-up installation directory and database to reapply the customizations they may contain.

8 Upgrading Site Capture

This chapter contains instructions for upgrading a Site Capture 1.1 or Site Capture 11gR1 (11.1.1.6.x) test environment to Site Capture 11gR1 (11.1.1.8.0), verifying the test environment, and then upgrading the active environment.

This chapter contains the following sections:

- Section 8.1, "Upgrading the Test Environment"

- Section 8.2, "Upgrading the Active Environment"

- Section 8.3, "Upgrading Custom Implementations and Integrating with the Publishing System"

8.1 Upgrading the Test Environment

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.

This section contains the following topics:

- Section 8.1.1, "Backing Up Your FatWire Site Capture 1.1 or WebCenter Sites: Site Capture 11gR1 (11.1.1.6.x) Environment"

- Section 8.1.2, "Creating the Test Environment"

- Section 8.1.3, "Upgrading Site Capture Instances to Version 11gR1 (11.1.1.8.0)"

- Section 8.1.4, "Verifying the Upgraded Environment"

8.1.1 Backing Up Your FatWire Site Capture 1.1 or WebCenter Sites: Site Capture 11gR1 (11.1.1.6.x) Environment

1. Review Chapter 9, "Reference: Site Capture Backup and Recovery" for guidelines and specific instructions.

2. Back up Site Capture in the active environment, as described in Chapter 9, "Reference: Site Capture Backup and Recovery."

3. Take note of all the information about your existing installation, such as application server configuration and database configuration. While these will not be changed during the upgrade, you might need to reference existing settings if changes are needed elsewhere.

8.1.2 Creating the Test Environment

Note:

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 active Site Capture environment and expect extended downtime. We strongly recommend using a test environment.

1. When you are ready to create the test environment, recover the backup that you created in the previous step. Refer to Chapter 9, "Reference: Site Capture Backup and Recovery" for guidelines.

2. Continue with the guidelines below to complete the test environment:

1. Site Capture:
Copy Site Capture into the same location that it occupied on its previous host.

2. Application Server:

1. Install the application server using the same paths that were used on the previous host.

2. Create the data source using the same JNDI name that was used on the previous host. Use the database information for the restored database.

3. Deploy the Site Capture application as required by your application server.

Note:

In the WAS environment, while deploying SiteCapture ROOT.war file, select metadata-complete = true in the deployment screen.

8.1.3 Upgrading Site Capture Instances to Version 11gR1 (11.1.1.8.0)

In this section, you will run the Site Capture 11gR1 (11.1.1.8.0) upgrade installer in the preferred manner (interactive or silent) on each instance of Site Capture 1.1 or Site Capture 11gR1 (11.1.1.6.x).

- Interactive Upgrade can be used on environments where the X11-like GUI is available.

- Silent Upgrade can be used on environments where the command prompt is available.

8.1.3.1 Interactive Upgrade

1. Extract the Site Capture installer archive into a temporary directory and run the installer script:

- On Windows:   scinstall.bat

- On UNIX:      /scInstall.sh

Note:

Monitor the installer log (install_log.log) during post-upgrade testing. If an error occurs, you can trace its source by reviewing the logs.

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).

2. Proceed to the Oracle Fusion Middleware WebCenter Sites Installation Guide for the Site Capture Application and follow instructions for installing Site Capture. Once the installation is completed, return to this guide and continue.

Note:

At this point, it is assumed that the upgrade of Site Capture has been completed and you have a valid Site Capture installation running. If the upgrade failed, review the previous steps and the logs and resolve any issues.

3. Wait until the installer process exits normally and shows the command prompt again. The ROOT folder and the ROOT.war file will be created in the webapps folder of the installation directory specified in the omii.ini file.

4. If you update the Site Capture host name/port number, delete SiteCapture FW_Application and SiteCapture FW_View from AdminSite.

5. The only way to customize Site Capture is through Java code, which can be incorporated into the Site Capture web application in the form of class/jar files. No other files must be manually configured. Once the upgrade is complete, all changes must be manually preserved in the installer-generated war file. Refer to Section 8.3, "Upgrading Custom Implementations and Integrating with the Publishing System."

6. Deploy the Site Capture ROOT.war file on the applicable application server.

7. In the custombeans.xml file located in <Sites_install>/bin directory, add the following sample URL for the Site Capture to work with WebCenter Sites. If this is not added, then the Site Capture Application icon is not displayed in the Sites interface.

<value>http://<<hostname>>:<<port>>/__admin/*</value>

8.1.3.2 Silent Upgrade

1. Copy the omii.ini file from /fw-site-capture/ominstallinfo to a folder outside and rename the copy as desired. The silent installer will use this copy during the upgrade.

2. Open the desired omii.ini file.

3. Search for the isAlreadyInstalled property.

4. Set the isAlreadyInstalled property to true for upgrade silent installation.

5. Search for the CSInstallAccountPassword property.

6. Provide the unencrypted password for the CSInstallAccountPassword property.

7. Save the property file.

8. Open the Install.ini file (located at the root level in the extracted folder), add the line loadfile= to the first section, and save the file.

9. Open a command prompt and run one of the following commands:

- Windows:   scInstall.bat -silent

- Linux:     scInstall.sh -silent

You will see the following message in the command window after installation is successful: "Installation Finished Successfully".

10. Proceed to the Oracle Fusion Middleware WebCenter Sites Installation Guide and follow instructions for installing Site Capture. Once the installation is completed, return to this guide and continue.

11. Wait until the installer process exits normally and shows the command prompt again. The ROOT folder and the ROOT.war file will be created in the webapps folder of the installation directory specified in the omii.ini file.

12. If you update the Site Capture host name and port number, delete the SiteCapture FW_Application and SiteCapture FW_View assets from AdminSite.

13. The only way to customize Site Capture is through Java code, which can be incorporated into the Site Capture web application in the form of class/jar files. No other files must be manually configured. Once the upgrade is complete, all changes must be manually preserved in the installer-generated war file. Refer to Section 8.3, "Upgrading Custom Implementations and Integrating with the Publishing System."

14. Deploy the Site Capture ROOT.war file on the applicable application server.

15. In the custombeans.xml file located in <Sites_install>/bin directory, add the following sample URL for the Site Capture to work with WebCenter Sites. If this is not added, then the Site Capture Application icon is not displayed in the Sites interface.

<value>http://<<hostname>>:<<port>>/__admin/*</value>

8.1.4 Verifying the Upgraded Environment

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.

Complete the following steps on each Site Capture instance in the upgraded environment:

1. Log in to WebCenter Sites as a general administrator.

2. Go to the Site Capture application.

3. Test the Site Capture application and all functions that are routinely used during normal operations.

4. When the environment is verified, do one of the following:

- If you upgraded the test environment, continue to Section 8.2, "Upgrading the Active Environment."

- If you upgraded the active environment:

1. Enable the publishing schedules.

2. Enable any events.

3. Back up the upgraded environment.

4. Clear Client Browser caches (as existing cached content may cause issues).

5. Resume work.

Note:

You must verify if passwords are encrypted accurately in the omii.ini file.

8.2 Upgrading the Active Environment

The following steps apply if you upgraded the test environment:

1. Having verified the test environment, you will now upgrade the active environment. Assuming the active environment continued to operate during the trial upgrade, upgrade the active environment by referring to the previous steps in this chapter and any notes that you may have created during the trial upgrade.

2. Verify the upgraded environment, as described in Section 8.1, "Upgrading the Test Environment."

3. Resume work.

8.3 Upgrading Custom Implementations and Integrating with the Publishing System

This section contains the following topics:

- Section 8.3.1, "Custom Implementations"

- Section 8.3.2, "Integrating with the Publishing System"

8.3.1 Custom Implementations

Site Capture supports custom implementations such as ResourceRewriter and LinkExtractor, so that websites can be crawled according to desired URL patterns. Developers can customize a crawler with these customized implementations and create the required class/jar files. In upgrade scenarios, you must preserve and redeploy custom class/jar files in the latest application war files before starting the application.

8.3.2 Integrating with the Publishing System

In this section you will integrate Site Capture with the WebCenter Sites RealTime publishing process:

1. On the WebCenter Sites source system:

1. Do one of the following:

- For upgrade from Site Capture 11gR1 (11.1.1.6.0):
Replace the fw-crawler-publish-listener-11.1.1.6.0.jar with fw-crawler-publish-listener-11.1.1.8.0.jar to the /WEB-INF/lib folder.

- For upgrade from Site Capture 1.1:
Replace the fw-crawler-publish-listener-1.1.jar with fw-crawler-publish-listener-11.1.1.8.0.jar to the /WEB-INF/lib folder.

- For upgrade from Site Capture 11gR1 (11.1.1.6.1) Bundled Patch 1:
Replace fw-crawler-publish-listener-11.1.1.6.1.jar with fw-crawler-publish-listener-11.1.1.8.0.jar to the /WEB-INF/lib folder.

2. Unzip the fw-crawler-publish-listener-11.1.1.8.0-elements.zip file and re-import FW_PublishingEventRegistry.html using CatalogMover.

3. Restart the WebCenter Sites source system.

2. On the WebCenter Sites target system:

1. Using CatalogMover, re-import ElementCatalog.html and SiteCatalog.html from the unzipped fw-crawler-publish-listener-11.1.1.8.0-elements.zip file extracted in step 1 above (on the WebCenter Sites source system).

2. There is no need to copy the crawler.properties file (keep the existing file as is). If you update the Site Capture host name/port number, update the crawler.properties file accordingly.

3. Do one of the following:

- For upgrade from Site Capture 11gR1 (11.1.1.6.0):
Replace the fw-crawler-publish-listener-11.1.1.6.0.jar with fw-crawler-publish-listener-11.1.1.8.0.jar file to the /WEB-INF/lib folder.

- For upgrade from Site Capture 1.1:
Replace the fw-crawler-publish-listener-1.1.jar with fw-crawler-publish-listener-11.1.1.8.0.jar file to the /WEB-INF/lib folder.

- For upgrade from Site Capture 11gR1 Bundled Patch 1:
Replace the fw-crawler-publish-listener-11.1.1.6.1.jar file with fw-crawler-publish-listener-11.1.1.8.0.jar file to the /WEB-INF/lib folder.

4. Restart the WebCenter Sites target system.

9 Reference: Site Capture Backup and Recovery

This chapter supports the previous chapters of Part III, "Upgrading Oracle WebCenter Sites: Site Capture" by providing detailed information about the backup and recovery steps you are instructed to complete in those chapters.

This chapter contains the following sections:

- Section 9.1, "Prerequisites for Backing Up and Recovering"

- Section 9.2, "Backup and Recovery Guidelines"

9.1 Prerequisites for Backing Up and Recovering

- Before backing up any part of Site Capture application, it is best to shut down the application server. If you must make a backup of the active Site Capture application, ensure the website is not in use and no requests are being made to the application server.

- Before recovering any part of the Site Capture application, ensure the application server is shut down.

9.2 Backup and Recovery Guidelines

This section contains steps for backing up and recovering the Site Capture installation directory, web application, and database.

This section contains the following topics:

- Section 9.2.1, "Site Capture Installation Directory"

- Section 9.2.2, "Web Application"

- Section 9.2.3, "Non-Exploded Files Backup"

- Section 9.2.4, "Non-Exploded Files Recovery"

- Section 9.2.5, "Exploded Files Backup"

- Section 9.2.6, "Exploded Files Recovery"

- Section 9.2.7, "WebCenter Sites Database"

- Section 9.2.8, "Running the Recovered Application"

9.2.1 Site Capture Installation Directory

This section contains the following topics:

- Section 9.2.1.1, "Backup"

- Section 9.2.1.2, "Recovery"

9.2.1.1 Backup

Jar or tar the Site Capture installation directory.

For example:

tar -cvf SiteCapture_backup.tar /u01/CS/Install
jar cvf SiteCapture_backup.jar /u01/CS/Install

9.2.1.2 Recovery

Unjar or untar the backed-up Site Capture installation directory.

For example:

tar -xvf SiteCapture_backup.tar
jar xvf SiteCapture_backup.jar

9.2.2 Web Application

Refer to Table 9-1 and the sections that follow.

Table 9-1 Backup and Recovery Information for the ROOT .war File

.war Deployment Method

Backup

For Recovery Information, See...

Non-Exploded.For Site Capture on WebSphere

Unnecessary if the Site Capture installation directory is backed up.The ROOT.war file contained in the Site Capture installation directory:

<sc_install_dir>/ fw-site-capture/webapps/

Section 9.2.4, "Non-Exploded Files Recovery"

Exploded.For Site Capture on:

- Apache Tomcat

- Oracle WebLogic

- No "development changes" to the files.

- Backup is unnecessary if the files have not been changed during development and the Site Capture installation directory is backed up.

- The ROOT.war file contained in the Site Capture installation directory:

<sc_install_dir>/fw-site-capture/webapps/

Section 9.2.6, "Exploded Files Recovery" with no development changes

Same as previous row.

- With "development changes" to the files.

- Backup is required.

Section 9.2.6, "Exploded Files Recovery" with development changes

9.2.3 Non-Exploded Files Backup

See Table 9-1.

9.2.4 Non-Exploded Files Recovery

1. Undeploy the Site Capture application.

2. Recover the Site Capture installation directory (for instructions, see Section 9.2.1, "Site Capture Installation Directory.").

3. Redeploy the Site Capture application.

9.2.5 Exploded Files Backup

- To back up exploded files with no development changes, see Table 9-1.

- To back up exploded files with development changes:
Jar or tar the deployed Site Capture web application. Label the backup to distinguish it from the compressed ROOT.war file. For example:

tar -cvf ROOT_web_backup.tar /u01/software/Tomcat/webapps/ROOT
jar cvf ROOT_web_backup.jar /u01/software/Tomcat/webapps/ROOT

9.2.6 Exploded Files Recovery

- To recover exploded files with no development changes:

1. Stop the application server.

2. Delete the exploded web application.
For example:

rm -rf /u01/software/Tomcat/webapps/ROOT/*

3. Recover the Site Capture installation directory (for instructions, see Section 9.2.1, "Site Capture Installation Directory."

4. Unjar the backed-up Site Capture web application. For example:

cd /u01/software/Tomcat/webapps/ROOT
jar xvf /ominstallinfo/app/ROOT.war

- To recover exploded files with development changes:

1. Stop the application server.

2. Delete the exploded web application.
For example:

rm -rf /u01/software/Tomcat/webapps/ROOT

3. Unjar the backed-up Site Capture web application. For example:

cd /u01/software/Tomcat/webapps
jar xvf <sc_install_dir>/ROOT_web_backup.tar

9.2.7 WebCenter Sites Database

This section covers the following databases: Oracle 11g; Microsoft SQL Server 2005, 2008, and 2008 R2; IBM DB2 9.7

This section contains the following topics:

- Section 9.2.7.1, "Backup of Oracle, Microsoft SQL Server, and IBM DB2 Databases"

- Section 9.2.7.2, "Recovery of Oracle, Microsoft SQL Server, and IBM DB2 Databases"

9.2.7.1 Backup of Oracle, Microsoft SQL Server, and IBM DB2 Databases

- To back up Oracle 11g

1. Log in to the server as the oracle user.

2. Set <ORACLE_HOME> to the Oracle database directory and ORACLE_SID to the database name.

3. Log in to sqlplus as sys. Then, do the following:

1. Use the create directory sql to map to the operating system directory, where the exports will be stored. For example:

SQL> create directory exp_dp_dir as '/u01/backup/exports';

2. Grant permissions for database export and directory access. For example:

SQL> grant read,write on directory exp_dp_dir to system;
SQL> grant EXP_FULL_DATABASE to system

4. Run the expdp command to start exporting. For example:

expdp system/<password> DIRECTORY=exp_dp_dir
DUMPFILE=<file_name>.dmp FULL=y SCHEMA=<YOUR_SCHEMA>;

- To back up Microsoft SQL Server 2005, 2008, or 2008R2

1. Open SQL Server Management Studio.

2. Connect to the database server.

3. Expand Databases.

4. Right-click on the database to be backed up. Click Tasks > Backup.

5. Under "Backup type," select Full. Under Destination, click Add.

6. Enter the path and file name for the backup file. Click OK.

7. Under "Destination," select the newly created backup location.

8. Click OK.

- To back up IBM DB2 9.7

1. Log in to the server as the db2inst user.

2. Run the following command:

db2 force applications all

3. Run the following command:

db2 backup db <db_name> to <backup_dir>

Note:

After the command has completed, note the timestamp. This timestamp will be included in the name of the database backup file.

9.2.7.2 Recovery of Oracle, Microsoft SQL Server, and IBM DB2 Databases

- To recover Oracle 11g

1. Log in to the server as the oracle user.

2. Set <ORACLE_HOME> to the oracle database directory and ORACLE_SID to the database name.

3. Go to <$ORACLE_HOME>/bin.

4. Run the following command:

./impdp system/<password> DIRECTORY=exp_dp_dir DUMPFILE=<file_name>.dmp SCHEMAS=<YOUR_SCHEMA>;

- To recover SQL Server 2005, 2008 or 2008R2

1. Open SQL Server Management Studio.

2. Connect to the database server.

3. Expand Databases.

4. Right-click on the database to be restored. Select Tasks > Restore > Database.

5. Under "Source for restore," select From database.

6. Under "Select the backup sets to restore," select the most recent backup.

7. Click Script at the top.
This step opens the query editor containing the restore statement.

8. Edit the query by adding REPLACE, after WITH. This will allow the database log to be overwritten.

9. Click Execute.

- To recover DB2 9.7

1. Log in to the server as the db2inst user.

2. Run the following command:

db2 force applications all

3. Run the following command:

db2 restore db <db_name> from <backup_dir> replace existing

9.2.8 Running the Recovered Application

Before starting the application server, note the following:

- If you are using Apache Tomcat, clear the application server cache:

rm -rf <server_dir>/tmp/*
rm -rf <server_dir>/work/*

- For the Oracle WebLogic application server, the cache will be cleared upon redeployment of the application.

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2014, Oracle and/or its affiliates. All rights reserved.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.