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

Question

我对使用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);

Answer 1

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

BAPI是支持RFC的功能模块，因此调用BAPI和任何其他启用RFC的功能模块之间没有技术差异。不同之处在于BAPI正式发布供客户和合作伙伴使用。它们受到支持，维护并且大部分都有详细记录 - 而不是某些内部功能模块由于某些技术原因必须支持RFC。有一套严格的规则，任何想要提供BAPI的开发人员都必须遵守这些规则，以便在整个编程接口中维护一组标准。确实，BAPI有相当冗长的参数名称和庞大的数据结构来涵盖各种特殊应用程序，但称这种“混乱”并不会留下积极的印象......

Answer 2

你的主管给了你一个非常半的答案，这让你想知道他是否理解他试图通过强迫你使用自定义（我假设）RFC来实现的目标。

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

如果您在使用BAPI时未遇到所提供的RFC功能模块的问题，则功能模块可能出现问题。或者至少它不能用于将SAP的复杂性隐藏在.NET程序中，并且不会为您提供使用标准BAPI的任何好处，至少有很好的文档和支持。