是否可以使用基于CDS和基于代码的OData混合服务?

2020-08-22 01:32发布

点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)我有一个中等复杂的导航树场景,其...

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


我有一个中等复杂的导航树场景,其中大多数节点可以通过 OData:Publish = true 表示,但是两个不能。 因此,现在我想吃点蛋糕,然后将CDS用于所有非CDS实体。

我将尝试绘制图片:

/Entity1/to_Entity2/to_Entity3/to_Entity4 
| |
| + ----/to_Entity5 *
| + ------/to_Entity6/to_Entity7 *

这里,除实体5和7之外的所有内容都可以通过CDS生成。 实体5和7需要代码才能返回数据。

过去,我为此创建了一个单独的GW服务。 但是在我当前的情况下,这将意味着使用一个大的$ filter进行多个查询,并且这也是一个对性能敏感的过程,因此我们希望一次通过$ expand和$ filter检索所需的所有内容。

我已经开始在DPC_EXT中对所有代码进行编码,但是想知道是否有一种方法可以节省构建每个导航/选择并仅覆盖SADL生成的服务的一部分?

顺便说一句,关于命名的一个小意见问题:

我注意到有一种将导航路径命名为" ToCustomer"," ToOrder"等的趋势(包括在The Gateway Book中),但是OData将它们格式化为to_Customer,to_Order。 我使用" to _..."来保持一致。 人们使用什么?

5条回答
jovirus
2020-08-22 02:01

嗨,安德烈 , 感谢那! 我在这里搜索了一段时间,但以某种方式错过了该博客。

但这不是我所追求的。 我认为。 希望使用OData:publish生成OData生成的视图的原因是,所有操作都是通过关联完成的,而我的印象是,这将一次进入数据库进行查询。

据我了解,我必须创建每个实体并将其指向其自己的CDS视图。 这样做本身还可以,但是我将依靠SADL框架来优化查询。 这也是一项性能至关重要的服务,性能是我们使用OData的主要原因。 您还链接到博客中的一个出色文档,其中详细介绍了如何覆盖/管理查询策略。 但是总的来说,这看起来比起构建基于代码的直接服务要更多甚至更多。

因此,我希望创建具有关联的CDS视图并使用OData生成整个实体树。 :发布。

顺便说一句,我还有《网关大全》的第二版和第三版,非常有用! :-)