This week we configured the integration of Lotus Quickr into Lotus Connections Activities and Communities. We experienced some minor problems of which I like to write here, so you don't step into them, too. First of all, the configuration is quite straight forward and looks more complicated on first glance, than it actually is, so don't be afraid of it.
Activities
How Activities need to be configured, is described in the Infocenter, here. However, we had the problem, that we were not able to connect to the Quickr server that we configured. The reason of that was, that we used a self-signed certificate for the HTTP server, since it was only a proof of concept installation. But first, some words, how the Activities integration works.
For querying the Quickr server for places, Activities uses a REST service of Quickr and since Activities is mainly based on AJAX, the REST request is sent via JavaScript. For security reasons, the JavaScript script can't access the quickr sever directly, since it runs on a different server that the connections server. So the request is delegated to a proxy running on the connections server and the proxy forwards the request to the Quickr server.
However, to send the REST request from the proxy to the Quickr server, the proxy servlet needs to establish an HTTP connection, and since we used SSL for that, the connections was established over HTTPS. The trouble we had was, that the proxy did not trust the self-signed certificate of the Quickr HTTP server, so we needed to import that self signed certificate into the trust store of the WebSphere Application server (described here) the proxy was running on. That was all.
Communities
Different from Activities, the integration of Quickr into Communities requires some more steps. Therefor you need to download the Lotus Connections Connector for Lotus Quickr, and follow the installation instructions. That was straightforward, but it did not work with our setup, unfortunately.
To explain a little bit the setup we used, Connections and Quickr were both running on seperate servers, both with a collocated HTTP Server that performs the forwarding from the standard http ports 80 and 443 to the ports Quickr is running on in the AppServer, which are for instance 10038 for http. So we configured during the installation of the Connector to use the default ports, 80 and 443 for ssl. What worked in Activities, did not work in Communities.
When we created a new community and checked the both new Quickr integration checkboxes, we experienced an exception, telling us (in the logs) that an URL like this one http://quickr.demolab.com/myqcs/rest/places/feed was not found. The reason for this was, that the Connector searched at the wrong port. For this particular URL the HTTP did no port forwarding, we still need to find out, why not. But anyway, after changing the http port following the instructions in the InfoCenter to port 10038, the integration worked perfectly... and btw. is pretty cool :)
Activities
How Activities need to be configured, is described in the Infocenter, here. However, we had the problem, that we were not able to connect to the Quickr server that we configured. The reason of that was, that we used a self-signed certificate for the HTTP server, since it was only a proof of concept installation. But first, some words, how the Activities integration works.
For querying the Quickr server for places, Activities uses a REST service of Quickr and since Activities is mainly based on AJAX, the REST request is sent via JavaScript. For security reasons, the JavaScript script can't access the quickr sever directly, since it runs on a different server that the connections server. So the request is delegated to a proxy running on the connections server and the proxy forwards the request to the Quickr server.
However, to send the REST request from the proxy to the Quickr server, the proxy servlet needs to establish an HTTP connection, and since we used SSL for that, the connections was established over HTTPS. The trouble we had was, that the proxy did not trust the self-signed certificate of the Quickr HTTP server, so we needed to import that self signed certificate into the trust store of the WebSphere Application server (described here) the proxy was running on. That was all.
Communities
Different from Activities, the integration of Quickr into Communities requires some more steps. Therefor you need to download the Lotus Connections Connector for Lotus Quickr, and follow the installation instructions. That was straightforward, but it did not work with our setup, unfortunately.
To explain a little bit the setup we used, Connections and Quickr were both running on seperate servers, both with a collocated HTTP Server that performs the forwarding from the standard http ports 80 and 443 to the ports Quickr is running on in the AppServer, which are for instance 10038 for http. So we configured during the installation of the Connector to use the default ports, 80 and 443 for ssl. What worked in Activities, did not work in Communities.
When we created a new community and checked the both new Quickr integration checkboxes, we experienced an exception, telling us (in the logs) that an URL like this one http://quickr.demolab.com/myqcs/rest/places/feed was not found. The reason for this was, that the Connector searched at the wrong port. For this particular URL the HTTP did no port forwarding, we still need to find out, why not. But anyway, after changing the http port following the instructions in the InfoCenter to port 10038, the integration worked perfectly... and btw. is pretty cool :)
3 comments:
cool blog ...
Well I want to know by integrating Quickr and connection , is it possible to search any kind of Quickr data (docs/list) from Connections.
Hi G.Muecke,
Realy like your blog already added it to my RSS reader :-).
Did you do this with LC 2.5 or with LC 2.0.1 ? We still have issues getting the LC2.5 Quickr Connector to work.
See our forum post at
http://www-10.lotus.com/ldd/lcforum.nsf/d6091795dfaa5b1185256a7a0048a2d0/c46f4fc59b1b380a852576b300584c82?OpenDocument
Maybe you have some ideas what we are doing wrong?
Thanks!
Hi Marco,
at the time of the posting, LConn 25 was not available, in other words, we used version 2.
I posted a reply to you forum post:
http://www-10.lotus.com/ldd/lcforum.nsf/DateAllThreadedWeb/53b4076ac6d1adc4852576d20031fb62?OpenDocument
Post a Comment