Définition des actions

Une action est un groupe d'instructions Transact-SQL exécutées par Notification Services à chaque fois qu'il active une règle d'abonnement. Chaque règle d'abonnement peut contenir une seule action : soit une action de base, qui est une requête prédéfinie, soit une action conditionnelle, qui permet aux abonnés de définir l'équivalent d'une clause WHERE pour la requête de génération de notification. Cette rubrique décrit les actions de base et comment les écrire.

Actions

Les instructions Transact-SQL d'une action effectuent une tâche donnée pour la règle. Cette tâche consiste en général à générer des notifications en fonction d'une jointure entre les champs d'abonnement et les champs d'événement. L'exemple suivant montre une action qui génère des notifications pour une application météorologique :

INSERT INTO WeatherNotifications (SubscriberId, DeviceName, 
    SubscriberLocale, City, Forecast)
SELECT s.SubscriberId, s.DeviceName, 
   s.SubscriberLocale, e.City, e.Forecast
FROM WeatherEvents e 
JOIN WeatherSubscriptions s
ON s.City = e.City;

Cet exemple sélectionne l'abonné, le périphérique, les paramètres régionaux, la ville et le texte prévisionnel à partir d'une jointure entre l'affichage des événements WeatherEvents et la table d'abonnements WeatherSubscriptions, puis ajoute les résultats à la table de notifications WeatherNotifications. Notification Services crée automatiquement l'affichage WeatherEvents pour la classe d'événements WeatherEvents ; cet affichage contient uniquement le jeu d'événements actuel à traiter par le générateur.

Il n'est pas nécessaire que les actions utilisent l'affichage d'événements et la table d'abonnements. Vous pouvez par exemple interroger des tables dans d'autres bases de données.

En outre, il n'est pas nécessaire que les actions génèrent des notifications. Toutefois, au moins une règle d'abonnement doit contenir une action qui génère des notifications. Sinon, votre application ne générera pas de notifications et ne les enverra pas aux abonnés.

Pour plus d'informations sur l'écriture de requêtes Transact-SQL, consultez Principes de base des requêtes.

Instruction INSERT

Remarque :
L'instruction INSERT remplace la fonction de notification utilisée pour créer des notifications dans Notification Services 2.0.

Comme illustré dans l'exemple de code, vous devez spécifier dans l'ordre cité les champs suivants dans l'instruction INSERT :

• SubscriberId
• DeviceName
• SubscriberLocale
• Tous les champs non calculés définis dans le schéma de notification. Si vous utilisez des champs calculés, n'insérez pas de valeur dans ces champs ; les valeurs de ces champs sont calculées lorsque vous insérez les données de notification.

Ajoutez-les à la table de notifications uniquement dans une règle d'abonnement. Lors du traitement des règles d'abonnement, Notification Services prépare l'activation de chaque règle, active les règles, puis effectue un nettoyage après l'activation des règles. Si vous essayez d'insérer des notifications en dehors d'une activation de règles d'abonnements, la préparation et le nettoyage ne se produisent pas, ce qui provoque des échecs.

Utilisation d'une clause WHERE pour des conditions supplémentaires

Si votre schéma d'abonnement possède plusieurs champs personnalisés, vous pouvez ajouter une clause WHERE pour fournir des conditions supplémentaires. Par exemple, si l'application météorologique permet aux abonnés d'entrer une plage de température, vous pouvez ajouter la clause suivante à l'exemple de code précédent :

WHERE  e.HighTemp > s.High 
    OR e.LowTemp < s.Low

En raison de cette clause WHERE, l'action générera uniquement des notifications si la valeur HighTemp de l'événement est supérieure la plage entrée par l'abonné ou si la valeur LowTemp de l'événement est inférieure à la plage entrée par l'abonné.

Remarque :
Si vous définissez une application dans un fichier XML, vous devez remplacer les caractères XML réservés, tels que « < », par leurs références d'entité. Pour plus d'informations, consultez XML Reserved Characters.

Autres clauses

Transact-SQL prend en charge de nombreuses autres clauses pour l'instruction SELECT. Toutefois, la plupart de clauses ne concerne pas Notification Services. Par exemple, la clause ORDER BY met en ordre les résultats de la requête SELECT, mais cet ordre n'a pas d'incidence sur la manière ou l'heure de mise en forme et de remise des notifications par Notification Services. La clause UNION peut est utilisée pour combiner les résultats de deux requêtes, mais elle est rarement utilisée pour les règles d'abonnement.

Utilisation des procédures stockées

Au lieu d'incorporer les instructions Transact-SQL dans l'action, l'action peut appeler une procédure stockée. Vous devez créer la procédure stockée dans la base de données d'application. Vous pouvez définir la procédure stockée dans un script de déploiement. Vous devez créer la procédure stockée une fois que Notification Services a créé l'instance ou ajouté l'application, mais avant que vous activiez l'instance ou l'application.

Pour utiliser une procédure stockée, exécutez-la à partir de l'action. L'exemple suivant montre une action qui exécute une procédure stockée :

EXECUTE dbo.WeatherActionSP;

Transactions

Toutes les instructions d'une action font partie de la même transaction ; ainsi, elles se terminent toutes avec succès ou elles sont toutes restaurées. Si la transaction échoue, Notification Services écrit une erreur dans le journal d'application Windows.

Actions pour des règles d'événement

Les actions des règles d'événement sélectionnent généralement les données d'événements à partir d'un affichage nommé d'après la classe d'événements. Cet affichage d'événements fournit uniquement le jeu d'événements actuel, ce qui garantit que l'action n'utilise pas les événements anciens de la table d'événements.

Attention :

N'utilisez jamais la table d'événements, qui porte le nom NSEventClassNameEvents, comme source d'événements. Les tables d'événements contiennent tous les événements qui n'ont pas été supprimés de l'application, ce qui provoquera des notifications dupliquées par votre application. De même, n'insérez jamais de notifications directement dans la table de notifications. Insérez plutôt les notifications dans l'affichage nommé d'après la classe de notification.

Modèle

Le modèle suivant présente la structure de base d'une action pour une règle d'événement. Ce modèle d'action montre comment joindre les événements de l'affichage des événements et les abonnements de l'affichage des abonnements et comment insérer les résultats dans l'affichage des notifications.

INSERT INTO schema.notificationClassName (SubscriberId, DeviceName, 
    SubscriberLocale, NotificationFields)
SELECT s.SubscriberId, DeviceName, SubscriberLocale, Fields
FROM schema.subscriptionClassName s 
JOIN schema.eventClassName e
ON s.columnName = e.columnName
[WHERE...][;]

Vous pouvez sélectionner les valeurs DeviceName et SubscriberLocale d'une source de données, telles que l'affichage des abonnements, ou fournir des valeurs littérales tel que « File » et « en-US ».

Notez que les valeurs SubscriberId et DeviceName doivent correspondre à un enregistrement de la table SubscriberDevices.

Gestion des chroniques d'événements

Vous pouvez également utiliser les règles d'événement pour gérer les chroniques d'événements. Ainsi, la règle d'événement peut utiliser l'ancienne chronique d'événements pour vérifier la valeur des événements précédents avant de générer les notifications. Vous pouvez créer une nouvelle règle d'événement pour la gestion des chroniques ou ajouter du code de gestion des chroniques aux instructions d'une règle d'événement existante.

Remarque :
Dans le cas de plusieurs règles d'événement, Notification Services peut activer les règles dans n'importe quel ordre.

La règle suivante supprime d'abord toutes les données de la chronique d'événements. La règle sélectionne ensuite le lot d'événements actuel de l'affichage WeatherEvents et ajoute les événements à la chronique d'événements.

DELETE FROM dbo.WeatherEventsChron;
INSERT INTO dbo.WeatherEventsChron(City, Date, Low, High, Forecast)
SELECT e.City, e.Date, e.Low, e.High, e.Forecast
FROM dbo.WeatherEvents e;

Si vous souhaitez mettre à jour la chronique d'événements avant de générer des notifications, définissez la règle de chronique d'événements dans la classe d'événements. Pour plus d'informations, consultez Définition des règles de chronique d'événements.

Pour définir une action pour une règle d'événement

Si vous définissez une application par le biais de XML, définissez les actions dans le fichier de définition d'application (ADF). Si vous définissez une application par programme, utilisez Notification Services Management Objects (NMO) pour définir les actions.

• Action Element for EventRule (ADF)
• Propriété Action (NMO)

Actions pour les règles planifiées

Les actions des règles planifiées sélectionnent généralement les données d'événements à partir d'une chronique d'événements, et non à partir de l'affichage des événements. L'affichage des événements fournit uniquement le lot d'événements actuel et peut être vide lors de l'exécution de la règle planifiée.

Modèle

Le modèle suivant présente la structure de base d'une action pour une règle planifiée. Ce modèle d'action montre comment joindre les événements d'une chronique d'événements et les abonnements de l'affichage des abonnements, puis ajouter les résultats à l'affichage des notifications.

INSERT INTO schema.notificationClassName (SubscriberId, DeviceName, 
    SubscriberLocale, NotificationFields)
SELECT s.SubscriberId, DeviceName, SubscriberLocale, Fields
FROM schema.subscriptionClassName s 
JOIN schema.eventChronicleName ec
ON s.columnName = ec.columnName
[WHERE...][;]

Dans l'instruction SELECT, vous pouvez sélectionner les valeurs DeviceName et SubscriberLocale d'une source de données, telles que l'affichage des abonnements, ou fournir des valeurs littérales tel que « File » et « en-US ».

Gestion des chroniques d'abonnements

Vous pouvez également utiliser les règles planifiées pour gérer les chroniques d'abonnements. Pour plus d'informations sur les chroniques d'abonnements, consultez Définition de chroniques pour une classe d'abonnement. Vous pouvez créer une nouvelle règle planifiée pour la gestion des chroniques ou ajouter du code de gestion des chroniques aux instructions d'une règle planifiée existante.

Remarque :
Dans le cas de plusieurs règles planifiées, Notification Services peut activer les règles dans n'importe quel ordre.

Pour définir une action pour une règle planifiée

Si vous définissez une application par le biais de XML, définissez les actions dans le fichier de définition d'application (ADF). Si vous définissez une application par programme, utilisez NMO pour définir les actions.

• Action Element for ScheduledRule (ADF)
• Propriété Action (NMO)

Voir aussi

Concepts

Définition des actions de condition
Définition de règles d'événement
Définition de règles planifiées

Autres ressources

WHERE (Transact-SQL)
INSERT (Transact-SQL)
SELECT (Transact-SQL)
Définition de classes d'abonnement

Aide et Informations

Assistance sur SQL Server 2005