One problem with creating very useful apps sometimes is that you end up making more work or trouble for yourself 🙂 My QuickMon tool has been created to help me monitor some services and ‘stuff’ which alerts me if things go pear shape… That is all good and wonderful until you (me) realize I’m beginning to ‘spam’ myself with too many messages (since I’m using smtp alerts…). Now they are all ‘valid’ alert messages and I still need to be aware of them but at some point there are just too many individual messages flying around. QuickMon alerts are quite configurable and if you want to some suppression is possible but managing this is almost a job on its own since things change with time, conditions change etc. etc. etc.
So I started thinking (an act that in itself could be dangerous at times) about how to solve the problem by grouping messages before they get sent. QuickMon itself raise alerts and immediately send them off – fire and forget style. Sure, I can build a new notifier that tries to do some batching (not sure how I can do that yet) or modify the QuickMon service itself to ‘hold on’ to alerts for time periods but that won’t be a generic solution any more. A better solution is to build a separate ‘generic’ solution that can also be used from QuickMon plus any other apps I might still create that need smtp messages to be sent out automatically (system level stuff).
This is where the idea of the MailAggregator service started. In itself it is a very simple thing – it runs, periodically checking for all messages from some ‘source’ that need to be send to the same destination, groups them as one message and sends it. The ‘source’ could be a database table or directory with files (or possibly any other place that can store a bunch of messages that can be retrieved at one time. For my own proof of concept I created a simple working example that checks for text files in a directory, use the content as the message content, group/append it, send it and then either deletes or renames the original files.
I decided to make the service a bit more dynamic in that you can add aggregators – implementing a standard interface so adding new aggregator source types in the future would be easy (like Text file and Sql table I already mentioned). Also, the service can run multiple aggregators (of the same or different types) at the same time – each serviced on its own thread (I just love threading but yeh, you have to be careful!). As with QuickMon each instance (or host as I termed it here) can have its own separate config.
So the end result of this little experiment is a working (or should I say workable) example that can already (with some electronic duck tape) be used with QuickMon alerts.
Basic architecture overview
The main component of this little project is again a simple ‘Windows Service’. The service on its own is actually very simple – really just a shell that contains the aggregator hosts which calls the aggregator libraries. A host instance gets created for every config entry (in an array) as specified in the config file.
This service also contains my code for self registration (to install it with the -install command line)
The MailAggregatorHost (class) is the container that holds the ‘aggregator source type library’. Because each source type implements a standard interface the host does not know or care which specific aggregator it is dealing with. The host is the entity that runs in a permanent loop calling the GetMessages() method of the aggregator, sends the smtp messages and then waits until the next iteration.
Each mail aggregator source library implements the IMailAggregatorSource interface for a particular resource type a.k.a. like Text files, Sql table or whatever. The interface itself is fairly simple and has the following members:
- event AggregatorError
- string GetConfigIdentifierType() – will be use later to dynamically load source types
- bool SetConfig(string config) – configure the source type with specified config
- List<MailAggregatedMessage> GetMessages() – get the messages dub…
- string LastError { get;set;} – not used yet but one day….
- MailAggregatedMessage
This is just a container to hold and pass the aggregated messages from the source type to the host.
This is the first example implementation of the IMailAggregatorSource interface that check for plain text files (txt or anything you specify in the config) and groups them for messages. This implementation optionally checks for lines starting with ‘TO:’ and ‘SUBJECT:’. It is possible to specify default values that will be used if these lines are not available. The rest of the file is taken as the ‘body’ of the message.
By default it only groups ‘messages’ by the ‘TO’ address but you can also specify that the subject (plus TO address) will be used for the grouping. Grouped messages simple get appended.
A maximum messages size can be specified so that when a grouped set of ‘messages’ exceed the specified size a new MailAggregatedMessage instance will be created.
Once all the reading and grouping of messages have been done the processed files get either deleted or renamed as per config. When using the renaming option there is another choice – if the renamed file already exists it can either be overwritten or appended. ‘Done’ files are renamed to the original file name plus ‘.done‘.
Example source code
If you like to play with the source code yourself you need VS2010 – it requires .Net 4 (client framework)
MailAggregator