Choisir entre l’accès URL et SOAP dans Reporting Services

  • Article

S’applique à :✅ SQL Server Reporting Services (2016) ❌ SQL Server Reporting Services (2017) ❌ Power BI Report Server

L’intégration de Reporting Services dans des applications personnalisées peut s’avérer 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, est conçu avec une flexibilité de programmation à l’esprit. La flexibilité entraîne la nécessité de prendre des décisions importantes concernant l’intégration de la navigation dans les rapports Reporting Services et les fonctionnalités de gestion dans vos applications de gestion existantes.

Notes

À partir de SQL Server 2017 Reporting Services, l’accès de l’API REST est disponible pour le développement de solutions. L’accès de l’API SOAP a été déprécié. Pour plus d’informations, consultez Développer avec les API REST pour Reporting Services.

Il existe deux manières d’intégrer Reporting Services dans des applications personnalisées : l’accès URL et l’API SOAP de Reporting Services. Celle à utiliser dépend de plusieurs facteurs. Dans certains cas, l’intégration de Reporting Services à vos applications de gestion personnalisées nécessite l’utilisation à la fois de l’accès URL et de SOAP. Vous devez vous poser les questions suivantes :

  • De quel type de fonctionnalités de création de rapports d'entreprise vos utilisateurs finals et vous avez-vous besoin ? Avez-vous besoin d'une manière simple de générer et parcourir des rapports ou de fonctionnalités de gestion de serveur de rapports plus avancées dans votre solution d'entreprise personnalisée ?

  • Dans quel type d'environnement vos utilisateurs travaillent-ils habituellement ? Votre application d'entreprise est-elle une application Web ou une application Windows ? Vos utilisateurs finaux peuvent-ils parvenir facilement à basculer d’un environnement Win32 vers un environnement web ? De quel type de contrôle avez-vous besoin sur l'environnement dans lequel les rapports sont exécutés et gérés ?

Après avoir répondu aux questions précédentes, vous pouvez décider comment intégrer Reporting Services à votre infrastructure informatique. En général, l'accès URL est préféré pour consulter et parcourir des rapports individuels. L'accès URL vous permet de parcourir librement et rapidement des rapports sans le traitement du service Web. De plus, l'accès URL est actuellement la seule technique de programmation qui utilise la Visionneuse HTML complète pour la navigation entre les rapports, laquelle inclut la barre d'outils Rapports. Par ailleurs, l’accès URL est plus performant que SOAP, car il contourne le marshaling des demandes SOAP vers et à partir du serveur. Dans les scénarios d'intégration qui requièrent un accès rapide et facile aux rapports avec des outils intégrés pour la consultation et la navigation, l'accès URL constitue le meilleur choix.

Notes

L'accès URL du serveur de rapports prend en charge la Visionneuse HTML et les fonctionnalités étendues de la barre d'outils Rapports. L'API SOAP ne prend pas en charge ce type de rapport rendu. Si vous effectuez le rendu des rapports à l’aide de l’API SOAP, vous devez concevoir et développer votre propre barre d’outils Rapports.

Pour plus d’informations sur la barre d’outils du rapport, consultez Visionneuse HTML et barre d’outils Rapports.

Pour plus d’informations sur l’accès URL, consultez Accès URL.

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 riches fonctionnalités générales de l'API SOAP de 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 de serveur, gérer l'espace de noms du serveur de rapports, créer des abonnements, etc. L’API SOAP expose le jeu complet de fonctionnalités de gestion dans Reporting Services. L'API SOAP peut également permettre de consulter et de parcourir des rapports via la méthode Render 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 l’accès URL fournit.

Pour plus d’informations sur l’API SOAP de Reporting Services, consultez Service web Report Server.

Dans la plupart 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 présente la liste disponible des rapports dans une interface utilisateur. L’accès URL est utilisé pour accéder et naviguer dans des rapports individuels.

Pour obtenir un exemple de combinaison de l’accès URL et du service web à des fins de création de rapports intégrée, consultez SQL Server Reporting Services Product Samples (Exemples Reporting Services pour le produit SQL Server).

D’autres questions ? Essayez de poser une question dans le forum Reporting Services