Portal V7.0 cluster: Web content post migration steps

Portal V7.0 cluster: Web content post migration steps

Context root settings for secondary nodes

If we are migrating a cluster, update the context root for WCM on any secondary nodes to ensure that web content is displayed properly.
To update the context root...
On the primary node, view...
WP_PROFILE/ConfigEngine/properties/wkplc.properties

...and note the value of the WpsContextRoot property.

On each secondary node, edit wkplc.properties, and set the value of the WpsContextRoot property to match the value on the primary node.
On each secondary node, run the action-update-wcm-cluster-variable-map
./ConfigEngine.sh action-update-wcm-cluster-variable-map \
                  -DWasUserId=username \
                  -DWasPassword=foo \
                  -DPortalAdminId=username \
                  -DPortalAdminPwd=foo 
JSP files and Web content plug-ins

Any JSP files used on the old system will need to be manually copied to the new system.

Any Web content plug-ins used on the old system, such as custom workflows, will need to be manually copied to the new system and enabled.

Search Indexes

Before you migrated the search components, you exported the search collections as XML files and deleted the search collections from the Manage Search portlet. After migrating to the current version of WebSphere Portal, we can rebuild your search indexes.

Create the new search collections.

Import the backed up configuration information for each of the search collections.

Check if the URLs for the crawlers are still valid.

Stop the WebSphere Portal server.

If the schedules have not been set, start the crawlers manually.
Ignore this step if schedules have been set. When schedules are set, the crawlers update the search collections.

Syndication

Automatic syndication is disabled during migration. If we use automatic syndication enable it after migration. To do this, from the WAS admin console, in the the WCM WCMConfigService service, set...
connect.moduleconfig.syndication.inittasks = true

If the migrated server is to be a syndicator, also set...
deployment.subscriberOnly property = false

Local rendering portlets based on the IBM Portlet API

The traditional rendering portlets that are provided for earlier versions of WCM are based on the IBM Portlet API. If you migrate any traditional local rendering portlets, update the permissions on the portlets by running the following configuration

./ConfigEngine.sh action-set-wcm-legacy-localrender-permissions -DWasPassword=foo -DPortalAdminPwd=foo

The IBM Portlet API web content viewer is deprecated and no longer available with the default installation. Wherever possible IBM recommends that you adapt the web content environment to use the JSR 286 web content viewer to ensure future compatibility.

Remote rendering portlets based on the IBM Portlet API

The traditional rendering portlets that are provided for earlier versions of WCM are based on the IBM Portlet API. If you migrate any traditional remote rendering portlets, update these portlets to v8.0.
If you fail to update the migrated remote rendering portlets as described here, some basic features, such as previewing, are not functional in WCM.

Update the portlet WAR file.

Log in to the migrated server as an administrator.

Go to the Administration view and then Portlet Management.

Select Web Modules.

Click Update.

Click Browse.

Select the file called ilwwcm-remoterendering-portlet.war from the PORTAL_HOME/pzn.ext/portlet.remoterendering/remoterendering.war/installableApps directory of the v8.0 server. This must be a content server installation as this file is not installed on an administration server installation.

Click Open.

Click Next.

Click Finish.

Remove the ilwwcm-wcmimport application.

Log in to the WAS admin console as an administrator.

Click Applications > WebSphere enterprise applications.

Select the ilwwcm-wcmimport application, and click Uninstall.

Save the changes.

Register the remote rendering portlet again.

On the migrated server, delete the PORTAL_HOME/temp/node_name/WebSphere_Portal/_extensionregistry directory.

Delete the PORTAL_HOME/configuration directory.

Run the osgiCfgInit command from the PORTAL_HOME/bin directory:

./osgiCfgInit.sh

Restart the portal server.

The configuration settings of the remote rendering portlets on remote servers will be unchanged after you have migrated the servers. If the migrated servers use the same naming conventions as the old servers, then you will not have to re-configure the remote rendering portlets. If you have changed the naming conventions of the migrated server, such as giving the migrated cluster a different name than your old server cluster, then you will have to re-configure the remote rendering portlets.
If you have a small number of remote rendering portlets, we can edit the configuration settings of the remote rendering portlets manually. If you have a large number of remote rendering portlets, then we can use xmlaccess.sh to re-configure the remote rendering portlets. To do this you will have to export the pages containing the remote rendering portlets:

We can use xmlaccess.sh to export the remote rendering portlet web application and all related portal pages.

We can also use the Export Pages portlet in the portal's administration to export the entire page hierarchy containing the remote rendering portlets.

Once exported, change the value of the WCM_REMOTE_HOST_BASE_PATH variable for all the portlets to v8.0 servers. This updated XML file can then be imported using the xmlaccess command or the Import XML portlet.
The IBM Portlet API web content viewer is deprecated and no longer available with the default installation. Wherever possible IBM recommends that you adapt the web content environment to use the JSR 286 web content viewer to ensure future compatibility.

Parent: Portal V7.0 clustered environment
Related:
Set up search collections
Search and crawl portal and other sites
Related:
Portal V7.0: Migrating search components
Start and stop servers, dmgrs, and node agents