SAP 与外部系统的接口有哪些及其区别？

RFC：Remote Function Call
BAPI：Business Application Programming Interface
IDOC：Intermediate Document
EDI：Electronic Document Interchange
ALE：Application Link Enabling
UDDI：Universal Description Discovery and Integration
SOAP：Simple Object Access Protocol Web Service
WSDL：Web Service Definition Language
REST：REpresentational State Transfer
API：Application Programming Interface
FTP：File Transfer Protocol
SFTP：Secure File Transfer Protocol (or SSH File Transfer Protocol where SSH stands for Secure Shell)

作者：雨绸缪
链接：https://juejin.cn/post/7226999918119764024
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

文件

FTP

RFC

SAP 的 RFC 接口的发布与 JAVA 调用

https://blog.csdn.net/Jay_1989/article/details/51829469

Web Service

ALE

EDI

Idoc

RFC 不同设置性能以及 RFC、WebService 的性能对比

https://mp.weixin.qq.com/s/6k1gYH5ICzzvjUdZdchQnQ
首先，在确定的服务器、客户端，接口逻辑和数据量一定的前提下，RFC 的性能主要取决与两个地方，一是内表放到 Tables 还是 Export 下面，二是 RFC 的序列化协议。
一般来说，如果协议是典型序列化器(Classic Serializer)，内表放到 Export 和放到 Tables 两者之间性能差别是非常大的，在检查 RFC 函数的时候，系统也会警告提示，放在 Export 影响性能。

结论：
1、如果是用 Classic 协议，内表一定不要在 Export，否则性能极差。
2、BasXML 协议是需要转成 XML 来传输的，性能不是太好。
3、快速序列化是性能最好的，但是老系统不支持，S4 开始支持，如果可能请尽量使用此序列化协议。
4、WebService 性能不如 RFC，小数据量且调用次数较少时可以使用。
5、Restful 因为可以自定义传输数据的格式，方法不同性能差别也很大，所以就不做比较了，但是大概可以参考 WebService 的性能。

做接口 XML 和 JSON 的选择以及处理 XML 的几个函数

https://mp.weixin.qq.com/s/NfnAFYI11xtHyRz6Q8eAaw
ABAP 和外部系统做接口的时候，XML 和 JSON 是两种常用的数据传输格式，它们各自有一些优缺点，如下所述：
XML：
优点：XML 具有较好的可扩展性和灵活性，可以通过定义 DTD 或 XSD 等文档类型定义来定义和验证数据结构。XML 的标记语言具有很强的可读性，易于人们理解和处理，对于需要手动编辑的文件而言，这是一个重要的优势。
缺点：XML 语法比 JSON 复杂，需要更多的字符和标签来表示相同的信息，这导致 XML 的文件大小较大。在处理大型数据时，会带来较高的处理负载和内存占用。与 JSON 相比，XML 处理速度较慢。

JSON：
优点：JSON 比 XML 更轻量级，因此在传输和处理大量数据时更有效率。语法简单，易于阅读和编写，并且可以通过各种编程语言和平台进行处理。
缺点：JSON 缺乏 XML 的严格数据类型，无法通过 DTD 或 XSD 等文档类型定义来验证数据结构的正确性。不支持注释，这使得 JSON 文件不像 XML 那样容易被人类读取和编辑，对于需要手动编辑的文件而言，JSON 的可读性不如 XML。

实事求是的讲，就 ABAP 做的接口而言，大多都是固定的数据格式，不需要人工解读，DTD 和 XSD 在接口使用场景下更是毫无用处，所以 XML 的优点在这儿无任何卵用，反而是文件大、效率低、处理起来恶心，相比 JSON 一无是处。所以建议使用 JSON 来代替 XML。
正是因为 XML 处理起来太麻烦，所以给大家提供几个有用的函数，有了这几个函数足矣应付 90+%的 XML 格式接口场景了。

RFC 接口的数据分页传输

外部系统调用 SAP RFC 接口取数，如果数据量太大，有时候会导致外部系统无法处理，所以希望能够分批取回数据，比如一次 5 万条。

这种接口有多个写法，有的是每次调用都重新取数，然后根据对方传入的起始和结束行把数据摘出来返回去，有的是把取出来的数据存到表，每次把表里的数据发出去指定条目数，并在表里删除这部分数据，还有的是在 SQL 中就使用分页功能，正所谓小鸡不尿尿，各有各的道儿，但是这些方法都不怎么好用，有这种那种的问题。数据是不断在更新的，如果不在一个时间点把数据取完，有可能会造成数据的不一致。

利用 RFC 的特性做的分批次传输数据接口，这种方式是效率最高且数据最正确的接口方式。
前提知识：SAP 在调用函数的时候，会把整个函数组都放入内存，并且函数的全局变量会一直保持到程序结束，在函数多次调用的时候，可以通过全局变量获取上次调用的状态，外部系统调用 RFC 函数的时候如果使用了长连接（会话保持），这个特性亦是如此，也就是说，外部系统一旦开始调用，函数的上下文会一直在内存中，除非主动断掉连接。

本方案就是利用了这一特性，数据取出来后放到一个全局内表，返回指定的条目数后，在全局内表删除这部分数据，如果删除后内表不为空则说明数据还没有返回完，则设置参数 MORKZ 为 X，外部系统发现此参数为 X 后，知道还有数据，就会再一次调用，直到 MORKZ 为空。如果剩余的数据不想要了，直接断开会话即可。
如果是 SAP 产品通过 RFC 互相调用，默认就是会话保持连接，除非专门使用函数 RFC_CONNECTION_CLOSE 断开连接，
如果是 JAVA 调用 SAP，使用 JCoContext.begin 和 JCoContext.end 来使会话保持连接。具体用法请根据这两个关键字搜索。
题外话：现在很多新人做数据同步接口只知道 PI(PO)和 WebService，问及 RFC，则言技术太老已经过时了。这个观点是错误的，不论从哪点来说，RFC 都是做接口的第一选择。