 |
|
Domino Portal Integration: Commentary, Examples, and Ideas Van Staub works for IBM as the technical team lead for the Domino Portal Integration team. Primarily, Van and his team integrate the following IBM products: Lotus Sametime, Lotus Domino, Lotus QuickPlace, Team WorkPlace, Quickr, and WebSphere. In his free time, Van spends much of his time with his wife and two dogs in Atlanta and travels to his hometown, New Orleans, quite frequently.
|
|
|
Sametime 8.0.1 and Portal Integration
Sametime 8.0.1 has released a complementary toolkit called the "Sametime Connect Web API Toolkit". To quote from release notes, "It allows Web developers to Sametime-enable their Web pages and applications with "livenames." Web-based applications that integrate the Connect Web API are essentially able to proxy the functionality of the locally running Sametime Client (managing contacts, starting chats, Presence status)."
First, I'm not sure I've found any public documentation on this. I'll have to check with some IBMers, but here is where I am going with this. The Connect Web API isn't a replacement for STLinks, but sure seems like a good candidate for exploring alternatives to the STLinks architecture.
Everytime you access Portal, a multitude of checks occur to determine if the logged in user is "Sametime capable". If so, the STLinks applet then loads and viola, awareness, chat, endless chat requests for your help, etc. If you're using dual directory - more overhead. The most common "statement" I've heard is that once an admin enables Sametime, performance in Portal is degraded. This isn't surprising, but could the Sametime Connect Web API Toolkit could be the performance capable alternative.
Likely the first obstacle to this is entitlement. There's a reason you're using STLinks and not the Connect client. If I am not mistaken, the Collaboration Accelerator package for Portal gives you web capable chat, but not the Connect client (I don't sell it, just support it). So if you've got a Connect client, it would be extremely interesting to do a conditional check to the Connect client and if present, use it rather than calling the and tags to load STLinks. Even more interesting would be a performance comparison between the two.
I'd like to explore this in more detail, but if you have already experimented with this, post a comment.
Categories
: [ API | Connect | Sametime ]
Jun 25 2008, 08:23:19 PM EDT
Permalink
|
|
Nawlins and Java
I drove back to the NOLA the other weekend and found myself listening to a good bit of podcasts along the way - mainly from the Java Posse and developerWorks. More than one seemed to question the longevity of Java. Both IBM and the Java Posse have some great dialog on the subject:
The takeaway ... Java and the Java language are not always synonymous. The legacy of Java is likely to be ensured by the JVM rather than the language, which may simply evolve with the community in various forms such as Groovy, Jython, or perhaps JRuby.
Categories
: [ Java ]
May 27 2008, 11:42:28 PM EDT
Permalink
|
|
My QuickPlaces and Quickr 8
There's an interesting pitfall that new Quickr 8 for Domino customers encounter when migrating from QuickPlace to Quickr. The My QuickPlaces portlet is not compatible with Quickr 8. IBM has withdrawn support for My QuickPlaces in Quickr 8. So your new Portal 6.1 server will have the option to install My QuickPlaces, it just won't be supported with your new Quickr 8 for Domino server. Or that accelerator package that gets you Quickr because it's bundled ... you'll need to use the My Places portlet to integrate the Portal and Quickr world. The My Places portlet kinda fills the niche, but only slightly. My Places simply gives you a list of place - no more my tasks, pages, search, etc. Quickr 8.5 is planned to provide a new portlet to integrate better Quickr 8 for Domino and Portal. Until then, you can force the experience via RSS feeds, Web Clipping portlets, duct tape, or the always fun weekend project - build your own portlet.
Categories
: [ MyQuickPlaces | Quickr ]
May 16 2008, 12:19:19 PM EDT
Permalink
|
|
LTPAToken2
It's been sometime since I've had a chance to post. My team also supports Quickr for WebSphere Portal, and needless to say - we've been busy. Let's briefly bring up LTPAToken2 support. LTPAToken2 has been around in Portal 6.0, but I seem to be getting the inclination that it may be a touted feature in Portal 6.1. LTPAToken2 is simply the next generation of LTPAToken Single Sign On (SSO) support. Those enterprises looking for more secure forms of SSO might find LTPAToken2 desirable. Beware of two limitations when moving to LTPAToken2:
1. DIIOP does not yet support LTPAToken2. This means that any custom code which leverages creation of Notes Sessions using a token must do so with the legacy LTPAToken. This will effect the Domino Extended Products portlets. Those Portals with heavy NotesView portlet integration should simply weigh the need for LTPAToken2 with the possible lack of features in NotesView.
2. The Sametime STLinks API does not support LTPAToken2 at this time. Within Portal, you can configure the STLinks API to pass a STToken rather than an LTPAToken2. This is fairly easy by setting useLTPAToken=false in the CSEnvironment.properties. The trade off is additional overhead in creating connections to Sametime to obtain a STToken.
The point here is to be aware that LTPAToken2 support available in Portal does not guarantee that legacy portlets will operate will the same feature support previously seen in Portal 6. When in doubt, test or give support a ring.
Categories
: [ LTPAToken | LTPAToken2 ]
Apr 30 2008, 08:43:08 PM EDT
Permalink
|
|
DEPP Hotfixes
I've uploaded a DEPP cummulative hotfix for those possibly interested in downloading and applying. I'll try to update the server on a regular basis so that updates are available as soon as support is aware of a bug.
The V5 version is based on Portal 5.1.0.5 and V6 is based on Portal 6.0.1.3. If you are not using that level on your current server, you can still apply the fix. The DEPP portlets and CS.jar operate fairly independently of the underlying Portal version. Just ensure that you apply all the relevant files in the hotfix.
As always, backup before applying and read the readme ;)
Categories
: [ DEPP | Hotfix ]
Feb 15 2008, 04:28:07 PM EST
Permalink
|
|
Portal Federation
My team manages a fair amount of server configurations. We support three major versions of Portal integrated with Lotus Domino, QuickPlace/Quickr, and Sametime. So it's easy to see that the number of servers and their configurations grow quite quickly.
At one time, we had three LDAP vendors (Domino LDAP, IBM Directory Server, and Active Directory) paired with its own Portal server. QuickPlace and Sametime were then paired with a respective Portal and LDAP server. All in all, at a minimum that makes 15 servers.
To consolidate, we use Portal LDAP federation. The Portal Infocenter makes a fair attempt at explaining this; however, I find the following technote much more helpful: How to configure WebSphere Portal for multiple LDAP servers. This allows us to use three versions of Portal federated to three LDAP servers.
Technically, you can further reduce the configuration overhead by federating the three LDAPs to QuickPlace by configuring QuickPlace to use Domino directory for authentication and setting up directory assistance to the various LDAP servers. The Sametime server's stconfig.nsf databases's LDAP documents can be copied to federate the LDAP servers with Sametime. Be aware that if you copy the LDAP documents, they should point to different LDAP server FQDNs. The LDAP servers can physically reside on the same server, but you should set up DNS or local hosts files to separate them out as ldap1.ibm.com, ldap2.ibm.com, ldapN.ibm.com. I assume that Sametime stores the LDAP settings using the LDAP FQDN as a key so multiple documents with the same FQDN will overwrite each other.
We tried the above QuickPlace and Sametime configurations with some success but eventually opted to use a single IDS LDAP. Ultimately, you do want to keep the environment as simple as possible if you can. This always limits the likelihood of a "less than tested" issue from arising. But if you're pressed for space, servers, or the adventureous type, some form of federation may assist you in server consolidation.
Categories
: [ LDAP | Portal ]
Feb 14 2008, 07:30:14 PM EST
Permalink
|
|
Sametime's Case-Insensitivity
I was reminded today by a colleague of a subtle nuance of Lotus Sametime and WebSphere Portal integration. For those not familiar with this area of integration, WebSphere Portal directly uses the STLinks toolkit from the Sametime server to provide awareness and chat capabilities with the Portal offering. The Sametime Links Toolkit (STLinks) has been released for some time now, and little has changed with respect to WebSphere's usage of the toolkit except for one seemingly minor detail.
WebSphere Portal initiates the Sametime applet (STLinks) which is responsible for direct Sametime server communication via the toolkit's Javascript function, writeSTLinksApplet(). In Portal V5 and V6, this appears similar to the following in the HTML page source:
writeSTLinksApplet("uid=idsuser1,cn=users,dc=ibm,dc=com", "nHrxIukUwZxbTDDDfqkx7PU8SM3UBjbt25uzMTfLAkbqTZUPuu3ULaHW4dtJtBGhYSl4SvKIK1OA6Oj
R5/MGCspSPl4nlD91dqRmNOhhxwJDib59nv4YlZZnjxgWHHk4GBJqsMnc9dZaTLd776FDxDA3ImGFKBWpeExrmDZJHDq7+zTDN0pZGe86Qhr0/g1ZxJOJq8R7nl+3Cj5qOI+jL
0IyeabmiQ3LhzIL48x/OXyw06uKHhVm2OxSBLBbXxv/XDU+hBlyxclBHiTrBp9WV7A3mf4kbFql1Hxg1e7kMutJRw3eFDjx1B+yWCKmK7FO", true)
Depending on your LDAP directory, the case of the LDAP user's distinguished name might be the lower case uid=idsuser1,cn=users,dc=ibm,dc=com as in the example above or mixed case UID=idsuser1,CN=users,DC=ibm,DC=com. This minor detail has an impact on WebSphere Portal V6's ability to easily integrate Sametime. In Portal V6, the distinguished name that is used as the first argument in the writeSTLinksApplet function is always lower case. WebSphere does this by default (designed behavior), and the result is the example shown above. If the case in LDAP differs, you'd ideally want Portal to use the following STLinks function call:
writeSTLinksApplet("UID=idsuser1,CN=users,DC=ibm,DC=com","nHrxIukUwZxbTDDDfqkx7PU8SM3UBjbt25uzMTfLAkbqTZUPuu3ULaHW4dtJtBGhYSl4SvKIK1OA6Oj
R5/MGCspSPl4nlD91dqRmNOhhxwJDib59nv4YlZZnjxgWHHk4GBJqsMnc9dZaTLd776FDxDA3ImGFKBWpeExrmDZJHDq7+zTDN0pZGe86Qhr0/g1ZxJOJq8R7nl+3Cj5qOI+jL
0IyeabmiQ3LhzIL48x/OXyw06uKHhVm2OxSBLBbXxv/XDU+hBlyxclBHiTrBp9WV7A3mf4kbFql1Hxg1e7kMutJRw3eFDjx1B+yWCKmK7FO", true)
The above example is the behavior in Portal V5 - not so in Portal V6. Portal V6 changes all distinguished names to lower case. If you've ever designed your own application to use STLinks, the immediate response is, "so just change the case". This brings us to the relatively unknown nuance. The second argument in the writeSTLinksApplet function is the LTPAToken. The LTPAToken is a single sign on mechanism which is an encoded string of the LDAP realm, user's distinguished name, and expiration time. If attained from Portal V6, the token contains a distinguished name that is - you guessed it - lower case. When the Sametime server logs the user in using the writeSTLinksApplet call it will compare the name sent in the first argument and the name decrypted from the LTPAToken. If they differ (in case for example), no login to Sametime occurs. If you're troubleshooting but using the user's password as an argument, you might notice that you achieve awareness successfully. Again, the issue with case occurs only when using the LTPAToken.
This is a fairly long post for the simple fact that if your users in LDAP contain mixed case characters (Domino LDAP and Active Directory specifically), you will require a case fix applied to Sametime when integrated with Portal V6. If using Sametime 7.5.1+, this is trivial as a workaround is inherent in the product. If you're using any previous version of Sametime, you may need to contact support for added assistance. If using Sametime 7.5.1+, update the stlinks.js file's STlinksCaseSensitive variable to :
var STlinksCaseSensitive=false;
Append the AWARENESS_CASE_SENSITIVE=0 argument to the STLINKS_VM_ARGS property and add the AWARENESS_CASE_SENSITIVE=0 property value pair to the [Config] section. For example,
[STLinks]
STLINKS_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause -Xrs -DAWARENESS_CASE_SENSITIVE=0
[Config]
AWARENESS_CASE_SENSITIVE=0
Hope this helps prevent some unnecessary troubleshooting.
Categories
: [ Portal | STLinks | Sametime ]
Feb 13 2008, 08:08:53 PM EST
Permalink
|
|
|
| S | M | T | W | T | F | S | | | | 1 | 2 | 3 | 4 | 5 | | 6 | 7 | 8 | 9 | 10 | 11 | 12 | | 13 | 14 | 15 | 16 | 17 | 18 | 19 | | 20 | 21 | 22 | 23 | 24 | 25 | 26 | | 27 | 28 | 29 | 30 | 31 | | | | | | | | | | | | Today |
|
