Best practice (Part 3: workflow & stored forms)
Written by Ben Poole on 07 Nov 2002
Categories / keywords: Best practice, Mailflow, Workflow, Stored forms
(click on a term to search for related articles at this site)
Introduction
Blimey. 'Architecting.' That sounds suspiciously American. Do you mean 'designing'?
Well, yeah, sorry. Let's — ahem — move on. Part 1 of this series talked about giving your application a bit of forethought in terms of where best to put your code. Now we move on to some practical assistance in this regard for you, the fledgeling Notes developer (or indeed for the fully-fledged hoary old coder, who cares?)
If you're a bit of a Notes geek, the whole area of mailflow can get quite interesting... One of my biggest bugbears is that because Notes is a collaborative platform based around messaging, people feel obliged to have their application mail someone about something. Grrr... Come on, we've all done it. OK, so lesson #1: don't mail people for the sake of it. Think about what you're trying to achieve with an application, and take the business processes from there.
Moving on, have you ever produced an application that chugs documents round to various people via Notes mail? Using stored forms? Heh. Aren't stored forms a nightmare?!? They're a great idea, and they have their place. But with a bit of ingenuity you can avoid them sometimes, and do so in a way that doesn't detract from usability. This is going to be the focus of this article.
You probably have used stored forms. They allow you to send mails with nice header graphics and formatted text / tables / whatever in them, not to mention all those extra fields and controls. Well, that's cool. It helps users, and makes life easier. How about I make life harder for you, and we move on to something slightly more sophisticated with the same end result? Yeah? Good. Consider this:
- You have a view, with documents in it. These documents are created by database "super users" and contain the text / otherwise for your emails.
- You have a button or whatever that allows you to select documents (you can of course literally mean "you", or indeed the server, selecting documents programmatically. I'm not fussy) and mail people mentioned within those self-same documents. So, you mail them one or more of your "template" emails.
Now, at this point, most developers would simply do some kind of @MailSend (or if they're more flash, NotesDocument.Send(True)) with a stored form. Far too lazy, and not nearly as much fun. Consider generating a standard email (i.e. Notes "Memo" form) on the fly, complete with rich text elements, dynamic elements per the underlying document, formatting, and so on. It will take you longer in terms of coding / tweaking, but it makes a hell of a difference in terms of source and target mail size, and also allows for easier updating of form design (ever tried to extract the original form from a stored form?)
As an example, I recently got a stored form that was 137KB in size. This document was designed to tell me about a database on one of our servers, providing a button to take a local replica of said file. As a challenge, I knocked up a new version of this document that was identical in terms of look 'n' feel and functionality, yet didn't use a stored form. It took me about an hour to code, and was just over 18KB when emailed. In a reasonable size organisation the dividend here is quite clear, even in this age of vast disk arrays and so forth (who uses shared mail?!?). Not to mention the fact that with lots of stored forms whizzing around, UNK** tables can fill up, and mail routers fail to deliver (ever seen that 'orrible error message, "Database has too many unique field names" or its bed-fellow "Cannot Store Document; Database has too many unique field names..."? That's the UNK table freaking out on you, though it doesn't happen nearly as much in R5 and up).
Anyway, forgetting all that infrastructure stuff, surely as a Notes programmer par excellence you take pride in developing such clean efficient solutions?
The attachment
The attached database contains an "About..." document, a couple of views, an agent and a couple of forms. A button in the "Main view" will send a selected Notes document, as a dynamically generated Notes mail, to you. It's not a stored form. Grab the agent code, and do with it what you will. Add dynamic / rich text elements to your mailshot templates, and observe the difference in size of sending such documents with and without their forms attached. You can even send mails with dynamic buttons (even though there's no nice and easy NotesButton class to leverage) in them, if you think about it hard enough (I did this with my 137KB - > 18KB mock-up mentioned above).
I must use stored forms!
The flip-side of all this is the application that absolutely has to use stored forms. OK, fine. But if these documents end up getting sent back to a database, I can help here too. Again, with reference to the attached database, you should discover in there a resource document containing a code snippet devoted to stripping down stored forms. What this actually does is commented in the code, but essentially, it strips out all "stored form fields", preserves the application-specific fields you need, and gives the document a form attribute. This means that what was a stored form document can now happily reside in your application as a normal Notes document: fields are referenced from a common field table, there are no UNK-related issues, etc. You could perhaps use this code in either a scheduled agent, or in an agent triggered when new mail arrives. Either way, as a developer you get back the flexibility / tweak-ability that is lost when a document stores its form, and database size and speed benefits also.
** - if you want to know more about UNK, look it up in the Lotus Notes knowledgebase... or ask me (contact details to your left). If enough people ask, I'll do some kind of fiendishly techie article on UNK tables and how to look after 'em.
Further reading:
Attachment(s): bp_part3.zip (38 KB)
» Best practice (Part 3: workflow & stored forms) (Ben Poole 07 Nov 2002)
RE: Best practice (Part 3: workflow & stored forms) (Tamajit Sarkar 12 Sep 2003)
RE: Best practice (Part 3: workflow & stored forms) (Ben Poole 12 Sep 2003)
RE: Best practice (Part 3: workflow & stored forms) (Nick 17 Sep 2003)
RE: Best practice (Part 3: workflow & stored forms) (Ben Poole 17 Sep 2003)
