Collaboration : Intégration de SQL Server 2008 R2 Reporting Services dans SharePoint 2010
Alan Le Marquand
SQL Server et SharePoint ont toujours très bien collaboré. La commercialisation de SharePoint Server 2010 et SQL Server 2008 R2 a donné lieu à des améliorations significatives de l'intégration entre SharePoint et SQL Server 2008 R2 Reporting Services (SSRS). Cet article explique comment configurer et utiliser les toutes dernières améliorations.
Architecture de l'intégration de serveur
Le complément Reporting Services pour SharePoint est l'élément clé de l'intégration entre les deux serveurs. Ce complément, qui peut être téléchargé gratuitement à partir du Centre de téléchargement Microsoft, doit être installé sur tous les serveurs Web frontaux SharePoint 2010 qui nécessitent une intégration à un serveur de rapports. La Figure 1 illustre l'architecture des composants d'intégration.
Sur le serveur Web frontal SharePoint 2010, le complément installe trois composants : le proxy SSRS, un composant WebPart de visionneuse de rapports et les pages d'application qui vous permettent d'afficher, de stocker et de gérer le contenu du serveur de rapports sur un site ou une batterie SharePoint. Le proxy SSRS facilite la communication entre le serveur Web frontal et le serveur de rapports. Dans les pages Reporting Services de l'Administration centrale de SharePoint, vous configurez le proxy avec le serveur de rapports auquel vous souhaitez accéder, ainsi que la méthode d'authentification et les informations d'identification nécessaires pour accéder au serveur. Pour que l'intégration fonctionne, vous devez configurer le serveur de rapports pour qu'il s'exécute en mode intégré SharePoint.
.jpg)
Figure 1 Architecture d'intégration de serveur
L'un des éléments à noter sur la Figure 1 est le composant de modèle objet SharePoint sur le serveur de rapports. Pour que le serveur de rapports comprenne les informations de rapports stockées dans SharePoint et puisse les sécuriser, il doit interagir avec les bases de données de configuration et de contenu sur votre site ou batterie SharePoint. Pour cela, vous pouvez installer une copie minimale de SharePoint sur le serveur de rapports et la joindre à la batterie.
La version de SharePoint que vous installez sur le serveur de rapports doit être identique à celle utilisée dans toute la batterie. Cette action est nécessaire uniquement si vous exécutez votre serveur de rapports sur un ordinateur distinct. Si vous exécutez SharePoint et Reporting Services sur le même ordinateur, seul le complément doit être installé.
Configuration de l'intégration
Globalement, la configuration de l'intégration a été simplifiée avec SharePoint 2010 et SQL Server 2008 R2. L'ordre dans lequel vous procédez à la configuration dépend de ce que vous avez déjà installé. Que vous partiez de zéro ou d'une installation existante, le principal est d'installer tous les composants principaux avant de configurer le proxy SSRS dans SharePoint. Pour de meilleurs résultats lors de l'intégration de SQL Server Reporting Service 2008 R2 avec SharePoint 2010, l'ordre recommandé si vous partez de zéro est le suivant :
- Exécutez l'installateur des composants requis de SharePoint 2010 ; cette opération installe le complément SSRS 2008 R2 pour SharePoint.
- Installez et configurez SharePoint 2010 dans une configuration de batterie.
- Répétez les étapes 1 et 2 sur l'ordinateur Report Server s'il est différent du serveur Web frontal SharePoint, puis configurez-le de façon à joindre la batterie SharePoint créée à l'étape 2.
- Installez SQL Server Reporting Services en mode intégré SharePoint.
- Configurez le proxy SSRS via la page Intégration de Reporting Services et activez la fonctionnalité Reporting Services.
Si les types de contenu Reporting Services ne s'affichent pas dans votre site sous le menu Document| Nouveau, vous devez les ajouter manuellement. J'explique comment ajouter les types de contenu Report Server plus loin dans cet article dans la section intitulée Intégration avec Report Builder 3.0.
Dans ce scénario, j'utiliserais SQL Server pour la base de données SharePoint, plutôt que l'édition incorporée utilisée par défaut par SharePoint. Si vous prévoyez d'installer tous les composants sur un même ordinateur, l'étape 5 est redondante. Les étapes 1 et 2 peuvent être combinées dans le processus d'installation de SQL Server.
Si vous avez une installation de SharePoint existante, vous pouvez télécharger et installer le complément à tout moment. Le processus d'installation du complément ajoute les pages nécessaires à l'Administration centrale de SharePoint, ainsi que les nouveaux types de contenu Report Server pour les bibliothèques SharePoint existantes dans les sites à l'aide du modèle de site Business Intelligence Center.
Du côté SharePoint, vous pouvez configurer l'intégration sur SharePoint Server 2010 ou sur SharePoint Foundation 2010. Tous deux prennent en charge l'installation du complément Reporting Services. Si vous installez SharePoint et Reporting Services sur différents ordinateurs, vous devez installer la même version de SharePoint sur le serveur de rapports. Par exemple, vous ne pourriez pas installer SharePoint Foundation 2010 sur le serveur de rapports si vous utilisiez SharePoint Server 2010 comme serveur Web frontal.
L'installation du complément est très simple ; outre la saisie de votre nom et de votre société, aucune autre configuration n'est requise. Si vous installez SharePoint pour la première fois, vous installez le complément avant d'installer SharePoint ; cette opération s'effectue automatiquement lorsque vous exécutez le composant requis SharePoint 2010.
La configuration du serveur de rapports est simple. Les principaux éléments à prendre en compte sont les suivants :
- l'édition de SQL Server doit être Standard, Enterprise ou plus ;
- la base de données du serveur de rapports doit être créée pour le mode intégré SharePoint ;
- si vous utilisez des ordinateurs distincts pour SharePoint et Report Server, une installation minimale de SharePoint est nécessaire et doit être jointe à la batterie sur le serveur de rapports.
Un serveur de rapports est implémenté en tant que service Windows unique qui s'exécute sous un compte intégré ou un compte d'utilisateur Windows local ou de domaine. En mode intégré SharePoint, le compte de service Report Server est mis en service afin d'accéder aux bases de données de configuration et de contenu SharePoint et aux ressources de modèle objet SharePoint. Cela se produit lors de la configuration de l'intégration de Reporting Services avec SharePoint via la page Intégration de Reporting Services.
Lorsque le mode d'authentification est « Intégré Windows », l'identité de l'utilisateur Windows connecté à SharePoint sera empruntée lors de la connexion du serveur Web frontal au serveur de rapports. Lorsque le mode d'authentification est un compte approuvé, le contexte utilisateur SharePoint de l'utilisateur connecté à SharePoint est passé au serveur de rapports sous la forme du jeton utilisateur SharePoint. Le compte du pool d'applications du serveur Web frontal SharePoint est utilisé pour établir la connexion du serveur Web frontal au serveur de rapports. Vous trouverez un résumé de la configuration du compte de service dans l'article TechNet intitulé « Configuration de Reporting Services pour l'intégration de SharePoint 2010 »
Si vous avez déjà installé Reporting Services avec les paramètres par défaut, la base de données Reporting Services sera en mode Natif. Pour opérer en mode intégré SharePoint, vous devrez revenir à l'outil de configuration de Reporting Services et, depuis la page Paramètres de la base de données, modifier le mode de Natif en Intégré SharePoint.
Vous pouvez modifier le mode de serveur de rapports de Natif en Intégré SharePoint à tout moment ; néanmoins, cela ne convertit pas la base de données existante. Chaque fois que vous changez de mode, vous devez créer une base de données ou vous connecter à une base de données existante.
Avant de configurer les options de proxy Reporting Services dans SharePoint, une autre configuration est nécessaire. Vous devez vous assurer que l'accès anonyme n'a pas été activé sur l'application Web. Bien que cela ne vous empêche pas de configurer les paramètres de proxy Reporting Services, vos utilisateurs recevront une erreur lorsqu'ils exécuteront des rapports. Vous pouvez choisir d'utiliser Windows ou toute authentification basée sur les revendications proposée par les autres fournisseurs d'authentification, et si vous configurez l'intégration entre un serveur de rapports et une batterie SharePoint, chaque application Web SharePoint de la batterie peut être configurée de façon à utiliser différents fournisseurs d'authentification.
Le complément crée une nouvelle section Reporting Services dans la page Paramètres généraux de l'application de l'Administration centrale de SharePoint. Dans la page Intégration de Reporting Services, vous entrez l'URL du serveur de rapports, les détails d'authentification et l'activation de la fonctionnalité Reporting Services sur toutes ou certaines des collections de sites de la batterie.
.jpg)
Figure 2 Configuration du proxy Reporting Services
Une fois que vous avez achevé les opérations de la page illustrée à la Figure 2, le processus de configuration de l'intégration est terminé.
Intégration avec Report Builder 3.0
Le principal avantage de l'intégration entre SharePoint et Reporting Services est qu'elle permet aux utilisateurs de créer, modifier et publier des rapports depuis SharePoint. Reporting Services fournit certains types de contenu prédéfinis qui servent à gérer divers fichiers, notamment les fichiers de sources de données de rapports partagées (.rsds), le modèle Report Builder (.smdl) et les fichiers de définitions de rapports Report Builder (.rdl). Après avoir configuré l'intégration de façon à permettre aux utilisateurs de créer et de gérer ces nouveaux types de contenu à partir du Ruban et des menus contextuels, vous devez activer les nouveaux types de contenu sur ces bibliothèques.
Si vous utilisez le modèle de site Business Intelligence Center, vous n'avez rien à faire ; les types de contenu sont activés automatiquement avec le modèle et pour tous les sites créés à l'aide de ce modèle. Pour tous les autres sites et bibliothèques de documents, vous devez effectuer un processus de configuration en deux étapes. Tout d'abord, vous devez activer la gestion des types de contenu dans les bibliothèques ; par défaut, elle est désactivée. Ensuite, vous devez activer les types de contenu pour la bibliothèque. Pour activer la gestion des types de contenu pour une bibliothèque de documents, appliquez la procédure décrite dans l'article TechNet intitulé « Procédure : ajouter des types de contenu de serveur de rapports à une bibliothèque (Reporting Services en mode intégré SharePoint).”
Une fois ces nouveaux types de contenu ajoutés à une bibliothèque, trois nouvelles options apparaîtront dans le menu déroulant Nouveau document sous l'onglet Documents. Si vous sélectionnez maintenant l'option Rapport du Générateur de rapports, Report Builder 3.0 sera téléchargé sur le client et exécuté. Vous pouvez modifier ce comportement à partir de l'Administration centrale de SharePoint. Les Paramètres par défaut serveur de Reporting Services vous permettent de désactiver cette option et de configurer une autre URL pour Report Builder.
Utilisation du composant WebPart Visionneuse de rapports sur un site SharePoint
Le composant WebPart Visionneuse de rapports est un composant WebPart personnalisé installé par le complément Reporting Services. Vous pouvez l'utiliser pour visualiser, explorer, imprimer et exporter des rapports sur un serveur de rapports. Pour ajouter ce composant WebPart à une page, vous pouvez suivre les étapes décrites dans l'article TechNet intitulé « Procédure : ajouter le composant WebPart Visionneuse de rapports à une page Web (Reporting Services en mode intégré SharePoint) ».
Chaque composant WebPart Visionneuse de rapports restitue un rapport à la fois sur la base de l'URL absolue du fichier de rapport (.rdl) spécifiée dans la propriété Rapport. L'URL doit être le chemin d'accès complet à un rapport sur le site SharePoint actuel ou sur un site dans la même batterie ou application Web. L'URL doit être résolue en une bibliothèque de documents ou un dossier dans une bibliothèque de documents qui contient le rapport. L'URL de rapport doit comporter l'extension de fichier .rdl. Si le rapport dépend d'un modèle ou de fichiers de sources de données partagées, il est inutile de spécifier ces fichiers dans l'URL. Le rapport contient des références aux fichiers dont il a besoin.
Authentification basée sur les revendications et Reporting Services
L'une des nouvelles fonctionnalités introduites dans SharePoint Server 2010 est la prise en charge de l'authentification basée sur les revendications. Dans les applications compatibles avec les revendications, les clients présentent des « revendications » à l'application. Ces revendications sont des informations relatives à l'utilisateur, telles que le nom d'utilisateur, l'adresse de messagerie ou le nom du responsable hiérarchique. L'application dispose ainsi de davantage d'informations qu'elle n'en recevrait à l'aide du protocole Kerberos. Prenons par exemple une application d'achat : deux des revendications passées à l'application pourraient être l'adresse de messagerie du responsable de l'utilisateur et la limite d'achat de cet utilisateur. Dans une application non compatible avec les revendications, ces informations devraient être gérées par l'application.
Dans le monde de SharePoint, l'authentification basée sur les revendications résout le problème lié au partage des sites SharePoint parmi des organisations. Grâce à un produit comme les services ADFS (Active Directory Federation Services), deux organisations avec des méthodes d'authentification différentes peuvent configurer des revendications qui permettent à SharePoint d'identifier un utilisateur et d'assigner les autorisations correctes.
Cette fonctionnalité étant intégrée aux produits SharePoint 2010, Reporting Services peut opérer avec ce modèle d'authentification. Reporting Services n'est pas compatible avec les revendications ; au lieu de cela, la communication avec SharePoint s'effectue par le biais d'un compte approuvé. Le service de proxy dans le complément SQL Server 2008 R2 utilise le modèle objet SharePoint pour convertir le jeton de revendications en un contexte utilisateur SharePoint correspondant sous la forme d'un jeton utilisateur SharePoint que le serveur de rapports peut comprendre et utiliser afin d'effectuer la validation par rapport à la base de données SharePoint. En gros, le processus se déroule de la manière suivante :
- SharePoint effectue l'authentification basée sur les revendications appropriée et, à l'aide du service d'émission de jeton de sécurité SharePoint, communique le jeton de revendications au proxy Reporting Services.
- Le proxy Reporting Services utilise ensuite le jeton de revendications pour communiquer avec le modèle objet SharePoint et générer un jeton utilisateur SharePoint correspondant qu'il transfère au serveur de rapports.
- Le serveur de rapports utilise le jeton utilisateur SharePoint contre le modèle objet SharePoint local afin de générer le contexte utilisateur SharePoint correct.
- Si l'utilisateur dispose de l'autorisation requise, le serveur de rapports renvoie les informations demandées à SharePoint à l'aide du contexte utilisateur SharePoint approprié, comme il le ferait normalement.
Génération de rapports de liste native
SQL Server 2008 R2 Reporting Services prend désormais en charge les listes SharePoint comme sources de données. Cette prise en charge vous permet d'extraire des données de listes à partir de SharePoint Foundation 2010, SharePoint Server 2010, Windows SharePoint Services 3.0 et Office SharePoint Server 2007. La capacité à accéder à des données de listes ne dépend pas du complément, ni de l'exécution du serveur de rapports en mode natif ou en mode intégré SharePoint. Cette fonctionnalité est intégrée au serveur de rapports. Ce qui change dans les différentes configurations, c'est le mode d'accès.
Les données de listes SharePoint sont accessibles de deux manières : par le biais du service Web lists.asmx et par le biais des API du modèle objet SharePoint. Sur toute installation SharePoint, si vous entrez l'URL http://<nom_serveur_sharepoint>\lists.asmx, vous obtenez une liste XML de toutes les listes sur le site SharePoint auxquelles vous pouvez accéder. Grâce à cette méthode, Report Builder 3.0 est en mesure d'extraire les listes. Un serveur de rapport configuré en mode natif utilise également cette méthode.
La méthode faisant appel aux API du modèle objet SharePoint peut être employée dans deux scénarios. Tout d'abord, celui dans lequel un serveur de rapports est configuré en mode intégré SharePoint et où la liste existe dans la batterie SharePoint à laquelle Reporting Services est intégrée, tout ceci sur le même ordinateur. N'oubliez pas que dans ce scénario, une copie de SharePoint s'exécute sur le serveur de rapports qui lui donne accès à l'ensemble d'API. L'autre scénario est celui dans lequel SharePoint 2010 est installé en même que le complément, mais en l'absence de serveur de rapports. On emploie dans ce cas le terme de « mode local », qui est décrit plus loin dans la section intitulée « Génération de rapports sans Reporting Services ».
Pour utiliser des données obtenues à partir d'une liste SharePoint dans un rapport, vous devez d'abord créer une source de données, puis un groupe de données qui utilise cette source de données. Dans Report Builder 3.0, il existe un nouveau type de connexion dans la page Propriétés de la source de données appelé Liste Microsoft SharePoint, comme illustré à la Figure 3. Avec cette option, vous pouvez entrer l'URL de votre site SharePoint ; inutile d'ajouter lists.asmx à l'URL. La source de données peut également être configurée avec des informations d'identification différentes à utiliser lors de l'accès au serveur SharePoint.
.jpg)
Figure3 Type de connexion Liste SharePoint
Lorsque vous créez un groupe de données basé sur cette source de données, une liste de toutes les listes SharePoint sur le site auxquelles vous avez accès vous est présentée. Vous pouvez explorer une liste et accéder à des éléments de liste spécifiques, créer des filtres, créer des paramètres et créer des rapports comme s'il s'agissait d'une table de base de données SQL.
Prise en charge du mappage des accès de substitution
L'une des autres améliorations apportées à l'intégration est la prise en charge du mappage des accès de substitution. Le mappage des accès de substitution est présent dans SharePoint depuis la version 2007, mais Reporting Services ne le prenait pas en charge. Désormais, si vous configurez un mappage des accès de substitution dans l'Administration centrale de SharePoint, le complément Reporting Services conserve la structure d'URL, comme illustré dans le rapport très simple de la Figure 4. Les URL http://sql-01 et https://www.contoso.com restituent toutes deux le même rapport.
.jpg)
Figure 4 Mappage des accès de substitution
Génération de rapports sans Reporting Services
Jusqu'ici, toutes les informations de cet article ont concerné ce que l'on appelle le mode connecté. Dans les versions précédentes de Reporting Services, il s'agissait du seul mode disponible, ce qui signifie que SharePoint devait être connecté à un serveur de rapports Reporting Services configuré en mode intégré SharePoint afin de restituer les rapports à l'aide de la Visionneuse de rapports.
Avec SQL Server 2008 R2, vous pouvez restituer des rapports sans intégrer votre batterie ou site SharePoint à un serveur de rapports Reporting Services. Au lieu de cela, vous pouvez utiliser la Visionneuse de rapports pour restituer directement les rapports à partir de SharePoint lorsque l'extension de données prend en charge la génération de rapports en mode local. Par défaut, seules les extensions de génération de rapports Microsoft Access 2010 et Liste SharePoint offrent cette prise en charge.
Lorsque vous êtes en mode local, vous pouvez également restituer un rapport qui possède une source de données incorporée ou partagée à partir d'un fichier .rsds. En revanche, vous ne pouvez pas gérer le rapport ou sa source de données associée, car cela n'est pas pris en charge en mode local.
Combinaisons du complément SharePoint et du serveur de rapports prises en charge
Avec la commercialisation de SQL Server 2008 R2 et de SharePoint Server 2010, il existe désormais trois versions de SQL, trois versions du complément et deux versions de SharePoint. Les composants d'intégration peuvent fonctionner sur chacune de ces versions, mais vous devez combiner les versions correctes. Le tableau de la Figure 5 répertorie les combinaisons de produits prises en charge.
.jpg)
Figure 5 Combinaisons du complément SharePoint et du serveur de rapports prises en charge
Alan Le Marquand* travaille comme Architecte de contenu informatique pour Microsoft au Royaume-Uni. Vous trouverez d'autres articles sur son blog intitulé** Alan's World of IT*.