[Top] [All Lists]

digest notifications for different events

Subject: digest notifications for different events
From: "gotcha"
Date: 1 Mar 2006 12:56:35 -0800
Newsgroups: microsoft.public.sqlserver.notificationsvcs

we're currently designing a notification system for our document
management product, and we're thinking about using SQL NS instead of
developing a home-brewn subscription engine.

SQL NS looks very promising to us. However, one of the critical
requirements for our subscription system is the ability to bundle
multiple notifications into a single e-mail message.
SQL NS does support digest delivery, which is able to bundle all
notifications for a single event class into one message.

That would be very nice, if I would have only one event class.
However, I've got a whole bunch of different events happening in the
document management system.
For example:
- new document is added
- document is changed
- document is due to expire
and so on..

Our users can subscribe to any combination of these events, however,
they don't want to receice separate e-mails for every event type. They
don't want a mail which tells them which documents are added, and
another mail telling them which documents are changed.
Instead of separate mails, I need to be able to combine all
notifications into one single message.

As far as I can see, there is no way I can change the way SQL NS
determines which notifications can be digested into one single

This leaves me with 2 alternatives:
1) not using SQL NS
2) use SQL NS, and build a custom delivery protocol.
The custom delivery protocol would store all notifications into a
database table.
While the delivery protocol handles all subscriptions, notifications
for all event types are collected together in this database.
Following to that, I would run a "GROUP BY subscriber" query on this
table to get the notifications for each user. Finally, I would create
an e-mail message for each user, containing the grouped notifications,
send this message via SMTP, and clean up the table.

I don't like option 1), because it would cost us a lot to develop our
own system, and especially make it perform as well as SQL NS.
Option 2) isnt' that great either.

So, are there any alternatives to solve this problem ?


<Prev in Thread] Current Thread [Next in Thread>