Partager via

Installer les services de rapport et les services d'information Internet en parallèle (mode natif SSRS)

Vous pouvez installer et exécuter SQL Server 2014 Reporting Services (SSRS) et Internet Information Services (IIS) sur le même ordinateur. La version d’IIS que vous utilisez détermine les problèmes d’interopérabilité que vous devez résoudre.
S’applique à : Mode natif Reporting Services
Version des services IIS (Internet Information Services) Problèmes Descriptif
IIS 6.0, 7.0, 8.0, 8.5 Les requêtes prévues pour une application sont acceptées par une autre application.

HTTP.SYS applique des règles de priorité pour les réservations d'URL. Les requêtes envoyées aux applications qui ont le même nom de répertoire virtuel et qui surveillent conjointement le port 80 risquent de ne pas atteindre la cible prévue si la réservation d'URL est faible par rapport à la réservation d'URL d'une autre application.		 Dans certaines conditions, un point de terminaison inscrit qui remplace un autre point de terminaison d'URL dans le schéma de réservation d'URL peut recevoir des requêtes HTTP destinées à l'autre application.

L’utilisation de noms de répertoires virtuels uniques pour le service web Report Server et le Gestionnaire de rapports vous permet d’éviter ce conflit.

Des informations détaillées sur ce scénario sont fournies dans cette rubrique.

Règles de priorité pour les réservations d'URL

Pour pouvoir traiter les problèmes d’interopérabilité entre les services IIS et Reporting Services, vous devez comprendre le fonctionnement des règles de priorité pour la réservation d’URL. Les règles de priorité peuvent être généralisées à l'aide de la formule suivante : la réservation d'URL dont la définition des valeurs est la plus explicite est la première à recevoir les requêtes qui correspondent à l'URL.

  • Une réservation d'URL qui spécifie un répertoire virtuel est plus explicite qu'une réservation d'URL qui omet un répertoire virtuel.

  • Une réservation d'URL qui spécifie une adresse unique (via une adresse IP, un nom de domaine complet, un nom d'ordinateur réseau ou un nom d'hôte) est plus explicite qu'un caractère générique.

  • Une réservation d'URL qui spécifie un caractère générique fort est plus explicite qu'un caractère générique faible.

Les exemples suivants illustrent une plage de réservations d'URL, de la plus explicite à la moins explicite :

Exemple : Requête
http://123.234.345.456:80/reports Reçoit toutes les demandes envoyées à http://123.234.345.456/reports ou http://<computername>/rapports si un service de noms de domaine peut résoudre l'adresse IP en ce nom d'hôte.
http://+:80/reports Reçoit toutes les requêtes envoyées à une adresse IP ou un nom d'hôte valide pour cet ordinateur, tant que l'URL contient le nom de répertoire virtuel « reports ».
http://123.234.345.456:80 Reçoit toute requête qui spécifie http://123.234.345.456 ou http://< computername> si un service de nom de domaine peut résoudre l’adresse IP en ce nom d’hôte.
http://+:80 Reçoit les demandes qui ne sont pas déjà reçues par d’autres applications, pour tous les points de terminaison d’application mappés à tous les affectés.
http://*:80 Reçoit les demandes qui ne sont pas déjà reçues par d'autres applications, pour les points de terminaison d'application associés à Tous les non attribués.

Une indication d’un conflit de port est que vous verrez le message d’erreur suivant : « System.IO.FileLoadException : le processus ne peut pas accéder au fichier, car il est utilisé par un autre processus. (Exception de HRESULT : 0x80070020). »

Réservations d’URL pour IIS 6.0, 7.0, 8.0, 8.5 avec SQL Server 2014 Reporting Services

Grâce aux règles de priorité décrites dans la section précédente, vous pouvez comprendre comment les réservations d'URL définies pour Reporting Services et les services IIS (Internet Information Services) favorisent l'interopérabilité. Reporting Services reçoit des requêtes qui spécifient explicitement les noms de répertoires virtuels de ses applications ; les services IIS (Internet Information Services) reçoivent toutes les requêtes restantes, lesquelles peuvent être adressées ensuite aux applications qui s'exécutent dans le cadre du modèle de processus IIS.

Application Réservation d'URL Descriptif Réception de requête
Serveur de rapports http://+:80/ReportServer Caractère générique fort sur le port 80, avec le répertoire virtuel du serveur de rapports. Reçoit toutes les requêtes sur le port 80 qui spécifient le répertoire virtuel du serveur de rapports. Le service web Report Server reçoit toutes les demandes adressées à http://< computername>/reportserver.
Gestionnaire de rapports http://+:80/Reports Caractère générique fort sur le port 80, avec le répertoire virtuel Reports. Reçoit toutes les requêtes sur le port 80 qui spécifient le répertoire virtuel reports. Le Gestionnaire de rapports reçoit toutes les demandes adressées à http://< computername>/reports.
IIS http://*:80/ Caractère générique faible sur le port 80. Reçoit les demandes restantes sur le port 80 qui ne sont pas reçues par une autre application.

Déploiements côte à côte de SQL Server 2014 et SQL Server 2005 Reporting Services sur IIS 6.0, 7.0, 8.0, 8.5

Les problèmes d’interopérabilité entre IIS et Reporting Services se produisent lorsque les sites Web IIS ont des noms de répertoires virtuels identiques à ceux utilisés par Reporting Services. Prenons l'exemple de la configuration suivante :

  • Site Web IIS assigné au port 80 et répertoire virtuel nommé « Reports ».

  • Une instance de serveur de rapports SQL Server 2014 installée dans la configuration par défaut, où la réservation d’URL spécifie également le port 80 et l’application du Gestionnaire de rapports utilise également « Rapports » pour le nom du répertoire virtuel.

Étant donné cette configuration, une demande envoyée à http://< computername> :80/reports sera reçue par le Gestionnaire de rapports. L’application accessible via le répertoire virtuel Rapports dans IIS ne recevra plus de demandes après l’installation de l’instance du serveur de rapports SQL Server 2014.

Si vous exécutez des déploiements côte à côte de versions antérieures et plus récentes de Reporting Services, vous êtes susceptible de rencontrer le problème de routage décrit simplement. Cela est dû au fait que toutes les versions de Reporting Services utilisent « ReportServer » et « Rapports » comme noms de répertoires virtuels pour les applications du serveur de rapports et du Gestionnaire de rapports, ce qui augmente la probabilité que vous ayez des répertoires virtuels « rapports » et « reportserver » dans IIS.

Pour vous assurer que toutes les applications reçoivent des requêtes, suivez ces instructions :

  • Pour les installations de Reporting Services, utilisez des noms de répertoires virtuels qui ne sont pas déjà utilisés par un site web IIS sur le même port que Reporting Services. En cas de conflit, installez Reporting Services en mode « fichiers uniquement » (à l’aide de l’option Installer, mais ne configurez pas l’option serveur dans l’Assistant Installation) afin de pouvoir configurer les répertoires virtuels une fois le programme d’installation terminé. Une indication indiquant que votre configuration a un conflit est que vous verrez le message d’erreur : System.IO.FileLoadException : le processus ne peut pas accéder au fichier, car il est utilisé par un autre processus. (Exception de HRESULT : 0x80070020). »

  • Pour les installations que vous configurez manuellement, adoptez les conventions d'affectation des noms par défaut dans les URL de configuration. Si vous installez SQL Server 2014 Reporting Services (SSRS) en tant qu’instance nommée, incluez le nom de l’instance lors de la création d’un répertoire virtuel.

Voir aussi

Configurer les URL du serveur de rapports (Gestionnaire de configuration SSRS)
configurer une URL (Gestionnaire de configuration SSRS)
Installer le serveur de rapports Reporting Services en mode natif

  • Last updated on