microsoft.public.sqlserver.notificationsvcs
[Top] [All Lists]

Re: digest notifications for different events

Subject: Re: digest notifications for different events
From: Joe Webb
Date: Thu, 02 Mar 2006 07:41:22 -0600
Newsgroups: microsoft.public.sqlserver.notificationsvcs
Can you change your event class model so that it passes another
parameter indicating the type? For example, a ChangeType parameter
where 1 = new doc added, 2 = doc is changed, or some such? 



-- 
Joe Webb
SQL Server MVP
http://www.sqlns.com


~~~
Get up to speed quickly with SQLNS
http://www.amazon.com/exec/obidos/tg/detail/-/0972688811 

I support PASS, the Professional Association for SQL Server.
(www.sqlpass.org)

On 1 Mar 2006 12:56:35 -0800, "gotcha" <[email protected]> wrote:

>Hi,
>
>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
>notification.
>
>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 ?
>
>regards,
>Hilbert

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