将 Reporting Services 集成到自定义应用程序中可能很有挑战性。 但是，挑战不是编程模型或 API 的复杂性，而是集成它的许多可能方法。 Reporting Services 从头开始设计为开发人员平台，因此，它以编程灵活性构建。 由于灵活性，需要就将 Reporting Services 报表导航和管理功能集成到现有业务应用程序中做出重要决策。
Reporting Services 编程支持各种方案。
有两种方法可将 Reporting Services 集成到自定义应用程序中：URL 访问和 Reporting Services SOAP API。 要使用哪个因素取决于几个因素。 在某些情况下，将 Reporting Services 集成到自定义业务应用程序中需要你同时使用 URL 访问和 SOAP。 应提出以下问题：
你或最终用户需要哪种类型的企业报告功能？ 是否需要一种简单的方法来启动和导航报表，或者是否需要自定义业务解决方案中的更高级的报表服务器管理功能？
用户通常运行哪种类型的环境？ 业务应用程序是 Web 应用程序还是 Windows 应用程序？ 最终用户如何轻松地从 Win32 环境切换到 Web 环境？ 对运行和管理报表的环境需要哪种类型的控制？
回答上述问题后，可以决定如何将 Reporting Services 集成到 IT 基础结构中。 通常，首选 URL 访问来查看和导航单个报表。 通过 URL 访问，无需 Web 服务的开销即可自由快速地导航报表。 此外，URL 访问目前是唯一一种使用完整 HTML 查看器进行报表导航的编程技术，其中包括报表工具栏。 此外，URL 访问比 SOAP 提供更好的性能，因为它绕过了对服务器和服务器发出 SOAP 请求的封送。 在需要使用内置工具来查看和导航报表的集成方案中，URL 访问是更好的选择。
注释
报表服务器 URL 访问支持 HTML 查看器和报表工具栏的扩展功能。 SOAP API 不支持这种类型的呈现报表。 如果使用 SOAP 呈现报表，则需要设计和开发自己的报表工具栏。
有关报表工具栏的详细信息，请参阅 HTML 查看器和报表工具栏。
有关 URL 访问的详细信息，请参阅 URL 访问（SSRS）。
URL 访问对于查看报表很有用，但它不提供报表和命名空间管理功能，这对于任何企业报告方案都至关重要。 在这种情况下，建议使用 Reporting Services SOAP API 的广泛和丰富功能。 使用 SOAP API，可以管理和部署报表、创建计划、配置服务器属性、管理报表服务器命名空间、创建订阅等。 SOAP API 在 Reporting Services 中公开完整的管理功能集。 SOAP API 还可以通过 API 方法启用报表查看和导航 Render 。 但是，通过 SOAP API 查看报表不会启用报表工具栏的内置查看功能，也不会自动处理 URL 访问提供的报表交互性。
有关 Reporting Services SOAP API 的详细信息，请参阅 报表服务器 Web 服务。
在大多数情况下，URL 访问和 SOAP 调用都需要满足报告需求。 最初连接到报表服务器数据库并在用户界面和 URL 访问中显示报表的可用列表用于实际访问和导航单个报表时使用 SOAP。
有关合并 URL 访问和 Web 服务以提供集成报告的示例，请参阅 SQL Server Reporting Services 产品示例。
另请参阅
将 Reporting Services 集成到使用SOAP 集成 Reporting Services 的应用程序时，使用 URL 访问技术参考 （SSRS） 集成 Reporting Services