Le fichier ADF (application definition file) permet de définir complètement l'application de notification. Pour schématiser, il est possible de dire que le fichier est composé de 4 sections principales (voir schéma ci dessous). La structure de chacune des sections est décrites ci dessous.

Le fichier ADF va contenir les informations suivantes:
Cette base de données est associée au service de notification. C'est elle qui va conserver toutes les informations nécessaires à la bonne exécution du service de notification.
C'est à dire qu'elle va conserver les informations relatives aux différents évènements, aux abonnées et aux abonnements. Cette base peut être créée lors de la mise en place du service, ou bien le service peut
travailler avec une base existante.
Pour utiliser la base Club existante comme base de données d'application la
définition suivante est nécessaire:
<DatabaseName>Club</DatabaseName>
C'est dans la section évènement quel les classes
d'évènements sont définies. Pour avoir la possibilité de stocker dans la base de données d'application des informations relatives aux évènements, il est nécessaire de définir ces classes d'évènements.
Une classe d'évènement est définie par un nom, des champs, le groupe de fichiers, des index et des tables d'évènements ainsi que les règles qui permettent de mettre à jour ces tables.
Il est possible de définir plusieurs classes d'évènements si cela est nécessaire.
Le service de notification ajoute systématiquement les colonnes EventID et EventBatchID aux tables d'évènements.
L'exemple suivant illustre la définition d'une classe d'évènement:
<EventClasses>
<EventClass>
<EventClassName>AdhesionEvt</EventClassName>
<Schema>
<Field>
<FieldName>numero</FieldName>
<FieldType>int</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>DateFin</FieldName>
<FieldType>datetime</FieldType>
<FieldTypeMods>null</FieldTypeMods>
</Field>
</Schema>
<FileGroup>Primary</FileGroup>
<IndexSqlSchema>
<SqlStatement>CREATE INDEX AdhesionEvtIndex ON AdhesionEvt ( numero );</SqlStatement>
</IndexSqlSchema>
</EventClass>
</EventClasses>
Chaque abonné définie sont propre abonnement au service de notification en fonction de critères qui lui sont propres.
L'application doit être capacble de conserver toutes ces informations dans la base d'application.
Les classes d'abonnements permettent de précise comment est organisé le stockage des ces informations.
Chaque classe d'abonnement:
<SubscriptionClasses>
<SubscriptionClass>
<SubscriptionClassName>AdhesionSubscription</SubscriptionClassName>
<Schema>
<Field>
<FieldName>DeviceName</FieldName>
<FieldType>nvarchar(255)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>SubscriberLocale</FieldName>
<FieldType>nvarchar(10)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>numero</FieldName>
<FieldType>int</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
</Schema>
<EventRules>
<EventRule>
<RuleName>AdhesionRegle</RuleName>
<EventClassName>AdhesionEvt</EventClassName>
<Action>INSERT INTO AdhesionAlertes(SubscriberId, DeviceName,SubscriberLocale, numero, DateFin)
SELECT sub.SubscriberId, sub.DeviceName, sub.SubscriberLocale, evt.numero, evt.Datefin
FROM AdhesionEvt evt, AdhesionSubscription sub
WHERE evt.numero = sub.numero;</Action>
</EventRule>
</EventRules>
</SubscriptionClass>
</SubscriptionClasses>
La classe de notification est nécessaire pour décrire les notifications que l'application peut émettre. Comme toutes les classes, une classe de notification possède sa propre structure qui est:
<NotificationClasses>
<NotificationClass>
<NotificationClassName>AdhesionAlertes</NotificationClassName>
<Schema>
<Fields>
<Field>
<FieldName>numero</FieldName>
<FieldType>int</FieldType>
</Field>
<Field>
<FieldName>DateFin</FieldName>
<FieldType>datetime</FieldType>
</Field>
</Fields>
</Schema>
<ContentFormatter>
<ClassName>XsltFormatter</ClassName>
<Arguments>
<Argument>
<Name>XsltBaseDirectoryPath</Name>
<Value>%_BaseDirectoryPath_%</Value>
</Argument>
<Argument>
<Name>XsltFileName</Name>
<Value>AdhesionTransformations.xslt</Value>
<Argument>
</Arguments>
</ContentFormatter>
<Protocols>
<Protocol>
<ProtocolName>File</ProtocolName>
<Fields>
<Field>
<FieldName>numero</FieldName>
<FieldReference>numero</FieldReference>
</Field>
<Field>
<FieldName>datefin</FieldName>
<FieldReference>DateFin</FieldReference>
</Field>
</Fields>
</Protocol>
</Protocols>
</NotificationClass>
</NotificationClasses>
Le fournisseur d'évènement prend en charge la collecte des données pour les fournir au service de notification. Par défaut, SQL Server 2005 propose 3 fournisseurs d'évènements qui sont les requêtes Transact SQL, les requêtes MDX et les fichiers. Toutefois, il est possible de développer son propre fournisseur d'évènements.
Chaque application dispose de son propre générateur. La configuration du générateur doit être un compromis entre les résultats attendus et l'utilisation des ressources du serveur.
Une application peut disposer de plusieurs distributeurs. Chaque distributeur effectue le même travail, mais la répartition de la charge entre plusieurs distributeurs est souhaitable si le volume des informations est important et/ou les traitements sont complexes.
Ces paramètres permettent de configurer la fréquence à laquelle les informations seront traitées.
Il est possible de définir un numéro de version et de gérer un historique de l'application.
En savoir plus
La documentation
Le didacticiel