SAP环境中的OData与BAPI

无论我们能用OData做什么，我们都能用BAPI做，对吗

那么，与BAPI相比，OData的主要特点是什么

请让我知道你的观点

SAP专有 基于RFC，SAP专有协议 固定输入结构无URL，查询参数灵活 固定的输出结构、表，但不是每个表的动态数量 手册文档仅为人类描述服务的结构 结论：有利于SAP系统之间的连接 奥达塔

开放标准 基于REST，web事实上的应用程序集成标准协议 灵活的查询语言筛选、排序、展开、关联、搜索 灵活输出实体、实体集、扩展实体 元数据文档以机器可读的格式解释服务结构 结论：适用于将SAP系统连接到SAPUI5和类似UIs 与BAPI相比，OData的主要优势在于灵活性、开放标准和机器可读性。这可能是以速度为代价的

这个比较有点不恰当。虽然BAPI是为了连接服务器而发明的，但OData更适合于将服务器连接到客户端。尽管OData的发明者可能已经考虑了服务器连接，但纯REST已经成为连接这一级别的事实标准。因此，将BAPI与REST以及相关标准（如web服务）进行比较会更干净

---

可以通过BAPI接口模拟OData：输入URL查询字符串，输出JSON结果字符串。因此，你可以得出结论，两者在权力方面是同等的。但是，底层协议是不同的，与SAP专有的RFC协议相比，系统更可能识别REST下的HTTP协议。

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

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

---

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

目前，如果您从SAP浏览S/4 HANA云的API中心，您将看到SAP正朝着OData和SOAP等开放协议的方向发展。

---

您可以轻松地将BAPI包装为oData服务或SOAP服务。

将第一个集成概念称为RFC可能更准确。BAPI已启用RFC，但与业务对象绑定。集成的定制开发使用RFC，但我认识的几乎没有人会费心创建真正的BAPI。您可能想指出，还有其他集成选项ABAP Web服务、自定义HTTP调用。。。除了这两个。