使用直接 Rfc 调用而不是 BAPI 是否有优势？答案

【问题标题】：Is there an advantage of using direct Rfc calls instead of the BAPI?使用直接 Rfc 调用而不是 BAPI 是否有优势？
【发布时间】：2013-04-24 20:17:12
【问题描述】：

我对使用 SAP 不是很熟悉，但我目前的任务是利用 Rfc 调用通过我正在处理的 c# 项目在 SAP 中创建采购订单。

使用直接 Rfc 调用而不是 BAPI 有什么好处吗？我问过我的主管，他的理由是“避免未知/不必要的混乱”。

我们的旧程序使用 BAPI。我发现在完成这项任务时，我正在追逐元数据并解决使用/获取所需结构的问题。

一切都在进行中，但我就是不理解坚持使用 Rfc 代替 BAPI。

编辑以澄清我糟糕的术语：我们目前使用一个包装器，然后为我们调用 BAPI。我的任务是不使用包装器，而是使用与 BAPI 相同的 Rfc 调用。

例子：

IRfcFunction poCreateFunction = _dest.Repository.CreateFunction("BAPI_PO_CREATE1");
IRfcStructure poHeader = poCreateFunction.GetStructure("POHEADER");
poCreateFunction.SetValue("POHEADER", poHeader);
...
poCreateFunction.Invoke(_dest);

【问题讨论】：

标签： sap saprfc bapi sap-dotnet-connector

【解决方案1】：

一个技术上正确但有点无益的答案是?SYNTAX ERROR，然后是一个巨大的蓝色闪烁光标。

BAPI 是启用 RFC 的功能模块，因此调用 BAPI 和任何其他启用 RFC 的功能模块之间没有技术差异。不同之处在于 BAPI 是正式发布的，供客户和合作伙伴使用。它们得到支持、维护并且大部分都有很好的文档记录——与某些内部功能模块相反，由于某些技术原因必须启用 RFC。任何想要提供 BAPI 的开发人员都必须遵守一组严格的规则，以便在整个编程接口中维护一组特定的标准。诚然，BAPI 具有相当长的参数名称和庞大的数据结构来涵盖各种特殊应用，但称其为“一团糟”并没有给人留下积极的印象……

【讨论】：

我不认为他认为这真的是一团糟，但更多的是一个冷淡的答案。正如我对 Esti 的回复，我们目前使用了一个非常适合我们的包装器，但现在我正在尝试使用 IRfcFunctions 和 IRfcStructures 重做所有事情。

【解决方案2】：

你的主管给了你一个非常不靠谱的答案，这让你怀疑他是否理解他通过强迫你使用自定义（我假设）RFC 来实现的目标。

在 .NET 集成项目中，我（作为 ABAP 程序员）通常会提供包装 RFC 模块来隐藏 BAPI 的一些复杂性，或者因为 .NET 端可能没有 BAPI 所需的所有信息。这通常会导致界面更简单，但功能有限。但最终只是将 BAPI 调用从 .NET 移到了 ABAP 堆栈中。

如果您在使用 BAPI 时没有出现所提供的 RFC 功能模块问题，则可能是功能模块有问题。或者至少，它并没有起到将 SAP 的复杂性从 .NET 程序中隐藏起来的目的，并且与使用标准 BAPI 相比没有任何好处，至少有很好的文档记录和支持。

【讨论】：

是的，我们当前的程序使用了一个包装函数，所以我们只需要传入我们需要/使用的参数。它易于使用，对我们来说效果很好。我的术语可能是错误的。我没有创建任何新的 Rfc，而是利用 IRfcFunction 和它需要的所有 IRfcStructures。示例：IRfcFunction poCreateFunction = _dest.Repository.CreateFunction("BAPI_PO_CREATE1");
@Ento 看起来在那种情况下我并没有真正回答你的问题。我搜索了 IRfFunction，但没有 .NET 方面的专业知识来告诉您使用 IRfcFunction 是否有好处。我所知道的只是在我从事的项目中。NET 程序员能够通过连接器拉入 RFC 的接口，并且不需要在他们这边做太多额外的设置。当我再次有空闲时间时，这是我要考虑的事情。（我想我在 2025 年有一些休假时间 :)）。
哈哈没关系。感谢您考虑并回复。这对我来说真的只是一个奇怪的问题。不过，这是我的任务，而且我现在大部分时间都在工作，所以我继续。谢谢。 :)