Définition des actions de condition

  • Article

Mis à jour : 17 juillet 2006

Une action est un groupe d'instructions Transact-SQL qu'exécute Notification Services à chaque fois qu'il active une règle d'abonnement. Chaque règle d'abonnement peut contenir une action, soit une action de base qui est une requête prédéfinie, soit une action de condition 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 condition et explique comment les écrire.

ms172509.note(fr-fr,SQL.90).gifImportant :
Utilisez des actions de condition uniquement si vous devez autoriser les abonnés à créer leurs propres conditions complexes pour générer les notifications. Sinon, utilisez les actions prédéfinies qui autorisent les utilisateurs à entrer des valeurs pour une requête paramétrée, ce qui est plus efficace. Pour plus d'informations, consultez Définition des actions.

Actions de condition

Une action de condition permet aux abonnés d'écrire des règles souples. Alors qu'une action prédéfinie permet uniquement aux abonnés de spécifier des valeurs de paramètres pour les requêtes définies par le développeur, une action de condition leur permet de créer l'équivalent d'une clause WHERE pour la requête, en utilisant les opérateurs booléens (AND, OR et NOT ) pour combiner des conditions individuelles.

Une application météorologique, par exemple, peut comporter une classe d'événement contenant deux champs : City et Forecast. Le développeur peut définir une requête de base pour créer des notifications, par exemple :

INSERT INTO dbo.WeatherNotifications(SubscriberId, DeviceName, 
    SubscriberLocale, City, Forecast) 
SELECT [Subscription.SubscriberId], [Subscription.DeviceName], 
    [Subscription.SubscriberLocale], [Input.City], [Input.Forecast])
FROM dbo.FlightEventRule

Notez que cette opération sélectionne les données à partir d'une vue nommée selon la règle (dans le cas présent, FlightEventRule). Les champs de cette vue sont nommés Subscription.SubscriptionFieldName et Input.EventFieldName, ce qui nécessite que les noms de champ soient entre crochets.

Via une interface de gestion d'abonnement, un abonné peut définir des conditions qui équivalent à une clause WHERE. Un utilisateur peut par exemple spécifier deux conditions : City correspond à « Seattle » et Forecast contient le mot « neige », puis joindre ces conditions à l'aide de l'opérateur AND. Cela équivaut à la clause WHERE suivante :

WHERE City = 'Seattle' AND Forecast LIKE '%snow%'

Lorsque Notification Services exécute la règle d'abonnement, il traite toutes les conditions ensemble, ce qui améliore les performances. Notification Services remplit ensuite la vue de la règle avec les paires d'entrées et d'abonnements qui correspondent.

Considérations relatives aux performances

Même si Notification Services traite toutes les conditions similaires ensemble, l'utilisation des actions de condition entraîne une surcharge. En effet, Notification Services doit obtenir un jeu de toutes les conditions, organiser les conditions pour une évaluation efficace, les évaluer, puis produire les notifications obtenues pour tous les abonnements. En raison de cette surcharge, il prend généralement plus de temps pour évaluer les règles qui utilisent des actions de condition que pour évaluer des actions prédéfinies.

Sécurité

Toutes les actions de condition s'exécutent dans le contexte d'un utilisateur de base de données que vous spécifiez pour l'action de condition. Le fait de passer par un utilisateur à faibles privilèges réduit la menace de sécurité pour le cas où quelqu'un compromettrait votre interface de gestion d'abonnement et insérerait des conditions tentant d'accéder à d'autres tables ou d'effectuer d'autres actions.

L'utilisateur de base de données doit disposer d'autorisations restreintes pour autoriser l'utilisateur à sélectionner uniquement les données provenant des sources d'événements et à exécuter uniquement les fonctions définies par l'utilisateur utilisées par les conditions.

Le compte de connexion SQL Server associé à cet utilisateur doit exister lorsque Notification Services crée des objets d'application dans la base de données d'application.

Transactions

Toutes les instructions dans une action de condition font partie d'une même transaction, si bien qu'elles sont toutes exécutées ou toutes annulées. Si la transaction échoue, Notification Services écrit une erreur dans le journal d'application Windows.

Définition d'une action de condition

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

Pour définir une action de condition

Connexion SQL Server

Étant donné que Notification Services exécute toutes les actions de condition dans le contexte d'un utilisateur de base de données spécifié, vous devez spécifier le compte de connexion associé à l'utilisateur. La connexion doit exister avant que Notification Services crée l'application. Si la connexion n'existe pas, Notification Services échoue en tentant de créer l'application et annule la création ou la mise à jour de l'instance.

Assurez-vous que la connexion dispose d'autorisations limitées sur le serveur. Il est préférable que la connexion ne dispose d'aucune autorisation à l'échelle du serveur et qu'elle n'appartienne à aucun rôle de serveur.

Pour définir la Connexion à SQL Server 

Utilisateur de base de données

L'utilisateur de base de données est le compte sous lequel toutes les actions de condition s'exécutent. Notification Services accorde à cet utilisateur de base de données certaines des autorisations nécessaires pour l'exécution des actions de condition. Si l'utilisateur de base de données n'existe pas lorsque Notification Services crée l'application, Notification Services le crée également.

Notification Services octroie les autorisations nécessaires sur les objets Notification Services, mais n'accorde pas d'autorisations sur les tables d'entrée ou les vues, ni sur aucune des fonctions définies par l'utilisateur qui sont utilisées par les actions de condition. Vous devrez accorder ces autorisations lors du déploiement de l'application. Les commandes Transact-SQL pour l'octroi de ces autorisations prennent la forme suivante :

-- grant permissions on the view for an input event class
GRANT SELECT ON ApplicationSchema.EventClassName TO SqlUserAccount
-- grant permissions on an input event chronicle table
GRANT SELECT ON ChronicleSchema.ChronicleName TO SqlUserAccount
-- grant execute permissions on a user-defined function 
-- used in Subscription.Conditions
GRANT EXEC ON UDFSchema.MyUserDefinedFunction TO SqlUserAccount
Pour définir l'utilisateur de base de données

Nom d'entrée

Lorsque vous utilisez une action de condition, vous devez spécifier la vue ou la table qui contient les données d'événements.

  • Si l'action de condition figure dans une règle d'événement, l'entrée est généralement l'affichage d'événement qui porte le même nom que la classe d'événement.
    Attention   Ne pas utiliser la table d'événements, intitulée NSEventClassNameEvents, en tant qu'entrée. Cette table contient tous les événements qui n'ont pas été supprimés du système et entraîneront des notifications dupliquées.
  • Si l'action de condition concerne une règle planifiée, l'entrée est généralement une chronique d'événements.
    Attention   Pour les règles planifiées, ne pas utiliser la vue d'événements, intitulée EventClassName, en tant qu'entrée. Cette vue contient uniquement le lot des événements en cours ; elle sera souvent vide ou incomplète pour les règles planifiées.
Pour définir le nom d'entrée

Schéma d'entrée

Le schéma d'entrée est le nom de schéma de base de données correspondant à l'entrée.

  • Si l'entrée est l'affichage d'événement, le schéma est le schéma d'application. Le schéma d'application peut être défini lors de la définition de la base de données d'application, ou il peut être la valeur par défaut de dbo. Pour plus d'informations, consultez Définition de la base de données d'application.
  • Si l'entrée est une chronique d'événements, le schéma est défini dans l'instruction CREATE TABLE qui crée la chronique d'événements. C'est généralement le même que le schéma d'application. Pour plus d'informations, consultez Définition de chroniques pour une classe d'événements.
Pour définir le schéma d'entrée

Expressions Transact-SQL

Chaque action de chronique spécifie la requête principale pour générer des notifications. La requête spécifie la requête qui sélectionne les champs d'entrée et d'abonnement et les ajoute à la table de notifications.

La requête doit sélectionner les champs d'entrée et d'abonnement dans un affichage qui relie les données d'abonnement et les données d'événements. Les champs d'abonnement de l'affichage portent des noms sous la forme [Subscription. SubscriptionFieldName]. Les champs d'entrée (d'événement) portent des noms sous la forme [Input.EventFieldName].

Les abonnés créent l'équivalent de la clause WHERE pour la requête via une interface de gestion d'abonnement. Notification Services évalue les actions de condition pour tous les abonnements pertinents et génère ensuite les notifications.

Modèle

Le modèle Transact-SQL suivant montre comment écrire une expression Transact-SQL pour une action de condition.

INSERT INTO schema.NotificationClassName(SubscriberId, 
    DeviceName, SubscriberLocale, NotificationFields) 
SELECT [Subscription.SubscriberId], DeviceName, SubscriberLocale, 
    [Input.EventFieldName], ...
FROM schema.RuleName

Dans l'instruction SELECT, vous pouvez sélectionner les valeurs DeviceName et SubscriberLocale dans une source de données, telle que la vue nommée d'après la règle ou fournir des valeurs littérales, telles que « File » ou « en-US ».

La requête peut contenir d'autres instructions et n'est pas obligée de générer des notifications. Elle peut effectuer tout le travail nécessaire, par exemple conserver une chronique. Toutefois, au moins une règle d'abonnement doit générer des notifications. Sinon, votre application ne générera ni ne distribuera les notifications aux abonnés.

Clause INSERT

Comme illustré dans le modèle, vous devez spécifier les champs suivants, dans l'ordre suivant, dans l'instruction INSERT :

  • SubscriberId
  • DeviceName
  • SubscriberLocale

Tous les champs non calculés sont définis dans le schéma de notification. Si vous utilisez des champs calculés, n'ajoutez pas de valeurs à ces champs. Les valeurs sont calculées lorsque vous insérez les données de notification.

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

Effectuez des ajouts à la table de notifications uniquement dans le cadre d'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, les processus de préparation et de nettoyage ne se produisent pas, ce qui risque de provoquer des erreurs.

Utilisation des procédures stockées

Au lieu d'incorporer les instructions Transact-SQL dans l'action de condition, vous pouvez 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 la définir dans un script de déploiement. Vous devez créer la procédure stockée avant d'activer l'instance ou l'application, mais après la création ou l'ajout de l'application par Notification Services.

Pour utiliser une procédure stockée, remplacez le texte de requête par un appel à la procédure stockée. L'exemple suivant montre comment appeler une procédure stockée :

EXECUTE dbo.WeatherConditionActionSP;
Pour définir l'expression Transact-SQL

Création d'interfaces de gestion d'abonnement

Quand vous créez des interfaces de gestion d'abonnement, vous devez prendre en compte les types d'abonnements que l'application prend en charge. Pour les abonnements basés sur les conditions, votre interface de gestion d'abonnement doit permettre à l'Abonné d'entrer des conditions, comme la sélection d'un champ dans une liste déroulante, la saisie d'un opérateur et la fourniture d'une valeur.

Pour obtenir un exemple de code qui montre comment ajouter un abonnement basé sur les conditions, consultez Ajout d'un abonnement.

Voir aussi

Référence

Microsoft.SqlServer.NotificationServices.Rules

Concepts

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

Autres ressources

INSERT (Transact-SQL)
SELECT (Transact-SQL)
Définition de classes d'abonnement
Développement d'interfaces de gestion d'abonnement

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications

Version Historique

17 juillet 2006
Contenu modifié :
  • Ajout d'une section sur les interfaces de gestion d'abonnement.