Portal administration and performance
An important caching technology to ensure good performance in WebSphere Portal is fragment caching. Portlet html fragments are cached for reuse for subsequent requests.
Due to an issue with the install scripting in Portal 7 and 8 fragment caching on any secondary nodes in a cluster was not working. This issue was fixed with CF15 for WebSphere Portal 220.127.116.11 and 18.104.22.168 and CF1 for Portal 8. If you created the secondary node(s) though before having the fixes applied fragment caching on secondary node(s) will not work.
To verify if you are having the issue - check if the file cachespec.xml exists in the <profile>/properties directory on the secondary node(s). If the issue exists on your system and you are using fragment caching you should copy the file from the primary node and restart to fix the problem. To verify that the issue is solved you can leverage the WebSphere Application Server Extended Cache Monitor. After installing it, check the base cache to ensure that fragment cache entries are inside the cache after hitting a page that has portlets that use fragment caching. A sample entry could look like this:
/wps/PA_WCMLRingPortJSR286/Web Content Viewer (JSR 286):Z7_18GAHIS0I8T970IBKLE1L20NR4:anonymous:text/html:en, en-US;q=0.9:ZM_CGAH47L0004820IDBHD79M0047:UTF-8:normal:PUBLIC_CONTEXT=mylibrary/content/welcome&pcid=032scfc-42c5-4342-8502-bfaa9c365f82:UTF-8:requestType=GET
You can find more information about the WebSphere Application Server Extended Cache Monitor here: http://www.ibm.com/developerworks/websphere/downloads/cache_monitor.html
WCM customers frequently want to preview draft WCM content in an actual WebSphere Portal context before approving that content.
Out of the box, WCM only supports a “preview” button on the WCM Authoring GUI that will pop-up a window in the browser and display draft content via the presentation template assigned to that content. However. the methods that a user might use to get to this new component cannot be preview. Fro example, the preview button does not allow the viewing of new draft content in an existing WCM Menu component.
This topology and code sample code provides one solution for this problem.
To implement a preview server topology, we need at least 3 servers. The high level picture looks like this:
From the picture, you can see that the WCM Authoring Server is a syndication source. It will syndicate content to two systems. One is the Production Rendering Server. The other system is the WCM Preview Server.
The WCM Preview Server is a subscriber only; it will not syndicate content but only receive it. Further, in Portal 7, all page definitions that are required to render content via WCM rendering portlets must be defined. In Portal 8, Portal pages themselves can be syndicated along with the WCM content.
Once content is syndicated to the preview server, it will automatically be advanced from “draft” status to “publish” status. By doing this, all content will immediately render (on the preview server) via the Portal page's WCM rendering portlets. So, for example, content which is “draft” on the authoring server will appear on the preview server in WCM menus exactly as they would ultimately appear on the production rendering server.
An approver could look at the draft content in a traditional Portal content on the preview server. If the approver wishes to advance the draft content in it's workflow after previewing it, he would go on the authoring server and move the draft item to the next stage of the workflow. Ultimately, the content would move to the publish state on the authoring server and be syndicated to the production rendering server. Note that it would also re-syndicate to the preview server with a new state.
In order for this scheme to work, all content that syndicates to the preview server will need to move from the “draft” state to the WCM “publish” state automatically. By moving to the “publish” state, the draft content will be viewable in the WCM rendering portlets contained on the actual portal pages.
One approach to automatically covert this content to the “publish” state would be to write Java code which listens for the updating of items on the preview server. The mechanics of the process rely on fact that WCM can generate a JMS message anytime an item is created, updated or removed if configured properly. When an “itemUpdated” event occurs on the preview server WCM will fire a JMS message. This JMS message will contain the identification of an item that was updated.
The act of “subscription” causes an item to be updated on the preview server. If the item that is syndicated is in “draft” state, JMS handlers will be deployed on the subscriber which will consume the JMS “itemUpdated” message. The new JMS handler (a Javabean) is notified as each item is processed on the subscriber. This Javabean will iteratively move the syndicated content thru it's workflow stages until it reaches the “publish” state. This conversion to “publish” state will allow the content item to be shown in Portal pages and WCM rendering portlets.
Sample code is included which consumes the JMS itemUpdate message and iteratively moves the item thru the item's workflow stages until it reaches the “publish” state.
Simply install the provided EAR file as a WebSphere Application.
WCM Setup Required
In order to use the code, WCM must be configured to generate JMS events on an item update event. To do this, refer this WCM configuration URL.