RE: Avoiding sending duplicate notifications.
Thanks very much Tony. A chronology table does indeed look like it will solve
my problem here.
In addition, I also need to be able to "log" to the database exactly WHO
recieved a notification and for what, so I think I will be able to kill 2
birds with one stone, so to speak.
This looks like the clasic use of a chronology table use inside the
rule where you would keep track of the specific items you want to
dissallow. You would use the table in the join to filter out say
everyone who had recieved a mail on account 123 already then insert
into the chronology table new rows for those subscribers. The basic
method is outlined in one of the samples for NS and it can be modified
to meet your needs. I used it to perform some filtering on larger
volumn events such that a person would only recieve at most one
message in any 24hr period, but could also be used without a time
component to allow only one.
You could trap the subscriberid and categoryid to allow only one per
category. If you needed to allow for messages only on particular
state changes you could also trap a status value and allow mail only
on certain changes from last message to current event (i.e. only send
mail if the status changed from active to inactive, but not when
change is back to active)
If there is more than one rule to which the same chronology would
pertain, I would think that you could leverage the same table accross
them (I have not tried this myself so no guarantees)
HTH - Tony
"matt roberts" wrote:
I am hoping this is a really simple queastion. I haven't come accross
it yet in Shyam's book...
I want to make sure that people don't get duplicate notifications.
For example, if you can subscribe to recieve notifications when
records of a certain category are added to the system, I want to
allow people to subscribe mutliple times with multiple categories,
but make sure that I don't notify the person more than once when
something happens. Do I need to add state to my SSNS app?