有朋友提問：

外部SaaS應用通過ODATA API訪問SAP標準接口，直接從本方應用發起訪問就可以，無需借助PI或者BTP類的平臺吧？既然這樣，通過BTP或CPI來構建應用相對比直接在第三方平臺上構建應用的好處是什么呢？是因為這2個平臺除了獲取數據，有更多關于流程設計和類似擴展插件（不用重復造輪子）的功能，并可以發布到SAP應用市場嗎？也就是如果我不需要這些插件輔助，不到應用市場發布，是可以繞過這些平臺的。

關于 SAP 和第三方系統之間的集成，我寫過一篇短文：SAP S/4HANA Cloud 系統集成的一些場景介紹

SAP On-Premises 和 SAP Cloud 產品，都可以將其業務，以 OData 服務的方式暴露出來，供第三方系統集成使用。

SAP Cloud 產品，更準確的說，SAP Public Cloud 產品，其 OData 服務可以直接通過公網訪問。理論上，在第三方應用上，直接采用 Java，C#，nodejs，Python 或者其他編程語言，調用 OData API 即可。在同 SAP Public Cloud 集成的場景下，第三方應用既可以部署在 SAP BTP 上，也可以部署在任何其他服務器上，比如本地服務器，或者騰訊云，阿里云等等。

反觀 SAP On-Premises 暴露的 OData API，因為 SAP On-Premises 通常部署在企業內網，因此其 OData API 無法直接被第三方應用訪問到，需要使用 SAP Cloud Connector，實現內外網穿越，即下圖中間的 Secure Tunnel. 在這種場景里，SAP BTP 是必須的。

SAP BTP 除了結合 SAP Cloud Connector 實現第三方應用訪問企業內網 On-Premises 系統之外，本身的 Service Market Place 上也提供了很多開箱即用的服務，即包括應用程序層級的 Business Service，也有偏底層基礎設施(infrastructure)層面的 Technical Service. 第三方應用部署到 SAP BTP 上之后，可以消費這些服務，避免重復造輪子。

當然，如果第三方應用不需要連接 SAP On-Premises 系統，也不需要使用 SAP BTP 服務市場這些服務，那么理論上，不將第三方應用部署在 SAP BTP 上，技術上也沒有問題。

再說 CPI. 第三方系統通過同步 OData API 的方式同 SAP 系統集成，實現簡單，代價小。而 SAP CPI 作為 第三方系統和 待集成 SAP 產品之間的中間件，兩種方式各有優缺點。采用 OData API 直連 SAP 系統的方式，我們可以理解成廣義上的消息通訊機制，這種機制缺乏消息的持久化，消息監控，消息發送出錯后的重試機制等等。當第三方系統同 SAP 產品交換的場景趨于復雜時，比如下面這張圖里展示的，外部系統同 SAP S/4HANA 服務場景的集成，第三方應用會主動向 S/4HANA 發送兩條消息，并接收從 SAP S/4HANA 回復的一條異步消息。只有當這兩發一收操作全部結束之后，一個場景才算完全處理完畢。如果采用 OData API 發送機制實現，這個場景的錯誤處理，邊界條件控制等措施，需要在第三方應用內部實現，開發復雜度比較高。而這些正是 SAP CPI 作為中間件的強項和用武之地。

綜上，第三方系統同 SAP 系統集成，是否選擇 SAP BTP 或者 CPI，取決于集成所需實現的具體場景以及實現復雜度。

更多Jerry的原創文章，盡在：“汪子熙”:

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的答网友问：如果用 OData 就能直接和 SAP 系统互通，BTP 和 CPI 这样的平台意义在哪里呢？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。