How to overcome Domino Webservice Timeout issues

Many of you might be aware of the restriction described here. I was not, and it caused me and my colleague quite some time to investigate, and fix this. Additionally, it caused us a lot of pain, because this issue increased the pressure on our project. So this might be relevant to some of you too...

So this is the story: We had a very annoying issue with a Domino WebService Consumer which was running in a timeout (almost all the time). As with many other projects the WebService was running fine in our Development environment. In both, our Integration as well as our Production Environment, the WebService always ran into the following error:

Error while reading data from server, Network operation did not complete 

in a reasonable amount of time; please retry

You have experienced this yourself too, don't you? Obviously, the amount of data in our development system was a lot smaller than in the integration and production environment. This is why the issue did not occur in our DEV system. But why the heck does the WebService stop at all??

After quite some research and opening a PMR we were pointed into te right direction:
The default Web Service Timeout is set to 60 seconds. It is a hard coded limitation, IBM seems not to be willing to fix this. To overcome the issue you have to be smarter than me and set the timeout on each WebService consumer individually at runtime. You can do this by calling the setTimeout() function of the WebService and pass the number of miliseconds.

More details can be  found in APAR LO48272: WEBSERIVCE CONSUMER BREAKS THE CONNECTION AFTER 60 SECONDS

Extract Top-Level-Domain from a URL using client-side JavaScript

I needed a way to extract the top-level-domain from a url in a client-side javascript. I use the window.location object to achieve this (as I needed it in a CSJS anyway). There might be an easier way to do this, but this is my version of doing this:

 /*  
  * This function returns the TLD part of the url based on window.location => CSJS   
  */  
 function getTLD() {  
      var hostName = window.location.hostname;  
      var hostNameArray = hostName.split(".");  
      var posOfTld = hostNameArray.length - 1;  
      var tld = hostNameArray[posOfTld];  
      return tld;  
 }  

Looking forward to your approacches to to this ;-)

Some thoughts on Source Control Management for XPages development

In my career as a Domino developer I have been playing with various Source Control Managent solutions already. I used TeamStudio Ciao! for many many years and this tool proved to be a life saver in many occasions already. So I owe some drinks to the guys from TeamStudio... (don't tell them!!)

Since IBM started opening Domino Designer in Release 8.5.3 (was it 8.5.2 ???) towards the "standard" SCM systems (Git, SVN, Mercurial) I have been playing with these options a lot. There was quite some pain involved, I lost source code, my repositories lost the link to the NSF/ODP, etc... No pain, no gain! The good news for me: Today I have a working environment which fits my needs :-)
My first steps were with SVN, but I admit that I was not able to get this setup running properly. Additionally, I was not too happy about the centralized approach. That said I started using Mercurial. Finally I ended up using Git, first the implementation in Domino Designer and nowadays using SourceTree. This setup provides me with such a high flexibility with regards to my work-related projects as well with my pet-projects.

The last missing bit so far was a proper SCM system. I have been looking around for a while and playing with various systems. As I am a corporate developer, using a hosted environment was not an option at all. So I was looking for a solution to run my self-hosted SCM server for my code coming from both, work-related projects as well as pet-projects. Finally, I think my journey has ended successfully (or at least I have reached an intermediate stop). I have played with GitLabHQ for a a while now and it looks very promising to me. I got it up and running relatively painless on a local Ubuntu VM. If you are looking for a self-hosted SCM server, I can highly recommend looking into GitLab (it is very focussed on SCM though).
There is a lot of useful information available in- and outside the XPages community. In the upcoming weeks I will describe my environment and approaches and specifically GitLab a little more in detail and hopefully add some more useful bits. So stay tuned!

Today I learned how to override session authentication using a web site rule

Did you know that you can override session based authentication based on URL patterns?‎ Yes? Lucky you, I didn`t. I honestly admit it: I am more a developer than an admin ;-). The feature dates back to R7.0.2 so I must have been missed something at that time...

In one of my projects domino provides a web service which can be consumed by a 3rd-party-system. All sites on that server (R8.5) are configured to use  session-based authentication. Since web services cannot authenticate via basic authentication (at least I did not get it working) I  was looking for a way to work around session based authentication. An additional web site involves a lot of effort and patience in this environment as there are quite a few people involved. 

Finally I got the right hint from the developer who consumes the web service. There is a web site rule for that! And I just did not know about it:-o

The setup is quite straight forward. Open an Internet Site document and click on Web Site - Create Rule and select "Override Session Authentication" as type of rule.

You can specify a URL pattern for which domino overrides session based authentication. On the one hand this provides a lot of flexibility‎. On the other hand, the pattern should be chosen with care. Wildcards (*) can be applied too.

So, this is it, my lesson learned today.

Domino Web Services SSL Error - Keyring file not found

Today I came across a strange behaviour on our Domino (R9.0.1) server.
We have a database with a web service consumer. This Web Service consumer is used by a schedules background agent. The Web Service makes calls to a third party system using https.
The Domino Web Server is configured using Internet Site documents. All https traffic and calls to the server worked perfectly fine from the evry beginning.
Whenever the web service is called, the following error is thrown on the server console:

Error 4746 Web Service XXXXXXXX method XXXXX error 
Error connecting to 'xxxxx.xxxxx' on Keyring file not found

 So there seems to be something wrong with SSL certificates. After some time of trial and error with some more HTTP server restarts I found two helpful ressources on Google:

IBM Technote LO47722: "SSL ERROR: KEYRING FILE ACCESS ERROR" ON WEBSERVICE CONSUMER US ING INTERNET SITE DOCUMENTS

and a thread in the good, old notes.net IBM DeveloperWorks forum:
HTTPS Web Service - SSL Error: Keyring file not found

Both describe the exactly same scenario as used here. The solution is that in both places, the Internet Site as well as the Server document the specified SSL certificate must match. In general I think this makes perfectly sense. However, as soon as you enable "Load Internet configurations from Server\Internet Sites documents"

in the server document, you cannot specify the SSL certificate in the server doc anymore. What I had to do is temporarily turn this setting off, specify the correct SSL certificate and turn it on again. This is the bit that confused me here. The setting in the server document seems to be used for requests issued by the server itself (i. e. web service consumers).

To make a long story short: 
Make sure you have the same SSL certificates specified both in the server doc and the Internet site document.