Définition du schéma d'abonnement

Article
12/15/2008

Notification Services génère des notifications en utilisant les requêtes Transact-SQL qui joignent des données d'événements et d'abonnement. Pour la plupart des applications, vous devez spécifier les champs d'abonnement qui sont utilisés lors de la génération des notifications. Vous spécifiez ces champs dans le schéma de la classe d'abonnement.

Cette rubrique décrit les champs par défaut qui sont ajoutés par Notification Services, les champs standard que vous pouvez ajouter au schéma et le mode de création de champs personnalisés.

Champs d'abonnement par défaut

Tous les abonnements ont besoin d'informations communes. Notification Services doit être en mesure d'identifier de manière unique chaque abonnement, d'identifier l'abonné pour chaque abonnement et de déterminer si l'abonnement est activé. Si la classe d'abonnement prend en charge les abonnements planifiés, l'abonnement doit être associé à une planification d'abonnement.

Pour simplifier le développement d'applications, Notification Services ajoute automatiquement les champs de classe d'abonnement suivants pour ces informations communes :

Remarque :
Ne définissez pas les champs ci-dessous dans le schéma de classe d'abonnements. Sinon, la création de l'application échoue à cause des définitions de champ dupliquées.

Notification Services contient les champs SubscriptionId, SubscriberId et Enabled. Lorsque Notification Services crée l'application, il ajoute les colonnes suivantes à la définition de la table d'abonnements :
- SubscriptionId est une colonne d'identité bigint. Notification Services fournit une valeur à cette colonne pour chaque nouvel abonnement.
- SubscriberId est une colonne nvarchar(255). Votre interface de gestion d'abonnement doit fournir la valeur d'identifiant d'abonné lorsque vous ajoutez un abonnement.
- Enabled est un champ Boolean que vous pouvez définir par programme pour chaque abonnement. La définition de la valeur Enabled sur false suspend la génération de notifications pour l'abonnement. La valeur par défaut est true.
Si la classe d'abonnement contient des règles planifiées, Notification Services inclut un champ ScheduleId. Dans la table d'abonnements, il devient une clé étrangère à une table de planification d'abonnement. La valeur de planification est définie dans une interface de gestion d'abonnement lorsque l'utilisateur crée un abonnement planifié. ScheduleId est une colonne int qui autorise les valeurs NULL, au cas où la classe d'abonnement prend en charge les abonnements pilotés par les événements et planifiés.

Champs standard : DeviceName et SubscriberLocale

En fonction de votre application, vous pouvez souhaiter définir deux champs dans un schéma de classe d'abonnements : DeviceName et SubscriberLocale. Ces champs sont souvent définis dans chaque classe d'abonnement pour permettre à l'abonné de sélectionner un périphérique et des paramètres régionaux, mais ils ne sont pas requis. Si les champs sont définis, le serveur de distribution peut utiliser les informations pour la mise en forme et la remise des notifications.

Champ DeviceName

Un périphérique d'abonné est le lieu de remise d'une notification. Un périphérique peut être une messagerie, Windows Messenger, un téléphone cellulaire ou tout autre périphérique que votre application prend en charge.

Lorsque vous générez des notifications, les données de notification doivent comprendre le nom de périphérique pour la remise des notifications. Si vous autorisez les abonnés à spécifier un périphérique lorsqu'ils créent un abonnement, incluez le champ DeviceName dans le schéma de classe d'abonnements.

Utilisez les propriétés suivantes pour le champ DeviceName :

Nom du champ : DeviceName
Type de champ : nvarchar(255)
Modificateur de champ : NOT NULL

Les informations sur le périphérique, telles que l'adresse de l'abonné, figurent dans les données d'abonné de la base de données d'instance. Utilisez la vue NSSubscriberDeviceView pour vérifier les informations d'abonné et de périphérique d'abonné pour une instance de Notification Services. Pour plus d'informations, consultez NSSubscriberDeviceView.

Si vous excluez le champ DeviceName du schéma, vous devez également effectuer l'une des opérations suivantes :

Si votre application prend en charge un seul périphérique, fournissez un nom de périphérique statique dans la règle Transact-SQL utilisée pour générer des notifications.
Si votre application prend en charge plusieurs périphériques, sélectionnez un périphérique de manière dynamique. Par exemple, un abonné peut disposer de plusieurs périphériques et votre application peut sélectionner le périphérique en fonction de l'heure de la journée. Pendant les heures ouvrables, vous pouvez envoyer toutes les notifications au compte de messagerie professionnel d'un abonné. En dehors des heures de bureau, vous pouvez envoyer des notifications critiques au téléphone de l'abonné et toutes les autres notifications au compte de messagerie privé de l'abonné.

Champ SubscriberLocale

Les paramètres régionaux représentent un langage et un pays pour la notification. Notification Services prend en charge de nombreux paramètres régionaux. Pour une liste des paramètres régionaux, consultez Subscriber Locale Codes.

Lorsque vous générez des notifications, les données de notification doivent inclure les paramètres régionaux. Si vous autorisez les abonnés à spécifier des paramètres régionaux, incluez le champ SubscriberLocale dans le schéma de classe d'abonnement.

Utilisez les propriétés suivantes pour le champ SubscriberLocale :

Nom du champ : SubscriberLocale
Type de champ : nvarchar(10)
Modificateur de champ : NOT NULL

Si vous excluez le champ SubscriberLocale, vous devez effectuer l'une des opérations suivantes :

Si votre application prend en charge un seul ensemble de paramètres régionaux, fournissez des paramètres régionaux statiques dans la règle Transact-SQL utilisée pour générer les notifications.
Si votre application prend en charge plusieurs paramètres régionaux, sélectionnez les paramètres régionaux d'abonné à partir d'une autre source, par exemple une table de profil utilisateur dans une autre base de données.

Champs d'abonnement personnalisés

La plupart des applications dispose également de champs d'abonnement personnalisés. Ces champs définissent les valeurs que les abonnés peuvent personnaliser dans leurs abonnements et sont utilisés pour créer des colonnes dans la table d'abonnement.

La création de champs personnalisés impose de connaître les informations que les abonnés peuvent fournir pour personnaliser leurs abonnements. Par exemple, une application météorologique peut permettre aux utilisateurs de sélectionner une seule ville, donc vous définiriez seulement un champ personnalisé « ville ». Une application de vol peut permettre de sélectionner l'origine, la destination, le prix et l'opérateur d'un vol, donc voue créeriez des champs tel que LeavingFrom, GoingTo, Price et Carrier.

Lorsque vous définissez un champ personnalisé, vous devez également définir le type de données SQL Server du champ et tous les modificateurs de champ, par exemple si le champ autorise ou non les valeurs NULL. Comme ces champs définissent des colonnes de table, vous devez suivre les instructions de définition des colonnes de table. Pour plus d'informations, consultez CREATE TABLE (Transact-SQL).

Remarque :
Pour une liste des types pris en charge, consultez FieldType Element for SubscriptionClass/Schema/Field (ADF).