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实
际上是数据的载体。