Running the Application

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.

More Info

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

1.	Using Windows Explorer, copy the following files from the My Documents\Microsoft Press\SQLAppliedTechSBS\Chapter13 folder to the folder where you have stored the project: AddSubscribers.vbs AddSubscriptions.vbs ViewSubscribersAndDevices.sql ViewSubscriptions.sql
2.	In SQL Server Management Studio, right-click SQL2005StepByStep_NS in the Solution Explorer window. Select Add | Existing Item from the context menu. Add the four files above to the project. The .vbs files will go to the Miscellaneous folder, and the .sql files will go to the Queries folder.
3.	Open the AddSubscribers.vbs file by double-clicking it in the Solution Explorer window, then browse its contents.
4.	You cannot run the VBScript files from inside the Visual Studio IDE. Therefore, return to the Windows Explorer, select the AddSubscribers.vbs file, right-click it, and select Open from the context menu. The script runs. When the script is finished, the message box on the following page appears.
5.	In the event that something is wrong, an error dialog box similar to the one shown below will appear. Resolve the error and rerun the script.
6.	Repeat step 4 with the AddSubscriptions.vbs file.
7.	Return to SQL Server Management Studio, open the ViewSubscribersAndDevices.sql query file, and run it. If the results window shows the subscriber's data, the script has run without problems. Notice that the query is run against a view, not a table.
8.	Open the ViewSubscriptions.sql query file and run it. If the results windows show the subscription's data, the script has run without problems.

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

More Info

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.

1.	Using Windows Explorer, copy the following files from the My Documents\Microsoft Press\SQLAppliedTechSBS\Chapter13 folder to the folder where you have stored the project: AddSightEvents.sql ViewSightEvents.sql
2.	In SQL Server Management Studio, right-click SQL2005StepByStep_NS in the Solution Explorer window. Select Add | Existing Item from the context menu. Add these two files to the project. The files will go into the Queries folder.
3.	Open the AddSightEvents.sql file by double-clicking it in the Solution Explorer window, then browse its contents. Note that the events are added by means of a few stored procedures named NSEventBeginBatchSightData and NSEventWriteSightData. The former starts a batch of events, while the latter adds the specific events. When the event batch is finished, the script executes the NSEventFlushBatchSightData stored procedure to instruct Notification Services that the batch is ready for processing. Notification Services processes the events in batches in order to improve performance. If you were not able to submit batches, Notification Services might fire when events are still being sent to the application, thus reducing the efficiency of the notification multicast and digest functionalities.
4.	Execute the script. It will return the EventBatchID and the number of events received by the application. Write the EventBatchID down; you will need it in the following step. If this is the first time you have executed the script, the EventBatchID will be 1. Each time you run the script, the EventBatchID will increase.
5.	To check the events in the system, open the ViewSightEvents script. Browse it and edit the @EventBatchId parameter value to match the EventBatchId returned by the previous step.
6.	Execute the script. It will return both the EventBatch data and the Event details.

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:

Checking Notifications

1.	Using Windows Explorer, copy the following file from the My Documents\Microsoft Press\SQLAppliedTechSBS\Chapter13 folder to the folder where you have stored the project: ViewNotifications.sql
2.	In SQL Server Management Studio, right-click SQL2005StepByStep_NS in the Solution Explorer window. Select Add | Existing Item from the context menu. Add this file to the project. The file will go to the Queries folder.
3.	Open and run the ViewNotifications.sql script. The Results pane will show you the state of notifications. Warning The Distributor (described in the next section) runs on its own schedule, and therefore it might take some time for the results to show up. Rerun the query every few seconds until it returns a successful or failed delivery status for each pending notification.

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:

• The directory where the XSLT files are located. This corresponds to the XsltBaseDirectoryPath argument.

• The actual name of the XSLT file to apply. This corresponds to the XsltFileName argument.

• Optionally, you can instruct the content formatter that the data contained in the notification table is already in XML or HTTP format and no further content encoding is needed. You might achieve that functionality by including the DisableEscaping argument. The default value for this argument is false.

More Info

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.

Delivering Notifications

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.

Warning

If the SightNotifications.htm file is empty, ensure that the BirdingTransform.xslt file is in the project directory as instructed earlier in this chapter.

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.