[Top] [All Lists]

Re: Looking to subscribe "roles" rather than "users"

Subject: Re: Looking to subscribe "roles" rather than "users"
From: matt roberts
Date: Fri, 10 Mar 2006 11:01:56 +0000 UTC
Newsgroups: microsoft.public.sqlserver.notificationsvcs
Hello Tony,

Thanks for the suggestions.

I understand the second option you suggested - about setting up subscriptions that represent the role memberships. Like you said there's overhead involved in maintaining this but its possible.
I've got an idea that is based on your first suggestion, although doesn't
involve sending one event for each member.
My idea is this (and I've not yet prototyped it, so I can't guarantee I haven't
missed anything);
1) All users in my application subscribe to recieve notifications about new
records, for their userID.
2) When a new record is added, an event is created that includes the recordID,
and a comma-seperated list of users who should get the notification.
3) The subscription matches on subscriptions.UserID IN event.UserIDs

And thats it!

I *think* its going to work, if you can spot any holes in this then feel free to flame me ;)
Once more, thanks to everyone for the advice - its very appreciated :)

Another option would be to use the data you know about  the users and
the roles to resolve the role to each of the current members in that
role.  For each of the members generate events for each of the
individual subscribers which are already known to NS.  This may be a
large number of events in some cases depending on your role
membership, but the control stays within your application and no
changes required to what is carried with NS.

Another option still is to set up a number of subscriptions which
would represent the role memberships for the users - this would
involve a greater amount of subscription management as users changes
the roles they play, but could be work as well.  It would drop the
number of events coming through to one containing say the RoleID and
all subscrbers to a role with id = # would then recieve it.  There may
be limitations here to how customized the mail itself could be based
on receipient.  Did something quite similar to this with account data
where an event would come through for the account and all subscribers
to events for that account would get a copy of the mail (same mail to
each subscriber).

"matt roberts" wrote:

Hello Joe & CoreyB,

Thanks for the reply.

I like the simplicity of the exhange idea, but........unfourtunately
creating exchange distribution lists won't work for this app. The
reason is that its a web app that we provide to many customers, who
install it onn their intranet. We have no control over these
intranets, and cannot setup distribution lists on any of them. Also,
the "roles" change quite often, as people come and go in the
application, so it create a big overhead to sync the exhchange
distributions with them.

Another idea I am considering is to get my web app to pass all the
in the event when it passes one to SSNS. That way, I could allow all
to subscribe to the notification, and then only send out
notifications when:
"subsriber.emailaddress IN event.allemailaddresses"....
Does that sound feasible?
Hi Matt -

Thanks for the kind words regarding a previous post of mine!   :)

CoreyB's suggestion of creating an Exchange distribution list for
your roles would be the easiest solution to implement. That way the
subscriber and associated subscriptions would accurately reflect
what you want to have happen.

Will that work for you?


Get up to speed quickly with SQLNS
I support PASS, the Professional Association for SQL Server.
On 8 Mar 2006 08:53:41 -0800, "CoreyB" <[email protected]> wrote:

My suggestion would be to tack on something in your mail system
(exchange, groupwise, etc. whatever you're using) to have these
"roles" existing as email lists.  User1, User2, User3 could be
grouped in EmailList1 in exchange.  Then in notification services,
the subscriber device would be the email address for EmailList1.
This would be easier than doing a custom delivery protocol.

Or maybe if you don't have exchange or similar, you can setup
forwarders on your email server to forward all messages to
EmailList1 to User1, User2, User3.

matt roberts wrote:

Hi all,

I'm starting designing a SSNS application to support our own web
based app. I've just got the Shyam book for SSNS 2005, which looks
pretty good so far. Anyway, I have a specific requirement that is
making me nervous, and I would appreciate any responses:

In our web app, we have users and roles. A role is a group of
users, for example "Data Inputters", or "Auditors". As part of the
SSNS solution, I need to be able to "subscribe" roles as well as
users. So for example all "Auditors" want to be notified when a
record appears in table X.

I've not seen any examples of this in the book or in the books
online. In mulling over how this could be done, so far I can only
think of the following solution:

1) Subscribe a "dummy" user, (my role)
2) Create a custom delivery protocol, that takes notifications
destined for
my role subscriber, and instead passes the notification on to all
users who
are members of that role.
But this solution "feels" wrong to me, quite complex to develop
maybe even not possible.
I've looked through the existing posts here, and a few posts seem
to be quite similar but don't seem to provide a way forward. A
very helpful chap called Joe Webb wrote this in response to a
similar posting:

That's true. SQLNS is a develoment framework so you cannot really

and choose what portions you'd like to implement.

However, in many (or most) cases you can pretty easily integrate

into your existing process with little duplication.

For instance, since you already have your data in a specific
table, you

can use that information as the basis for your events.

So I'm wondering if this means that since I already have and
maintain a table
of users, and details about which users live in which roles, then
I can tell SSNS to use this data....or perhaps I got that wrong.
Any thoughts/opinions appreciated!
Matt Roberts

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