Integrating Quickr with IBM WebSphere Portal

If the subject of the Quickr / WPS integration is of interest for you, here is an article on the IBM Quickr wiki, which proposes a very simple and light solution:
Integrating Quickr with IBM WebSphere Portal

Basically, the approach is based on the new tool 'Web Application Integrator for IBM WebSphere Portal" which gives the ability to include some part of the portal navigation in any web application (like Quickr).
So integration is achieved by "injecting" Portal navigation markup into Lotus Quickr at render time, leveraging the new V6 portal capability (WPS is now able to expose its navigation through REST WebServices).

I did not test this solution, but it seems quite simple (and a simple solution is often a good solution).
Assuming you have choosen to deploy WPS and Quickr on 2 separate servers (mainly for performance reason...) this kind of approach could probably ensures a seamless integration for your end-users...

If some of you did test this tool, please feel free to give your feedback...

Quickr and ECM integration

In one of my last post about Quickr (Quickr and ECM relationship), I was mentioning how an Enterprise could include Quickr in its own Document Management (ECM) strategy, and how both tools could be used together. It's important because companies have to leverage their existing ECM solution (like Documentum, FileNet, LiveLink, Alfresco, etc), and also to provide tools to improve collaboration between peoples.

My point of view was that Quickr should be used as a "front end solutions" (to manage "draft" documents or working copy), compare to the existing ECM which could play the role of a more reliable back-end for storing or archiving "Corporate documents".
On the Quickr wiki, there is now an example of how to use the Quickr Document Services to publish content between Quickr and Documentum: Quickr and Documentum

The solution has been implemented by Infosys. This movie briefly describes how the solution works from a functional point of view: see

This integration approach between Quickr and Documentum clearly illustrates what could be the role of each tool: the Collaboration tool is made to initialize the "draft" (or version V0) of a more official document that has to finally be
approved by the boss. The first version of the document is created in Quickr, where a team of colleagues collaborate on the first n versions of the document. Once the document is finalized, it is simply "moved" in Documentum, where the boss can validate it.

As described in this article: "The integration of collaboration platforms such as IBM® Lotus® QuickrTM with any ECM solution, faces numerous challenges. These include leveraging the existing centralized ECM system and driving the collaboration via Lotus Quickr, presenting a unified user interface for Lotus Quickr and the ECM system, having seamless content management processes across both systems and managing documents between the two."

The example that is presented on the Quickr wiki seems to describe a very basic approach: the document is simply moved from Quickr to Documentum. Then Quickr probably only keeps a "link" to the document (only the main META-DATA and a reference link to the ECM repository) in its own database.
After the move operation, the document reference is still available from Quickr, but it is physically stored in Documentum.
So in this example, the Quickr repository is clearly separated from the ECM repository. The document is first stored in the Quickr storage (JCR 170 database, for WPS implementation) and an explicit user action is required to move it to the ECM database.

The problem is that people will probably not do the effort of moving documents from one repository to another...So documents will remains in the Collaborative tool database...forever.
Moreover, end-users will probably not understand what is the difference between the Collaborative and the ECM repository, and why and when they have to use each solution separately.
A better approach (both for IT team and end-users) would be to have the ability to replace the Quickr Document repository to plug it directly on their own ECM solution database. But this is probably a bigger challenge...
I will try to investiguate to see if it is really feasible, or if a more pragmatic approach must be used...but this will be the purpose of a next post.

Quickr components definition

This WE, I spent some times to browse and read the Quickr Wiki.
There are a lot of useful information to start understanding this new product. However, it is sometimes difficult to understand the meaning of each technical term, and the role of each component. So I have tried to define in this post, some of the main concepts on which Quickr is built.

What is the Quickr Content Service layer ?

Basically, the Content Service is the interface which exposes features for manipulating content in Lotus Quickr.
The Content Service provides diverse set of clients and programming models (such as REST- or SOAP-based protocols) to manage the Quickr data.
Using this layer, you can launch action to create, manage, update, search, query, and delete Lotus Quickr content, simply by lauching a web service call (with the proper input parameters).

As a result, with a basic Client (like a browser) you can launch an http request (formatted as a REST URL), to trigger an operation in the Quickr Content Repository (ex: WPS Portal JCR 170 Database). For instance, using a simple REST request, you can create a new "folder" in Quickr, or you can delete a document.

An other type of Client can be a Quickr Connector (see definition below). For instance, a Connector installed on the MS Outlook Client can interact with the Content Service layer to publish a mail attachment in Quickr.

What is the difference between the Content Service definition and implementation ?

Lotus Quickr uses a services oriented architecture to access content. Quickr defines a set of open services, that makes it possible to access content remotely for manipulating content in Lotus Quickr.

The Content Service stays on top of a repository (or a back-end) which can be implemented using different kind of technologies (Java, Domino, etc).

Whatever the type of the repository, the Quickr Content Service layer should present a unified user interface.
So the Service definition is the common way to define this interface, and the features that are exposed.
The Service implementation is built on the concrete "back-end side", and corresponds to the core of the features and methods which run within the back-end application and interact with the back-end data model.

Currently, only 2 Services implementation have been provided by IBM: the first is Lotus Quickr Services for Lotus Domino and the other one is for WebSphere Portal.
When using the Websphere Portal implementation, the Quickr repository relies on the WPS JCR 170 Database, and the Quickr API use the java portal runtime to execute.


What is a Quickr Connector ?
A Quickr Connector can be considered as a Client plug-in, which is designed to interact with the Quickr Content Services layer.

For instance, the Microsoft Exchange connector should be installed on the end-user computer, in the Microsoft Outlook Client.

Using this connector, the user will be able to see the list of his/her Quickr Places (directly from the Outlook window), and the user will be able to publish or retrieve mail attachment documents directly in the Quickr repository.

The list of Lotus Quickr Connectors (provided with the Content Integrator tool), at publication time is as follows:

• IBM Lotus Notes/Domino
• Microsoft SharePoint (supports WSS 2003/2007, SPS 2003, and MOSS)
• IBM Lotus Quickr services for Lotus Domino
• Microsoft Exchange
• IBM Lotus QuickPlace
• IBM Lotus Domino.Doc

Portal pages syndication

I still continue to send my "message in the bottle" on the ideajam forum. There is also a place dedicated to WebSphere Portal, so I proposed this idea about portal pages "syndication": see

In our company, we are using WPS version 5.x and the existing tool - to export pages from one authoring server to the live environment - are really limited !
Using release builder is simply not an option for us, because it is not able to manage only the new pages creation or update. For any company that has a big intranet site, it is not really possible to built a release by analyzing the full page list of the entire site...it is probably feasible for small site, but this is not our case.

Moreover (a bigger problem), most of other portal administrator I have talked to, think that release builder is not really reliable, and it cannot be used as a basis for an automatic export/import process. This issue was also explicitely mention in one presentation in the 2007 WebSphere Conference (Munich): "do not use r-b without verifying the content of the xml file...because it might contain additional delete operation which are not wanted....". So basically, it is simply not usable to build an industrialized a process.

So we decided to build our own "transport process" mechanism, based on the xml-access tool, and custom XSL and ANT script...This works fine, but this require to fully understand the complexity of the xml page structure, so be carefull if you are thinking to develop a similar solution. The most difficult issue is to manage properly the delete operation on the source server and to propagate them to the target server...another problem is to avoid loosing the User Portlet preferences on the target server....so it can be tricky depending on what are your need.
In addition, we now provide a user interface (Portlet) to allow the end-user to select which part of the site he want to export, and to launch the process manually whenever he want.
If some of you are interested about such a tool, I can post more information about it.

Also, note that in the WPS V6.1 release, IBM will provide a new web interface (Portlet) called "Site Management" which will provide a similar feature for end-user. But it is still limited: by example, the user must specify the unique name of the page he wants to export, and also the location where to insert the page in the target site structure...No doubt IBM will improve this feature in the next release, but this is a quite good start for people which don't want to develop their own solution.
Just to finish on this topic, I think that the "Site Management" solution will use an RSS based mechanism to publish the pages on the target environment. This producer / consumer pair is similar to the syndicator/subscriber principle in WCM. I think using RSS (or any xml over http mechanism) is a good approach, and I hope IBM will be able provide more user-friendly and flexible tool in the futur....that's what our user want !

New ideajam about WCM

I found this new opportunity to share information about the WCM product, and to propose evolutions for the product:
ideajam Lotus WCM

I posted a proposition about adding multi-language as a core feature of WCM....just in case :-)
see