The developerWorks Connections platform will be sunset on December 31, 2019. On January 1, 2020, this blog will no longer be available. More details available on our FAQ.
Coding IBM Collaboration Solutions
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.[Read More]
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.[Read More]
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 18.104.22.168 and V6 is based on Portal 22.214.171.124. 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 ;)[Read More]
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.[Read More]
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.
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:
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 :
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
Hope this helps prevent some unnecessary troubleshooting.[Read More]