1.PI - 信使中間件 (大公司多選擇)
數據： SAP- PI- U8
U8- PI- SAP
PI 底層用的還是webservice 技術
優點：實時性高； 可處理大數據（在調用PROXY 發送時 還可以分包處理）； 有接口數據日誌在PI系統；
缺點：PI 服務器+1； PI系統配置工作； 和每個外部系統都要做wsdl配置;
2. RFC - 函數 （小公司 / 簡單業務場景使用）
SE37 函數設置成remote 形式
遠程啓用的模塊：
由其他系統調用SAP的RFC，在J2EE項目裏有JCO可以使用（其他語言也有類似的dll包），可以調用RFC和返回結果。
這個方式只要能夠熟悉類似JCO的使用，就可以在其他系統中使用，比中間表有
優點：更好的實時性，（如果數據量大，會導致進程時間過長，有超時風險）
缺點：SAP中Fuction屬於純過程式語言，很多時候功能不是很強，另外只能單向進行調用，一般是和Web Service同時使用（在C++/C#項目裏，也可以建立RFC，但不確定SAP也能調用其他系統的RFC）。
3. webservice （一個平臺獨立的，低耦合的，自包含的、基於可編程的web的應用程序）
SAP調用其他系統的Web Service還是比較常見的，其實SAP也可以提供Web Service的，
這也算是與時俱進，和所謂的SOA扯上關係了。
優點：都符合WS的標準，任何其他系統都實現了相應的接口，在實時性和交互性上都有了保障。
缺點：SAP對Web Service發佈的格式要求比較嚴格，很多時候無法調用就是因爲格式不對，（格式問題是這種方式使用過程常見問題，而且雙方開發產生爭議很大原因，可能需要一方配合調整）
還好一般在建立Web Service Proxy的時候就會發現。
補充：
SOA(面向服務的架構)
面向服務的架構（SOA）是一個組件模型，它將應用程序的不同功能單元（稱爲服務）通過這些服務之間定義良好的接口和契約聯繫起來。
接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。
SOA是一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義接口進行通訊，不涉及底層編程接口和通訊模型。SOA可以看作是B/S模型、XML（標準通用標記語言的子集）/Web Service技術之後的自然延伸。
SOA將能夠幫助軟件工程師們站在一個新的高度理解企業級架構中的各種組件的開發、部署形式，它將幫助企業系統架構者以更迅速、更可靠、更具重用性架構整個業務系統。較之以往，以SOA架構的系統能夠更加從容地面對業務的急劇變化。
4. XML文件，其他固定格式文件 txt / csv
下傳數據：
SAP系統生成XML 文件（[1]溝通好命名規則, [2]溝通XML 格式 ）放到指定的ftp 文件夾，MES 系統開發程序，定時讀取產生的文件，成功後自行解析，並把文件改爲加上_HIS文件，
作爲存檔，
上傳數據：相反方向
優點: 實現需求時，雙方各自還是獨立，做自己系統需要功能，增加的任務就是， 產生指定格式文件放到ftp 文件， 讀取文件並解析，修改文件名，
缺點：（1）ftp文件服務的穩定性第一要求， （2） 交互不及時，需要MES 更高頻率掃描ftp 文件夾上的文件，
4.DB 中間表:
也就是利用中間數據庫作爲交互的方式。
SAP系統利用dbco建立與中間數據庫關聯，利用SQL或者TSQL直接對數據庫進行操作。
而其他系統也對該中間表進行操作。
優點：是實現比較簡單，對現有其他系統學習成本要求比較低，基本不需要有太多改造就能與SAP進行連接。
缺點：可能會造成交互不及時，也就是隻能靠輪詢和刷新來獲取新數據，實時性不夠高。
---------------------
se37寫出來的叫function,其中可以遠程調用的叫rfc,remote-enabled function,abap語法和輸入輸出參數就會有一些限制。bapi是sap做好的實現特定業務操作的rfc。idoc是基於sap自己的類似xml格式的文檔數據交換的方式。rfc必須在線的方式調用，一般做同步的，idoc基於文檔，可以實現異步的。
idoc是基於sap自己的類似xml格式的文檔數據交換的方式。rfc必須在線的方式調用，一般做同步的，idoc基於文檔，可以實現異步的。
idoc是系統間利用message傳遞,不涉及底層函數調用,idoc的處理方式是用edi來執行的.
你可以理解爲IDOC是SAP爲了同外部系統或內部不同client通迅所採用的一種數據結構,不同的idoc type 定義了不同的格式，如關於material master data 的IDOC, BOM, PO,SO等相關的IDOC,, ALE 主要用於內部數據交換用的，如不同client, EDI用於同外部系統的交換數據，它們的本質都 是base on IDOC。。。idoc是基於sap自己的類似xml格式的文檔數據交換的方式。idoc基於文檔，可以實現異步的。
RFC是面向過程的，調用簡單直接；
BAPI是面向對象的，有屬性、有方法、有事件，更加複雜和豐富，更能反映SAP的業務應用，而
BAPI方法的構造是基於RFC的，你也可以認爲BAPI封裝了RFC
我覺得RFC在應用時最爲靈活。
IDOC是SAP標準的文件交換格式，SAP已經有了大量的Function Module來處理和傳遞IDOC，特別
是對於要和其它系統交換數據時，配合一些系統如biztalk server，IDOC會顯得非常的方便，開
發的工作量也是最小的。
RFC的話，如果配合SAP的BDC使用的話，或者你是一個ABAP的高手的話，RFC也是很靈活的。
至於BAPI的話，我覺得SAP的bapi概念很好，但是接口很不完善，很多數據無法通過SAP本身的
BAPI完成，得自己來做開發。
對於bapi和rfc到底那個好用，我覺得沒什麼定論。
有時bapi好用，有時rfc好用。
bapi好用在於，其效率相對比較高，這個主要體現在有些bapi是用direct input的方式寫的，
效率高。
但你如果用rfc寫也有他的好處，當你寫的不只是一個luw時，而每個luw都比較簡單，
在這種情況下就用rfc開發比較快。
SAP的idoc文件替代了edi文件的作用。
ale是一種通訊的模式。
bapi,一種函數，sap提供一大堆，用於主要的業務流程的處理
rfc,一種函數，用於與外部程序調用
應該說RFC是其它內容的基礎，它是一個Function module，可以被遠程調用。而BAPI本身就是一
個RFC，但它被作爲BO的Interface，作用更進一步，除了BAPI文檔中提到的內容外，還可以作爲
ALE/IDOC的開發基礎。
ALE是R/3系統之間的應用層數據交換，至於用什麼，就看具體配置了，比如可以用IDOC，同步／
異步BAPI，甚至用EDI。非SAP系統無法用ALE來實現。
至於數據傳輸的方式，可以是IDOC（底層是用RFC來實際的），也可以是EDI，所以說IDOC／EDI實
際上是數據的載體。