Inside IBM WCM : Part2 - How to stop a background WCM library delete

There are occasions when you wish to stop a background Library Deletion process.

First thing to realise is that a WCM Library delete using the WCM Libraries portlet triggers an EJB which does the job. The EJB will lock the library (icon will be greyed out) prior to the start of the process.

In order to stop the deletion process you will need to find the EJB's, remove them, unlock the library and then restart the server.

Firstly, find the EJB id's using the findEJBTimers script. You need the java server name for this:

For UNIX/Linux:

findEJBTimers.sh WebSphere_Portal -all

(For windows use the "bat" equivalent)

This script will return a list of timer numbers. Make a note of these numbers

Next run the script passing the timer number in as a parameter:

cancelEJBTimers.sh WebSphere_Portal -timer xxxx

Repeat for all timers previously listed

Next, you MUST unlock the libraries otherwise the EJB timers will simply restart again when the server restarts. To unlock the libraries, you must use a WCM connect URL:

http://host:port/wps/wcm/connect?MOD=UnlockLibrary&library=libraryname

With the library unlocked you can not restart the Portal.

The delete library task will now be terminated and the delete icon will display correctly.

Inside IBM WCM : Part 1 - When does an item get saved on the subscriber?

Imagine you have a single WCM authoring server and a single WCM delivery server. You set up a syndicator/subscriber pair between them.

As you know, when you examine a content item, the "Last modified date" of the item is shown in the "History" secion of the UI. This is the date the item is saved on the authoring server. But how can you determine when it arrived at the delivery server? If you knew this you could tell how long syndication took to move the item.

The issue here is that if you look at the copy of the same item on the delivery server, the "History" section is identical to that of the authoring server.

We know it must have taken some time for the item to syndicate from syndicator to subscriber - but how can you determine when it actually arrived?

The JCR

All WCM content is stored in the associated Java Content Repository (JCR) which is defined as part of the portal configuration.

The JCR is implemented as a set of tables in a relational database but it is not possible to simply query the relational database since it contains literally thousands of tables and indexes which are, for the most part, human unreadable.

In order to investigate what is going on in the jcr you will need a special portlet - the "WCM Support tools portlet". You can download this portlet from Lotus Greennhouse or request it directly from your IBM rep.

Install it like any other portlet.

With this tool, you can browse the JCR and view all properties of items stored within. Choose the "Browse nodes" option from the menu.

Content items are stored as a series of "nodes" in the jcr. Nodes have "property values" and can have child nodes.

All the WCM nodes are children of the "contentRoot" node in the "ROOTWORKSPACE" workspace. This will be listed under "Children" of the "ROOTWORKSPACE"

The children of node represent libraries shown with titles of icm:libraries

The children of a library node can be thought of as set of "folders" in which items are stored. For example the child "Content" will contain all content items. A full set would be:

• Authoring Templates
• Components
• Content
• Presentation Templates
• System
• Taxonomies
• UI Controls
• Taxonomies

Within the "Content" node you will find site nodes

Within Site nodes you will find site area nodes that match the Site Framework that is visible to the WCM UI.

You can traverse this hierarchy until you find your content item.

Once you find the item and open it, you will notice that it has many properties listed.

The "jcr:lastModifed" property represents the date that WCM last modifed the item. This one is put there by WCM.

However the "icm:lastModified" property is the one that contains the time that the item actually arrived in the JCR. Comparing these two dates on the subscriber gives you some indication of how long the syndication process took to complete for this item. On the syndicator it will show how quickly the save occurred after being processed by the UI (typically a few milliseconds)