RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Get Started Using SQL Server 2005 Notification Services : Page 3

Because of the complex configuration options required to write SQL Server 2005 Notification Services (SQLNS) applications, it can be difficult to get started, but after you've learned the concepts and ideas behind SQLNS, you'll find yourself able to write great applications that are both scalable and extensible using common interfaces.

Using NSControl.exe
After configuring the SQLNS instance and application you must create all the necessary databases and tables specified in the configuration files. SQLNS provides a command utility tool called nscontrol.exe to simplify the process. Table 4 describes the nscontrol.exe options.

Table 4. The table lists the command-line options available for nscontrol.exe.
Option Description
Create Creates a new instance of SQLNS.
Delete Deletes an existing instance of SQLNS.
Disable Disables a SQLNS instance.
Enable Enables a SQLNS instance.
Register Registers a new instance of SQLNS.
Unregister Unregisters a instance of SQLNS.
Update Updates an existing instance of SQLNS.

For example, to create a new instance of SQLNS you call nscontrol.exe with the Create option and supply the name of the Instance Configuration file as a parameter to the call as follows:

   nscontrol.exe -Create -In Instance.xml 
The In parameter specifies the instance configuration file that nscontrol.exe should process. When you make this call, nscontrol.exe creates a new SQLNS instance and registers the SQLNS application with that new instance. In addition, it creates the instance database DMNSMain and the application database DMStockPrice with the structure specified in the Application Definition File. These database names are created automatically by nscontrol.exe and can't be customized in any configuration file.

Defining Events
To make use of SQLNS you need to define events that SQLNS will process to produce notifications. SQLNS processes events from an EventProvider, which writes the new events to the event table. You need to define Event classes that process new incoming events. You define the Event classes in the Application Definition file in the <EventClasses> section. Listing 2 shows the Event class definition for the sample application.

Listing 2 defines only defining one event, called StockEvt. This event consists of the properties StockCode, ExchangeCode and Price. When you create or update the application using nscontrol.exe, it creates a new event table for use by the SQLNS application. To process events you need one additional component—an Event Provider. Event Providers pass new events to SQLNS for processing. You configure Event Providers through the <Providers> section in the Application Definition file as illustrated by the following XML fragment. You can place the <Providers> node anywhere in the configuration file.

The <Providers> section shown above defines an Event Provider named StockEP that uses the built-in FileSystemWatcherProvider. This provider monitors a directory for new files. For example, in the sample application scenario another application periodically places a new file into the WatchDirectory, defined as C:\Events. The StockEP provider watches this directory, processes the event, and writes a new record into the event table. After adding the <Providers> section to the Application Definition file, you must update the SQLNS application using nscontrol.exe.

   nscontrol.exe --Update --in appADF.xml
Because the FileSystemWatcherProvider is a so-called Hosted Provider (the other option is a Non-hosted Provider), you must activate the Service Mode on the SQLNS instance. A Hosted Provider is hosted within a SQLNS instance and a Non-hosted Provider can be hosted in your own application. When you do that, the SQLNS instance runs as a normal Windows Service and monitors the specified directory for new incoming events in the form of XML files.

   nscontrol.exe --Register name DM --server 
      localhost --service
When you execute this command nscontrol.exe creates and starts a new Windows Service named NS$DM. SQLNS always adds the prefix NS$, which indicates that this is a Windows Service used for SQLNS. You can't change the service name prefix using configuration. Because the service is a normal Windows Service you can administer it through the standard MMC Services snap-in.

The <Providers> section shown above also specifies a XSD schema. All new event files written in the event directory must be successfully validated against that XML schema file. Here's the definition for the XML schema file used in the sample application.

                  type="xsd:string" />
                  type="xsd:string" />
According to that schema, an XML event file can have the following structure:

   <?xml version="1.0" encoding="utf-8" ?>
SQLNS processes those event files and writes a new record in the application's event table, NSStockEvtEvents.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date