Now that Domino V10 is out, we can leverage new functionality, e.g. DQL, but the new functionality has been added in a way that the remaining project still runs on Domino R9.0.1 servers.

Domino Query Language (DQL) Domino V10 provides a new facility to run adhoc searches against Notes databases, using the new Domino Query Language, with a much better performance compared to a classic database search via formula language.

At CollabSphere 2018, John Curtis, software architect and lead on the DQL project at HCL, gave an introduction to the available search options, how queries are planned and executed and how search performance can be improved by creating lookup views that the facility then uses for efficient data lookups.

A DQL search returns a set of note ids for matching documents, in the Domino C API called an IDTable (in Domino JNA: NotesIDTable).By nature, note ids in an IDTable are sorted in ascending note id order, because that is the way they are written in memory (compressed to reduce memory consumption, see this technote for details).

To display DQL search results in a web application, a note id sort order is not really useful, that's why the test case demonstrates a technique to cast the IDTable onto a Domino view.

In short, this means that you can efficiently filter a view down to only return view rows with note ids from that IDTable.

Blog series about Domino JNA

Another topic that I would like to draw your attention to is a great blog series about Domino JNA, written by Mark Leusink.

The first two articles are already available and demonstrate how to implement faceted searches:

Karsten Lehmann 6 March 2018 16:19:03

By setting the programmatic column name and formula value of a view column to "$C1$", the column automatically displays the content of all reader items in the document.

If there are any readers, the column also container the author item values, since these are also allowed to see read-restricted documents.

"$C1$" is a special column value that the NIF indexer sends to the NSF Search command in the C API to let it compute read access. This information is stored in the view index and compared to the current user's NAMES_LIST (list of name wildcards, groups and roles) on view access (case-insensitive). To use this in your own C code, some more work is required. You don't pass a compiled selection formula to NSFSearch, but a view formula, which is the selection formula merged with all view column formulas (NSFFormulaSummaryItem).

Of course this is not documented anywhere in the C API, that such a view formula can be passed to NSFSearch, same for the special value "$C1$". ;-)

In addition, you need to pass the constant

SEARCH_NOITEMNAMES 0x0020

to the NSF Search, which tells it to not return the whole note summary buffer for each search match (ITEM_TABLE structure), but just the values specified as columns in the view formula in their order, which makes the search a lot faster.

Too difficult? No problem. Domino JNA to the rescue. This NSF search is the base of our incremental Domino data sync.

So effectively, we do (almost) index Domino data like NIF, but with different target system. If not all information is available via summary items, the sync code can provide access to the document as well.

Karsten Lehmann 8 January 2018 11:14:30

I spend a few days during the Christmas holidays and first week of January to work on our Domino JNA project. The result is version 0.9.11, which is now on its way to Maven Central and available for download as an OSGi plugin for XPages developers.

Here are the three main features that I have been working on:

Improved performanceThe project source code has been completely rewritten to use JNA direct mapping. This significantly improves performance in areas with lots of native method invocations like document item access or when adding note ids to ID tables. Other performance work has been done to speed up LMBCS-Java-String conversion and to lazily convert summary buffer values when doing a database search (the old version always converted the whole buffer).

Incremental data indexingAs I recently wrote on Twitter, I do not know how many code I have written in the past to sync Domino data to external databases or indexers, because they are more powerful doing adhoc-queries than Domino. The good news is that IBM is actively looking into this topic for Domino 10.

So here is another approach, this time using C API calls, incrementally searching for database changes filtered by an @-formula and not requiring any lookup views.

The key to getting it implemented this way was the discovery that NSFSearchExtended3, which I am using to search for formula matches, can not only run incrementally by passing a "since" value and returns all changed notes matching the formula, but also calls the callback for all changed and deleted notes not matching the formula.

This way my code knows what to add/update in the external db or index and also knows what to remove if it existed in the index before.

To make the algorithm easily reusable, I haven't hard coded a specific sync target. The whole sync process is running against a simple Java interface.

A sample project is already available with code that synchronized Domino data with the Java based CQEngine indexer. The project contains a testcase that indexes the fakenames database and makes sure everything is working as expected. My plan is to create more implementations, e.g. for SQLite or Lucene, but no promises :-).

The generic sync process handles replication against multiple replicas of the same database (e.g. when replicating with a Domino cluster) and changing the selection formula between syncs, where we do a performance improved comparison what needs to be added to the target and what does not match the new selection formula anymore and gets purged.

Better testcasesThis is far from being finished, but I started reworking the available testcases so that they do not any longer only "work on my machine", because the sample database that is available for download does not contain some newly added lookup views or documents.

The plan is to automatically create the sample database with the required structure the first time the test cases are executed, based on a Domino address book template, creating lookup views in code and 50.000 fake person documents.

Karsten Lehmann 10 November 2017 17:25:35

Wow - I haven't written a blog post in the last 9 months! It's just so much easier to write a Tweet than to produce long articles, when I split the week between three customers and my family with two children.

Just wanted to let you know that we are alive and kicking and still doing very much Domino related work! :-)

Technologies have as always shifted a bit. Most of the time we create pure JavaEE projects now for our customer web apps, developed in Eclipse and not Domino Designer (ok, using it to create lookup views, still working on that part ;-) ). A Maven build then collects all moving parts and generates an OSGi update site that can be deployed on the Domino server. So our NSFs contain no code and no further design elements except those lookup views.

For the frontend, we are mostly using a mix of Bootstrap, React, jQuery and a lot of open source widgets and libraries that we find on the Internet. Some other areas of interest include using ES5/ES6 JavaScript features like async/await and as always exploring what other database systems have to offer.

The backend of our apps is more and more powered by our Domino JNA project to get the most out of Domino. The project is now used in 7 of our customer web apps and services, of course running on production servers for months.

Since my last post in January, a lot of work has been done to make the project more powerful and more robust.

I'd love to write more about all the features or product some slides and (re-)appear at conferences, but unfortunately time is very limited. So I see what I can do to at least produce more test cases or make the existing ones work.

I should have a bit more time now, since there are not many prio 1 topics left on my list that I need to add to the project. :-)

Karsten Lehmann 16 January 2017 08:21:26

It took some time (mainly because I was very busy and my main use case for the project is not XPages), but now the Domino JNA project is available for XPages development.

That means that there is an XPages Extensibility API plugin available in the project's release section on Github that can be installed both in Domino Designer and on the Domino R9 server to use the API in your own applications.

After installation, the API classes are available in SSJS and Java code including API source code. Since they are integrated with the JSF lifecycle, memory management is automatically handled by the plugin. That means that code using the API does not have to be wrapped in NotesGC.runWithAutoGC() blocks to automatically recycle allocated C handles and memory after a HTTP request.

If you want to build your own release of the project (or of your own fork), please take a look at the section "Using Domino JNA in XPages applications". The Maven build has been tested on macOS and Windows.

New features

Tons of new features have been added to the project during the last months. It's difficult to keep up with test cases and extend code documentation.

Karsten Lehmann 3 November 2016 11:10:49

Last week I sent an email with enhancement ideas for the Domino Java API to IBM development. Most of the stuff listed here (except new @-functions) can be implemented by wrapping existing C API functions or simple copy&paste of already existing code. We already did this using our Domino JNA project, but I thought it would be a good idea to add this functionality to the standard API and provide full platform support.

I don't really have unrealistic expectations whether this will ever be added to the product, given the latest speed new features got in, but I haven't given up hope yet.

I am posting this here in the blog in case it is interesting for anyone.

To navigate the view, NIFReadEntries would be called with NAVIGATE_NEXT_SELECTED / NAVIGATE_PREV_SELECTED flag.

2. int[] View.getAllIdsByKey(Object key, boolean exact)Convenience function to only read the note ids of view entries matching the lookup key for better performance (less data in the summary buffer returned from NIFReadEntries, so more rows read with one C API call).

Using the C API, this can be done with NIFReadEntries calls where only READ_MASK_NOTEID is used as return data mask.

This view lookup technique is already being used by us at a big Domino customer in Germany using C calls (Domino JNA project), but platform support is currently limited to those supported by JNA and this should really be part of the standard API.

Other useful APIs to add:

4. @ModifiedInThisFile / @AddedToThisFile (posted in the Design Partner Forum in January 2014)Two new @-functions to sort view entries by the date their corresponding documents got added to/modified in the database. Required for synchronization of Domino data with external databases. Using @modified instead would not cover changes coming in via replication that happened before the cutoff date for the current data synchronization. Response to DP forum article in 2014 said the feature will be in 9.0.2, so it seems to be already implemented and would need to be added to a feature pack.

5. NoteCollection.add(int[] noteIds)Fast bulk add function to add many note ids at once to a NoteCollection for better performance.

6. int[] DocumentCollection.getNoteIDs()Fast method to get all note ids stored in a DocumentCollection as an int array. If DocumentCollection is sorted internally, the array should have the same sorting. Could be used in combination with "DocumentCollection Database.FTSearch()" to quickly get a note id list of documents matching a fulltext search.

7. int[] Database.getDeletedDocuments(DateTime since, int noteClass)Method to get a list of note ids for documents deleted since the specified datetime. C API function NSFDbGetModifiedNoteTable already returns deleted notes ORed with RRV_DELETED flag. So this function would simply copy this list to an int array. Already available method Database.getModifiedDocuments(DateTime since, int noteClass) is no help because it filters out deleted documents.

Use case is data synchronisation between Domino databases and with external systems.

Karsten Lehmann 11 July 2016 23:33:05

Note (Document) APIsThe last weeks since creating the project, I added basic APIs to work with database notes (documents). The main focus was to be able to read the classic note item value types, e.g. String, Number and Date/Time with single or multiple values per item, handle a few rarely known edge cases (e.g. multiline text values that Domino stores with delimiter \0 between the lines instead of platform dependent \n or \r\n), do proper LMBCS/Unicode conversion routines for special characters like Umlauts and provide access to item metadata like the sequence number or the last modified date of an item.

While reading the note flag documentation, I discovered NOTE_FLAG_READONLY, which Domino automatically adds to the note info area. This note flag can be used to quickly check whether the current Domino user has edit access to a document without all the work of traversing all author items and manually compare the values to @UserNamesList. So that's what is being queried now when you call NotesNote.isReadOnly().

Attachment streamingAnother thing I added was support for note attachment streaming. You probably know that IBM's (poor) implementation of EmbeddedObject.getInputStream() internally first extracts the file to a temp directory and then returns an InputStream to this temporary file. Depending on the file size, that may ruin application performance and fill disk space. So the Domino JNA way of reading attachment is to manually decode the $File items and read the file content in small chunks of 16K, the buffer size of the C function to read attachment data.

The Domino C API provides some easy methods to set item values for selected data types (e.g. single values for text, number and Date/Time). I added them to the Domino JNA as well, but there is still work to do to write multiple values.

A few other things that are new:

User spoofing - reader items on steroidsA NAMES_LIST data structure is what Domino returns when you call NSFBuildNamesList with a Domino username. This NAMES_LIST contains all name variants/wildcards and groups/nested groups on the server for the specified username. It is passed as a parameter when you open a database or a view so that Domino can compute document visibility (reader items) and write access rights.

Ever since writing the code to decode this simple memory data structure, I was asking myself whether it can be built programatically, because it's just the number of names and the null terminated LMBCS encoded list of names.

And since I need that functionality for an upcoming customer project (Google+ like application with very flexible read access rights for postings), I tried it and it worked like a charm. :-)

So now you can build your own Domino users at runtime that do not have to be in a Domino directory. Just pass a Java List with name variants in the NotesDatabase constructor and all operations are executed on behalf of that user.

Unification of view column value readingDomino has two ways to read view column data: READ_MASK_SUMMARY which returns programmatic column names and their values in the summary buffer and READ_MASK_SUMMARYVALUES that just returns the column values.

The latter leaves more space in the summary buffer for data, as the column names never change between view entries. Unfortunately, one new optimized lookup call that IBM added in R9 to atomically look up a key and start reading values, currently only works with READ_MASK_SUMMARY.

I don't think that developers should care about this difference, so I now handle all that internally in the NotesViewEntryData object and you simply call NotesViewEntryData.get("Firstname") to read a column value.

Here is a test case to see some sample code for view data reading (the API has changed compared to the initial release).

Performance optimizationsI did some profiler sessions and optimized the API for performance. The main optimization was to add an LMBCS string decoder cache that reduces the string conversion operations and to lazily convert strings when they are first needed (e.g. when reading only a few view column values).

The code on Github was tested on Mac 64 bit and Windows 32 bit clients so far. The next days, I will do further tests with Windows 64 bit servers since we are using the API in multiple customer projects.

Karsten Lehmann 8 April 2016 19:11:37

I would like to introduce you to a pet project that I have been working on for the last months:

Domino JNA -

Cross-platform access to IBM Notes/Domino C API methods from Java

As you might have already read in this blog in the past, we have been playing with the Domino C API for some time now and found out that you can speed up view reading dramatically when you talk directly to the C API instead of using IBM's Java classes.

The C API also provides lots of other functionality for which no Java or LotusScript methods exist yet.

It has always been possible to build your own DLL with C code calling Domino methods and use it via Java's Native Interface (JNI). We did this in applications developed for customers and partners, e.g. to render Richtext to HTML format, directly stream attachments (IBM's API first stores files temporarily to disk, not a good idea) or replicate databases with a progress callback.

But the problem has always been that the native code has to be compiled for each platform.

JNA to the rescue

Java Native Access is a project that gives Java developers access to native shared libraries without creating their own DLL or library file. You simply call Java methods and make sure that your method arguments match those on the C side.

So I created my first small sample application months ago calling some Domino code, found out that it worked in Windows 32 bit, found out that I had to change something for Windows 64 bit to get more than just crashes, found out that the whole stuff did nothing than crashing in Linux systems, read lots of Domino C API documentation, build testcases, documented the API methods....

An API is nothing without documentation and sample code. And I am working on that, but this takes time. There are already a few testcases available for the view functions.

Since talking to low level functions is not what everybody likes, I am also creating helper functions that make working with the API easier. I rename stuff, I add stuff and hide stuff. So please be aware that this project is definitely not finish and will change, but I want to share the code today because it already creates value and works quite well for us.

Karsten Lehmann 4 March 2016 01:23:48

new view action to extract selected features as an update site to disk (also available in headless mode via Java agents “(API)” and “(Java-API)“)

new view actions to install/uninstall selected features via rcplauncher based deployment, which is used by software distribution systems and should also work on clients where widget deployment is blocked via policy

new database icon

Update: I had to renew the download package on 4th March 2016 and fixed/added the following items:

fixed bug where the rcplauncher deployment log could not be written for Notes data directories containing whitespaces

added alternative UI which can be activated via role [WidgetUILaunch]. Setting the role displays an install wizard on database open instead of the classic Update Site UI views. The wizard guides the user through a a widget (extension.xml) based plugin installation