集成是企業(yè)信息化中經(jīng)久不衰的話題,它可以聚焦到某一個(gè)點(diǎn),例如兩個(gè)系統(tǒng)之間的接口;也可以擴(kuò)散到整體IT架構(gòu)的設(shè)計(jì),涵蓋標(biāo)準(zhǔn)化、總線、微服務(wù)等一系列的內(nèi)容。這么多年來(lái),隨著SAP解決方案的不斷增加,與之相關(guān)的集成場(chǎng)景范圍也在不斷的擴(kuò)大。
SAP的技術(shù)顧問(wèn)們也要快速刷新自己的知識(shí)庫(kù),雖然二十年前的IDoc、RFC等技術(shù)仍然存在,思路和架構(gòu)仍然經(jīng)典,但是我們要以另外一種視野和角度去表達(dá)。話不多說(shuō),先上一張總圖:
這張總圖有著非常清晰的定義,無(wú)論是否有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)用的用戶訪問(wèn)集成
User2Cloud
到云端應(yīng)用的用戶訪問(wèn)集成
Thing2OP
本地物聯(lián)網(wǎng)集成
Thing2Cloud
云端物聯(lián)網(wǎng)集成
咱們先從最熟悉的OP2OP談起,懷舊一下,貼一張當(dāng)年《BIT100 Integration Technologies》教材的目錄:
通過(guò)圖中的RFC,可以實(shí)現(xiàn)ABAP與Java、ABAP與.net之間的互通(教材《BIT526 Dev. BAPI-Enabled Web Apps with Java》、《BIT528 SAP .NET Connector Programming》),在當(dāng)時(shí)來(lái)講,解決了絕大多數(shù)的集成需求。
隨著Web Service的發(fā)展,SOA興起,SAP順勢(shì)推出了NetWeaver平臺(tái),沿用至今,現(xiàn)在仍然是S/4 HANA重要的底層技術(shù)平臺(tái)。在NetWeaver框架體系下,系統(tǒng)集成由點(diǎn)對(duì)點(diǎn)向總線式發(fā)展,后面就出現(xiàn)了大家熟悉的NetWeaver Exchange Infrastructure(XI) à Process Integration(PI)à Process Orchestration(PO),產(chǎn)品演化的過(guò)程中, 融合了BPM、B2B、微服務(wù)等理念,將業(yè)務(wù)流和數(shù)據(jù)流實(shí)現(xiàn)在統(tǒng)一平臺(tái)中。
SAP Process Orchestration是本地部署解決方案中解決集成問(wèn)題的重要工具,但是就像上文所說(shuō),OP2OP在今天只是眾多場(chǎng)景中的一個(gè),我們還需要考慮OP2Cloud,甚至Cloud2Cloud。這樣,我們?cè)谠贫司托枰粋€(gè)類(lèi)似Process Orchestration的工具,可以帶給我們更多的集成場(chǎng)景選擇,這就是SAP Cloud Platform Integration(CPI)。
從系統(tǒng)截圖可以看出,SAP Cloud Platform Integration的技術(shù)實(shí)現(xiàn)思路基本與Process Orchestration一致,我們也可以初步簡(jiǎn)單的把CPI理解成一個(gè)「云端的PI」。
對(duì)于不同集成工具的選擇,有借鑒的思路可以參考。比如OP2OP場(chǎng)景,Process Orchestration更合適一些;Cloud2Cloud場(chǎng)景,就應(yīng)該選擇Cloud Platform Integration。但是兩者之間也有重疊的使用場(chǎng)景,例如OnPremise2Cloud。應(yīng)該說(shuō),我們根據(jù)系統(tǒng)的整體環(huán)境、技術(shù)路線、總體成本等因素綜合考慮,來(lái)選擇用哪一個(gè)更合適,又或者是兩者共同使用。
我們?cè)诤芏鄨?chǎng)合中,經(jīng)常會(huì)聽(tīng)到「無(wú)縫集成」這一說(shuō)法,例如「XX解決方案和ERP無(wú)縫集成」。這個(gè)說(shuō)法本身帶有了很多修飾的意味,從技術(shù)本身來(lái)講,同構(gòu)和異構(gòu)系統(tǒng)都是通過(guò)API的方式,或許有private API和public API,但是都不會(huì)造成技術(shù)上的太大區(qū)別。所謂的「無(wú)縫集成」,SAP實(shí)現(xiàn)的方式是通過(guò)開(kāi)箱即用的「集成內(nèi)容包」,把常用的場(chǎng)景一個(gè)個(gè)提煉出來(lái),提前預(yù)置在「集成內(nèi)容包」當(dāng)中隨軟件一起發(fā)布,這樣我們?cè)谑褂玫臅r(shí)候就可以進(jìn)行快速的復(fù)制或者參考,減少工作量。早在NetWeaver XI時(shí)代,與之配套的就有XI Content,解決針對(duì)于ECC的快速集成;同樣在Cloud Platform Integration中,也提供了Cloud Integration Content,面向S/4 HANA以及SAP SaaS應(yīng)用的快速集成。
下圖以on-premise S/4HANA和SAP SuccessFactors為例,我們可以看到通過(guò)Cloud Platform Integration快速實(shí)現(xiàn)的集成場(chǎng)景。
前面講的很多內(nèi)容都是從企業(yè)內(nèi)部信息化的角度出發(fā),那么,對(duì)外的應(yīng)用該如何考慮集成呢?我們是否會(huì)搭建一些B2C、B2B、或者是IoT的對(duì)外應(yīng)用?從技術(shù)棧來(lái)看,企業(yè)應(yīng)用和互聯(lián)網(wǎng)個(gè)人應(yīng)用的側(cè)重點(diǎn)仍然會(huì)保持差異化,但是很多方面二者又在相互滲透,比如在集成領(lǐng)域,我們不去糾結(jié)SOA與微服務(wù)的矛盾點(diǎn),而是應(yīng)該去找到各自適合的場(chǎng)景,一起發(fā)揮效果。
在對(duì)外集成的場(chǎng)景下,早期實(shí)現(xiàn)的方式是通過(guò)EDI,SAP也很早就把EDI包含在了PI的功能組件當(dāng)中。今天我們談的場(chǎng)景是API經(jīng)濟(jì),例如企業(yè)把內(nèi)部的制造工廠、產(chǎn)品等物理資產(chǎn)數(shù)字化,把企業(yè)擁有的數(shù)據(jù)、服務(wù)和業(yè)務(wù)能力以API的形式開(kāi)放給生態(tài)系統(tǒng)各參與方,實(shí)現(xiàn)業(yè)務(wù)能力的互聯(lián)互通,各參與方共贏的新的價(jià)值網(wǎng)絡(luò)。實(shí)現(xiàn)API經(jīng)濟(jì)的技術(shù)基礎(chǔ)之一,就是需要有一套統(tǒng)一的API管理平臺(tái),SAP的解決方案就是Cloud Platform API Management。
API Management把所有企業(yè)內(nèi)部的應(yīng)用都當(dāng)做是API Sources,無(wú)論是本地應(yīng)用還是云端。它提供了例如API開(kāi)發(fā)、注冊(cè)、版本管理、轉(zhuǎn)換、API交通流量管理、安全、監(jiān)控、分析等等一系列的能力,然后統(tǒng)一在云端以REST API的方式對(duì)外發(fā)布,提供給生態(tài)系統(tǒng)的各參與方去消費(fèi)使用。下圖中列舉了一個(gè)最常見(jiàn)的例子,就是API的交通流量管理,以限流限頻的方式把內(nèi)部的API發(fā)布出去,根據(jù)特定的條件限制它的使用次數(shù)和頻率。
-
SAP
+關(guān)注
關(guān)注
1文章
385瀏覽量
21692 -
集成技術(shù)
+關(guān)注
關(guān)注
0文章
24瀏覽量
10959 -
RFC
+關(guān)注
關(guān)注
0文章
16瀏覽量
10121
原文標(biāo)題:SAP集成技術(shù)發(fā)展之路(上)
文章出處:【微信號(hào):sapdaily,微信公眾號(hào):SAP天天事】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論