Stefan Hagen在博文SAP Cloud Application Studio Performance Best Practices里介绍了在C4C里使用Cloud Application Studio进行ABSL编程的一些性能方面的最佳实践。编程
文章里提纲挈领地给出了一些guideline。这里提供一些具体的例子。app
很差的例子:ide
第一行和第四行有两个循环,而后在第二次循环里调用一个比较耗时的ServiceRequest BO的item 节点上定义的标准action FinishFulfilmentProcessing。代码的时间复杂度为o(n<sup>2</sup>)性能
正确的作法:优化
优化的原理就是,C4C和其余不少基于Netweaver的SAP产品同样,其BO的核心service都支持批量操做。所谓批量操做,技术上就是指这些service的输入参数是一个内表,而非单条数据。若是您作过CRM开发,能够类比CRM_ORDER_MAINTAIN这个function module,其全部输入参数都是内表结构。C4C的BO提供的service的接口定义也彻底采用了这种支持批量操做的设计。ui
上述很差的例子,编译出来的ABAP代码的伪代码以下:(由于C4C的后台代码没有开放给Partner和客户,我只能提供伪代码)。能够看出尽管BO的action是执行批量操做,可是这种写法并无发挥批量操做的做用,每次在循环内部做为输入参数的内标在第二行被清空,形成每次调用BO action时输入参数只有一条记录。设计
而正确的例子,编译后生成的伪代码为:orm
能清楚地看到BO action的执行已经放到循环外部了。blog
当咱们在Cloud Studio里经过代码自动完成功能试图调用BO的Retrieve方法时,IDE会提示咱们Retrieve方法有三个重载(Overload), 这代表Retrieve可以支持传入不一样的参数。接口
正确和不建议的作法分别见下图蓝色和红色代码。能够看到蓝色代码retrieve接受的输入参数是一个集合, 包含了两个ID为3和4的元素,使得41行的调用可以一次便可返回2个ServiceRequest的数据。
line 43编译后生成的ABAP代码的伪代码:
line 41编译后生成的ABAP代码的伪代码:
经过比较能发现若是传入retrieve的参数是一个ID的集合,那么编译生成的ABAP代码会调用一个接口为内表的retrieve方法,批量读取数据。
对于基础的Create操做,见下列代码第54行,只支持基于单个节点的数据建立。
可是对于CreateWithReference的场景,则和第二个例子的Retrieve场景同样,不只支持传入单个数据(第56行), 也支持传入一个集合(第58行)。
这两种不一样的输入,会致使编译生成的ABAP代码分别进入CREATE_WITH_REF_1和CREATE_WITH_REF_N的执行逻辑,产生性能差别。
要获取更多Jerry的原创技术文章,请关注公众号"汪子熙"或者扫描下面二维码: