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.

DOTS: Logging to server console and log.nsf (part2)

In my previous blog post I showed how I implemented console logging in my DOTS projects. As I mentioned already yesterday, I prefer using logMessage respectively logException which are both implemented in the ServerConsole class of DOTS.
Both methods can easily be used directly inside your tasklet. When my first tasklet was growing, I started implmenting my own classes. Thereby I realised that logMessage and logException both are not available outside the tasklet class.

As these methods are implemented inside an own class "ServerConsole" I need an object of this class to use these methods. First I declare an object of type ServerConsole. In my case this object is in my class header and initialized in the class constructor. Thus I can use this object anywhere in my class - and even outside my class as it is declared as a public object.

In my DOTS projects I usually declare one ServerConsole object in one of my classes and use this object anywhere possible.

Beyond this approach I was pointed into two different directions today:

Rene Winkelmeyer mentioned another useful approach in a comment  here. If you want to log outside of the tasklet class you can easily use ServerTaskManager.getInstance().logMessageText("").

So if you only want to log messages, this might be the easiest solution for you. However, if you want to log messages and/or exceptions, the ServerConsole class is your friend...
OR you go down the road that Serdar suggested in his comment here. and use his Logger class.
He created an own TaskletLogger class which extends another Logger class. I haven't tried it out yet, but I am pretty sure it works great :)
Speaking of logger classes, I think I have to mention the XPages OpenLog Logger OpenNTF project by Paul Withers which can be used from OSGi extensions too.

To make a long story short: there are many options available - and while writing this update post I am realizing that this "blogging thing" revealed a lot of good new stuff to explore ;-)

DOTS: Logging to server console and log.nsf

In one of my current development projects I am developing a DOTS server task(let). One thing that I found very annoying is the logging part of DOTS. With logging, I essentially mean - at least in this post - an output to the server console and / or log.nsf. To achieve this, there are basically two different possibilities for logging in your DOTS projects.


Option 1:  System.out.println
As in other Java projects you can use System.out.println("your message") to print out message to the server console.

Running this little tasklet results in the following output on the server's console:

As you can see, the message is printed to the console. What you cannot see from here is that these messages are not save to log.nsf.

Option 2: logMessage
A way better logging is provided by a specific method logMessage("your message") which is part of the class com.ibm.dots.task.ServerConsole.
While your cord  resides inside the tasklet you can easily use this method instantly without any further declarations:

The output looks like that:

Using this method has several benefits:

• Messages logged using the logMessage method are saved to log.nsf. 
• You can see the date and time of the message.
• In addition, the message indicates that it comes from the DOTS Tasklet "Helloworld".

In my opinion this is the clean way to go for logging from a DOTS tasklet to the console respectively log.nsf.

Moreover, the ServerConsole class provides another very useful method "logException" which accepts a throwable Java Exception which then will be printed to the console. In other words: you can use this method in any catch statemen to handle error logging to the server console / log.nsf.

iNotes calendar control - a good example to get started

In my previous blog post about the iNotes calendar control, I talked about some issues I was having with the iNotes calendar control which is part of the XPages Extension library. Yes, there are some issues, but to mke a long story short: the control is a great resource. If you want to learn more about this control, I can highly recommend to have look at the latest release of the TeamRoom Template which is deployed to your Lotus IBM Notes client.

If you want to learn more about the iNotes calendar control, check out the calendarView custom control.

BTW: On this control, I experience the same issue with the events as described here.

There is also a TeamRoom project available on OpenNTF (older version). And a demo video by Ed Brill demoing the TeamRoom template. The OpenNTF project description says:

This new TeamRoom OpenNTF 8.5.2 template has been built as a showcase application for the XPages Extension Library.  Approximately 80 different XPages Extension Library controls have been used in the construction of the TeamRoom OpenNTF 8.5.2 template, therefore making it a great learning resource on how to leverage the XPages Extension Library!

In my opinion this hits the nail on the head. This is excatly the reason why everyone learning developing XPages applications (beyond the entry level) should have a look at this template. Additionally this version of the TeamRoom template provides a much better Web UI. So your users might benefit from this template too :-)

XPages iNotes Calendar control - Events oddities

While working in one of our projects with the iNotes calendar control I experienced some oddities with the Events of this control. What I wanted to achieve is that some magic happens when clicking somewhere inside the control - e. g. opening the entry on which the user clicks... Should be pretty straightforward, I was thinking. Stupid me! As usual the devil's in the details.

I started by selecting the control and opening the events view and entered a simle JavaScript in the "onNewEntry" event. The script is supposed to show a message box after  clicking in an empty time slot.

 

In my case the result is that the event just doesn't get fired at all. I tested with FireFox, Google Chrome and even Internet Explorer. After some more testing and playing with the control I noticed an odd behaviour of Domino Designer:
As you can see on the Screenshot above, both events "onNewEntry" and "onOpenEntry" are marked blue which indicates, that there is some code in the event to be executed.  When I opened the "All Properties" view of the control to check the scripts there, I noticed that both events were empty, no script, nada, nil... Switching back to the events view, the scripts were there.

So that got me thinking. Once I entered the same code in an event from the "All Properties" view, the code is executed.

As far as I understand, the "Events" view is kind of buggy for at least this control. Besides the issue described above, I noticed that from the "Events" view I can enter CSJS as well as SSJS and Simple Actions. From the "All Properties" view, only CSJS can be used - and as far as I can see only CSJS is supported. Side note: I am using Domino Designer and Domino Server R 9.0.

 Lesson learned (again): All Properties is where you should do your work!The good news: as soon as you know how to work with this control, it works great :-)