One of the key elements in a larger WebSphere Portal installation is the Workplace Web Content Management System (WCM).

The integral part of WCM is the syndication between servers. Syndication replicates data and content from one library to another. Currently there is no way of monitoring if all items or the items intended are moved correctly, and it is extremely difficult to determine if syndication has occurred correctly and with the intended result.

If syndication fails you will notice it in the logs, if you monitor the portal. But there are no alerts or triggers that will make you aware of the problem.

This is where a new asset from IBM comes in handy. The asset is called WCM SMART, and as you will see in the following article the asset will be able to help you address the key issues above.

Now you might ask yourself what is an asset? How does it differ from a product from IBM?
If the service organizations (IGS, SWG Services, GBS, GTS) that usually only work on time/material contracts or solutions for single customers generate a piece of code that can be bought by and will be offered to more than one customer, they call it an asset. At times assets end up becoming part of the official product.

SMART provides the ability to analyze syndication states of WCM items across syndicators, it helps you to keep an overview of all syndication pairs and to quickly obtain an overview of their current state. If something is wrong with the syndication, it allows you to drill down and obtain further information on what is wrong with the syndication. SMART also allows you to setup notification alerts if syndication fails in any way.

SMART is based on 2 components, SMART services and the SMART core.

SMART services are responsible for keeping and eye on the state of the WCM items, and are deployed on both the syndicator and subscriber servers.

The SMART core is the main GUI component, it consists of a monitoring, notification and scheduling engine, together with a set of portlets.

The Installation
 
Since this is an asset, the installation instructions and information about the asset are very limited. When aquiring the asset from IBM, it includes a full installation and configuration guide. But as the install instructions and files may only be distributed by IBM, I will give you a brief overview of what needs to be done during the installation, without going into too much detail.

First of all, the installation requires:

• JDK 1.4.2,
• WebSphere Portal and WCM 6.0.1.4 (or higher),
• WCM fixpack 15,
• and DB2 v8.2 (or higher).

Note: When we installed SMART it required us to install fixpack 6.1.0.29 (or above), in order to get SMART working (PK85473), otherwise it would give us the error “ERRORCODE=-4471”, when accessing the portlets.

The following overview is just meant to give you an idea of what is needed to install SMART, and get it running. The complete instructions are obtained from IBM, when acquiring the asset.

1. SMART comes as a .zip file, so you should unpack it into folder
2. DB2 database WSMARTDB should be created and configured, as per the install guide
3. JNDI datasource should be created
4. Deploy SMART Services (WCMSmartServices.war) from the deployment manager
5. Deploy SMART Core portlets from Portal Admin, on both subscriber and syndicator
6. Create the Websphere Portal page that contains the portlets deployed. This would typically be located in the administration section.
7. Create syndicator pairs in the SMART configuration portlet
8. Configure notification and alert settings
9. Seed the SMART database or do a full rebuild for each of the syndication pairs*
10. Configure the SMART scheduler – to indicate when should it run
11. Rebuild each syndication pair
12. Configure the Reporting portlet

*It is recommended to seed the SMART database unless you have very few WCM items. This is one of the areas of the installation that could have been done more elegantly. You will have to export/import .csv files.

Export is done using an “export” .jsp file, and the import is done using a command line tool called WCMSmartDataUpload.

The installation and configuration guide is quite easy to follow, but as this is an asset, it is not a wizard driven installation. Some things need to be configured and done manually, that’s what makes the installation less elegant than it might have been, but the guide does a good job in explaining what needs to be done and in what order.

The following files are distributed with the WCM SMART asset.

Figure 1. SMART.zip file contents

If you look into any of the .war files, you will see that they are actually Portlet Factory projects (reference to other Portlet Factory articles in The Sphere). You can import these files into an existing Portlet Factory project, but since SMART uses some imported java builders, you will not be able to modify the code - you’ll only be able to study it and learn how they built it.
The ability to modify the code in forthcoming versions would make for a great feature, making it possible to customize some or even the entire asset if it were eventually to become part of the product.

Here you see a screenshot of the SMART Portlet Factory models, after they have been imported into an existing project.

Figure 2. SMART in Eclipse (click image to enlarge)

The SMART Portlets
 
Now let’s have a look at how you use the portlets that come with the asset. During the install and configuration you have deployed the portlets to the portal server, so they are ready to be used.

On the page you set up during the installation  start with logging into the portal server and locating the reporting portlet.

Figure 3. WCM Smart page (click image to enlarge)

As you can see from the figure above, the way we set up the WCM Smart portlets was by creating a new page as part of the Administration area in the portal. The portlets were then added as any new portlet in the portal environment.

The page has been split into 3 subpages:

Monitoring (SMART Monitoring portlet)

This is where you get an overview of the syndication pairs, as to when they have last run, and if monitoring has been enabled etc.

Figure 4. Monitoring portlet (click image to enlarge)

The monitoring portlet contains,

• Email settings
• Notification history
• Scheduler status (log and start/stop scheduler)
• Syndication pair settings (the syndication pairs defined, and their current status)

Let’s have a look at adding a syndication pair, which is where you configure and determine where and how often, the syndication should be monitored.

Figure 5. Add syndication pair (click image to enlarge)

As you can see it is fairly simple to set up the syndication pair  Give the pair:

• A pair name
• The syndicator and subscriber servers
• Which library it should monitor

Administration (SMART Admin Configuration portlet), this is where you:

• Edit and view you scheduler settings
• Set logging levels
• Edit property files (Scheduler properties and WCM Smart properties)

SMART Log (SMART Reporting portlet)

Here you can monitor the syndication. Each of the syndication pairs defined in the monitoring part can be watched from here.

This is what you see in Figure 3

As you can see in the portlet, we currently have no syndication errors, otherwise the “report count” column would show how many items were error items in each area for each of the syndication pairs defined.

When selecting a syndicator-subscriber pair, you receive a report on:

• Published/Drafts/Deleted/Expired documents missing on either the syndicator or the subscriber server
• Title mismatch across servers
• Modified date mismatch across servers
• Deleted and expired on syndicator, but published on the subscriber server

If any of these report an error item count, you can click on the header and get more information on which items are problematic. This is called an analysis report.

In the analysis report you can see the UUID of the item in question. The UUID can be used to find the item in the library. Now use the “Support Tools” in the administration page (under the Portal Content section) to locate further information about the actual item. There is also a .jsp called displayNodeV3.jsp, which is distributed together with the SMART asset. This .jsp can also be used for the same purpose.

After having located the items that were problematic, you can resolve conflicts and eventually contact the owner of the items.

That way you can resolve syndication problems.
 
Syndication Types

Several features could be improved, but since this is an asset, there is no active development on the code. An asset should “as a general rule” be seen as a “take it as it is” product. Only if there is enough interest from customers might the asset turn into a product or part of a product.

During our initial install of SMART, we found two issues that were essential for us to get fixed, or at least get a workaround to address:

1. SMART only allows synchronization of all items. There is no way to differentiate between all items and live items.

   If your environment has been set up only to syndicate live items, SMART will report errors on all deleted items in the authoring environment, as the items are obviously not available on the rendering side.

   It means that when some pairs syndicate all items, and some only live items, we cannot trust the errors that SMART reports.

   A modification could be done by creating an option when creating pairs, to enable “live items only” or “all items”.

   However, if you are only using “all items” syndication, help is on the way. Below you can find a workaround for this particular issue, until it is fixed in the asset.

2. There is no way to setup notification thresholds, as to when SMART should alert about errors.

   This means that you will receive many mails for the same error (and even more with the first issue not being solved), making it spam the mail box.

   Depending on the setup, if you syndicate all items, it is advised to turn off mail notification. If syndicating only live items, you should just think twice before adding a person to the notification list.

Unless you want to write your own SMART code, you’ll need to look at workarounds, and inform IBM about the needs and changes you would find necessary.

For the time being , let’s go back and look at issue 1 and consider a possible workaround,.

By searching and looking a bit at the Portlet Factory models in the WCMSMART directory, we found that there is a file called DB2SQL.xml. This is the file that contains many of the SQL statements executed in order to get the reports back to the portlet.

If you look in the file - each SQL statement has a tag called this contains information about what that statement is used for – e.g., “Expired and Deleted on Syndicator and Published on Subscriber”. The tag after the tag is the tag. Each of these statements can be modified to suit your needs. In our example we would want to add a
“AND Syndicator.STATUS=’PUBLISHED’, that way we are only looking at “PUBLISHED” items both on the syndicator and on the subscriber.

The file can be located in the .war files and directly on the server (after deploying the portlets). As an example this could be the location of the file on the portal server:

/installedApps/wp61-auth0-prod/PA_WPF.ear/WCMSmartCore.war/wcmsmart/sql/DB2SQL.xml

However as this is a workaround, it does not support the mixed syndication pairs, i.e. if some are live items and some are all items.

As you can see, you can manipulate the SQL queries quite easy, making it possible to change what SMART is actually monitoring.

The Future of SMART
 
Due to the fact that SMART is an asset, information from IBM about what is happening to the asset in the near future is very limited.

There are rumors that some parts of the SMART asset will be part of Websphere Portal 7.x, but we have not seen or heard the actual plans for this. In any case, there is no question about the fact that Portal needs to improve the way syndication is monitored.

The two issues that we briefly touched on in this article will be fixed by IBM. IBM has not committed themselves to a time schedule for this, but they have indicated that it will more than likely happen during the next few months.

We hope that IBM will either:

1. Make both Portlet Factory models and java source code publicly available, so that the customers can expand the original asset to suit specific needs.
2. Improve SMART so that it will match how syndication actually works, giving more options for the customer on how it works - then eventually make it part of the Portal product.