Architecture de traitement des abonnements

Après la collecte des événements, Notification Services peut traiter les abonnements, en générant des notifications. L'évaluation des abonnements par rapport aux événements constitue la tâche du générateur.

Pour générer des notifications, le développeur d'application crée une ou plusieurs règles pour l'application. Ces règles sont écrites sous forme de requêtes Transact-SQL qui spécifient les relations entre événements et abonnements, ainsi que toutes les conditions éventuelles à remplir pour la génération d'une notification.

Dans le cas d'une application simple, lorsque le générateur déclenche une règle, l'application évalue tous les abonnements disponibles en fonction du lot en cours d'événements visibles dans un affichage d'événements. Si un seul événement correspond à un seul abonnement, le générateur de notifications crée une notification. Cette notification contient des données sur l'événement ; elle référence aussi les données relatives à l'abonné, au périphérique de l'abonné et parfois aux paramètres régionaux de l'abonné, ainsi que d'autres informations nécessaires pour la distribution.

La notification n'est pas envoyée dès qu'elle est créée. En fait, le générateur écrit la notification dans une table interne de notifications. Lorsqu'un lot de notifications est prêt, les notifications sont formatées et distribuées par le distributeur.

Si une application prend en charge des abonnements planifiés, au moment où le générateur traite ces abonnements il ne voit que les abonnements dont l'évaluation arrive à échéance. Par exemple, si le générateur s'exécute toutes les 15 minutes, à 8h00, il évalue tous les abonnements qui ont été planifiés entre 7h45 et 8h00.

Si une application utilise des données historiques, elle peut stocker ces données avec les informations sur les événements et les abonnements dans une table supplémentaire, qui est appelée une chronique ; elle peut dès lors utiliser ces données pour produire les notifications.

Le générateur s'exécute selon un calendrier défini par la durée du quantum dans la définition de l'application. Le quantum définit la fréquence selon laquelle le générateur se réveille et déclenche les règles. Une courte période quantum provoque l'exécution fréquente du générateur, et consomme donc plus de ressources système. Une longue période quantum entraîne un délai plus long entre l'arrivée des événements et la génération des notifications.

Types de règles

Le fonctionnement du générateur est contrôlé par les règles définies pour l'application. Vous pouvez créer les types de règles suivants :

• Les règles de chronique d'événements stockent ou mettent à jour l'historique des événements dans les tables de chroniques définies par le développeur de l'application. Chaque fois que le générateur s'exécute, il déclenche en priorité ce type de règle.
• Les règles d'événement génèrent des notifications pour les abonnements pilotés par événement. Ce type de règle s'exécute après la règle de chronique d'événements si un lot d'événements associé est disponible. Ce type de règle peut aussi gérer des tables de chroniques.
• Les règles planifiées génèrent des notifications pour les abonnements planifiés. Ce type de règle s'exécute après la règle de chronique d'événements pour tous les abonnements concernés dont le traitement arrive à échéance. Ce type de règle peut aussi gérer des tables de chroniques.

Types d'actions des règles

Les règles d'événement et les règles planifiées spécifient l'action à effectuer quand la règle est déclenchée. Chaque action est une requête Transact-SQL qui définit une unité de travail à effectuer par le générateur. Ces requêtes peuvent générer des notifications, mais elles peuvent aussi effectuer d'autres travaux, comme la gestion des données des chroniques.

Les règles d'événement et les règles planifiées peuvent utiliser des actions simples, basées sur des paramètres, ou des actions conditionnelles plus souples :

• Les actions simples sont des requêtes Transact-SQL qui définissent entièrement la requête de génération de notification, y compris toutes les clauses WHERE. Les actions simples obtiennent les expressions des clauses WHERE des données de l'abonnement et de l'événement. Par exemple, une application dans le domaine de la météorologie peut permettre aux abonnés de spécifier une localité pour les notifications des conditions météorologiques. La requête de l'action simple va dès lors utiliser une clause WHERE telle que WHERE subscription.city = event.city, qui réalise une jointure des données de l'événement et de l'abonnement sur les noms de localité.
  Quand une règle utilise une action simple, les abonnés fournissent des paramètres pour la requête, tels que le nom de la localité.
• Les actions conditionnelles permettent aux abonnés de définir entièrement les conditions de recherche de leur requête. Par exemple, vous pourriez exposer le schéma des données d'événement dans votre interface de gestion d'abonnement, et permettre aux abonnés de créer leurs propres conditions de recherche sur ces données, telles que WHERE event.State = Washington AND event.LowTemperature < 0. Votre interface de gestion d'abonnement peut rendre l'écriture de ces conditions de recherche aussi simple que la sélection de colonnes et d'opérateurs dans des zones de liste et l'entrée de valeurs dans des zones de texte.

Les actions simples produisent un ensemble limité de conditions de recherche à évaluer par le générateur, et elles fonctionnent dès lors généralement mieux que les actions conditionnelles. Les actions conditionnelles sont plus puissantes, mais elles engendrent une charge supplémentaire due à l'évaluation de davantage de conditions de recherche pour la règle d'événement ou la règle planifiée.

Voir aussi

Concepts

Définition de la durée de quantum du générateur
Définition de règles d'abonnement
Architecture de collecte des événements
Architecture d'administration des abonnements
Architecture de formatage et de remise des notifications

Aide et Informations

Assistance sur SQL Server 2005