dominoGuru.com
Your Development & Design Resource
Sometimes IBM Lotus Domino HTTP RPC Agents aren't the answer...
02/05/2010 12:50 PM by Chris Toohey
I was asked via email the other day by a developer (and reader of the site) how they could improve the speed of one of their Lotus Notes Domino Applications. I run into this now and then: an application that's quick and responsive when deployed becomes slower and slower the more it's used. This is often attributed to a combination of transactions (ie., number of concurrent users hitting the application) and data (n number of NotesDocuments, etc.). In this case, it was indeed a combination of both - the function in question being an AJAX-based call to a Lotus Notes Domino Agent Design Element to return JSON data. The more users hitting the application looking for their particular data combined with the growing volume resulted in poor response times from the server.
You can imagine the rest of the story. Taxed application == poor UX == frustrated users == Why aren't we running our applications on Sharepoint|Google|Notepad?
It's a slippery slope, people - and I'm here to tell you how we can dig in with a slight application architecture modification. Now, this might not be applicable to all Lotus Notes Domino Applications, but there are certainly scenarios where this can be one of the most effective and efficient ways to deliver content and avoid scaling issues with Domino HTTP RPC Agents.
Domino HTTP RPC Agents?
Simply put, these are Lotus Domino Agent Design Elements that are called either directly via URL or fired from an functional event which perform some behind the scenes function. For the purpose of this exercise, let's say that our Domino HTTP RPC Agent does the following:
Use Case Scenario
We have a Lotus Domino Web Application - let's say it's a Helpdesk app - and our Helpdesk Analysts are complaining that it's taking forever to get their task information. The task information is returned to the browser client via an AJAX call to a Lotus Domino Agent Design Element, which builds a runtime list of any NotesDocument-driven item that requires their attention. We couldn't use a simple categorized View Design Element as - quite frankly - Views don't allow Data Joins and these items exist across multiple applications.
The Lotus Domino Agent Design Element is getting the job done, but it's on-demand dynamic rendering is taxing the server as more users check their task lists and - as this data grows - it's really responding slowly. People are getting frustrated...
External Indexing
Indexing is one of the applied technologies that makes IBM Lotus Notes
Domino so powerful. Views are indexed to improve response time
for both user interface rendering and data lookups. The Full Text Index itself
is designed to speed up NotesData access when searching (and for those that
don't believe me, try a db.search
versus a
db.ftsearch
...).
The problem is, there are no meta-indexing options available in IBM Lotus Notes Domino... unless you build them yourself!
... and this was the idea behind one of my it's on the to do list applications that I mentioned a while back, which I named MatchMaker. The idea was simple: create a meta-index for use in Lotus Notes Domino Applications. And while MatchMaker would be more complex and a more complete solution, the idea of creating an external NotesDatabase that contains the aggregated information that we need still applies.
Since I am a visual person...
Our Helpdesk application - LND App in the above diagram - doesn't look up the NotesData in it's own NotesDatabase, nor does it access the other NotesDatabases (LND App 2 & LND App 3) for their NotesData, but rather relies on the Index. The Index is a single NotesDocument residing in the External Index NotesDatabase. The Index Agent -- triggered either on event or via schedule -- aggregates the information from the multiple NotesDatabases and compiles it into a single RichTextItem in the Index NotesDocument.
See, it's JSON in this example, but it could just as well be other XML, HTML, or any type of markup.
So, let's say our aggregating Index Agent Lotus Domino Agent Design Element builds our JSON and stores it in the body RichTextItem of the Index NotesDocument... how do we get it?
Well, that part's easy - it's a NotesDocument. You'll either want to use a logic-driven UNID or some type of categorization. Either way, you're going to access the content via combination of a simple Form Design Elements and a Domino URL Command.
Starting backwards and reverse-engineering the result...
You're going to access your Index NotesDocument via the following Domino URL syntax:
http://server/indexdb.nsf/lookup/key
Your key, depending on your approach, will either be your logic-driven UNID or your category.
The lookup View itself is simple:
Column | Value |
1 | categories |
Yeah... that's really all you need. This won't be a UI view, but rather just a simple indexing View Design Element to facilitate our lookup. Your categories could contain anything, and will match your key.
Note: if you're using logic-driven UNIDs, you won't need a View Design Element at all, as NotesDocuments called via UNID can use dummy/placeholder values for the View.
Our Form Design Elements are going to be the easiest thing you've ever built:
- Create a new Form Design Element
- Add a Rich Text Field named Body
- In the Form Properties, modify the Content Type to match your desired output
For example, this will give you a Form Design Element named JSON, with a Content Type set to application/json.
... and that's it. The Index Agent that aggregates your JSON markup and stores it in your categorized Index NotesDocuments should set the desired Content Type as the Form NotesItem value, which completes your build.
And now, instead of relying on an Agent to pull all of this information, you're getting the low-cost, Domino HTTP cached, completely-customizable speed of using a simple Domino URL NotesDocument GET!
The application I mentioned, MatchMaker, will have all of the code to do this... but it's so simple really. If you find yourself needing help before I can publish the app (which isn't high priority on the ol' to do list to be honest), get in touch with me or comment on this post.