SAP对外接口方案根据公司对系统的管控而不同，总体上常用的主要有下面几种：
1、IDOC 方案；2、WebService方案；3、RFC 方案；4、中间件（接口平台）方案；5、FTP/SFTP 方案。
方案评估需考虑的因素，如 公司已有方案、交互数据量、交互频率、安全级别等
SAP系统的接口方式
1. PI (信使中间件)中间件（接口平台）方案
2. RFC (远程函数调用)
3. Web Service
4. IDOC 方案
5、FTP/SFTP 方案。
4. 中间式接口：使外部系统和SAP系统相对独立，不涉及双方内部结构。
5. 主动式接口：SAP系统主动发起请求，读写数据。
6. 被动式接口：SAP系统作为被动方接收其他系统的数据请求
SAP系统接口方式的详细划分：
1. PI (信使中间件)：适用于大公司，使用Web Service作为底层技术，具有实时性高和处理大数据量的优点。
数据： 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. Web Service：（一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序接口）
SAP调用其他系统的Web Service还是比较常见的，其实SAP也可以提供Web Service的，
这也算是与时俱进，和所谓的SOA扯上关系了。
优点：都符合WS的标准，任何其他系统都实现了相应的接口，在实时性和交互性上都有了保障。
缺点：SAP对Web Service发布的格式要求比较严格，很多时候无法调用就是因为格式不对，（格式问题是这种方式使用过程常见问题，而且双方开发产生争议很大原因，可能需要一方配合调整）
还好一般在建立Web Service Proxy的时候就会发现。
补充：
SOA（Service-Oriented Architecture，面向服务的架构）是一个组件模型，是一种高层级的架构设计理念，可通过在网络上使用基于通用通信语言的服务接口，让软件组件可重复使用。
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 文件夹上的文件，
5.DB 中间表----中间数据库交互的方式
也就是利用中间数据库作为交互的方式。
SAP系统利用dbco建立与中间数据库关联，利用SQL或者TSQL直接对数据库进行操作。
而其他系统也对该中间表进行操作。
优点：是实现比较简单，对现有其他系统学习成本要求比较低，基本不需要有太多改造就能与SAP进行连接。
缺点：可能会造成交互不及时，也就是只能靠轮询和刷新来获取新数据，实时性不够高。
RFC ,BAPI,IDOC区别
se37 RFC function,其中可以远程调用的叫rfc,remote-enabled function,abap语法和输入输出参数就会有一些限制。
BAPI是sap做好的实现特定业务操作的rfc。
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开发比较快。
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实
际上是数据的载体。
IDOC、ALE、EDI三者之间的区别与联系
EDI (Electronic data interchange) - 是指按照同一规定的一套通用标准格式，将标准的经济信息，通过通信网络传输，在贸易伙伴的电子计算机系统之间进行 数据交换 和自动处理。由于使用 EDI 能有效的减少直到最终消除贸易过程中的纸面单证，因而 EDI 也被俗称为 “ 无纸交易 ” 。它是一种利用计算机进行商务处理的新方法。EDI是将贸易、运输、保险、银行和海关等行业的信息，用一种国际公认的标准格式，通过计算机通信网络，使各有关部门、公司与企业之间进行数据交换与处理，并完成以贸易为中心的全部业务过程。
EDI用于不同企业间的电子数据的交换。
ALE (application link enable) 是一种通讯的模式。是SAP专门为SAP与SAP之间所设计的整合中间件，在SAP 3.0版本开始就作为SAP整个应用体系的一部分，为分布式数据交换提供了可靠安全的通讯机制。ALE的设计，原本作为两个SAP流程之间的一种消息传递服务(Messaging Service) ，使SAP与SAP的业务流程之间企业数据能够有效的交换，为两个独立的SAP之间提供了的系统整合服务。不过，随着应用的发展，ALE/ IDOC s接口机制也已然成为与其它非SAP系统的标准的整合方式。
ALE的设计结构可以分为三层，即应用层，数据/消息分配层和通讯层。通讯层是SAP整合机制的基础，它利用远程功能呼叫RFC(Remote Function Call) 调用SAP系统的功能模块。
ALE主要用于同一企业不同sap系统之间的数据交换。
IDOC(Intermediate Document)
是信息系统之间（通常是ERP） 进行事务性或数据交换使用的标准数据格式，其中比较公认的是符合EDI标准的IDoc，个别系统可以用过EDI子系统转换为EDI标准来使用。IDoc一般是面向消息的，含有事务性数据、主数据和控制数据；异步处理的。
IDOC是SAP R/3与SAP R/3或其他外部系统交换数据用过的文件格式
IDoc是EDI的一个实现,SAP的idoc文件替代了edi文件的作用。
IDoc文件交换数据的逻辑示意图,由此可见以它做为通讯媒介构成了一个强大的分布且开放的系统
一. IDOC（Intermediate Document）配置
SAP IDOC 是SAP系统中一种标准数据结构，它用于在SAP系统之间或SAP系统与非SAP系统之间交换数据。这是一种自包含的数据结构，可以用于SAP系统之间或SAP系统与外部系统之间的电子数据交换。IDoc包含一组标准化的数据，可以用于通信，这些数据与发送和接收系统的实际格式无关.
SAP IDOC 常用于SAP 内部不同模块的集成，也可用于SAP 与外部系统交互：
ALE(Application Link Enabling)：用于在同一集团中不同的SAP系统之间的数据交换
EDI(electronic data exchange)：实现不同企业间电子数据的交换,通过IDoc文件和业务伙伴进行数据交换
通过IDoc也可连接其它应用系统
创建IDOC步骤如下:
第一步:WE31 创建IDOC所包含的字段.
第二步:WE30 创建IDOC 把Segment分配给IDOC
第三步:WE81 创建信息类型
第四步:WE82 把IDOC类型与信息类型对应.
第五步:WE57 Assign Message & Idoc Type to a Function Module for Data Process
第六步:SM59 Define a RFC connection for Idoc transfer
第七步:WE21 Define a Port ( Assign a RFC destination which created in SM59 )
第八步:WE41/42 Creat Process Code
第九步:WE20 Define a Partner Profiles( Also creat a Outbound parameters with Port, or Inbound parameters with Process code )
具体案例可以参考：IDOC的配置和开发（完整的IDOC）
IDOC系统学习
运维过程中更常用的是分析管理IDOC:
WE02 显示IDOC，根据时间、类型等查看IDOC消息。
WE46 IDOC管理（出/入）
WE60 IDOC类型文档（查看IDOC结构及其字段属性）
WE19 根据IDOC号进行IDOC处理，直接修改IDOC参数进行手动补发（慎重）
4、关联Message Type和IDOC Type（WE82）
7、创建发送端Logical System并分配（SALE）
9、创建接收端合作和伴配置文件Partner profile（WE20）
3、将接收端Logical System分配到Client 810（SALE）
6、将入站函数与IDOC Type/Message Type关联（WE57）
7、创建入站处理代码Inbound Process Code（WE42）
8、创建发送端合作和伴配置文件Partner profile（WE20）
二、WebService(SOAMANAGER)
WebService 理论上既包含SAP封装的XML格式 也包含 HTTP 对应的REST方式。
XML格式的WebService
SAP既可以提供WS给外部系统调用，也可以配置调用外部系统WS，最后都是通过T-CODE：SOAMANAGER 完成服务配置。
SAP提供WS的一般步骤：
1、创建RFC
2、发布
3、SOAMANAGER配置
案例可参考：SOAMANAGER创建WEB服务
SAP Web Service简介与配置方法
SAP调用外部系统WS的一般步骤：
1、创建Services Consumer服务
2、SOANAMAGER配置
案例可参考：SAP 调用外部系统webservice接口（SOAP-XML）
经验之谈：大部分企业在使用SAP过程中，都会逐步对接外围系统，数据交互需求会越来越多，为了避免反复调整服务，需要提前规划好接口设计。如果使用这一类WebService对外提供接口，可以使用统一的RFC负责对外提供WS, 通过JSON字符串方式传输入参、出参，具体业务功能在RFC内完成分配，并分别在子RFC函数中完成解析和业务逻辑。
HTTP对应的REST方式
知识背景：HTTP教程
[JSON教程](https://www.runoob.com/json/json-tutorial.html)
- 1
灵活： 可以传输任意对象，对象类型由Content-Type标记
客户端请求request消息包括：请求行（request line）、请求头部（header）、空行、请求数据。服务端响应response包括：状态行、消息报头、空行、响应正文
主要请求方法：
- GET 请求指定的页面信息，并返回实体主体
- HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
- POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）
- PUT 从客户端向服务器传送的数据取代指定的文档的内容
- DELETE 请求服务器删除指定的页面
- CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器
- OPTIONS 允许客户端查看服务器的性能
- TRACE 回显服务器收到的请求，主要用于测试或诊断
常用的Get & Post 的区别：
- 请求缓存：GET 会被缓存，而post不会
- 收藏书签：GET可以，而POST不能
- 保留浏览器历史记录：GET可以，而POST不能
- 用处：get常用于取回数据，post用于提交数据
- 安全性：post比get安全
开发参考：
三、RFC
直接使用RFC完成数据交互，往往需要外围服务器安装sapjco3.jar, 同时处于公司内网，可以物理直连SAP服务器。
对于这类数据交互，对SAP 端的开发来说最为方便，不过对SAP服务器来说是一个考验，因为每次调用相当于多一个进程，并发数量过多会拖累SAP服务器整体性能。
案例参考：java使用jco连接sap调用rfc函数，环境配置+代码
四、中间件（接口平台）
中间件，可以通俗的理解为接口平台，统一管理企业不同系统之间的接口。常见的中间件包括SAP PO系统、企业总线（ESB）。其中SAP PO 作为SAP的产品，对SAP兼容性相当友好，但是费用高、开发复杂等缺点也不能忽视。
可以通过下面的文章了解SAP PO的发展历史和教程案例：
【SAP PO】SAP PO 简介：XI、PI、PO的关系与区别
这里分享几个SAP PI 系统开发的案例：
SAP PI System Landscape(SLD) 系统配置
【SAP PO】SAP PO 接口配置完整教程之一RFC服务发布
【SAP PO】SAP PO消息ID的应用与接口日志查询方法
五、FTP/SFTP方案
FTP/SFTP的概念和区别壳参考：什么是FTP？什么是SFTP？FTP和SFTP的区别是什么
程序逻辑主要为：
1、FTP连接
2、打开FTP文件夹（命令）
3、打开本地文件夹（命令）
4、文件转移（命令）
5、断开FTP连接
SAP也提供Demo程序：
RSFTP001 - SAPFTP Version (Current Version one is working on)
RSFTP002 - Execute FTP Command
RSFTP003 - FTP put / get Test
RSFTP004 - FTP Copy
RSFTP005 - SAPFTP check
RSFTP006 - FTP command list
RSFTP007 - Test FB:FTP_SERVER_TO_R3 / FTP_R3_TO_SERVER
RSFTP008 - Test FB:FTP_CLIENT_TO_R3 / FTP_R3_TO_CLIENT
RSFTP009 - Test FTP put with Verify
418
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
