Now that you've created the application, you should verify that it runs. To do so, you will use some simple system and SQL Server scripts and use the steps detailed in the following sections.
Adding Subscribers, Devices, and Subscriptions to Your Application
In a real system, you would use an application to gather required information about subscribers, their devices, and the subscriptions they want. The nature of this subscription management application will vary. Sometimes you will write an interface devoted purely to the subscription management process. In other cases, the subscription will arise as a result of some other application. For instance, if you are writing a solution for handling customers and online book orders, checking a box titled "I'm interested in other books from this author" should generate a subscription in the background.
For more information about the subscription process, see the SQL Server Books Online topic "Developing Subscription Management Interfaces."
For this example, you will use some VBScript files to add subscribers. A real system would use the Notification Services API to perform the operation exactly as these scripts do.
Adding Subscribers and Subscriptions
Sending Events to Your Application
Usually you will use one of the included event providers to send events to your application. You can send the events through the Event object model (event object API), packed in XML files (XML API), or through the provided stored procedures (SQL Server API).
To find out more about events, see the SQL Server Books Online topic "Defining Event Providers."
In this example, you will use a couple of simple T-SQL scripts that will leverage the SQL Server API stored procedures.
Specifying Which Subscribers Should Be Notified
While you are looking at the events, the system has checked the event's existence and fired the notification generation. Notification Services periodically checks for new events and executes the Event Rule in the Subscription class included in the ADF. The Event Rule inserts a record into the notification table. In this example, the notifications table is SightAlerts. As you see, the notification table name coincides with the Notification class name defined in the ADF.
You can check the expected notifications to send as follows:
Building the Notification Message
Once the Event rule generates the corresponding records in the notifications table, another process called the Distributor takes over. The Distributor performs two tasks: generating the final formatted notifications, ready to send, and passing this formatted content to the actual deliverers. The Distributor will use the content formatter component for the former task, and the latter involves servers external to the solution.
The final form of the notification is stated in the ADF/ICF. As you saw when building the ADF, at the end of the Notification class definition, you declare the corresponding content formatter. The attributes of the content formatter designate the name of the formatter and the required arguments. The XsltFormatter is the standard one and needs no more configuration than the three arguments we will discuss in this section. Other content formatters need a fully qualified name and complementary information that enables Notification Services to locate and use it.
The standard XsltFormatter uses three arguments:
To learn more about content formatters, see the SQL Server Books Online topic "Configuring Content Formatters."
In our scenario, the arguments listed above correspond to the variable _AppPath_ for the base directory path and to the BirdingTransform.xslt file for the XSLT file name.
Note that underneath the content formatter entries, there is a Protocol entry. This entry points to a definition of the protocol in the ICF.
Browsing the ICF, locate the DeliveryChannel element at the end of the file. This element includes the ProtocolName element, whose argument points to an HTML file in the Notifications folder you set up at the beginning of the chapter.
In summary, the Distributor will check the notification table views. There it will find the SubscriberID, the DeliveryChannel, the SubscriberLocale, the DeviceName, and the DeviceAd-dress. With that information, it can call the content formatter to generate the notification "messages" and collect the output for delivery.
When the delivery channel is a file, the process ends when the file is generated; thus, no further distribution or delivery is required.
You can check our example's results by looking in the Notifications folder you created under the project folder when setting up the infrastructure. There, you should find a file named SightNotifications.htm that should contain the formatted notifications in a row.
Real-world delivery will most likely be more complex. Delving into details of server configuration is not in the scope of this book. The scenario we have used does, however, give a good starting point for understanding how notifications work.