Scheduling XPages Code – Part Four
In the previous part I covered Node-RED. The announcement a few weeks ago of NodeJS integration with Domino will hopefully reduce resistance from customers for using the two together. In this part I’ll start covering XPages code triggered from the scheduled tasks – or external integration points – of Node-RED. Bear in mind that I’m starting from the most basic, manual example and will move towards the more involved, flexible and advanced example. But in actual fact, this most complex example also means the least code for developers and can leverage the advantages of Java 8.
XPages UI Action
Before starting, it’s important to look at the ContactsView XPage. This has a DataView which allows selection of documents and has a button to archive the selected documents. Yes, there are easier and better ways to archive, but this is about having XPages code used from the UI and from a scheduled task, and moving documents to another database was a simple example. I’m sure you can think of places where you’ve wanted to reuse code or will come across places where you want to. The button calls
To call a method in that class without creating a Utils object first, the method needs to be public (available outside the class) and static (can be called without an object being created from the class). This method calls
archiveDoc() which just copies the document to the archive database and removes it – pretty straightforward.
Basic Scheduled Task
The first example is an XAgent calling a Java method. The Java method kicks off a Xots task and returns a JSON response.
The XAgent SchedArchive.xsp is, as all XAgents should be, set with
viewState="nostate". The Java method is called in
That method gets the XspHttpServletResponse, sets content type as JSON and sets a header (other headers could be set). After triggering the Xots task JSON is written manually, the same as you would with a print statement in a LotusScript agent and the response marked complete. Obviously this is a painful way of constructing a JSON response and one that is prine to error, but it shows the most basic version.
The Xots task itself is
com.paulwithers.xots.SchedTask. For those not used to Xots, the class extends
AbstractXotsXspRunnable which means it’s a background task (Runnable) which gets loaded with a
XotsContext object which has access to the current session and database and can log to OpenLog. All the code for a Xots Runnable goes into the
run() method which all Runnables have. The key part is the call to
Utils.archiveDoc(doc) which is a generic method also used from our XPage for archiving.
Congratulations! We’ve now created a scheduled task which reuses code called from an XPage. However, this could be called from a GET, POST, PUT or DELETE. And constructing JSON manually is not ideal. We can do better.
The second example I want to cover is using SmartNSF.
This uses an “xrestArchive” endpoint. In order to trigger a Xots task we need to use the CUSTOM strategy. The code I’ve used is not very different from the example in the documentation. It uses a Java class
As with the documentation, this needs to implement the
CustomRestHandler Java interface and have a
processCall() method. As with the SmartNSF example, it uses JsonWriter to output JSON from a JsonJavaObject – it’s like a Map which you’re familiar with from scoped variables. The one difference is that the response code status is set to ACCEPTED, code 202, because we’ve received and validated the request but passed it off for background processing. So we’re not certain it’s successful, so we shouldn’t give a 200 response.
The other difference is we’re triggering a different Xots task,
com.paulwithers.xots.SchedTaskNonXSP. This is because SmartNSF doesn’t have access to all of the XPages runtime. So it needs to extend
AbstractXotsRunnable. Other than that the code is the same.
In the next part, we’ll look at making it even easier and giving a generic REST endpoint that can be used as well.