All Posts
- Implementation Notes: DRAPI Login via Keycloak OIDC — Works on Domino 12.0.2, No Need to Wait for 14
Wiring DRAPI (Domino REST API) up to a modern IdP like Keycloak, Azure AD, or Okta is widely assumed to require Domino 14, since most of the public documentation centres on the 14-era OIDC story. In practice, DRAPI's oidc mode works on Domino 12.0.2 — no server upgrade required. This article is the implementation notebook from reproducing the full setup locally: picking among DRAPI's three OIDC modes (jwt / oidc / oidc-idpcat), debugging the three-layer auth architecture (identity / mapping / authorization), and the four traps that ate the most time — the biggest of which is providerUrl using localhost failing across machines because Java resolves IPv4 by default. Full step-by-step lives in the companion GitHub repo and Pages site; this article doesn't repeat the setup, it focuses on decisions and pitfalls.
2026.06.01 - HCL Domino 14 vs Earlier Versions: A Reference for Admins and Developers
When upgrading from V11 / V12 to Domino 14.x, the structural changes that actually break existing deployments are surprisingly limited — concentrated in a few areas. This article organises the 14.0 / 14.5 / 14.5.1 differences along five dimensions: notes.ini location, Java / JAR environment, XPages editor (CKEditor → TinyMCE 6.7), new modules (Domino IQ / DQL @FTSearch / AdminCentral / AutoUpdate), and the complete deprecation list (iNotes UI, SNMP MIB, DCT, Server Load Utility, etc.). Each entry is tagged with its starting version and official source, plus a pre-upgrade checklist at the end.
2026.05.31 - NotesRegistration: Automating User Registration with LotusScript
Every Domino admin gets the same drumbeat — new hire onboarding, employee leave, departure notifications, all eventually landing as 'create / update / disable a Notes user' tickets. Clicking through Admin Client one user at a time scales badly. NotesRegistration is LotusScript's built-in answer: a single class that programmatically wraps user registration, certification, and ID-file management. This article walks through the practical HR-system-driven scenario, RegisterNewUser's 14 parameters, the required property setup, the server-context prerequisites, and a complete CSV batch example.
2026.05.30 - FTSearch vs db.Search vs DQL: Choosing the Right Domino Search Mechanism
Starting with Domino 14, there are three technical paths for searching documents: FTSearch (full-text index), db.Search (@Formula full scan), and DQL (introduced in V12, structured query using the design catalog and NIF indexes). This article puts the three side by side in a multi-dimensional comparison table, walks a three-question decision tree, and digs into Domino 14's integration of `@FTSearch()` as a DQL term — which finally lets you express text + structured conditions in a single query. Three practical scenarios (one-off lookup, scheduled agent, high-frequency REST API) map to recommended paths, with cross-links to the full search series and the DQL trilogy.
2026.05.29 - db.Search: Brute-Force Document Search with @Formula — The No-Index Path
NotesDatabase.Search is LotusScript's second search mechanism — no full-text index needed, just @Formula evaluated against every document. This article breaks down the three parameters (formula / dateTime / maxDocs) and how their semantics differ from FTSearch, why the result is unsorted, how the dateTime parameter doubles as a cursor for incremental processing, the truly-unlimited maxDocs=0 (unlike FTSearch's 5000 default cap), the @function subset that doesn't work in this context (UI / lookup / write-back), the snapshot-not-live-view gotcha that catches developers after StampAll, and a production-ready incremental scheduled agent example. Part 2 of a three-part series — the follow-up compares FTSearch / db.Search / DQL side by side.
2026.05.28 - FTSearch: Domino's Three-Tier Full-Text Search API (NotesDatabase / NotesView / NotesDocumentCollection)
FTSearch is a method on three different Domino classes — and each tier returns something different. This article walks through NotesDatabase.FTSearch (returns a new collection), NotesView.FTSearch (filters the view object in place, returns a Long count), and NotesDocumentCollection.FTSearch (in-place reduction, void), the sortopt and options constants, a query-operator cheat sheet, the five CreateFTIndex options-bitmask flags and their relationship to `load updall -x`, the silent gotcha that FTSearch on a non-indexed database still runs (just slowly), the default 5000-document cap, the wildcard `*`-only-at-end constraint, and the must-be-uppercase rule for AND / OR / NOT. First in a three-part series — db.Search comes next, then a decision article tying everything together with the DQL trilogy.
2026.05.27