First, move the PDM libraries from one server to another before syndicating WCM Document Manager Components

Using the process of moving PDM libraries from one server to another, although the documents are exported and imported correctly, the exact path within the PDM Library can change. Since WCM stores the path in the WCM PDM Components, that will cause the WCM PDM Component to have an incorrect path.

WCM stores the path to the object within the PDM library when a Document Manager component is created. For example, we may store "/contentRoot/icm:libraries[x]/folder/path/to/document.doc". The value for 'x' in the path can change for document libraries that are imported from another library. So, When syndicating WCM Document Manager Components, the path to the object within PDM can change when the object is exported from the syndicator and imported on the subscriber. This means that on the subscriber, the WCM PDM Component will have the incorrect path stored.


WCM was changed to correct the path when the WCM PDM Component is saved on the subscriber using ifix PK49150 . There are a couple of things to note in this ifix about syndication of PDM components:

1) In order to fix existing PDM components that have the incorrect path stored on the subscriber, the PDM Components need to be resyndicated.
2) When syndicating the WCM PDM Components, if the PDM Document Library has not yet been imported on to the subscriber, the path to the object in the Document Library cannot be updated, because the document does not yet exist in PDM on the subscriber. The WCM object will still be written to the subscriber, but the path will not have been updated correctly. Once the PDM Document Library has been imported to the subscriber, the WCM components will have to be resyndicated.
3) The same holds true if you delete the document library on the subscriber, and reimport the library in. The path to the document library will change, which means that the WCM PDM Components will have to be resyndicated to update the path again.

Beware of the login attribute length limitation in WebSphere Portal

Beware of the login attribute limitation of 32 characters in length in WebSphere Portal 6.0 using WCM and when connecting to Java Content Repository (JCR) which is nothing but PDM (Portal Document Manager). So when designing and choosing a login attribute ( uid, cn , samAccountName, email) for your portal application you should carefully select or enforce the attribute in such a way that it's not more than 32 characters in length. This really makes the life difficult as you can't even use the basic email address as your login attribute as there is a possibility that some valid email addresses will easily more than characters for example, the world's richest Warren Buffet warren.buffet@berkshirehathaway.com can't even register with your website. Good news to all this is that they support upto 175 character length in the newer WebSphere Portal 6.1 release.

Certain symptoms you might notice are that users with more than 32 characters of login id might complain about missing images or document that is referred in the webpage from PDM or WCM and you might see the following exception in the logs during their login.

Error logging in: com.ibm.content.exception.LoginException:
javax.jcr.LoginException: Unable to establish session with DB2® Content
Manger Runtime Edition for User
 

OutOfMemory errors with WebSphere Portal

WebSphere Portal server might throw OutOfMemory (OOM) errors and might got hung and unresponsive when serving or dowloading large documents through WCM (IBM Workplace Web Content Management ) which are stored in PDM (Portal Document Manager). You might see the following error in SystemErr.log and the JVM might have produced a heapdump,

[5/14/08 14:35:32:984 PDT] 00000086 ModuleManager E   IWKCT1382X: Major exception caught: com.presence.connect.business.module.ErrorExecutingRequestException: IWKMU1062X: Message: IWKCT1366X: Exception caught servicing a Servlet request for PDMProxy, Cause: java.lang.OutOfMemoryError
[5/14/08 14:35:32:985 PDT] 00000086 ModuleManager E   IWKCT1383X: Unexpected error from Module. Details of cause to follow:
[5/14/08 14:35:32:986 PDT] 00000086 ModuleManager E   
                                 java.lang.OutOfMemoryError
        at com.presence.connect.connector.content.ContentAPIConnection.getBytes(ContentAPIConnection.java(Compiled Code))
        at com.presence.connect.connector.content.ContentAPIConnection.getItemContents(ContentAPIConnection.java:516)
        at com.presence.connect.connector.content.ContentAPIConnector.getItemContents(ContentAPIConnector.java:216)
        at com.aptrix.pluto.resource.PDMResourceUtils.createPDMMime(PDMResourceUtils.java:632)
        at com.aptrix.pluto.resource.PDMResourceUtils.getPDMData(PDMResourceUtils.java:419)
        at com.aptrix.pluto.resource.PDMResourceServerModule.getResourceMime(PDMResourceServerModule.java:968)
        at com.aptrix.pluto.resource.PDMResourceServerModule.buildResponse(PDMResourceServerModule.java:516)
        at com.aptrix.pluto.resource.PDMResourceServerModule.retrieveResource(PDMResourceServerModule.java:355)
        at com.aptrix.pluto.resource.PDMResourceServerModule.process(PDMResourceServerModule.java:276)
        at com.presence.connect.business.module.ModuleManager.launchBusiness(ModuleManager.java:121)
        at com.presence.connect.business.module.ModuleManager.launchBusiness(ModuleManager.java:384)
        at com.presence.connect.RequestExecutable.execute(RequestExecutable.java:84)
        at com.presence.connect.dispatcher.Task.run(Task.java:151)
        at com.presence.connect.ConnectClient.processSynchronous(ConnectClient.java:167)
        at com.presence.connect.ConnectServlet.process(ConnectServlet.java:298)
        at com.presence.connect.ConnectServlet.doGet(ConnectServlet.java:120)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
        at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1572)
        at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java(Compiled Code))

In order to resolve the issue please apply the IBM recommended ifix PK66778 and tune the JVM heap size, xloratio , pCluster & kCluster based on your application needs, expected load and the optimum performance. IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer (GCMV) which is a part of IBM Support Assistant Tools can help you tune these parameters based on the Garbage Collection logs history.

PDM portlet not working after upgrading to WPS 6.1.0.2 or WCM 6.1.0.2

You might notice that pdm portlet (Portal Document Library ) might not function properly after upgrading to WPS 6.1.0.2 WP_PTF_6012 (IBM WebSphere Portal, Version 6.0.1.2 Fix Pack)or WCM 6.1.0.2 (WCM_PTF_6012 (Web Content Management, Version 6.0.1.2 Fix Pack), symptoms include,

1) PDM portlet will be unresponsive when you click on any of the folder strcuture and trying to navigate through it as show below.


2) The left navigation file tree view of the pdm portlet will be empty.


3) you may not able to browse the document libraries from the WCM portlet when trying to refer a document component from WCM Authoring portlet.


In order to fix the problem goto the WebSphere Adminconsole (Dmgr or AppServer)and do the following,

When the Document Manager Web module is redeployed, its groups must be mapped to the All Authenticated group in WebSphere. To map the groups, follow these steps:

Select the Document Manager application, as follows:
Expand Applications.
Select Enterprise Applications.
Locate the application that starts with Document Manager.
Click Map Security Roles to Users/Groups.
Assign the Authenticated role to the All Authenticated group.
Save your changes.
Restart the portal or sync the nodes and restart the portal cluster.