SAP RFC和BAPI有啥区别!

Posted 2023-04-20

BAPI和RFC不是同一个层次上概念，不能说从字面上看到BAPI函数和RFC函数就认为他们之间有必然的联系和区别。打个比如，问一个问题：人可以分为哪几类，答曰：男人和老人，呵~~，大家都知道，男人是基于性别来说的，老人是基于年龄的。BAPI是SAP提供的基于业务对象的函数，关键是它们处理的对象是R/3的业务相关business object），比如单据类销售订单，组织：公司等，它们是一系列实体。RFC则是一种系统间通讯的方式（Remote Funciton Call），一个男人可能同时也是一个老人，一个BAPI函数往往能是一个RFC函数（我不知道是不是所有BAPI都可以有基于RFC技术来调用，但是至少也可以说大部分吧，VB里面用BAPI，就是因为这个BAPI函数具有RFC的特性）

BAPI是个SAP里一个很好的思想，把业务对象都对象化了。刚学ABAP/4时，并不能理解SAP所说”ABAP/ 4”中的‘4’，而觉得它更像是一种脚本语言，顶多也就是和C一样，但是自从我接触了BAPI之后，我才体会到SAP说ABAP是种4G语言的确不虚。 当在外部调用BAPI的时候，比如VB，就可以把SAP里的诸如订单，物料，员工，工厂等作为一个对象来处理，而且这种处理又是那么的简单，可能只要几句代码就可以了，最关键就是：1.收集BAPI函数所要的数据,也就是BAPI输入参数，VB也好，SAP本身的 Screen也好，甚至Web页面也好，只不过是一个数据收集器！（要作一些必要的数据检查保证它们是正确的，不过即使不正确也没有关系，BAPI会返回错误信息） 收集完成了，就送给BAPI作为参数，剩下的事都是BAPI给做了，你就不用管了！ 2.接收BAPI返回的信息，也就是BAPI输出参数，并把它们“翻译”成恰当的形式给表达给用户 参考技术A 关于RFC和BAPI： SAP R/3的接口方式主要有RFC(Romote Function Call，远程函数调用)、IDOC、BAPI三种,BAPI实际上也是RFC函数，它处理一组业务。使用Tcode：BAPI/BAPIW在SAP系统中可查看到各模块的BAPI函数。 RFC版本： sRFC（ synchronous RFC）是RFC的第一个版本，它要求连接的双方是同步的工作方式，即都是在可用状态才能够实现成功调用。 aRFC（asynchronous RFC）这种RFC可以实现异步的RFC调用方式，它可以进行多个并发调用，并且不要求被调用系统的可用状态。发出调用系统会一直尝试直到获得被调用系统的应答。它通常用于当你需要提高系统并行调用多个RFC的效率，相对于强制等待程序的结果，它的效率更高。 tRFC（transactional RFC）是对aRFC进行相关技术改进后的一个RFC版本，其于ARFC相同点是实现异步调用，其优点是可以将多个调用进行LUW分组处理，并只执行一次运行。现在aRFC基本上已经停用。 qRFC（queue(d) RFC）是tRFC的一个增强版本，它保证了所传输数据的处理次序。 pRFC（Parallel RFC）是一种特殊的RFC，它是aRFC的一种扩展类型。因为它改善了系统的性能，在执行大量的aRFC时。SAP 使用它在MRP里面提高速度。但是它只能执行在同一个系统和同一个client里。 RFC不但是一种函数,更是一种数据通信协议,类TCP/IP 参考技术B 完全是两回事 rfc是远程功能调用，是fm设置成可以系统外调用。 bapi是BAPI(business application programming interface)是面向对象程序设计方法中的一组程序接口。它允许程序员通过SAP将第三方软件整合成R/3专有产品。为了完成一些特殊的商业任SAP RFC和BAPI有什么区别!本回答被提问者采纳

ISO 8601 和 RFC 3339 日期格式有啥区别？

【中文标题】ISO 8601 和 RFC 3339 日期格式有啥区别？

【英文标题】：What's the difference between ISO 8601 and RFC 3339 Date Formats?ISO 8601 和 RFC 3339 日期格式有什么区别？

【发布时间】：2010-10-06 01:18:08

【问题描述】：

ISO 8601 和RFC 3339 似乎是网络上常见的两种格式。我应该使用其中一个吗？一个只是扩展吗？我真的需要关心那么糟糕吗？

【问题讨论】：

我已将 RFC 的链接从 ietf.org/rfc/rfc3339.txt 更改为 HTML 版本 tools.ietf.org/html/rfc3339。链接到 RFC 时，您应该始终链接到位于 tools.ietf.org/html 的 HTML 版本。由于部分链接，它们不仅更易于导航，而且重要的是，它们在顶部列出了任何已更新或废弃您正在阅读的 RFC 的 RFC。人们不知不觉地在 Stack Overflow 上一直引用过时的 RFC，我将继续重复这个建议，直到问题消失。 （为免生疑问，this RFC 并未过时。）

这篇文章很好地解释了它们之间的区别：ijmacd.github.io/rfc3339-iso8601

ijmacd.github.io/rfc3339-iso8601

【参考方案1】：

您不必太在意。就其本身而言，RFC 3339 是一组源自 ISO 8601 的标准。尽管存在相当多的细微差别，它们都在 RFC 3339 中进行了概述。我可以在这里全部介绍，但您可能会做得更好如果您担心，请自己阅读文档：

https://www.rfc-editor.org/rfc/rfc3339

【参考方案2】：

一个只是扩展吗？

差不多，是的 - RFC 3339 被列为 ISO 8601 的配置文件。最值得注意的是 RFC 3339 指定了日期和时间的完整表示（只有小数秒是可选的）。 RFC 也有一些细微的差别。例如，不允许截断只有两位数字的年份表示 - RFC 3339 要求 4 位年份，而 RFC 仅允许将句点字符用作小数秒的小数点。 RFC 还允许将“T”替换为空格（或其他字符），而标准只允许省略它（并且仅当使用该表示的各方达成一致时）。

我不会太担心两者之间的差异，但是如果您的用例遇到它们的可能性不大，那么值得您看一看：

RFC 3339 Wikipedia entry on ISO 8601

【讨论】：

对不起 Java Guy，但这并不完全正确。您引用的附录仅供参考，限制是为了保持语法更简单。 5.6 节末尾的注释明确指出，为了便于阅读，可以使用空格，指的是前面提到的 5.2 节主题的可读性。引用：“为了可读性，使用这种语法的应用程序可以选择指定一个完整的日期和完整的时间，由（比如说）一个空格字符分隔。”

@JavaGuy 您链接到的附录甚至都没有讨论 RFC 3339 语法 - 它的标题是 ISO 8601 Collected ABNF 并试图正式描述语法ISO 8601 使用 ABNF。它所说的任何内容都不应被视为有关 RFC 3339 日期时间语法的证据。

FWIW：已经在 coreutils 列表中讨论过：lists.gnu.org/archive/html/bug-coreutils/2006-05/msg00019.html

“RFC 3339 要求日期和时间的完整表示” - 这是不正确的。请考虑编辑答案。为了完全确定，我给其中一位 RFC 作者发了电子邮件。回复包括“我认为如果你只想要一个日期戳，引用 [RFC3339] 'full-date' 语法产生是完全公平的游戏。......也许可能需要一个勘误表”此外，JSON Schema v7 明确支持 RFC 3339 个仅限日期（全日制）和仅限时间（全日制）的配置文件。 json-schema.org/draft-07/json-schema-release-notes.html.

我是贾斯汀（之前的评论）联系的作者（尽管不负责那里的大部分繁重工作）。我确认他的评论。一般来说，我会建议像 RFC3339 specify 之类的规范文档，而不是 require - 它是使用的上下文决定什么是 require。只要清楚意图是什么，那么引用特定的语法产生就可以了。 （这与 RFC3339 本身在选择性引用 ISO8601 时所做的并没有真正的不同。）另请参阅section 5.6 中的注释。

【参考方案3】：

RFC 3339 主要是 ISO 8601 的配置文件，但实际上与从 RFC 2822 借用的“-00:00”时区规范不一致。***文章中对此进行了描述。

【参考方案4】：

ISO 8601 和 RFC 3339 之间有很多不同之处。这里有一些示例可以让您了解一下：

2020-12-09T16:09:53+00:00 是符合这两个标准的日期时间值。

2020-12-09 16:09:53+00:00 使用空格分隔日期和时间。这是 RFC 3339 允许的，但 ISO 8601 不允许这样做。

2020-12-09T16:09:53-00:00 在时间偏移中指定负零。这是 RFC 3339 允许的，但 ISO 8601 不允许这样做。

20201209T160953Z 省略连字符和冒号。这在 ISO 8601 中是允许的，但在 RFC 3339 中是不允许的。

ISO 8601 允许诸如 2020-344 之类的序号日期，它代表 2020 年的第 344 天。RFC 3339 不允许这样做。

对于您的问题：

一个只是扩展吗？

没有。如上所示，每个标准都支持其他标准不支持的语法变体。因此，一种语法不是另一种语法的超集或扩展。

我应该使用一个而不是另一个吗？

当然，这取决于您的情况。一个安全的通用策略是生成对两种标准都有效的日期时间字符串。

另一个好的通用策略是使用现有的标准库来解析/格式化日期时间字符串，而不是编写自定义实现，除非您正在处理真正自定义的场景。

我真的需要那么关心吗？

好吧，这取决于你。大多数处理日期时间字符串的普通开发人员应该有较高的了解，但不需要深入细节。

【参考方案5】：

实际访问 ISO 规范似乎很困难和/或昂贵。这就是为什么我们会看到许多指向***页面的链接。

仅出于这个原因，我更喜欢 RFC3339：您可以直接访问主要来源。