將 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 也可以啟用報表檢視和流覽 Render API 的方法。 不過，透過SOAP API檢視報表並不會啟用報表工具列的內建檢視功能，也不會自動處理URL存取所提供的報表互動性。
如需 Reporting Services SOAP API 的詳細資訊，請參閱 報表伺服器 Web 服務。
在大部分情況下，URL 存取和SOAP呼叫都需要符合您的報告需求。 當一開始連接到報表伺服器資料庫，並在使用者介面和URL存取中呈現可用的報表清單時，會使用SOAP來實際存取和瀏覽個別報表。
如需結合 URL 存取和 Web 服務以提供整合式報表的範例，請參閱 SQL Server Reporting Services 產品範例。
另請參閱
將 Reporting Services 整合到使用SOAP 整合 Reporting Services 的應用程式使用URL 存取技術參考整合 Reporting Services （SSRS）