Martin Pradny's blog

 I haven't published my recap after Engage this year and the recent HCL Factory tour in Milan is a great opportunity to write a summary about what's happening in HCL (mostly Domino) space. It's a mix of news about 12.0.2, future directions, and my impressions, so it can be a bit chaotic, but I got the impression that many people see it similarly.  Engage 2022 Engage 2022 was great (as always). I love the atmosphere in Brudges. I visited it once after Engage a few years ago and I was happy to come back. This was also the first time I had the opportunity to speak at Engage, which obviously made it a bit more stressful, but also more fun. Together with Domino Jams, HCL continued conversations with customers and partners about the future of their products at Engage. Many of these ideas were now discussed in greater detail in Milan, some of them were even demoed.  My main takeaways from Engage were: Nomad (web and mobile) are a great addition to Notes family Restyle is a great g

 This post is long overdue. I originally planned to write it to document the issues and solutions while working on the app, but as the problems kept appearing I wanted to make sure that I have all the answers. Now I know that I probably won't have them in the near future as I'm seeing new issues even after having the app in production for some time.  The project was about a webization of an existing app that served well in Notes client UI for many years. It's a classic support/helpdesk app that once used to be a great example of Notes flexibility and integration of mail functions with app code. After all the mail database was just another app using the same APIs (mostly). Unfortunately, this is not the case for XPages as iNotes or Verse has nothing in common with XPages, so the APIs are not battle-tested for all the scenarios. I remember doing a similar project during the early days of XPages and I must admit that it was more painful, but mostly due to a lack of community

 I finally found an opportunity to try the new Database comparison tool that comes with 12.0.1 -  official documentation . Unfortunately, it did not work for me - all I got was a report for database.xml comparison and an error: Unable to output because no output object has been specified //DDDESIGNELEM.SAVE:1184-6 ... cc_body_xsp.xml ... My setup is: 12.0.1 - of course on Windows database configured to use WinMerge for comparison The error mentioned a Custom Control and the code contains a special if for *.xsp. After a bit of checking of the source code it seems that my problem can be fixed with a simple line that sets the output of the midDomp object - line 1117 on the screenshot. Now it outputs results for all elements and no errors anymore. Now I can continue to check the reports. Update: There is an official support article for this problem -  https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0096095  (but without a fix)

 Recently, I had to work on an app with a pretty huge server-side JavaScript codebase. Several developers with different levels of XPages knowledge worked on that project in the past, to the code is quite hard to follow. My suggestion to rewrite all the code to Java was not accepted, so we have to deal with SSJS for now. One of the most annoying things, when you work with SSJS, is that in many cases you don't know where an error is happening. If you keep things simple and allow redirection to an error page (default or custom), you get a lot of information, and usually, you don't want to scare users with that or you may even want to do something useful in a catch block to recover from the problem. If the problem is thrown directly in the XPages JS engine, it's usually an InterpretException, which contains the context information, but if you have to deal with standard Java exceptions, you don't have it. Imagine a simple scenario with a function in a ssjs lib. When you run

 I wanted to make this work for a very long time, but there were always some parts missing, so I could not get the full process running. Finally, the wait is over. The following paragraphs describe a way to build Notes/Domino apps automatically on a Jenkins server, allowing parallel builds and all "normal" continuous-integration behavior, without having to think too much about Domino specifics. The Problem Until now, I was running my automated builds of Domino apps using Jenkins in two ways: The official headless-designer way, where you need to pass special commands to Domino Designer and hope for the best as the Designer sometimes gets stuck. I have this wrapped inside a Jenkins pipeline, so I have some control and can e.g. avoid parallel builds by using locks on Jenkins, but still, sometimes it just dies. Some of my headless builds run for more than 30 minutes, so it's really hard to quickly spot an issue without actually connecting to the machi