APSQL

Le fichier ADF

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.

Structure fichier ADF

Le fichier ADF va contenir les informations suivantes:

  • La base de données d'application

    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>

  • Les propriétés des classes d'évènements

    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>
    					

  • Les propriétés de classes d'abonnement

    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:

    • est parfaitement identifiée par son nom,
    • renseigne éventuellement le groupe de fichiers sur lequel seront créées les tables de gestion des abonnements,
    • liste les champs qui peuvent être utilisés par les abonnées pour personnaliser leurs abonnements,
    • défini les règles de génération des notifications,
    • défini éventuellement des index,
    • défini des chroniques éventuelles 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>
      					

  • Les propriétés de classes de notification

    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:

    • un nom unique
    • le schéma de notification, qui permet de définir la forme des données brutes
    • le module de formatage, pour mettre en forme les informations
    • le type de livraison : digest ou multidiffusion
    • la taille du lot
    • les protocoles de remises
    • une période de conservation de la notification
    
    <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>					
    					

  • Les propriétés du fournisseur d'évènements

    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.

  • Les propriétés du générateur

    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.

  • Les propriétés du serveur de distribution

    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.

  • Les paramètres fonctionnels

    Ces paramètres permettent de configurer la fréquence à laquelle les informations seront traitées.

  • Version et historique

    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