Following the blog posts and the demo, which took some time, I’ve finally created a video on my YouTube channel, which you can also access below. It’s quite a long video but that’s because I go through all that I’ve gone through in the blog posts and more.
And if it’s not included elsewhere – and because this is the (current) end of the series, here is the Update Site for download. Scheduled Xots Update Site
But I’m consious that there are some discussions etc that may have come to mind while reading the blog posts and they’ve certainly come to my mind when thinking about adoption of this new approach.
When I came to looking at what had currently been put in ODA, in the XspUtils class, the helper methods added there only covered boilerplating request and response objects and, if required, a JsonJavaObject for holding your own JSON to pass back in the response. These are initialiseAndProcessResponse(IXspHttpServletResponseCallback) and initialiseAndProcessResponseAsJson(IXspHttpServletResponseCallback) It didn’t actually trigger the custom code as background tasks. So in the latest development branch of ODA, a new method has been added that does that, initialiseAndProcessResponseAsync(final IXspHttpServletResponseCallback callback). It’s been a while since the last release of ODA, and a few things have been added, so we may do a new point release shortly with that. But it will be for FP10.
Will the wrapper methods (XspUtils….) be available from SSJS?
This is not currently possible and unlikely to ever be the case. They inject code to run within a Java method. SSJS is a string that gets parsed by the XSP Command Manager and runs via a Java method of a component on an XPage. These wrapper methods allow you to write a process() method that gets run from a Xots task – there’s no component, there’s no XPage that’s running, so it’s almost certainly impossible. If it is possible, it’s way beyond my skill level.
Can you create a Xots task in SSJS?
Not currently and probably not likely. It’s a Java class extending Runnable / Callable implementations and I don’t think that’s possible from SSJS.
I only want to use SSJS
I’d love to believe no one is thinking this while reading these blog posts, but I don’t think it’s the case. To be brutally frank, if you’ve done XPages for more than a year or two, your server-side code should be starting to be written in Java. The fact I’m saying this shouldn’t come as a huge shock because I did sessions many years ago about moving from SSJS to Java. All the sessions I’ve done over the last few years, all the demos I’ve written have focused on Java. The XPages developer roadmap I created in 2015 talked about moving to Java just as it also talked about looking at other JavaScript frameworks. I’ve specifically developed and delivered training courses for Intec on Java for XPages developers, and even modules in the introductory XPages course introduce Java. SSJS should be used as a stop-gap while you get familiar with XPages processing, certainly I would not have been able to cope witih XPages and Java at the same time, I wouldn’t have known where my errors were. But then you should move to Java for your server-side processing in XPages. I developed a couple of XPages applications using SSJS only and, after struggling with it, took two weeks off to build XPages Help Application because I wanted to move away from SSJS to Java – and I’ve never seen any reason to move back and lots of reasons that what I did was right, even with the announcements about NodeJS, what I chose was the right course. With XPages you’re seriously hampering your functionality if you rely on SSJS and severely limiting your professional development. NodeJS will give server-side code in JavaScript, but using that from XPages seems counter-intuitive – you’re better off using a JavaScript framework for your UI with a JavaScript server-side; use a Java UI framework for Java server-side code.
Why no ODA wrappers for chaining?
Out-of-the-box on Domino, as an HTTP client, there’s just java.net.HttpUrlConnection. It works, but it’s not best and probably couldn’t be wrapped into a basic Xots task in a way that would work in all scenarios and environments. And to set it up you need the URL you want to call, and to do that it basically means the code has to expect that to be in a specific area of the HTTP request, e.g. a query parameter called redirectUrl as I did in the examples. That’s not flexible and it’s not really ideal.
There are alternatives, the two obvious ones being Apache HttpClient (this is what’s used in the tests and core functionality of Watson Work Services Java SDK) and OkHttp (which is what’s used in the Watson Developer Cloud Java SDK. To package either with ODA would further bloat ODA with additional third-party packages that might conflict with other OSGi plugins already in use, force a specific choice and require us to identify and support all potential scenarios for a HTTP client connection to places we have no idea you might want to connect to. Supporting that is virtually impossible. Create the connection yourself in your own process() method. Chances are if you’re connecting to other REST services you’ll need to get familiar with doing this kind of thing from Java or will have plenty of source code available to get you very familiar with it. It’s not rocket science and there are a number of examples on the web, plus lots of questions over the years on StackOverflow. And nothing in HttpClients is specific to XPages, so the answers will be appropriate, again one of the advantages of embracing Java.
Why no ODA wrappers for calling from outside XPages, e.g. custom REST service plugins?
The wrappers basically extract the HTTP request and pass them to a Xots task. That’s easy in XPages because the FacesContext exists. It’s probably less so outside XPages – SmartNSF exposes them in one way, a custom REST service in a plugin exposes them another, and so a basic Xots task can’t wrap them. What we may be able to do is create a basic Xots task that takes a callback and the request which you can use, I’m looking into that.
But I’m not familiar with Xots
It’s documented on wiki.openntf.org and with online documentation at http://paulswithers.me.uk/odaDemoApp/. There are also various Xots-related blog posts you can find here by clicking on the “xots” tag at the bottom of this post – the “XOTS: Background and MultiThreaded Tasks the OpenNTF Domino API Way” posts cover everything in depth. Once you’ve written one or two, it’s very straightforward.
Node-RED
In the video I show find-and-replace to update environmental aspects in Node-RED flows. Authentication is stored in a separate JSON file, encrypted, so it’s harder to change. So I’ll plan on small, application-specific flows, so that when I migrate, I just need to change a handful of updates. John Jardin used Agilit-e to handle the flows and authentication for our demo app for IBM Think. So that might be an alternative – logins should be able to be passed as basic authentication Base64-encoded headers to the REST service calls, that’s what happens in Watson Work Services Java SDK. So there may be other ways to store that elsewhere and re-use it.
But Node-RED just makes so much sense and it’s so easy to set up as a developer, there should not be no reason anyone doesn’t embrace it. And if you step back and think wider, there is so much potential with it. It’s certainly going to be a core part of my future application development architecture, it a no-brainer.
Open Source
I’ve talked about ODA and Xots. I’ve talked about XPages Help Application at the heart of me learning Java. From that came XPages OpenLog Logger, which has taught me so much and made my development so much easier than it was before. I’ve talked about Watson Work Services Java SDK and Java REST clients. I’ve talked about the Watson Developer Cloud Java SDK, that’s also open source. So much of what I’m advocating developers to embrace has come from my exposure to open source and involvement in community development projects.
I’d recommend anyone getting involved – developers are more than happy to help others get involved in their open source projects, whether it’s as documentation, testing, bits of development, even asking what seem dumb questions so you understand what the code is actually doing. Blog it, document the code, share it, whatever so that when you forget again in a few months, you can go back to that and remember.
Managers should also see the benefit – a training course is useful, but working on open source brings real business benefits. My business applications wouldn’t be what they are without the open source projects, and on many occasions I’ve done development on ODA during business applications because it made more sense to put the code there rather than in one application and have to copy it around various others in the future. And it’s given me a bigger corpus of samples from which to draw to more quickly solve business problems. And it’s improved the quality of code I write and the range of innovative solutions I can bring to a problem.
Maybe you agree, maybe you don’t. But I remember being invited to the XPages chat on Skype, when it was there years ago, and saying I didn’t know if I would have anything to contribute. The biggest thing I had to contribute was a willingness to learn and it’s at the heart of who I am. It’s why I’ve embraced Node-RED as a tool for scheduling REST services, to allow me to take the code I’m writing for normal business processing and re-use it for scheduled processes. And there are various other places I can seee to use Node-RED, which means in all areas, I’m very confident the investment made here will pay back over and over.
