The Realm of Possibilities 2: Keeping Current
Category SNAPPS Projects QuickrContinuing what may be a series (maybe of three, who knows, I could get bored...) of anecdotal approaches to development and customization, the next topic is the concept of managing and expiring Quickr content based on a set of business rules. The rules may be defined by a corporate mandate, regulatory issues, or simply best practices in keeping content fresh.
In this installation, I'll discuss two different approaches taken by two companies to the same issue. Each one was innovative and helped the client meet their specific business needs.
Clients:
International Beverage Company, International Insurance Company
Project:
QuickPlace/Quickr Document "Expiration"
Project Sizes:
Small to Medium
Features:
Project #1:
The firm had a mandate that all content posted on the Extranet, which was a QuickPlace server, be revisited by the author of the content within 180 days to be either a) re-saved, or b) removed. This was driven by a company-wide "document retention" policy. Now of course, there were some exclusions to the rules based on the kind of content entered into QuickPlace. For instance, calendar entries, discussion items, programmatic elements in QuickPlace applications, etc. were not required to be monitored. It boiled down to items in Library folders.
So how do you take this concept of "look at it every 180 days and make sure it's still relevant" and apply that simple rule to an environment like QuickPlace/Quickr, where content may be in hundreds of rooms and authored by hundreds of people? What happens when people move around, or leave positions? There are two approaches to this, and one of them is dead wrong.
Traditional QuickPlace/Quickr development, as discussed in forums, the documentation and Infocenter, would focus on using Lotusscript and Java Placebots in each QuickPlace to gather the information and send off emails. The problems with this approach are numerous when the number of places goes beyond ten or so, but I'll save that list for another post. It's sufficient to say that scheduled placebots are not the way to go when you have numerous places in which to run them.
Solution? A separate Domino application with agents, forms and views designed to aggregate metadata about the documents contained in QuickPlace/Quickr, pair the author information with their email address based on the record in each contacts1.nsf database, and hold that metadata for weekly agent-driven email "newsletters" to inform people of the titles, places and links to library documents. When an author is discovered to no longer be a member of the QuickPlace/Quickr, the Manager of the room in which the document resides is used instead.
Project #2:
This firm had a requirement to manage content, but only certain documents and not a whole category like the Library. They also wanted granular control over two things instead of a global ruleset - how long the document was "live" before a review was required, who was responsible for it when the expiration date came.
We borrowed from the aggregation concepts of the first project, with a twist. In this case, the additional control needed required us to build a custom form in the Quickr placetype. The form became known as the "Managed Content" form, and a description was created so it was obvious that this form was to be used when the content needed to be reviewed after a certain time.
Another difference with this application was that it went into a very large QuickPlace/Quickr environment - 2,500 places, 20,000 rooms. So even by consolidating the processing into a Domino database, it was unreasonable to ask an agent to comb through all the content looking for forms based on these documents like in the first project. A more targeted approach was required.
Upon submission of the custom forms, an Ajax call triggers an agent in the separate Domino database. This agent is passed some parameters including the place name, document UNID, author, email, date for review, etc. and it creates two metadata documents in the Domino database. One is simple, it just has the placename for each place that has triggered the agent. This way, when we do go searching for the documents later, we know exactly which places they are in and can focus the search. The other document is a placeholder for the individual documents that have been created or edited. The weekly agent targets each place and room that has a trigger, then compares the metadata documents to the real content to ensure nothing has been deleted from the place (deletions cannot trigger a placebot, so this cleanup stage is required). Then, an email consolidating all of the links to documents requiring review is sent to the designated author, or as before, the manager of the room if they're no longer around. A mime email is used for good formatting, and the user has a single email to link to all of the reviewable documents, where they can extend the dates, and reassign for the next round of reviews. This feature is useful for delegation or when people change assignments.
The End.
Lesson:
Quickr document management isn't that complex, it just takes some creative thought and use of the tools it presents us with - agents, forms, Ajax, and the judicious use of real Domino databases.
Next up, the flexible view.
Comments
It should all prove very interesting.
Cheers.
Posted by Pete Condon At 04:43:19 PM On 07/23/2008 | - Website - |