|
|
|
|
|
|
Migrating to WLCS 2.0.1
Migrating to WLCS 2.0.1 includes the following topics:
Portal Data Migration
This is a basic overview for migrating your portal data from 1.7 to 2.0.1.
Portlet definition
You should recreate portlet definitions from scratch. Because of changes to key types within the portal framework, it's not practical to automatically migrate portlet definitions. Please follow the WLPS 2.0.1 documentation to create the new portlet definition.
Portal definition
You should recreate portal definitions from scratch. Because of changes to key types within the portal framework, it's not practical to automatically migrate portal definitions. Please follow the WLPS 2.0.1 documentation to create the new portal definition.
Personalization
There is no migration strategy for user- and group-personalized portals because no personalized information for users and groups will be lost.
Note: Only the user and group portal layouts will be lost, including personalized information such as background colors, etc. Refer to Migrating Users and Migrating Groups for information about handling the transfer of personalized information.
Migrating Users
User Identification
The notion of the system user has significantly changed in release 2.0.1. In the 1.7 release, a username could be repeated across multiple portals (qualified by a <portalname> prefix), and be used to represent different actual users. In this release, a user is identified by a single unique String identifier. The impetus for this shift in user name identification is the support of WebLogic security realms in release 2.0.1. Because in a security realm, such as an LDAP realm, a unique identifier represents one and only one system user, this pattern is mirrored in the Personalization Server. In the 1.7 release, a user did not exist outside the scope of a portal, users now exist independently of any portal.
Moving Users
User login and password information must be moved from the PORTAL_SIGNON table to the WLCS_USER table. The only information retained from table to table is the username and password. To this end, if a username (e.g. bob) is repeated in the PORTAL_SIGNON table, and is meant to represent two different users, a unique username (e.g. bob2, bob3) must be created for each redundant entry when making the transition.
It is strongly recommended that as these unique usernames are created, the USER_HIERARCHY table be updated to reflect the new usernames. The portal name/username combination can be used when seeking the usernames to update in the USER_HIERARCHY table.
If the desire is to no longer authenticate the users against the Personalization table, but against another realm, for example the LDAP realm, set the IS_EXTERNAL value for each transported user to 1. If the users are to be authenticated against the WLCS_USER table, using the Realm class com.beasys.commerce.axiom.contact.security.RDBMSRealm, set the IS_EXTERNAL value to 0.
Unique User Ids
Numeric user ids are used in portions of the Personalization Server to ensure strong performance and scalability. String identifiers are discarded in favor of long identifiers in places such as the portal framework user personalization tables and the group-user hierarchy table. Since a sequence table is used to generate unique ids for users as they are required, unique ids for users must be generated in the following manner:
For each user transitioned into the WLCS_USER table, retrieve the corresponding com.beasys.commerce.axiom.contact.User object and call its getUniqueId method.
This will place the following three entries in the WLCS_ENTITY_ID_TABLE:
Migrating Groups
Group Identification
Just as users can now exist outside the scope of a portal, groups exist independently of portals, as well. Again, the impetus for this change is the support of WebLogic security realms by the WLPS 2.0.1 release.
Moving Groups
Group name information must be moved from the PORTAL_GROUP_HIERARCHY table to the WLCS_GROUP table. To this end, unique group names must be generated for each redundant group name entry in the PORTAL_GROUP_HIERARCHY table, and the group names (only) must be moved to the WLCS_GROUP table.
It is strongly recommended that as these unique usernames are created, the PORTAL_GROUP_HIERARCHY table be updated to reflect the new group names. The portal name/group name combination can be used when seeking the usernames to update in the PORTAL_GROUP_HIERARCHY table.
Unique Group Ids
Like user ids, group ids are shared as long values rather than String values. Since a sequence table is used to generate unique ids for groups as the ids are required, unique ids for users must be generated in the following manner:
For each user transitioned into the WLCS_GROUP table, retrieve the corresponding com.beasys.commerce.axiom.contact.Group object and call its getUniqueId method.
This will place the following three entries in the WLCS_ENTITY_TABLE:
Once unique ids have been generated for users and groups, the transition of data into WLCS_GROUP_USER_HIERARCHY table can take place. For each entry in the PORTAL_USER_HIERARCHY, two unique numeric ids must be obtained: the id corresponding to the user name and the id corresponding to the group name. If the previous recommendations regarding updating the USER_HIERARCHY table were adhered to, obtaining the unique id for each entry should be straightforward. The WLCS_ENTITY_ID table contains the unique ids corresponding to the user and group names. These ids should be put into the appropriate columns of the WLCS_GROUP_USER_HIERARCHY table.
Properties and Property Sets
The properties in the WEBLOGIC_USER table pertaining to a particular portal can be translated into a single property set for subsequent portal use. To collect these properties, unique property names must be collected from the WEBLOGIC_USER table across user profiles where the username is like <portalname>. Once the property names are collected, a new PropertySet (com.beasys.commerce.foundation.property.Schema) object can be created, and the collected properties can be added to it. Because the 1.7 release dealt only with String properties, each new property type should be set as a String type. It is also recommended that each property be multi-valued and unrestricted, in order to maintain all property values. The new property set can be created programatically or through the use of the Property Set Management suite of administration tools.
It is strongly recommended that particular user and group property values are set programatically by obtaining each com.beasys.commerce.axiom.contact.User and com.beasys.commerce.axiom.contact.Group object, and setting properties for these objects through the ConfigurableEntity interface. The database schema for property values in release 2.0.1 is considerably more complex than the database schema of the 1.7 release.
JSP Migration
The real development effort of the customer is in creating and maintaining the JSP pages. There are several new enhancements with the 2.0.1 release. The exampleportal reference implementation takes advantage of these features (Please refer to the Portal Management documentation and Setting up a portal for more information). If you have not modified any of the pages for your own personal Web site, there will be no migration issues for the framework code. If any changes have been made, the following items need to be made clear.
<% setOverrideDestination(request, "_userlogin.jsp"); %>
<jsp:forward page="<%=getTrafficURI(request)%>"/>
The portal framework first looks for the file relative to the working directory (setup within the service manager registration). If the file is not there, it looks for the file relative to the repository directory (also setup within the service manager registration).
Note: If the files are fully qualified it will only look in the location specified.
Affected methods:
<jsp:include page="<%=reconcileFile(request, "alternateheader.jsp")%>"/>
reconcileFile will handle the repository aspects.
Sample Tables
If you are using the sample bookmarks and todo list tables, these may simply be renamed.
Review the new tag documentation for the Personalization Server 2.0.1. Three tags that were in use in 1.7 have been retired.
New Tags
The tags discussed in this section are tags provided by the User Management subsystem of the Personalization Server that replace previously-used tags from the Portal tag library of release 1.7. Refer to the JSP Tag documentation for in-depth explanations of each tag.
<um:login>
The <um:login> tag replaces, in part, the <pt:signon> tag. The <um:login> tag provides username-password authentication against the security realm only. It performs no portal-particular activities, such as setting session values for the portal.
<um:getprofile>
The <um:getprofile> tag replaces, in part, the <pt:profile> tag. The <um:getprofile> tag retrieves a user/group profile for subsequent setProperty and getProperty calls.
<um:getproperty>
The <um:getproperty> tag replaces the get action of the <pt:profile> tag.
<um:setproperty>
The <um:setproperty> tag replaces the set action of the <pt:profile> tag. Unlike the old tag, the <um:setproperty> tag provides no profile autocreate option, as this option is no longer needed.
<um:removeproperty>
The <um:removeproperty> tag replaces the remove action of the <pt:profile> tag. Unlike the old tag, the <um:removeproperty> tag provides no profile autodestroy option, as this option is no longer needed.
<um:createuser>
The <um:createuser> tag replaces the create action of the <pt:signon> tag.
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|