在 Reporting Services 的 URL 存取與 SOAP 之間選擇

適用於： SQL Server Reporting Services （2016） ❌ SQL Server Reporting Services （2017） Power BI 報表伺服器 ❌

將 Reporting Services 整合至自訂應用程式頗具挑戰性。 不過，挑戰不是程序設計模型或 API 的複雜性，而是整合它的許多可能方式。 Reporting Services 從頭開始設計為開發人員平臺，因此，是以程式設計彈性來建置。 當要做出有關將 Reporting Services 報表瀏覽與管理功能整合至現有商務應用程式的重大決定時，彈性便會派上用場。

注意

從 SQL Server 2017 Reporting Services 開始，開發方案可使用 REST API 存取。 SOAP API 存取已被取代。 如需詳細資訊，請參閱使用 Reporting Services 的 REST API 進行開發。

有兩種方法可將 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 API 轉譯報表，請設計和開發自己的報表工具列。

如需報表工具列的詳細資訊，請參閱 HTML 檢視器和報表工具列。

如需 URL 存取的詳細資訊，請參閱 URL 存取。

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 呼叫，才能符合您的報告需求。 當一開始連接到報表伺服器資料庫，並在使用者介面中呈現可用的報表清單時，會使用SOAP。 URL 存取是用來實際存取和瀏覽個別報表。

如需結合 URL 存取與 Web 服務以提供整合報表的範例，請參閱 SQL Server Reporting Services 產品範例。

更多問題嗎？ 請嘗試詢問 Reporting Services 論壇