Wednesday, 23 September 2009

Using Sametime Links within a simple portlet

Whilst helping a colleague prepare for a Portal demo, we had one final hurdle to climb; how to enable Sametime awareness for a generic user e.g. Customer Services Rep, without needing to deploy the normal Sametime Contact List or Who Is Here portlets.

I knew this was possible, and think I'd actually done it in the past - however, I couldn't find any notes or blog postings, so had to start again.

Having previously set up Portal and Sametime integration, it was a relatively simple matter - I chose to use the Q&D approach of creating a JavaServer Page (JSP) file, and then rendering it on the portal page using the out-of-the-box Blurb portlet.

This is the portlet that IBM uses throughout WebSphere Portal to present simple messages, including the "Welcome to WebSphere Portal" portlet that has been deployed in WebSphere Portal for the past few releases.

To achieve this, I created a file called sametime.jsp and deployed it in the Blurb portlet's JSP directory: -


Here's the source of sametime.jsp: -

<link rel="stylesheet" href="" type="text/css" />
<script type="text/javascript" src="">
<script type="text/javascript" >
setSTLinksURL('', 'en');
STHost = '';
<script type="text/javascript">
writeSametimeLink('CN=domadmin,O=ibm', 'Portal Admin', false, 'icon:yes;');

As you can see, we're using JavaScript tags to specify the Sametime server ( in order to get both the Cascading Style Sheet and JavaScript code for the Sametime Links API, as well as to actually connect to Sametime ).

The value specified in the writeSTLinksApplet() call sets the domain from which the outgoing Sametime chat will be displayed e.g. when clicking on the Sametime link, a chat session will be opened up FROM ibm/Guest.

Finally, the value specified in the writeSametimeLink() call sets the Sametime user to whom we want to send the ST message - in our demo, this will a user such as Customer Services Rep or something similar.

Make sense ?

I have to admit that I borrowed much of the above JS coding from Daniele Vistali's most excellent blog post here: -

I love my post helped :) there.

Since where at it. Don't you think the whole Domino integration thing is a bit outdated.

We still rely on the old API from portal 4.1 to access domino / st / quickr etc.

The api is old, limited and could be improved a lot with some new ideas:

- Support for multiple domino servers not necessarily sharing a domino directory (currently you can only browser servers with a shared domino directory)
- Better documentation for the API
- Better configuration (move from to WAS properties)
- Better design as a set of portal service that allow for access of pre-configured and on demand backend servers.
- Exploitation of the credential vault API to create domino sessions using shared slots.

Can you see anything happen in the future of portal ?
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]