Some years ago I developed an XPages application that heavily used ODA. In fact, it was the first I used Xots in. At the time, I needed a scheduled agent to send email reminders. I was frustrated that the only option if I wanted code in the NSF was a Java agent, which required me to add a jar file of ODA into the Java agent and copy some utility methods from my XPages code across to the agent. The agent needed further refactoring when I learned of the issue of memory leaks from jar files in agents, so I needed to copy code from ODA into the agent to use standard Domino API code, including while loops for iterating views – which can result in infinite loops. The solution was far from satisfactory, and I’ve been looking for a better solution since.
When we built Xots, the plan was always to allow scheduling. There were a number of technical issues. Firstly, we needed to store the schedule somewhere. Initially we looked at storing it with annotations in the Java class itself added to the IconNote by a separate builder that needed installing into Domino Designer, but a separate NSF has often been mooted because it allows different settings for different environments. There are definite performance issues with iterating each NSF – even just the IconNote in each NSF on the server – to identify Xots tasklets set to run on schedule. Secondly, we needed to kick off those Xots tasks at the right time. This proved to be already coded in, with Xots.getService().schedule(). Thirdly, once kicked off, the code needed to run in the context of the relevant NSFComponentModule, which was not as simple as it seems, particularly if we’re storing just the hierarchical name of the Xots Java class in a scheduling NSF. Fourthly, having the schedules stored at HTTP restart is fine, but what if you want to change the schedule or you refresh the design with different metadata or amend / remove the Xots tasklet? Updating the schedule is another headache. The biggest technical headache for me has always been how to kick off a specific Java class – plus all dependencies, more importantly – in the context of a specific NSF when that database may not have been loaded into the XPages runtime.
Nonetheless, this was still one of the key milestones I wanted to address when I did a round table at Engage earlier this year titled “Domino Designer Next Generation IDE”. I summarised that in a blog post a few weeks later, backed up by a document on OpenNTF’s Wiki. The scope of the project is here. The timescales were aggressive – I aimed at Phase One being done by the end of this year. Except for the scheduler, the bulk of that is complete – the ability to sign the NSF with a specific ID programmatically and the ability to create / update the $TemplateBuild is outstanding but not critical.
The big part is the scheduler and ability to run Xots tasks scheduled. The major issue was, as often happens, that I was trying to be too precise: trying to solve a technical issue rather than focusing on trying to solve a practical situation. The solution John Jardin and I have come up with came very quickly, was inspired by a specific practice requirement which was on the surface unconnected, but grew out of discussions arising from that requirement: the fact that John uses the JSON-RPC component extensively for React applications, but his desire was for it to run asynchronously. Running asynchronously is easy – it is the basis of Xots. And the light bulb lit up.
We’ll be showcasing the approach we came up with soon, but the good news is that everything is backwardly compatible to a base 9.0.1 server and client, the approach to using a scheduler avoids reinventing the wheel, is free of charge, platform-agnostic, extends the Domino developer’s toolset in a non-scary way, requires no Java security changes, allows different schedules for different environments, allows easy deployment of schedules, and comes full-circle to blog posts by Devin Olsen and Stephan Wissel, which proved remarkably prescient. It allows re-usability of XPages code, allows use of SSJS (although that brings some limitations), and will appeal to those not wanting to leave the NSF as well as those seeking to avoiod using Domino Designer. It may be an approach others have used, but not something that anyone to my knowledge has blogged about or recommended.
SOunds very cool.
Was it not an option to store the schedule in his own property file inside the NSF. Currently I do that for specific settings in the HR Assistant application. Sven Hasselbach has a cool Utility class to read and store property files, http://hasselba.ch/blog/?p=1763
It’s possible, but it still leaves the challenge of identifying those properties files and iterating them for all NSFs at server start, plus re-loading the schedule if there’s a design change / refresh.