Showtime
My Blackberry Enterprise Server Push Utility for the Lotus Notes Client, allows you to create Jobs for individual Channel, Message, and Browser Content Pushes, as well as allows you to delete Pushed Channel Icons from defined recipient devices.
Contact Information
Blogger, podcaster, writer, and geek Chris Toohey covers topics from application development to the latest must-have-gadgets.
dominoGuru.com on Facebook
Latest Updates
Products & Applications
Time Tracker
The idea is simple. At the start of your day - upon completion of your first task - create an entry highlighting what you did and whether you feel it was an efficient or inefficient use of your time. Based on several requests, you can also select the priority, apply categories, or even align your time against a project.
For Lotus Notes Client v8.0 and above, you can use the Time Tracker Widget to make this process even easier!
Zephyr
My Configuration-based Rich Text Mail Merge and Emailing Utility, Zephyr allows you to create rich, data-driven emails to support automated workflow - all via Microsoft Word Mail Merge-like architecture. Dear <firstname> allows you to personalize each email message not only to the individual recipient, but also to the individual application workflow event!
xCopy
xCopy is a simple configurable xCopy client for the Lotus Notes client. By creating and defining xCopy Profiles, you can batch process your file backup or remote upload jobs. With the addition of the xCopy sidebar widget, you can easily kick-off these jobs, and modify both the xCopy Profiles and xCopy itself.
Community & Resources
Lotus Technical Information & Education Community
The Lotus Technical Information & Education community is comprised of IBM, business partner, and customer subject matter experts who use product wikis, published articles, white papers, community blogs and the latest in social media to build and share high quality technical content.
OpenNTF.org - Open Source Community for Lotus Notes Domino
OpenNTF is devoted to enabling groups of individuals all over the world to collaborate on IBM Lotus Notes/Domino applications and release them as open source.
developerWorks Lotus : Wikis
Share your deployment experiences and best practices in our wikis and help IBM to create scenarios for successful deployments. Contribute to the community by collaborating on shared content and leverage the shared knowledge from that community.
Sometimes IBM Lotus Domino HTTP RPC Agents aren't the answer...
02/05/2010 12:50:00 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.
|
Unless otherwise stated, this work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
Great stuff, Chris!
ok fair enough, but what you are saying is, create an efficient way to get the data to the user in terms of the way the application is put together. using agents to return data via ajax isn't the problem per se, it's the app architecture.
your example boils down to, the agent is doing too much work. so, do some of the work ahead of time by caching the data for the users. but you are still using ajax to go get the data. at the web layer nothing has changed. in fact you could still use an agent to go get the data out of the document if you wanted to, without a performance hit. it's just that now, the agent isn't piecing together the data at run time. it's been done already, on a scheduled basis, or on save, or whatever. unless i'm missing something?
still it's a great point and well worth considering.
@Lars:
Thanks!
@John:
Well, consider this:
Agent's don't cache. The Domino HTTP Engine will cache a View and NotesDocument - described in the above article - and render it as quickly as a Image or File Resource, or a static Page Design Element.
Sure, the Agent does all of the backend work, which is the main point of this article, but the other benefit is the improved response time you'll see as a result of the Domino HTTP Engine caching the content after it's initial launch.
I think the point here is that it's obvious once you've seen it -- even if it's completely invisible before someone points it out to us (or we have that Aha! moment ourselves). I remember doing just about the same sort of thing with Domino-generated SVG charts quite a while back (somewhere around 2002 IIRC) for the same reason (although I still had to use an agent to read the story to the kiddies so I could use the right MIME-type header; oh, those heady days of R5).
We're an easily-jaded lot, aren't we? It's almost hard to remember what Domino web development looked like ten years ago, and that's a good thing. Slow, fat, frame-driven Notes-on-the-web. It's almost embarrassing to think about.
chris - that's a great point. but then caching presents its own problems. Domino often caches too aggressively. just depends on the requirements of the app, but i'd usually rather have data that is always fresh. there's a balance there and i tend to lean toward fresh data where possible. for instance i write a lot of apps where i'm doing javascript callbacks and iterative ajax calls. so i do want data cached in the document, but very often i don't want the HTTP stack to cache it for me. it just doesn't refresh fast enough. tricks like appending a timestamp to the end of the URL sometimes don't work. why? Domino caching! drives me a little crazy sometimes. just my two cents. great discussion chris! i love your visio mockup - i'm visual like that too. :-)