SAP环境下的OData与BAPI

Question

无论我们如何使用OData，我们都可以使用BAPI，对吗？

那么，与BAPI相比，OData最主要的事情是什么？

请告诉我你的看法

Answer 1

巴比

• SAP-专有
• 基于RFC，一个SAP专有协议。
• 固定的输入结构(没有具有灵活查询参数的URL )
• 固定输出结构(结构、表，但不是每个结构的动态数)
• 手动文档仅描述服务的人类结构
• 结论:有利于SAP系统之间的连接。

OData

• 开放标准
• 基于REST，web事实上的应用程序集成标准协议
• 灵活的查询语言(筛选、排序、展开、关联、搜索)
• 灵活产出(实体、实体集、扩展实体)
• 元数据文档以机器可读的格式解释服务结构。
• 结论:有利于将SAP系统与SAPUI5和类似的UI连接起来。

OData相对于BAPI的主要优点是灵活性、开放标准和机器可读性。这可能是以速度为代价的。

这一比较略有不同。BAPI是用来连接服务器的，而OData则是用来连接服务器到客户端的。尽管OData的发明者可能已经想到了服务器连接，但是纯粹的REST已经成为连接这个级别的事实上的标准。因此，比较BAPI与REST，或者可能是相关的标准，比如web服务，将会更加清晰。

可以通过BAPI接口来模拟OData：(URL ) string in，(JSON ) string out。因此，你可以得出结论，这两者在权力方面是相等的。然而，底层协议是不同的，与SAP的专有RFC协议相比，系统更有可能识别REST下的HTTP协议。

Answer 2

从功能的角度来看，BAPI可以比OData数据源更具体、更适合您的用例。但是OData是一个标准，这意味着您在客户端开发过程中可以免费获得很多工具，例如OData js客户机库。您可以使用可以使用OData数据源的框架，而不是针对您制作或提供的单个BAPI进行编程。

客户端开发人员可能不熟悉他们必须从其中获取数据的每个子系统的复杂之处。您拥有需要处理的业务知识和必须满足的技术依赖。您可以公开一组标准的BAPI，以达到类似的目的(如果您忽略了所有不是SAP的内容)，但是OData就是这样。至少在数据源之间共享技术部分的标准接口。

您是否看到OData中的值取决于您来自何处。如果您的需求是开发一个单一的、高度集中的客户端应用程序，该应用程序可以从SAP系统读取和写入数据，那么BAPI很可能是最简单的选择。但是，如果您必须设置某种CEO仪表板，该仪表板集成了多个数据源，并显示了各种业务统计数据，如销售数据、生产中断、现金流以及您可能想出的其他任何东西，那么您将更容易地将OData数据源集成到可能用于安装此类仪表板的标准应用程序中。

Answer 3

到目前为止，如果您从SAP从https://api.sap.com/package/SAPS4HANACloud?section=Artifacts浏览API，您将看到SAP正朝着开放协议(如oData和SOAP )的方向前进。您可以轻松地将BAPI包装为oData Serivce或SOAP服务。