集成是企業(yè)信息化中經久不衰的話題，它可以聚焦到某一個點，例如兩個系統(tǒng)之間的接口；也可以擴散到整體IT架構的設計，涵蓋標準化、總線、微服務等一系列的內容。這么多年來，隨著SAP解決方案的不斷增加，與之相關的集成場景范圍也在不斷的擴大。

SAP的技術顧問們也要快速刷新自己的知識庫，雖然二十年前的IDoc、RFC等技術仍然存在，思路和架構仍然經典，但是我們要以另外一種視野和角度去表達。話不多說，先上一張總圖：

這張總圖有著非常清晰的定義，無論是否有SAP的解決方案，它都適用于現代IT集成體系的建設，一些名詞解釋如下：

OP2OP

傳統(tǒng)集成領域最熟悉的，本地預置應用之間的集成

OnPremise2Cloud

本地應用和云端應用之間的集成

Cloud2Cloud

云端應用之間的集成

B2B

同外部業(yè)務伙伴之間的集成

User2OP

到本地應用的用戶訪問集成

User2Cloud

到云端應用的用戶訪問集成

Thing2OP

本地物聯網集成

Thing2Cloud

云端物聯網集成

咱們先從最熟悉的OP2OP談起，懷舊一下，貼一張當年《BIT100 Integration Technologies》教材的目錄：

通過圖中的RFC，可以實現ABAP與Java、ABAP與.net之間的互通（教材《BIT526 Dev. BAPI-Enabled Web Apps with Java》、《BIT528 SAP .NET Connector Programming》），在當時來講，解決了絕大多數的集成需求。

隨著Web Service的發(fā)展，SOA興起，SAP順勢推出了NetWeaver平臺，沿用至今，現在仍然是S/4 HANA重要的底層技術平臺。在NetWeaver框架體系下，系統(tǒng)集成由點對點向總線式發(fā)展，后面就出現了大家熟悉的NetWeaver Exchange Infrastructure（XI） à Process Integration（PI）à Process Orchestration（PO），產品演化的過程中， 融合了BPM、B2B、微服務等理念，將業(yè)務流和數據流實現在統(tǒng)一平臺中。

SAP Process Orchestration是本地部署解決方案中解決集成問題的重要工具，但是就像上文所說，OP2OP在今天只是眾多場景中的一個，我們還需要考慮OP2Cloud，甚至Cloud2Cloud。這樣，我們在云端就需要一個類似Process Orchestration的工具，可以帶給我們更多的集成場景選擇，這就是SAP Cloud Platform Integration（CPI）。

從系統(tǒng)截圖可以看出，SAP Cloud Platform Integration的技術實現思路基本與Process Orchestration一致，我們也可以初步簡單的把CPI理解成一個「云端的PI」。

對于不同集成工具的選擇，有借鑒的思路可以參考。比如OP2OP場景，Process Orchestration更合適一些；Cloud2Cloud場景，就應該選擇Cloud Platform Integration。但是兩者之間也有重疊的使用場景，例如OnPremise2Cloud。應該說，我們根據系統(tǒng)的整體環(huán)境、技術路線、總體成本等因素綜合考慮，來選擇用哪一個更合適，又或者是兩者共同使用。

我們在很多場合中，經常會聽到「無縫集成」這一說法，例如「XX解決方案和ERP無縫集成」。這個說法本身帶有了很多修飾的意味，從技術本身來講，同構和異構系統(tǒng)都是通過API的方式，或許有private API和public API，但是都不會造成技術上的太大區(qū)別。所謂的「無縫集成」，SAP實現的方式是通過開箱即用的「集成內容包」，把常用的場景一個個提煉出來，提前預置在「集成內容包」當中隨軟件一起發(fā)布，這樣我們在使用的時候就可以進行快速的復制或者參考，減少工作量。早在NetWeaver XI時代，與之配套的就有XI Content，解決針對于ECC的快速集成；同樣在Cloud Platform Integration中，也提供了Cloud Integration Content，面向S/4 HANA以及SAP SaaS應用的快速集成。

下圖以on-premise S/4HANA和SAP SuccessFactors為例，我們可以看到通過Cloud Platform Integration快速實現的集成場景。

前面講的很多內容都是從企業(yè)內部信息化的角度出發(fā)，那么，對外的應用該如何考慮集成呢？我們是否會搭建一些B2C、B2B、或者是IoT的對外應用？從技術棧來看，企業(yè)應用和互聯網個人應用的側重點仍然會保持差異化，但是很多方面二者又在相互滲透，比如在集成領域，我們不去糾結SOA與微服務的矛盾點，而是應該去找到各自適合的場景，一起發(fā)揮效果。

在對外集成的場景下，早期實現的方式是通過EDI，SAP也很早就把EDI包含在了PI的功能組件當中。今天我們談的場景是API經濟，例如企業(yè)把內部的制造工廠、產品等物理資產數字化，把企業(yè)擁有的數據、服務和業(yè)務能力以API的形式開放給生態(tài)系統(tǒng)各參與方，實現業(yè)務能力的互聯互通，各參與方共贏的新的價值網絡。實現API經濟的技術基礎之一，就是需要有一套統(tǒng)一的API管理平臺，SAP的解決方案就是Cloud Platform API Management。

API Management把所有企業(yè)內部的應用都當做是API Sources，無論是本地應用還是云端。它提供了例如API開發(fā)、注冊、版本管理、轉換、API交通流量管理、安全、監(jiān)控、分析等等一系列的能力，然后統(tǒng)一在云端以REST API的方式對外發(fā)布，提供給生態(tài)系統(tǒng)的各參與方去消費使用。下圖中列舉了一個最常見的例子，就是API的交通流量管理，以限流限頻的方式把內部的API發(fā)布出去，根據特定的條件限制它的使用次數和頻率。