SAP解決方案不斷增加，集成場景范圍不斷擴(kuò)大

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

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

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

OP2OP

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

OnPremise2Cloud

本地應(yīng)用和云端應(yīng)用之間的集成

Cloud2Cloud

云端應(yīng)用之間的集成

B2B

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

User2OP

到本地應(yīng)用的用戶訪問集成

User2Cloud

到云端應(yīng)用的用戶訪問集成

Thing2OP

本地物聯(lián)網(wǎng)集成

Thing2Cloud

云端物聯(lián)網(wǎng)集成

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

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

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

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

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

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

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

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

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

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

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