技术文章
建议在OData $batch查询的后续请求中引用请求结果
我参加过比利时SAP技术之夜-第一版29日。2020年4月安德烈·菲舍尔介绍新事物SAP HANA 2.0开发者版上的SAP ABAP平台1909.在那之后,我就各种技术主题进行了很好的讨论。在那里,我就我想在这里更详细地描述的想法征求了反馈。
我建议使用一个增强SAP Gateway的方法,这样它就可以在OData $batch查询的后续请求中引用请求的结果。换句话说,$batch请求中第一个查询的结果应该作为筛选器提供给下一个请求。
并排扩展的约束
如在结合Power automation, Microsoft Teams Approvals和SAP云应用程序编程模型(CAP)应用程序我参与了SAP S/4HANA Side-by-Side扩展产品的开发。该产品应该在SAP S/4HANA on Premise系统上不安装ABAP AddOn的情况下实现。因此,我们需要约束自己只使用发布的api.
另一个限制是SAP BTP Cloud Foundry环境和SAP S/4HANA on Premise系统之间的延迟。甚至一个简单的ping从SAP业务应用程序工作室到后端,我已经测量了命令:
时间卷曲http://s4h.https.devstudio:9999/sap/public/ping
耗时0.211秒。所以,当我需要多个请求到一个API,以获得预期的结果,这加起来很快。
场景
让我们以下面的示例场景为例:
该应用程序应该允许用户筛选国家,城市和销售组织的客户。结果应该显示在一个表中。为此,我们找到APIAPI_BUSINESS_PARTNER.如果你想自己尝试,你必须使用SAP S/4HANA云API.只有在那里连接了一个沙盒。当用户现在搜索Country = DE和SalesOrganization = 1010我们必须发出以下请求:
- 我们将位于德国的BusinessPartners请求称为:/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartnerAddress?$filter=国家eq ' DE '& $选择= BusinessPartner
- 对于分配到销售组织1010的客户,我们使用:/ sap /含油率/ odata / sap / API_BUSINESS_PARTNER / A_CustomerSalesArea吗?$filter=SalesOrganization eq ' 1010 ' &$select=客户
- 现在我们必须找到与列表2中的Customers匹配的Business Partner(假设Customer ID和Business Partner ID相同)
- 然后我们可以阅读所有的细节:/ sap /含油率/ odata / sap / API_BUSINESS_PARTNER / A_BusinessPartner吗?$inlinecount=allpages&$filter=BusinessPartner eq ' 9980000043 '或BusinessPartner eq ' 9980000043 ' &$expand=to_BusinessPartnerAddress,to_Customer
超过一秒就过去了。你可能会问为什么不用这样的查询:
/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner ?$expand=to_BusinessPartnerAddress,to_Customer,to_Customer/to_CustomerSalesArea &$filter=to_BusinessPartnerAddress/Country eq 'DE' and to_Customer/to_CustomerSalesArea/SalesOrganization eq '1010'
因为对于该查询,您将收到错误消息:
memberaccess操作符的左手表达式有错误的基数(不允许有很多基数)
更新(2020-05-03)
我猜这是一个OData 2.0 API?4.0 api(和UI5 v4模型)应该支持“ANY”/“ALL”过滤操作符来基于依赖的子项进行过滤。换句话说,我认为你的第一种方法可能是更好的增强方法,因为它已经在4.0中成为标准。
我补充以下建议:
由于发布的用于S/4HANA(云)的OData V2 API不会迁移到OData V4,我建议增强SAP网关以支持" ANY " / " ALL "过滤操作符.所以请求看起来是这样的:
/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner ?$inlinecount=allpages &$expand=to_BusinessPartnerAddress,to_Customer,to_Customer/to_CustomerSalesArea &$filter=to_BusinessPartnerAddress/any(d:d/Country eq 'DE') and to_Customer/to_CustomerSalesArea/any(d:d/SalesOrganization eq '1010')
可能的解决方案
OData允许将请求合并到美元的批处理请求.我的建议类似于Insert请求中已经实现的功能。在规范中引用变更集中的新实体您可以找到步骤如何定义Content-ID头的描述。该ID可以在后续步骤中使用,例如$1。
以下是我的建议,在一次通话中获得3次单独通话之前所需的数据:
POST /sap/opu/odata/sap/API_BUSINESS_PARTNER/$batch HTTP/1.1主机:主机Content-Type: multipart/mixed;——batch_36522ad7-fc75-4b56-8c71-56071383e77b Content-Type: application/http Content-Transfer-Encoding:binary Content-ID: 1 GET A_BusinessPartnerAddress?$filter=Country eq 'DE'&$select=BusinessPartner HTTP/1.1 Host: Host——batch_36522ad7-fc75-4b56-8c71-56071383e77b Content-Type: application/ HTTP Content-Transfer-Encoding:binary Content-ID: 2 GET A_CustomerSalesArea?$filter=SalesOrganization eq '1010' and Customer in ($1)&$select=Customer HTTP/1.1 Host: Host——batch_36522ad7-fc75-4b56-8c71-56071383e77b Content-Type: application/ HTTP Content-Transfer-Encoding:binary Content-ID: 3 GET A_BusinessPartner?$inlinecount=allpages&$filter=BusinessPartner in ($2)&$expand=to_BusinessPartnerAddress,to_Customer HTTP/1.1主机:主机——batch_36522ad7-fc75-4b56-8c71-56071383e77b——
另一个很好的附加功能是指定批处理请求的哪些响应应该实际返回给客户端。
期待您的建议。
Hi Gregor -完全同意,因为这也将帮助我们“保持核心清洁”,允许将内部紧密耦合的选择替换为SbS -从而使更多的自定义报告程序作为相关的候选迁移到SbS。新万博买球
谢谢和问候
斯
一个有趣的提议——我可以看到这对我们的OData服务集成非常有用。说实话,我甚至不知道插入中的Content-ID语法——我们一直在处理类似链式异步API调用的情况,就像你在当前的GET设置中展示的那样。
我不太明白的一件事是“in”操作符在这里是如何工作的?这是否假设所有相关实体都有一个密钥?还是只对关联有效?
嗨,马修,
谢谢你的评论。我希望任何可以使用运算符。在我建议使用前一个请求的结果时,我希望使用单个键。具有多个键的实体是另一个挑战。
致以最亲切的问候
格雷戈尔
你好,格雷戈尔,
增加对您所提议的支持需要对
a)微软拥有的OData V2协议,该协议在过去9年没有更改过。
b) SAP Gateway OData V2框架(如果SAP决定添加新的SAP专有更改其OData V2框架实现)
b) SAP S/4 HANA提供的所有现有OData V2 API,因为这样的功能不会通过简单地更改OData V2框架来“开箱即用”。
如果API支持OData V4(任何和所有),您的需求将得到支持。
目前SAP S/4 HANA开发的指导如下。
因此,如果需要为现有的OData V2 API提供OData V4支持,则必须针对相应的产品组进行处理。
对于现有API的反馈或发布新API的需求,您可以使用客户影响流程:
SAP创新管理
现有API之上的任何附加功能都将通过使用SAP Graph得到支持。
SAP图
SAP Graph是一个新的易于使用的API,用于SAP的智能企业数据。它是一个内测版本。但是,beta阶段的注册目前已经关闭,但是你可以报名查看时事通讯,并继续关注来自SAP Graph的更多令人兴奋的新闻!
最好的问候,
安德烈