Martin Pradny's blog

 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

 2021 is here. I hope this year will be full of better things and our lives will get to normal, where we can travel and meet each other again. For me, it started in quarantine, but all tests were negative. Another change was that I'm HCL Ambassador for the very first time in 2021. I hope it will force me to blog and speak even more about HCL products, especially about all the goodies in V12 and beyond.  Last year, I've done a few tests of the new transaction methods. HCL checked my issues, so now it was my turn to do a few more tests. Problem with view access after a document save In Test 4 of my initial tests, I've found that you can no longer access views after you save a document. The problem seems to be deeper in the Domino code, so for now you must disable autoupdate on the view object.  This, of course, means that you will not get up-to-date result, because you'll work with the old view index. An interesting fact is, that the view index is not updated even when

 Domino V12 EAP contains new methods to manage code transactions. The underlying C API has been there for quite some time, but I've never really looked at it. Now it's finally official and you will be able to leverage these new features in your apps. The EAP program is currently only shipped as a Docker container, which makes the testing a bit hard - you don't have Domino Designer or easy access to the JVM. The only ways to test the APIs that I could think of were: Try to import the code using DXL on the server - should work for LotusScript Try server-side XPages compilation, e.g. using Jesse's NSF ODP Tooling Build a jar file locally using V12 Notes.jar and reuse that The last option seemed to be the easiest one and before I had a chance to try it, Ulrich Krause has used that in his test with Java server addin -  https://www.eknori.de/2020-11-01/testing-new-database-methods-in-domino-v12-early-access-without-domino-designer-v12/ I wanted to have something more interact

Domino AppDev Pack Java API is still quite fresh for me, but I always try to push the limits, so I've decided to add  Kotlin  to the mix. If you've never heard of Kotlin, please go and check it. It's a pretty cool language that can run on JVM and allows you to write more readable code more easily. I'll build a simple CRUD REST API, running on Spring Boot, that works with Domino data. Domino AppDev Pack series: 1.  First Java API 2. Certificates 3. Kotlin REST API (this) My original plan was to just try other APIs directly from Java, but Heiko Voigt has already done that in his presentation at CollabSphere 2020. The presentation is available here . If you want to know more about AppDev Pack, please watch it. You can also find the code in his github repo . I knew that C3UG had prepared a course about AppDev Pack, but I somehow missed their recent videos about Java APIs and 1.0.6  . It would have saved me a lot of time when I started to play with the Java domino-db API. Fe

In my previous post I've shown how to quickly start coding with Domino AppDev Pack Java API. I used an insecure connection to avoid dealing with certificates, now it's time to fix this. If you are testing the new Java API, which is marked as a preview, you probably enjoy living on the edge and may also have a V12 EAP Domino server somewhere. This may help us see how the future may look. Domino AppDev Pack series: 1.  First Java API 2. Certificates (this) 3. Kotlin REST API The AppDev Pack distribution contains sample files that generate ca, certificates and kyr file using openssl, but this is a one-time operation that is pretty hard to repeat or even use in production. If you want to use this in production, you should use a proper certificate authority. Last week Daniel Nashed posted info about nice enhancements coming to V12 that can help us here Domino V12 ACME for company CAs using smallstep  and  Easy kyr file creation with Early Access V12 in production . smallstep ca ste