Pour simplifier, il est possible de dire que le fichier IDF est composé de 2 sections majeures qui sont, d’une part, la définition des applications (avec une référence au fichier ADF), et d’autre part, la définition des canaux de remise qui vont pouvoir être utilisés par les abonnés. Voir Figure
Le fichier IDF
3. Le fichier IDF contient les informations suivantes :
• Le nom de l’instance Chaque instance du service de notification est parfaitement identifiée par son nom. Sur le même serveur, il ne peut pas y avoir 2 instances du service de notification qui utilise le même nom. <InstanceName>InstanceDemoService</InstanceName>
• Le nom de l’instance SQL Server qui héberge la base de données Par ce paramètre, le service de notification dispose du nom du serveur qui héberge la base de données d’application. Le nom de l’instance est toujours de la forme: nomOrdinateur[,numeroPort][\nomInstance]. Le nom d’instance n’est nécessaire que s’il ne s’agit pas de l’instance par défaut. Le numéro du port est quant à lui nécessaire uniquement si le serveur écoute un port différent du port 1433.
<SqlServerSystem>%SqlServer%</SqlServerSystem>
Ici, le nom du serveur sera passé au fichier IDF sous forme de paramètre lors de la mise en place du service.
• La liste des applications hébergées Une instance du service de notification peut héberger une ou plusieurs applications. Il est alors possible d’administrer chaque application de façon individuelle ou bien de grouper les applications pour faciliter les opérations d’administration lorsqu’elles portent sur plusieurs applications. Pour chaque application, il est nécessaire de préciser son nom, le fichier ADF qui permet de définir complètement l’application ainsi que les valeurs des différents paramètres.
<Applications>
<Application>
<ApplicationName>Stock</ApplicationName>
<BaseDirectoryPath>%SampleDirectory%\AppDefinition</BaseDirectoryPath>
<ApplicationDefinitionFilePath>adf.xml</ApplicationDefinitionFilePath>
<Parameters>
<!– Ces parametres sont definis comme des variables d environ nement. Elles sont passees au fichier ADF. –>
<Parameter>
<Name>_DBSystem_</Name>
<Value>%SqlServer%</Value>
</Parameter>
<Parameter>
<Name>_NSSystem_</Name>
<Value>%NotificationServicesHost%</Value>
</Parameter>
<Parameter>
<Name>_BaseDirectoryPath_</Name>
<Value>%SampleDirectory%</Value>
</Parameter>
</Parameters>
</Application>
</Applications>
Téléchargez cette ressource
Sécuriser Microsoft 365 avec une approche Zero-Trust
Découvrez comment renforcer la cyber-résilience de Microsoft 365 grâce à une approche Zero-Trust, une administration granulaire et une automatisation avancée. La technologie Virtual Tenant de CoreView permet de sécuriser et simplifier la gestion des environnements complexes, tout en complétant vos stratégies IAM, y compris dans les secteurs réglementés.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- Construire la souveraineté numérique en Europe grâce à un écosystème ouvert et collaboratif
- Le Zero Trust : pourquoi votre entreprise en a besoin
- Cloud souverain : répondre aux enjeux d’hybridation et de maîtrise des dépendances
Articles les + lus
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Adapter la sécurité OT aux réalités de l’industrie
Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
À la une de la chaîne Tech
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
- Adapter la sécurité OT aux réalités de l’industrie
- Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
- Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
