A search of OpenNTF projects for the term JSON will return a number of projects over a long period of time. JSON has long been a key data interchange format, being language independent and not requiring a fixed agreed schema. It is this reason in particular that has led to it overtaking SOAP as a data transfer mechanism, enabling microservices to be built and further developed without breaking existing interactions. Anything that delivers JSON data can of course be access via (Client-Side) JavaScript and, if client-side is your preferred approach and you're only interested in consuming and not delivering JSON data on request, there will be standard out-of-the-box approaches that you can leverage.

But for server-side approaches - whether for consuming or delivering on external request - the options available are various. When I initially developed XPages Help Application some years ago, the approach I used was to manually construct strings of JSON data. But the Domino platform has opened up tools for leveraging this, particularly in the 9.0.x timeframe with Domino Access Services and the com.ibm.commons.util.io.json package. Domino Access Services provide out-of-the-box basic CRUD APIs to access Domino databases, including Mail and Calendar. But DAS does not manage validation or manipulation of data types. The com.ibm.commons.util.io.json package provides low-level Java APIs to read to and write from JSON objects, and of course it is also via Server-Side JavaScript, since SSJS classes are actually Java classes under the hood. But every element of the JSON data needs reading or writing individually, which can be verbose.

Following on from his session with Kathy Brown at IBM Connect, Julian Robichaux has contributed a lightweight converter between JSON and Java, JsonBeanX. This is just a JAR file that can be imported into an individual NSF and avoids some of the security restrictions of other Java implementations, which would need amendments to the java.policy (or java.pol) file or would need the code adding to an OSGi plugin. Full details on how to implement it are in the JavaDoc documentation. This is designed to convert between JSON and Java objects, but it's an added incentive if needed to use Java instead of SSJS, to minimise the code you need to write and avoid some of the pitfalls you might otherwise need to (re-)address.

I've attached a simple example in the Java classes below. Within your XPages application, you would just go to Java\Code and import Julian's jar file, like this:
json_1.jpg

Then it's just a case of creating the Java code to use it. DavidJson is my Java class, which comprises a few properties - name, age, date of birth and characters. In the Utils class there is a method createBean() to create an instance of the class. (In reality, this would be loaded from a Notes Document , ViewEntry or multiple Documents/ViewEntries.)  The outputJson() method then uses just a handful of lines of code to return a String containing the JSON data:
json_2.jpg

When passed to a Computed Field component, the output is this:
json_3.jpg

Outside of XPages, the standard library for translating between Java and JSON is Jackson and Frank van der Linden is working on an OSGi plugin, already on OpenNTF's Stash, to wrap this for those who prefer something a bit meatier and can use OSGi plugins. The second output is the same DavidJson Java object outputted using Frank's plugin. Again, it's just a handful of lines of code.
json_4.jpg

The false parameter passed to the JacksonWrapper tells it to output date/times as date/times rather than converting them to timestamps. There are a variety of options for outputting to files, FileWriters, OutputStreams or just strings (which I use here). And beyond this there is a host of additional functionality from Jackson. Look out for a full release of this project on OpenNTF in the near future or download the source from Stash and get involved (developing, testing, adding feature requests or more).

For a walkthrough of the code, here is a YouTube video.


DavidJson.java
Utils.java



comments powered byDisqus