Upgrade Guide
|
 |
 |
|
 |
 |
Overview of the Upgrade Process from WebLogic Portal 7.0 SP2 to 8.1
This section provides an overview of the strategies and procedures for upgrading WebLogic Portal 7.0 SP2 applications to WebLogic Portal 8.1 and its associated service packs. The following topics are discussed:
Definitions
To clarify the different activities described by this document, a brief list of terms is included:
Moving an application/domain from a third-party technology to a BEA product. (For example, migrating a customer from IBM, webMethods or "home grown" to BEA.)
Updating BEA platform (and components) from older release/Service Pack to newer release/Service Pack. This includes updating existing application/domain to run in a newer version, for example, 7.0 to 8.1.
(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.
Portal Version 7.0 SP2 to 8.1 Upgrade Process Overview
Two paths are available for upgrading your WebLogic Portal 7.0 SP2 portal web application to WebLogic Portal 8.1:
- Compatibility: Allows for the configuration of an existing WebLogic Portal 7.0 SP2 portal web application to run on the 8.1 portal server.
Hosting an existing Portal Web application in a Portal Compatibility Domain requires following the procedure outlined in Hosting 7.0 Applications in 8.1 Compatibility Domain.
- Upgrade: Allows for the upgrade of WebLogic Portal 7.0 SP2 portal applications and resources to WebLogic Portal 8.1.
Hosting an existing Portal Web application in a WebLogic Portal 8.1 domain requires following the procedure outlined in Upgrading from Compatibility Mode to WebLogic Portal 8.1 on page 3-1.
Comparing Supported Features
This section outlines significant feature changes between the WebLogic Portal 7.0 SP2 and the WebLogic 8.1 release. For detailed descriptions and implementation details, consult Framework Reference for Portal Upgrades from 7.0 to 8.1.
The portal framework in WebLogic Portal 7.0 has a one-to-one mapping with the portal it represents; this methodology adheres to the single portal per web application architecture. Changes made to this framework will impact the portal and all group portals, with limited provisions for changes based on runtime factors. This code was not originally designed to be modified by end users and was instead considered part of the product itself. However, users who wished to change the way that the portal behaved or make significant changes to the way that the portal looked were forced to modify this framework.
In WebLogic Portal 8.1, the framework has been designed to allow users to more readily modify the look and the feel of the product. Instead of the single collection of JSP files for a portal, any portal can use a look and feel, which in turn is comprised of a skin and a skeleton. The portal framework is an XML skeleton that replaces the framework JSPs, allowing users to easily modify the behavior of the portal without modifying the underlying BEA code.
Look and Feel
The look and feel of a portal is determined primarily by the code used to render the HTML, the styles used by the HTML, and the images displayed. In 7.0 only the skin could be changed to obtain a different look and feel, but in 8.1 there is a look and feel document that sets the skin and the skeleton, with the latter being the framework that is used to render the elements.
The look and feel file used in 8.1 is an XML document with an .laf extension that defines the name, the skin to use, and the skeleton to use. This allows one skeleton to be used with multiple skins, or vice-versa, with the former being the most likely case. Creating or modifying the look and feel file in 8.1 involves working with XML directly as there is no visual editor provided.
Stylesheets
WebLogic Portal 8.1 uses Cascading Stylesheets (CSS) to a greater extent than 7.0, with more tags and improved structure.
In WebLogic Portal 7.0, a single main.css file contains entries for portal, portlet, pages, and other elements using a single-level naming convention. Examples include .titlebar, .portletcontainer, .pageheader, and so on. Creating a new skin includes modifying the main.css file and setting the desired values for these tags.
In WebLogic Portal 8.1, multiple files are used for this task:
body.css: Portal body (header, footer, and so on) stylesbook.css: Book, page, and menu stylesbutton.css: Button stylesfix.css: Browser bug-fix stylesform.css: Form, input, and text area styleslayout.css: Layout and placeholder styleswindow.css: Portlet styles
The naming convention in WebLogic Portal 8.1 is multi-level, providing more granularity and flexibility when using styles. Examples include bea-portal-book-primary-menu, bea-portal-window-titlebarcontainer, bea-portal-body-footer, and so on. As with WebLogic Portal 7.0, creating a new skin includes copying an existing skin and modifying the styles.
Properties
In WebLogic Portal 8.1, a skin.properties file contains entries that define the paths to images, links, scripts, and so on. In most cases it will not be necessary to modify this file, but the option to do so provides increased flexibility for locating resources.
Scripts
There are a few JavaScript functions that are used in WebLogic Portal 8.1 for popup menus, initialization, and so on. These can be modified on a per-skin basis, but it is recommended that application specific scripts be placed in separate files.
Images
Skins in the new release use fewer application-specific images. These images can be modified when creating custom skins.
Skeletons
The skeletons used in WebLogic Portal 8.1 are roughly equivalent to the framework JSPs in WebLogic Portal 7.0, but the code, tags, and overall structure are quite different. There is no direct path to transfer WebLogic Portal 7.0 framework modifications to skeleton in WebLogic Portal 8.1, but a JSP developer should be able to do the conversion manually.
JSP
The JSPs in a skeleton directory use scriptlets and JSP tags to render the various elements of the portal. Files include body.jsp, book.jsp, popupmenu.jsp, and so on, which correspond to the portal elements. Modifications to these files can change the way that the elements are rendered as well as the way that they behave.
Layouts
Layouts are similar to those in WebLogic Portal 7.0, but have added flexibility and functionality. The layouts are derived from three base types: grid, border, and flow. These format types place elements on a grid, at the center, north, south, east, or west, or in a horizontal or vertical flow, respectively.
Layout Definition
The layouts in WebLogic Portal 8.1 are defined in XML in the form of .layout files. These files specify the type of layout to use (grid/border/flow), the number of columns, the HTML to use for the tools, and naming. When creating a new layout it is easiest to start with an existing layout definition and modify it.
- HTML Files
The HTML files included in layouts in WebLogic Portal 8.1 are for use by WebLogic Workshop and the WebLogic Administration Portal. These HTML files use specific classes to specify the layout and placeholders, and are similar to the JSPs. The HTML is used to render the layouts and modify the contents of placeholders.
- JSP Files
The JSP files included in layouts in WebLogic Portal 8.1 are used to render the layout on a page and are part of the skeleton. There is one file for each layout type, including
gridlayout.jsp,borderlayout.jsp, andflowlayout.jsp. You can modify these layout types as part of the skeleton, but in general it is suggested that custom layouts be created if these do not behave in the desired way. For example, a spanning layout can allow portlets to span rows or columns.
Group Portals
Group portal definitions are not upgraded: in WebLogic Portal 8.1, the corresponding mechanism is the Desktop, by which a bundle of portal components is presented to a specified audience.
Webflow Support and Limitations
Portlet Webflow files can be upgraded, and can be used in conjunction with Page Flows.
WebLogic Workshop allows Webflow support to be added to existing WebLogic Portal 8.1 applications. This means Webflow portlets can run inside a WebLogic Portal 8.1. All Webflow presentation node types can be supported. An entire Webflow file can be supported, along with all its semantics, such as chaining.
Webflow and Page Flow portlets can be used in a common page. Page Flows can call Webflow files, allowing existing pipeline components and input processors to be leveraged. Page Flows can call out to Webflows and map the return to a forward in the Page Flow.
Exceptions
Page Flow JSPs cannot call validators. Webflow presentation nodes can be supported as long as they are the endpoint of a Webflow.
Page Flows
Provided they call the Webflow's entry point (using the syntax origin - namespace - event) Page Flows can call Webflow presentation nodes.
The resulting WebflowResponse can be used to construct a Java Page Flow Forward using the URI or URL constructors, but the processor nodes are definitely still in the loop.
Portal Services
Content from an existing WebLogic Portal 7.0 repository can be consumed and leveraged into any existing integration or process. The WebLogic Portal 8.1 Virtual Content Repository allows the content management administration tools to be used against content in a WebLogic Portal 7.0 repository. Additionally, a new bulkloader tool supports moving content from the flat WebLogic Portal 7.0 repository into WebLogic Portal 8.1 repositories, enabling you to take advantage of the new content management features.
Security
WebLogic Portal 8.1 implements the WebLogic Server SSPI and uses the default LDAP store for user information.
- Existing customers will be able to continue to leverage their RDBMS user stores by leveraging an SSPI authentication provider that will be provided for connecting to a RDBMS.
- Entitlement segments on WebLogic Portal 7.0 cannot be upgraded because of the change to leveraging the WLS SSPI. Customers will need to create roles using the WebLogic Administration Portal for entitlements.
Commerce and Personalization
The only significant change to commerce functionality is that the JSP tools for orders, payments and catalog are no longer included in the WebLogic Administration Portal.
Note: For instructions on adding Catalog Administration tools to an out-of-the-box WebLogic Portal 8.1 application, consult the "Adding Catalog Administration" section in Procedure for Upgrading from Compatibility on page 3-2.
Regarding personalization, property set schema and values remain unchanged and require no upgrade.
Behavior tracking requires current data be archived and re-hosted in a new schema. The procedure is outlined in Step 6: Upgrading Existing Behavior Tracking Data on page 3-14.
Struts
Some customers might have existing Struts-based applications or desire to start developing Struts applications on WebLogic Portal 7.0 because of the move to Page Flows in the WebLogic Portal 8.1 release, which are built on Struts 1.1. Guidelines on hosting Struts-based applications in WebLogic Portal 8.1 are listed in Struts Support.
How to Upgrade Existing Applications
When considering the route to run your WebLogic Portal 7.0 SP2 applications on WebLogic Portal 8.1, two choices are available immediately: to host the application to run in a Portal Compatibility Domain, as explained in Hosting 7.0 Applications in 8.1 Compatibility Domain on page 2-1, or to upgrade the application to run in WebLogic Portal 8.1, as explained in Upgrading from Compatibility Mode to WebLogic Portal 8.1 on page 3-1. The bulk of this guide is devoted to the Portal Compatibility Domain path, but also includes significant information required for re-implementation with WebLogic Portal 8.1.
Compatibility Domain
An existing Weblogic Portal 7.0 application can be converted to run in a Portal Compatibility Domain using the procedure detailed in Hosting 7.0 Applications in 8.1 Compatibility Domain on page 2-1.
Figure 1-1 Upgrade to Compatibility Domain
Upgrading to Weblogic Portal 8.1
Listing includes the information required for re-implementing an existing Weblogic Portal 7.0 application to run in WebLogic Portal 8.1. The capabilities and limitations of this configuration are explained here, along with a general description of new platform features included in WebLogic Portal 8.1.
Figure 1-2 Re-Implementation for WebLogic Portal 8.1
Conversion of Portal and Portlet Definition Files
WebLogic Portal 8.1 includes the command line tool upradePortalFiles.cmd (.sh) that converts .portal and .portlet files from version 7.0 SP2 to version 8.1. This file resides in the WL_HOME\portal\upgrade directory. For more information, see Step 4: Upgrade Portal and Portlet Files on page 3-9.
Portal Web Applications
Portal Web applications built on WebLogic Portal 7.0 SP2 can be run on WebLogic Portal 8.1, using the upgrade procedure contained in Upgrading from Compatibility Mode to WebLogic Portal 8.1 on page 3-1.
Look and Feel Components
WebLogic Portal 7.0 skins and UI components can be re-hosted to Look and Feels and appropriate components in the WebLogic Portal Version 8.1. For details on Look and Feel implementation, see Connecting to an Active Directory Server on page E-3.
