Shotgun Mailing

Ian Tree  10 May 2006 14:06:28

Design Pattern for Shotgun (mass) e-Mailing in Domino

Bulk internal e-mailing within a company can be a headache. Point source mass e-Mails can swamp your e-Mail infrastructure and cause tail-backs that can take many hours to clear. The design pattern presented here is a completely scalable solution that will minimise impact on even the largest infrastructures.

• The Problem
• The Concept
• The Design Pattern
  • The Memo Form
  • The Mailer
  • The Reporter

The Problem

You need to e-Mail all of the people in your organisation (or some sub-set of them), the numbers are large and whenever you kick off the e-Mail you swamp your e-Mail system.

The Concept

Instead of using a point source e-Mail to all of your target audience have the sending done on each mail server and the process on each mail server will only send the mail to people whose home mail server is the one on which the process is running. In this way all of the e-Mail activity is purely local delivery (no routing) and the workload is distributed evenly across all mail servers. Following this model it is possible to construct addressing patterns that can be based on any combination of attributes from the Person documents in the directory and avoids the need to build large groups for use in BCC lists.

The Design Pattern

Deploy a replica instance of the "Mass Mailer" database to all mail servers in your corporate infrastructure, the deployment patter should follow the replication pattern for your Name and Address Book(s) (NABs). The database has the following components.

1. The Memo Form

This form should be based on the Memo form from the Mail Template and will need extending to provide additional addressing options according to the addressing schemas that you wish to use. The Send action on the form should be modified so that it sets a trigger value in a specific field that tells the mailing component of the application to do it's stuff. You can, of course, implement any preparation, approval and sending workflows around this Memo form that fits your business practices. It is extremely important that you set the conflict action on the form to "Merge Replication Conflicts", the reason for this will become apparent later.

2. The Mailer

The Mailer is implemented as an agent that is set to run on "Any Server" (and of course must be signed by an ID that has the rights to execute on all of your mail servers). The Agent has a fairly simple structure consisting of an outer loop that iterates all of the Memo documents (in a suitable view that selects only Memos that have been "Sent") and for each one tests to see if the mail has already been sent on this particular server (see later). When a Memo document has been located that needs processing on the current server then the agent enters an inner loop, this loop processes all of the "Person" documents in the Name and Address Book (NAB). For each person the agent first tests if the Person's Home Mail Server is the same as the one it is running on, if not then that document is discarded. For each person on the current server the agent then applies it's address filtering logic. The simplest type of address filtering would be to perform wildcard matching against the organisational hierarchy - so if the SendTo field in the Memo document contained an entry */SALES/ACME then each Person would be tested to see if their hierarchy matched the SendTo entry. The filtering algorithm can be as simple or sophisticated as you like and can be based on any attributes in the Name and Address Book, the algorithm should discard any entries that do not match the address filtering. Person documents that are still selected then get mailed, create a new document in the mail(n).box on the current server, copy all fields from the Memo document to the new document, update the SendTo information with the name of the Person, set any fields needed for mailing (From, Recipients, ReplyTo and PostedDate) and save the new document. Then move on to the next Person document in the NAB. When the inner loop has completed i.e. everyone on the current server has been mailed then mark the Memo document as having been processed on THIS server, do this by creating two fields on the server the first called [Server Common Name].Time contains the current Date/Time and the second called [Server Common Name].Count contains the count of the number of people who were mailed on this server then save the Memo document. You can see now why it was essential to set Merger Replication Conflicts on the Memo form. Once one memo has been processed then the agent moves on to the next Memo if one is available, i.e. continues in the outer loop. The pseudocode for the process is laid out below.

Forall Memos    If Not Processed by Me Yet        Forall Persons            If Home Mail Server == Me                If Selected by the Address Filtering Algorithm                    Send the mail to this person                End If            End If        End Forall        Update the Memo document with time & count    End If End Forall

3. The Reporter

An agent running only on a single server monitors all of the memos that are marked as "Sent", when it detects that all mail servers have done their work by checking the .Time items on the document and perhaps matching them against all of the server (mail) documents in the Name and Address Book (NAB) it then sends an e-mail to the requester of the mass mail memo to tell them that the mail has been sent and gives a total count of the people who were mailed. The agent should then remove the "Sent" trigger form the Memo and possible archive the Memo document.

Share:

Tweet

• Comments [0]