Your help needed: Jump-start guide to IBM Notes for Outlook users

At my workplace we are about to start with migrating a decent amount of users from Exchange/Outlook to Notes 9. Yes, this still happens and I am quite excited about that ;-)

After a user has been migrated we want to provide access to useful information. What we already have is explaining general things like FAQs about using Mail and Calendar, enable Out of Office, Signature etc...

On top of that, I thought it would be helpful if we provided a jump-start guide explaining a few key differences between Notes and Outlook.  I have to admit that in the 18 years of my Notes & Domino carreer I haven't really touched Outlook - neither at work not for personal reasons... In other words: I have no experience with Outlook and therefore I cannot be very helpful in depicting differencs between both systems.

So I would like to ask you to share your experience in what Outlook users struggle most with when switching over to Notes & Domino.
How do users work with Outlook and what adjustment problems do they have when using Notes?
What is missing in Notes and what can we offer as a substitute (public folders...)?


Looking forward to your feedback :-)

Apply Java Permissions to Domino Agents at runtime - again ;-)

This post is supposed to be read by developers only. Admins, please move on ;-)

I have an agent which is used to make SFTP file transfers from Domino to our corporate SAP system. It's an interesting project and I am exploring new stuff on a daily basis :-)

One technical issue I had to solve was this:
The agent opens an SFTP session on a remote host. Unfortunately this is forbidden by Java Policies specified in the java.policy file of the JVM of the Domino server.
The error is
java.lang.SecurityException: not allowed to make a socket connection to MYHOST.MYDOMAIN.COM,-1

So I started to dig into java.policy and java.pol files. And to be honest I was not that much pleased about the whole thing. At first I started to grant ANY permissions in the global section of my policy file:

 grant {   
  ...  
  permission java.security.AllPermission;  
  ...  
 };   

This works but it goes a bit over the top for a productive environment... Therefore I started to tweak the policies to only allow one specific application the network operations required to do the job. Honestly, it's been painful... I think I got it more or less configured properly. But given the fact that we run the application in three different environments (DEV/TEST/PROD) on multiple servers I hardly could imagine a proper rollout scenario. I always thought one of the major strengths of domino and NSF was that usually the design and resides in a single database - and the configuration usually resides in the application, a few system databases (+ notes.ini).

There must be an easier way to grant my code the execution rights it needs.
I finally found a solution to grant my code the needed execution rights at runtime of the agent. There is a whole Java package for handling the permissions - and in my particular case I was looking for SocketPermissions. The code to grant a socket permission is pretty straight forward:

 String hostAndPort = "myhost.mydomain.com:22";   
 SocketPermission p = new SocketPermission(hostAndPort,  
       "accept,connect,resolve");  

This will allow my code to make a network connection to the specified host on the specified port. There might be neater solutions to that problem and not every admin would be happy about that. In my opinion it is not very consistent for what you need to grant permissions in policy files (like network connects) but on the other hand file handling can be allowed on the agent security (Allow restricted operations).

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!