Obtaining destination e-mail address

I have been asked if we can give NS the destination e-mail address via our Application's Event Table. I have suggested that this defeats the purpose of using NS and that we should instead call the Subcription Classes from our system to create and manage subscriptitons. That way we can take advantage of the more advanced Distribution features in NS. Is this the right way to think about NS or is passing the e-mail a common practice?

Thanks

...Ray

Hi Ray -

I'll agree with you. If I'm understanding your question correctly, what you're describing effectively shifts the burden of matching to the event provider.

For example, to send notifications to a set of subscribers, the event collection mechanism will have to determine what set of subscribers should be notified. Additionally, since each event will have an email address too, you'll potentially have lots of almost identical events, only differing by the destination email address. This is certainly the case for the sample apps - stocks, flight, etc - where the event data is not tied to any particular person or customer.

Your implementation may have some specific characteristics that would allow their suggested approach to work; for example the notifications are to notify customers when their order has arrived. In this case there is (or almost is) a one to one corrolation between the customer and the notification. But still your generator rules will have to be such that a match can be made.

I think the better approach is to get the email address from NS, allowing it to do what it does really well. The concept of subscribers is central to SQLNS.

I'm curious as to what the perceived benefit of getting the email address from the event would be.

Here's a link to a news group posting where Shyam describes how it's possible to bypass the subscribers view in NS and use one of your tables instead - something akin to a customers table in one of your own databases. He's not necessarily advocating it, just describing that it's possible.

http://groups-beta.google.com/group/microsoft.public.sqlserver.notificationsvcs/browse_thread/thread/9b66e513159c0c6a/32afae9a31b39e43?lnk=st&q=%22are+views+really+needed%22&rnum=1&hl=en#32afae9a31b39e43

HTH...

Joe

--
Joe Webb
SQL Server MVP

~~~
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)

|||Thanks Joe

To answer your question the perceived benefit is that the implementation might be easier/quicker.

Unfortunately I am dealing with someone who doesn't realize just how complex NS really is and I the pressure is on to do this really quickly. In his mind, a day and your done and the whole thing is in production. Maybe if you are already an expert or have written a book on the subject. The learning curve on this product is longer than that from what I have seen and some of the problems I've been getting are hard to debug (Ill post one of them next).

The books are OK but its all very hit and miss in terms of understanding how the thing really works. I wasn't mentally ready for how complex NS is.

...Ray|||Ray,
I understand that there's a lot ot learn before you can be productive with NS. Many things we're doing in the next release are aimed at reducing this burden.

That said, NS is very flexible and powerful and in the end, will help you build a production application more quickly than if you were doing it from scratch. I know this seems counter-intuitive (and it sounds like you're fighting some of the other argument from your managers/colleagues), but experience with many large production deployments has demonstrated this to be true over and over.

At first glance, building a notification app seems simple. Collect some events, match subscriptions, deliver emails. Nothing hard about that, in principle. But in a production app, there's much more too it than that. If you have lots of users, you have to think about scalability - building a scalable matching engine yourself isn't trivial. YOu have to think about reliability if the system is used in business - how do you guarantee uptime for your application. How do you support advance features like application state, scheduled subscriptions, formatting for multiple cultures/devices, delivery retry. What about administration? You'll need tools and processes to maintain the app over time. Speaking of maintenance, how do you make changes to the application without long downtime or losing data?

SQL-NS gives you all these things "out of the box", though admittedly, it takes a little while to learn. However, once you get the first app built, you really can prototype the next one in a day.

A large number our SQL-NS customers end up using the platform after trying unsucessfully to build their apps from scratch. It seems easy at first, but after you get started down the path, there are lots and lots of issues to resolve. SQL-NS thankfully deals with all these under the hood. Hopefully some of these arguments will help you as you discuss the merits of what you're doing with your management.

Please do keep posting your questions. We'll help you get up to speed and get your application working with SQL-NS.
Regards,
-shyam