In the previous part I covered setting up Node-RED, in my scenario as a Docker image. Triggering Domino code on schedule is surprisingly straightforward, requiring just two nodes. The first is the inject node and the second is the http request node.
The inject node allows a process to be scheduled. The payload for the inject node used is a timestamp. This allows code to be scheduled at a particular time on particular days, or at specific intervals (either all day or between times). You can also specify that it should start at startup of the Node-RED server. If you wish more sophisticated scheduling, that can always be managed within the XAgent or whatever is running, or you can include an additional node like big-timer, as mentioned in the first part.
The second node is the http-request node. This makes an http request to the URL entered, and can include basic authentication. The username and password are entered on the node, but John Jardin has suggested this could be stored globally. The username and password are stored in a json file, but encrypted before being stored. So once the password is entered, it’s secure.
One point worth noting is that because I’m running Node-RED in a Docker container, “localhost” for Node-RED is the Docker container itself: it doesn’t know the private host machine’s hostname. To get around that I’m using ngrok which allows me to create a secure route to port 80 on my laptop that’s accessible from anywhere, as long as ngrok is running. It also allows introspection of the requests, which can be useful. If you’re ever needing to develop a callback for a webhook from, for example, Watson Workspace or some other third-party application to your development envronment.
Then I added an output node, to write msg.payload to the debug console. All that was left was to connect the nodes up and click the Deploy button to deploy the new flow. Then it triggers on schedule, or manually by clicking the blue square to the left of the inject node.
What Can This Trigger?
When I started this, I was thinking of XAgents, ideally triggering asynchronous (i.e. background) code. If it triggers code that does not run asynchronous code – just your standard XAgent or a standard SmartNSF custom route – the http-request node will wait for completion of the code before ending.
But as I started thinking more deeply, I realised most scheduled agents in databases are not hidden from the web. And any agent not hidden from the web can be triggered from the web, via a http request. Which means this scheduler could be used for standard Domino agents as well. There may be some refactoring required if those agents issue print statements. I must admit I’ve not investigated more fully. Similarly you might want to create a print statement at the end to return JSON for the output. Of course if you don’t bother doing that, you have just as much auditing of the agents as you currently do, so you’re not losing anything. But you could also write the message to a file, using the file node.
XAgents etc can pick up the request headers, so you can restrict access further by, for example, passing an API key that can be stored in notes.ini or individual code. I’m not sure about standard LotusScript agents, but they can access query parameters, so you would be able to take that approach instead. And of course the Node-RED editor itself can be locked down.
And it’s worth bearing in mind I’ve barely looked at the nodes available. One particularly interesting node is the watch node, to watch a folder or file for changes. This could be used to better handle the standard approach of scheduling an agent to a particular time and checking for the existence of a file expected to have been pushed from an external system.
In the next part, I’ll start to dig into basic non-asynchronous XAgent and SmartNSF code.