Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’intégration de Reporting Services dans des applications personnalisées peut être difficile. Toutefois, le défi n’est pas la complexité du modèle de programmation ou des API, mais les nombreuses façons possibles de l’intégrer. Reporting Services a été conçu à partir du haut en tant que plateforme de développement et, par conséquent, il est conçu avec une flexibilité de programmation à l’esprit. Grâce à la flexibilité, vous devez prendre des décisions importantes sur l’intégration de la fonctionnalité de navigation et de gestion des rapports Reporting Services dans vos applications métier existantes.
de La programmation Reporting Services prend en charge un large éventail de scénarios.
Il existe deux façons d’intégrer Reporting Services dans des applications personnalisées : l’accès URL et l’API SOAP Reporting Services. L’utilisation dépend de plusieurs facteurs. Dans certains cas, l’intégration de Reporting Services dans vos applications métier personnalisées vous oblige à utiliser à la fois l’accès URL et SOAP. Vous devez poser les questions suivantes :
Quel type de fonctionnalité de création de rapports d’entreprise avez-vous besoin ou de vos utilisateurs finaux ? Avez-vous besoin d’un moyen simple de lancer et de parcourir des rapports, ou avez-vous besoin de fonctionnalités d’administration de serveur de rapports plus avancées à partir de votre solution métier personnalisée ?
Dans quel type d’environnement vos utilisateurs fonctionnent-ils généralement ? Votre application métier est-elle une application web ou une application Windows ? Comment vos utilisateurs finaux peuvent-ils passer facilement d’un environnement Win32 à un environnement Web ? Quel type de contrôle avez-vous besoin sur l’environnement dans lequel les rapports sont exécutés et gérés ?
Une fois que vous avez répondu aux questions précédentes, vous pouvez décider comment intégrer Reporting Services à votre infrastructure informatique. En règle générale, l’accès à l’URL est préféré pour afficher et naviguer dans des rapports individuels. L’accès à l’URL vous permet de naviguer librement et rapidement dans les rapports sans surcharge du service Web. En outre, l’accès à l’URL est actuellement la seule technique de programmation qui utilise la visionneuse HTML complète pour la navigation dans le rapport, qui inclut la barre d’outils de rapport. En outre, l’accès URL offre de meilleures performances que SOAP, car il contourne le marshaling des requêtes SOAP vers et depuis le serveur. Dans les scénarios d’intégration qui nécessitent un accès rapide et facile aux rapports avec des outils intégrés pour l’affichage et la navigation, l’accès URL est le meilleur choix.
Remarque
L’accès URL du serveur de rapports prend en charge html Viewer et les fonctionnalités étendues de la barre d’outils de rapport. L’API SOAP ne prend pas en charge ce type de rapport rendu. Vous devez concevoir et développer votre propre barre d’outils de rapport si vous affichez des rapports à l’aide de SOAP.
Pour plus d’informations sur la barre d’outils du rapport, consultez visionneuse HTML et barre d’outils rapport.
Pour plus d’informations sur l’accès AUX URL, consultez l’accès URL (SSRS) .
L’accès URL est utile pour afficher les rapports, mais il ne fournit pas les fonctionnalités de gestion des rapports et des espaces de noms qui peuvent être essentielles à n’importe quel scénario de création de rapports d’entreprise. Dans ce cas, les fonctionnalités étendues et riches de l’API SOAP Reporting Services sont recommandées. Avec l’API SOAP, vous pouvez gérer et déployer des rapports, créer des planifications, configurer des propriétés du serveur, gérer l’espace de noms du serveur de rapports, créer des abonnements, etc. L’API SOAP expose l’ensemble complet de fonctionnalités de gestion dans Reporting Services. L’API SOAP peut également activer l’affichage et la navigation des rapports via la Render méthode de l’API. Toutefois, l’affichage des rapports via l’API SOAP n’active pas la fonctionnalité d’affichage intégrée de la barre d’outils de rapport, ni ne gère automatiquement l’interactivité de rapport que fournit l’accès URL.
Pour plus d’informations sur l’API SOAP Reporting Services, consultez le service web Report Server.
Dans la majorité des cas, l’accès URL et les appels SOAP sont tous deux nécessaires pour répondre à vos besoins de création de rapports. SOAP est utilisé lors de la connexion initiale à la base de données du serveur de rapports et la présentation de la liste disponible des rapports dans une interface utilisateur et l’accès URL est utilisé pour accéder et naviguer dans des rapports individuels.
Pour obtenir un exemple de combinaison d’accès URL et du service Web pour fournir des rapports intégrés, consultez les exemples de produits SQL Server Reporting Services.
Voir aussi
Intégration de Reporting Services dans des applicationsintégrant Reporting Services à l’aide de SOAPintégrant Reporting Services à l’aide d’une référence technique d’accès URL(SSRS)