Subscriptions, Notifications, and Alerts

 <  Day Day Up  >  

Users not only need to be able to find information when they need it, but they want information to be delivered to them before they know they need it. Subscriptions, notifications, and alerts are valuable tools to achieve this capability. The .NET platform provides a number of ways to create and manage these types of personalization. The key concepts to understand are:

  • Subscriber. The person or application that receives notifications.

  • Subscription. Request for content or information, such as newsletter subscription, notification of news items, or updates to content in the portal.

  • Event. A change that triggers a notification, such as a sports score, product delivery, stock price change, or nearly any occurrence that is tracked in your database.

  • Notification. A message transmitted to the subscriber. This may take the form of an email message, an XML document sent to a subscribing application, or an update to a web page viewed by a user .

In the simplest form of subscriptions, users can subscribe to one or more online publications that are delivered via email. For instance, Microsoft provides many subscriptions to cater to different interests such as home computing, enterprise computing, operating systems, and general corporate news. You create a subscription by entering information in a web form. In the case of microsoft.com, your identity is managed with the Passport service. You may want to create your own similar newsletter and use your web site to gather email addresses from subscribers.

If you provide subscriptions, be sure to provide a page on which users can change their email newsletter subscriptions. Microsoft.com uses the page displayed in Figure 8.9 to allow users to add, edit, or delete subscriptions. You may also want to provide a link in the body of the newsletter itself to allow a user to change or cancel a subscription.

Figure 8.9. Maintaining Subscriptions in the Microsoft Profile Center of microsoft.com

graphics/08fig09.gif


Subscriptions can generate alerts when the content changes in ways that are even more targeted than for a newsletter. For instance, bidders on government contracts might want to subscribe to changes in documents relating to requests for proposals. With the high volume of contracts, users would not want their mailboxes flooded with every possible bid opportunity. Instead, they would prefer to choose their industry and products so they receive the appropriate bids.

For instance, the U.S. government posts requests for bids on a site called FedBizOpps. Through browsing or search, a user could find an opportunity such as the Coast Guard procurement request shown in Figure 8.10.

Figure 8.10. Coast Guard Procurement on FedBizOpps

graphics/08fig10.gif


Procurements consist of a number of documents. They start with a synopsis along with key dates in the procurement. The solicitation is in a separate document, and it may be accompanied by additional documents such as a bidders list, amendments , and background information. Bidders need to keep track of the procurement as it moves through the process. At the bottom of the page is a link to subscribe to the procurement. Clicking this link opens the page shown in Figure 8.11.

Figure 8.11. Acquisition Notification Service Subscription Form

graphics/08fig11.gif


The government contract or enters an email address and clicks Subscribe to Mailing List to receive notification whenever a new document is posted on the site. Federal Business Opportunities sends an email such as that shown in Figure 8.12 containing updates and links to the appropriate documents to which the contractor has subscribed.

Figure 8.12. Subscription Email

graphics/08fig12.gif


Finally, in a more sophisticated form, notifications can be event-driven, which means they are triggered when an event is reported to the system or scheduled. Events can come from inside a database or from another source. For instance, an investor might request a message when a stock price hits a certain level or when it varies more than 10% from its opening price in a single day. This is what SQL Server Notification Services calls a notification.

Notifications can be sent to a range of devices and programs. For instance, Microsoft Windows Messenger includes a notification service called Microsoft .NET alerts. You can receive popup messages based on your alert subscriptions. Similarly, notifications can be sent as email to any device that can receive email and also to cellular phones, personal digital assistants, and other devices. Anyone who owns a device such as a Pocket PC would probably appreciate receiving these notifications.

Both external and internal customers can benefit from notification services. They provide a rapid and automated means of reaching out to interested parties. The notification may contain a URL of a page that provides additional information. Imagine the value of letting customers and employees know when an order is running late or when a product has been recalled by its manufacturer.

In sum, subscriptions, alerts, and notifications can bring users back to your portal again and again and foster a stronger sense of community. They are also more targeted than a blanket email because they contain content that subscribers actively requested . This section introduces several approaches to integrating these capabilities into your portal.

SharePoint Subscriptions and Alerts

SharePoint provides similar subscription and alert functionality to that shown for FedBizOpps in the previous section. It applies to many portal elements: lists and list items, people, documents and folders, categories and news, sites and searches. Users can create their own subscriptions or they can be set by administrators. From a user perspective, starting a subscription is as easy as clicking Alert Me on a content page. For instance, Figure 8.13 shows the Alert Me link in the Actions menu of the News page.

Figure 8.13. News Page

graphics/08fig13.gif


By creating an alert (see Figure 8.14), users receive email notification whenever new items are added to the News page.

Figure 8.14. Adding a News Alert

graphics/08fig14.gif


Users can elect to have alerts displayed in the My Alerts web part or receive email notification of new content (or both). Clicking the Advanced options link on the Add Area Alert page reveals options for filtering the results of the alert based on criteria provided and determines whether updates or new items appear in the alerts (see Figure 8.15). The discussion group alert does not have an option to show the alert on the web page.

Figure 8.15. Add News Alert Advanced Options

graphics/08fig15.gif


Not all the SharePoint alerts behave in exactly the same way. For instance, when you subscribe to a threaded discussion, you get additional options, as shown in Figure 8.16. These let you receive an aggregated email containing multiple alerts on an immediate, daily, or weekly basis.

Figure 8.16. Alert for Discussion Group

graphics/08fig16.gif


Alerts are an excellent way to bring users back to the portal. For many of us, we belong to so many virtual communities that it is easy to forget to check in without a gentle reminder, such as an alert email.

SharePoint Audiences

The audiences feature of SharePoint Portal Server allows the administrator to target content to users based on attributes in their personal profiles.

Users can belong to one or more audiences used to target content. For details on creating an audience and an audience rule, see Chapter 7.

Subscriptions and Alerts with SQL Server 2000 Notification Services

For the most advanced notification capabilities on the Microsoft platform, the place to turn is SQL Server Notification Services (NS). This product is a highly scalable solution integrated with SQL Server and .NET, allowing application developers to add notification capabilities to an SQL Server database. Notification Services shipped in 2002 as an add-on for SQL Server 2000. It is covered by a customer's SQL Server licensing and is available as a free download. For customers licensing SQL Server on a per processor basis, there is no limit to the number of users who can receive notifications under the license. These users need proper server and client licenses for SQL Server but no special license for Notification Services.

Notification Services is essentially a database application devoted to providing scheduled and event-driven notification. It uses the familiar Transact-SQL, XML, and .NET programming environment you used to create the application in the first place.

The Notification Services architecture consists of the following elements (Figure 8.17):

  • SQL Server databases. Provide the repository for subscriber and subscription data. There are at least two databases involved: One holds instance data (subscribers, delivery channels) and one is created for each notification application to contain the subscriptions, events, and notifications for that application.

  • Notification Services application programming interface (API). Provides standard programming interfaces for Notification Services. For instance, subscription management objects are referenced by the developer to create a Notification Services application.

  • Event providers. Watch for events to occur, such as a new record being written to a database table, or a file being modified in the file system. May run in the event provider host or independently. The event provider writes to the database, like the subscription management application does. The generator then matches information in the event and subscriptions tables based on Transact-SQL rules specified by the developer.

  • Generator. Periodically runs to check events against subscriptions and generate notifications, forwarding them to the distributor component.

  • Distributors. Formats using a content formatter and transmits notifications to subscribers using one or more delivery services, such as SMTP email.

Figure 8.17. SQL Server Notification Services Conceptual Architecture

graphics/08fig17.gif


Notification Services provides control over the types of subscriptions and how notifications are delivered. The first step in designing a notification solution is to determine what subscriptions you want to provide to your users. The two types of subscriptions are scheduled subscriptions and event-driven subscriptions. Notifications for scheduled subscriptions are sent at a predetermined time, such as a daily email newsletter, or stock prices at market closing time. Notifications for event-driven subscriptions are triggered by an event. A change in a flight time, for example, could trigger notification to all passengers with reservations .

The subscription schema is the database structure for storing subscription information. While some fields, such as the subscriber ID, are required for all subscriptions, others are optional depending on the functionality of the subscription. You would need a field for subscriber device name to allow subscribers to receive notification on more than one device. Similarly, you would need locale information or target language to personalize a notification for the subscriber's region or language. Finally, you would need to specify the proper device to generate the notification. You do not have to store this content in the subscription necessarily , but you do have to get it from somewhere. Storing the information in the subscription record is the most common choice.

The next step in notification planning is to determine the content of the notification. For scheduled notifications, the content may be the same for all subscribers. Event-driven subscriptions tend to be more personalized and may contain data that is unique to the subscriber. For instance, order shipment confirmation could be sent as a notification based on the update to the shipped date field in a commerce database. In other words, the notification can consist of whatever content you choose, but it usually contains some static text combined with fields from the database and URLs for additional information. The optional fields are defined in the application definition file (ADF), as shown in Listing 8.1.

Table 8.1. Common Fields for Subscription Schema

Field

Type

Comments

SubscriptionID

Bigint

Required

SubscriberID

Nvarchar(255)

Required

Enabled

Boolean

Included automatically; default is true

SubscriberDeviceName

Nvarchar(255)

Allows multiple notifications per subscriber

SubscriberLocale

Nvarchar(255)

Allows localization


Listing 8.1. Application Definition File
 <Schema>    <Field>       <FieldName>OrderNumber</FieldName>       <FieldType>char(10)</FieldType>       <FieldTypeMods>NOT NULL</FieldTypeMods>    </Field>    <Field>       <FieldName>OrderPrice</FieldName>       <FieldType>money</FieldType>       <FieldTypeMods>NOT NULL DEFAULT 10</FieldTypeMods>    </Field> </Schema> 

You can design the format for the notification in pseudocode. For instance, you may want to use HTML tags to highlight certain information, and combine data from database fields with boilerplate text as in Listing 8.2.

Listing 8.2. Boilerplate Text in Customer Service Letter
 Dear [customer salutation]: I am pleased to inform you that your order number [order number]  shipped as of [shipdate] via [shipping method]. We appreciate your  business and look forward to serving you in the future. Best wishes, Customer Service 1-800-555-1212 

You need to determine the triggers for the notification, which means you need to build the event schema, event source, and notification rules. SQL Notification Services can obtain event information from XML data files, from SQL Server database tables, or somewhere else. You can build a custom provider to get data from almost anywhere . You could subscribe to a news ticker, for instance, and store the contents of the ticker in an XML file. Whenever a headline arrived that contained a keyword specified by the user and stored in a SQL Server database table, the event would be triggered. If I were to subscribe to "Tiger Woods" as a keyword, for example, that character string would create an event.

The notification generation rules compare the event with the subscription conditions to determine whether a notification should be sent. If the event information fulfills the subscription conditions, a notification is generated. The events are often recorded in a chronicle using an SQL Server database table for future reference. The notification generation rule is expressed as an SQL query such as Listing 8.3.

Listing 8.3. SQL Query
 SELECT i.ProductCode, i.Inventory FROM Inventory i, InventorySubscriptions s WHERE i.Inventory < s.InventoryTriggerValue AND i.ProductCode = s.ProductCode 

This query would send a notification to a subscriber whenever the inventory of a specified product fell below the inventory threshold specified in the subscription. The notification generation rule must contain a notification function ”a plain SELECT statement won't work. The Notification Service documentation for additional details.

The notification formatting is handled using an XSLT file, which gives the developer maximum flexibility in designing and formatting the notification. As a result, the notification is generated appropriately regardless of the target device.

Developers can deliver notifications through Simple Mail Transfer Protocol (SMTP) or a custom HTTP-based delivery protocol. Notification Services provides two interfaces for developing the custom protocol, implemented as a class in a managed code assembly. The custom protocol can use HTTP (using the IHttpProtocolProvider interface) or any other protocol (using the IDeliveryProtocol interface).

 <  Day Day Up  >  


Building Portals, Intranets, and Corporate Web Sites Using Microsoft Servers
Building Portals, Intranets, and Corporate Web Sites Using Microsoft Servers
ISBN: 0321159632
EAN: 2147483647
Year: 2004
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net