Skip Headers
Oracle® Fusion Middleware Upgrade Guide for Oracle WebLogic Portal
10g Release 3 (10.3.6)

Part Number E14253-03
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

1 Overview of the Upgrade Process to WebLogic Portal 10.3.6

This section provides an overview of the strategies and procedures for upgrading Oracle WebLogic Portal to 10.3.6. You can upgrade directly to Portal 10.3.6 from the following WebLogic Portal applications:

You are not required to upgrade from WebLogic Portal 8.1 to 9.2, from 9.2 to 10.0/10.2/10.3/10.3.2/10.3.4/10.3.5, and then to 10.3.6.

Note:

If you are upgrading a WLP application that uses Autonomy Enterprise Search and you would like to continue to use Autonomy Enterprise Search, you must first purchase the required license and obtain the binaries from Autonomy Corporation at http://www.autonomy.com. For more information on using Autonomy with WLP, see Oracle Fusion Middleware Autonomy Search Integration Sample Guide for Oracle WebLogic Portal.

You can also elect to use another search engine in place of Autonomy, such as Oracle's Secure Enterprise Search, which can be purchased separately or comes as part of WebCenter Suite.

The following topics are covered in this chapter:

Some of tasks associated with a WebLogic Portal upgrade are performed by running the WebLogic Upgrade Wizard. The WebLogic Upgrade Wizard is described in Oracle Fusion Middleware Upgrade Guide for Oracle WebLogic Server.

1.1 Definitions

To clarify the different activities described by this document, a brief list of terms is included:

Migration – Moving an application and domain from a third-party technology to an Oracle product. (For example, migrating a customer from IBM to Oracle.)

Upgrade – Updating Oracle platform (and components) from older release or Service Pack to newer release or Maintenance Pack. This includes updating existing application and domain to run in a newer version, for example, 9.2 MP1 to 10.3.6.

The process required to upgrade an application environment depends on the scope of the application. An application environment includes a WebLogic domain and any applications and application resources associated with the domain. It may also include external resources, such as firewalls, load balancers, databases, and LDAP servers.

Interoperability – (1) The capability of an application deployed in one release or service pack to communicate with another application that is deployed in a different release or service pack. (2) The capability of WebLogic Platform components to communicate with third-party software using standard protocols.

Compatibility – Application built using one release or Service Pack running in another release or Service Pack. This might involve rebuilding the application.

1.2 Portal 9.2, 10.0, 10.2, 10.3, 10.3.2/10.3.4/10.3.5 to 10.3.6 Upgrade Overview

You can upgrade your WebLogic Portal 9.2, 9.2 MP1, 10.0, 10.0 MP1, 10.2, 10.3, 10.3.2, 10.3.4, 10.3.5 applications to 10.3.6. The upgrade process involves upgrading your WebLogic Portal domain and applications. Upgrade the portal domain using the WebLogic Upgrade Wizard before you upgrade your portal application. The upgrade procedure is explained in Chapter 2, "Upgrading to WebLogic Portal 10.3.6."

The WebLogic Portal APIs have been maintained in the current version of WebLogic Portal (except for the Commerce API, which was deprecated in 10.0 and removed from the current version), and most core formats for the database and file based assets have not changed. Where changes have been made, tools are provided to upgrade you to the new format, or provide manual changes where needed.

The 9.2 and 10.0/10.2/10.3/10.3.2/10.3.4/10.3.5 upgrades are performed on a .project file. After you upgrade to Portal 10.3.6, you cannot go back to a previous portal version. If you are upgrading from WebLogic Portal 9.2 or 10.0/10.2/10.3/10.3.2/10.3.4/10.3.5 to 10.3.6, the Derby database version has already been upgraded.

You can choose one of the following methods to upgrade your Portal 9.2 or 10.0/10.2/10.3/10.3.2/10.3.4/10.3.5 application to 10.3.6:

For instructions on upgrading, see Section 2.6.2, "Upgrading from Portal 9.2 and 10.0/10.2/10.3/10.3.2/10.3.4/10.3.5."

1.3 Portal 8.1 to 10.3.6 Upgrade Overview

WebLogic Portal enables you to upgrade your 8.1 SP4, SP5, and SP6 applications directly to 10.3.6. Most WebLogic Portal APIs have been maintained in the current version of WebLogic Portal (except for the Commerce API, which was deprecated in 10.0 and removed from the current version), and most core formats for the database and file based assets have not changed. Where changes have been made, tools are provided to upgrade you to the new format, or provide manual changes where needed.

The upgrade process involves upgrading WebLogic Portal 8.1 portal applications and resources to WebLogic Portal 10.3.6. The 8.1 to 10.3.6 upgrade is performed on a .work file. If you customized how you set the domain in your start scripts, your changes will be overwritten when you run the WebLogic Portal 10.3.6 start scripts.

Note:

When you upgrade from WebLogic Portal 8.1 to 10.3.6, your Derby database is upgraded.

For instructions on upgrading, see Section 2.6.3, "Upgrading from Portal 8.1 to 10.3.6."

1.4 Library Module Changes

The Domain Upgrader tool is responsible for adding or removing library modules, as necessary. It also modifies existing library module path information to point to the new product installation.

Removed libraries are deleted from the config.xml file. If you upgrade from 8.1.x to 10.3.6, the libraries are added to your config.xml file. If you upgrade from 9.2 or 10.0/10.2/10.3/10.3.2/10.3.4/10.3.5 to 10.3.6, the module version number changes to 10.3.6 in your config.xml file. If you upgrade from 10.0 MP1 to 10.3.6, the domain upgrader removes the maintenance-lib references.

1.5 Supported Features Comparison

This section outlines significant feature changes between older version of WebLogic Portal and the Portal 10.3.6 release.

1.6 Security

WebLogic Portal 8.1 included a WebLogic Portal-specific RDBMSAuthenticator. This has been deprecated. WebLogic Server 9.2 contains a new default SQLAuthenticator authentication provider, which contains an RDBMS user store for users and groups. Oracle recommends upgrading to the new WebLogic Server SQLAuthenticator.

When you run the WebLogic Upgrade Wizard to upgrade your domain, it determines whether or not you are using the RDBMSAuthenticator in your 8.1 installation. If the RDBMSAuthenticator is detected, the WebLogic Upgrade Wizard prompts you to choose whether to upgrade to the WebLogic SQLAuthenticator as your default authentication provider or continue to use your existing RDBMS user store. Replacing the existing authentication provider with the new WebLogic Server SQLAuthenticator upgrades all content, including personalization features. You can also choose to manually upgrade your personalization features to the Portal 10.3.6 RDBMS user store later.

Choose one of the following options when upgrading your user store:

If you do not upgrade your user store during the domain upgrade process, you can perform a manual upgrade later. The script to upgrade from the WebLogic Portal-specific RDBMS Authenticator to the WebLogic SQL Authenticator is <WLPORTAL_HOME>/p13n/db/<dbms>/upgrade_fromdbmsauth_ towlssqlauth.sql.

For additional information, see Section B.2, "Upgrading 8.1, 9.2, or 10.0 Derby Databases."

Note:

If you upgrade a WebLogic Portal 8.1 application to 10.3.6 and you use the UserProviderControl.createUser() class in the upgraded domain, you might see a javax.security.auth.login.LoginException error when a new user attempts to log into WebLogic Portal. This occurs because by default new users in a WebLogic Portal 10.3.6 domain are created in the SQLAuthenticator and not in a migrated authentication provider (which normally is configured with a JAAS flag set to REQUIRED). Since the WebLogic Portal domain Upgrade Wizard does not adjust your JAAS settings or remove your existing authentication provider, you must adjust the JAAS setting or delete the authentication provider (as appropriate) to avoid this exception.

When you upgrade your domain to 10.3.6, the RDBMS Security Store is not enabled by default. To enable and configure the Security Store, you must use the Oracle WebLogic Server Administration Console. For detailed information on the RDBMS security store, see the WebLogic Server document, "Managing the RDBMS Security Store," in Oracle Fusion Middleware Securing Oracle WebLogic Server.

When upgrading a WLP domain to 10.3.6, if you also want to use the RDBMS Security Store, after performing the upgrade you must configure the RDBMS Security Store using the WebLogic Server console. After restarting the domain, policies are auto-migrated into the RDBMS security store. If you instead want to migrate policies to a new (not upgraded) domain configured for the RDBMS Security Store, see the details on migrating data from the old security store to the new security store in "Upgrading a Domain to Use the RDBMS Security Store" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

Note:

As part of the upgrade process, the DDL automatically creates the RDBMS Security Store tables in the schema for which the p13nDatasource is configured. Oracle recommends that administrators use the same database connection settings as the p13nDatasource. If a portal domain administrator wishes to use or configure a database schema other than the schema for which the p13nDatasource is configured, he or she must manually run the following script to create the RDBMS Security Store tables for that schema:

<WLPORTAL_HOME>/p13n/db/<database_vendor>/rdbms_security_store_create_tables.sql

1.7 Event Handling

Events can target content to a desired audience.

Note:

Events will fire for a content repository that was upgraded to 10.3.6 (unless you turned event tracking turned off at the repository level). Events can include repository configuration changes, as well as content additions, updates, and deletions to the repository. Events do not fire for content in an 8.1 or 9.2 repository that was not upgraded. Events are fired for content that is added, updated, or removed from that repository.

If you created a separate behavior tracking database in version 8.1 or 9.2, upgrade it as described in Section B.4, "Upgrading Separate 8.1 Behavior Tracking Databases."