DOTS and the eMail life cycle

To use the words of my friend Mikkel: " Domino OSGi Tasklet Container (or DOTS for short) is an uber-cool OpenNTF project that allows you to write addins for the Domino server in Java. The project used to be called JAVADDIN which kind of gives the purpose away.". Together with a simple mail rule DOTS is your entry ticket in a complete eMail life cycle management solution. Despite eMail being around for a very long time, the concept of eMail life cycle management seems to be very alien to a lot of IT managers (and it definitely sounds less exiting than Cloud computing strategy). Let's have a quick look:

• All eMails are created equal: someone wants to communicate something. The eMail leaves the sender's mail application and hits the mail server.
• The eMail is subjected to more or less technical scrutiny: is it small enough, is there no virus, is routing to a next hop possible (and where to)?
• The eMail is subjected to business decisions: can that user send (e.g. leak prevention, destination check etc.), does the eMail need retention, does the eMail need to trigger a business process (approval, alert, associate, alter)?
• Messages get delivered and now the sent message is a received message
• The eMail is subjected to more or less technical scrutiny: is it small enough, is there no virus, can messages from this source be accepted, can it be delivered?
• The eMail is subjected to business decisions: can that user receive, does the eMail need retention, does the eMail need to trigger a business process (alert, associate, alter)?

While the technical rules are well understood, the business rules typically are not developed deeply, after all "it is just eMail" and not a business rule engine. DOTS allow to "open the door" to business rule processing. The beauty of a DOTS approach: no template needs to be harmed! It will work with all access methods (client, web, POP, Traveler) and for any message (send by user, send by agent) A few steps are necessary:

1. DOTS needs to have the time to "catch" messages that are deposited into the server's mail.box(es). Since the router would get in its way, a mail rule in the server configuration document needs to work on "all documents" and set routing status to "HOLD" (that is stored in the NotesItem "RoutingState")
2. Write a DOTS tasklet that processes all documents that have been created in the mail.box (that's a triggered tasklet, not a scheduled) and remove, once done, the NotesItem "RoutingState". The router will then pickup the message for delivery
3. Business rules are wide and many, so you might want to use a rules engine. The JSR 94 describes the Java API for a rules engine and the WebSphere ILOG JRules are an implementation of it. You also can consider one of the OpenSource rule engines or adopt Apache Mailets to your needs. Of course for a small logic set coding it in the tasklet will give the best performance
4. Test, Test, Test!
5. A Prêt-à-Porter solution, if you want ready rules, is the Group iQ.Suite combining technical and business rules.

As usual YMMV