<<

. 22
( 87 .)



>>

except the Administrator and Security Administrator.
To migrate the access controls, do the following tasks:

1. Open a command prompt on your WebSphere Portal V5.0 machine
(sandbox5.rigorconsultants.com) and go to <wp5_root>
\migrate directory.
2. Enter WPmigrate migrate-user-groups-ac.
3. Wait for the Build Successful message and then check the
MigrationReport.xml ¬le for any errors.
4. Enter WPmigrate optimize-roles. This will eliminate obsolete roles
and role blocks.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




Migrating to WebSphere Portal Version 5.0 111


5. Wait for the Build Successful message and then check the
MigrationReport.xml ¬le for any errors.
6. On WebSphere Portal V5.0 portal, go to Administration ➪ Access ➪
Users and Group Permission and review carefully that all the roles
assigned to the Users and Group are correct and set the inheritance
blocks as per your company policies.

Migrating Extended User Attributes
In WebSphere Portal 4.x, user attributes are stored in the WebSphere Mem-
ber Services database while in WebSphere Portal 5.x, user attributes are
stored in WebSphere Member Manager. If you just use the seven default
user attributes (uid, userPassword, cn, sn, mail, preferredLanguage, and
givenName) and do not use a look-aside database (as in 95 percent of the
cases), then you can skip this section. If you have extended user attributes,
then you must take the following steps:
1. Copy the ¬les attributeMap.xml and attributeMap.dtd from
<wp4_root>\wms\xml directory to the <wp5_root>\template\
wmm\xml\migration directory.
2. In the <wp5_root>\template\wmm\xml\migration directory,
you will ¬nd three ¬les: wmmDBAttributes.xml,
wmmLAAttributes, and wmmMigrationAttributesInfo.xml .
The ¬le wmmDBAttributes.xml is edited only if you have a
database-only WMS con¬guration while the ¬le
wmmDBAttributes.xml is used if your WMS con¬guration uses
both a database and an LDAP. The wmmDBAttributes.xml ¬le
speci¬es the WMM attributes that will be inserted into the
WMMDBATR table while the wmmLAAttributes.xml ¬le speci¬es
the WMM attributes that will be inserted into the WMMLAATR
table. The wmmMigrationAttributesInfo.xml is read by the migration
utility to determine where the attribute value data is coming from for
each attribute in the wmmXXAttributes.xml ¬le. The ¬le
wmmXXAttributes refers to either the wmmDBAttributes.xml or
the wmmLAAttributes ¬le. In WMS, most attributes are stored in
the MBRATTR table and their corresponding values are stored in the
MBRATTRVAL table. The exception is that a column name for certain
WMS tables can become a WMM attribute and the values associated
with the attribute are the WMS column data (now that is confusing!).
3. For each attribute that you are migrating, add the following XML
code to the appropriate wmmXXAttributes ¬le and save it:
<attributeMap wmmAttributeName=subdepartment
pluginAttributeName=subdepartment
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




112 Chapter 6


applicableMemberTypes=Organization
dataType=String
valueLength=256
multiValued=true />
where wmmAttributeName is the attribute name in WMM and
pluginAttributeName is the plug-in attribute name in LDAP,
applicableMemberTypes is the member type which the attribute
is associated with, dataType is the attribute data type, and
multiValued is a ¬‚ag specifying whether the element is
multivalued. ValueLength is an optional ¬eld that applies only to
string data type and speci¬es the maximum length of the attribute
value.
4. Now edit the wmmMigrationAttributesInfo.xml ¬le and for
each attribute (that does not come from a WMS column name) add
the following XML code:
<AttributeInfo tableName=MBRATTR
wmsAttributeName=subdepartment
attributeType=String
wmmAttributeName=subdepartment />
where tableName is the table where the attribute is coming from
(usually MBATTR), wmsAttributeName is the WMS attribute
name, attributeType is the attribute data type, and
wmmAttributeName is WMM attribute name. If the attribute comes
from a WMS column name then use the following XML code instead:
<AttributeInfo tableName=wms_table
wmsColumnName=wms_column
attributeType=String
wmmAttributeName=registration />

where tableName is the table where the attribute is coming from
(usually MBATTR), wmsColumnName is the column name of
wms_table, which contains the attribute value data,
attributeType is the attribute data type, and
wmmAttributeName is WMM attribute name. If the attribute comes
from a WMS column name then use the following XML code instead;
5. Next you have to edit the mig_wmm.properties ¬le found in
<wp5_root>\migration. This ¬le only needs to be modi¬ed if you
are using a look-aside database. Table 6-4 shows the values you
would need if you were using a look-aside database for our example
infrastructure.
6. Open a command prompt on your WebSphere Portal V5.0 machine
(sandbox5.rigorconsultants.com) and go to <wps_root>\
migrate directory.
7. Enter WPmigrate migrate-wmm.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




Migrating to WebSphere Portal Version 5.0 113

Table 6-4 Properties to Migrate Look Aside Database
PROPERTY VALUE DESCRIPTION
WmsDbName wps42db Alias name of WebSphere Portal
V4.x database

WmsDbUrl jdbc:dbc:wps42db WebSphere Portal V4.x database
JDBC URL

WmsDbUser db2admin db2 administrator user ID

WMSDbPassword db2 administrator password

LDAP + look-aside database
WmmCon¬gType 2
con¬guration

WmmUid DB1 The value of the UUID element. The
UUID is an ID that uniquely
identi¬es the member from all
other members. You can ¬nd the
value in <wp5_root>\shared\
app\wmm\wmm.xml ¬le under the
node databaseRepository

Db2Home C:/SQLLIB DB2 root installation directory on
sandbox6.rigorconsultants
.com

LDAPHasUid true States if your LDAP already has a
UUID attribute de¬ned

LdapUuidName ibm-appUUID LDAP UUID Name


8. Wait for the Build Successful message and then check the
MigrationReport.xml ¬le for any errors.
9. On WebSphere Portal V5.0, check the trace.log ¬le under
<wp5_root>\templates\wmm directory for errors and check the
loader.log ¬le in the directory <wp5_root>\template\wmm\
db2\database or <wp5_root>\template\wmm\db2\
lookaside to see if all the rows are loaded correctly.


Migrating Themes, Skins, and Style Sheets
The migration of themes, skins, and style sheets that you may have cus-
tomized is a manual process. The steps to do it using our example infras-
tructure are as follows:
1. Copy the WPS 4.2.1 customized themes and skins directories to
<was5_root>\installedApps\sandbox5\wps.ear\wps.war
on the WP V5.0 server.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




114 Chapter 6


2. Scan the JSPs used by the themes and skins and change the following:
a. Remove the following tags: <wps:pageGroupLoop/>,
<wps:pageGroup/>,<wps:pageLoopInit/>, <wps:page/>,
and <wps:frameURL/>. They are no longer supported.
b. Replace <wps:pageLoop/> by <wps:navigationLoop/>,
<wps:pageLoopShift> by <wps:navigationShift/>,
<wps:pageRender/> by <wps:compositionRender/>, and
<wps:URLSelect> by the <URLGeneration/> tags.
c. The behavior of <wps:text/> and <wps:textParam/> has
changed. If the content is provided in the body of the
<wps:text/> tag, then it will always be written to the page.
d. The attributes computeSelectionPath and
useModelFromRequestAttributeNamed of the
<wps:navigation/> tag are no longer supported.
e. For <wps:if/> and <wps:unless/> tags, the attributes error,
pageGroupSelected pageSelected, and frameMode are no
longer supported. The attribute pageGroupAvailable has been
replaced by nodeInSelectionPath and pageAvailable has
been replaced by navigationAvailable.
3. Update the style sheets used by the themes by looking at the Science
theme in WP V5.0, ¬nd the classes that have a comment associated
with them, New in V5, and copy them to your theme. Then modify
the classes to match the look of your theme.
4. Log in to http://sandbox5.rigorconsultants.com/wps/
portal and go to Administration ➪ Manage Themes and Skins.
5. Add your customized skins.
6. Test the themes and skins by creating a root page using the Page
Customizer, assign the customized theme to the new page, and
assign some portlets.
7. Go to the new page and test to see if the new page is similar to the
customized skin and themes in your WPS 4.2.1 portal.

Migrating Portlet Applications
The next step is to migrate your portlet applications. Copy your custom
portlets from <wp4_root>\deployed on WPS 4.2.1 (sandbox1.rigor-
consultants.com) to a temp directory on your WP 5.0 machine
(sandbox5.rigorconsultants.com). Expand the WAR ¬le. If your por-
tlets worked on WP 4.2.1 then minimal modi¬cations are required of the
source code. The only changes you might need are the following:
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




Migrating to WebSphere Portal Version 5.0 115


1. Methods getAttribute(), getAttributeNames(), and
getLastLoginTime() are no longer supported.
2. The portlet helper classes JSP, File server, and RSS (XSLT) portlet
have been deprecated.
3. PortletURI.addAction(java.lang.String
simpleaction) should be used instead of PortletURI.
addAction(PortletAction action).
4. ActionEvent.getActionString () should be used instead of
ActionEvent.getAction.
5. PortletRequest.getUser() must be used instead of
PortletSession.getUser() especially since
PortletSession.getUser() returns a null value.
6. Make sure there is no portlet.tld ¬le in the WAR ¬le. If there is,
remove it.
7. If you used Java Authentication and Authorization Service to access
the user credentials, you must rewrite the code using the credential
vault service.
8. Click-to-action portlets behave differently in WP 5.0. Output
parameters will not automatically propagate unless they are
explicitly wired to input parameters. You may have to rewrite them
as a cooperative portlet, which is just an enhance click-to-action
portlet.
9. You need to copy the pbportlet.jar ¬le found in <wp4-root>\
pb\lib directory on you WPS 4.2.1 server (sandbox1.rigor
consultants.com) to each of your migrating click-to-action
portlets WEB-INF\lib directories. If within the click-to-action
portlet WAR ¬le there is another copy of the pbportlet.jar ¬le
in another location, then you must remove it to avoid classloading
con¬‚icts.
10. Ensure you are not referencing any deprecated tags mentioned in
the previous sections.
11. Make sure that multiple portlets within a portlet application do not
point to the same servlets de¬nition in web.xml.

After you have modi¬ed the ¬les, archive the ¬les back into a WAR ¬le
and copy them to <wp5_root>\installableApps on your WP 5.0 server.
Next perform the following tasks:

1. Ensure that in the mig_core.properties ¬le, you have set the
includeApps property with the names of all your custom portlets.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH

<<

. 22
( 87 .)



>>