Stefan Hagen 在博文SAP Cloud Application Studio Performance Best Practices里介绍了在 C4C 里使用 Cloud Application Studio 进行 ABSL 编程的一些性能方面的最佳实践。

文章里提纲挈领地给出了一些 guideline。这里提供一些具体的例子。

如何批量调用 BO action

不好的例子:

第一行和第四行有两个循环，然后在第二次循环里调用一个比较耗时的 ServiceRequest BO 的 item 节点上定义的标准 action FinishFulfilmentProcessing。代码的时间复杂度为 o(n²)

正确的做法：

优化的原理就是，C4C 和其他很多基于 Netweaver 的 SAP 产品一样，其 BO 的核心 service 都支持批量操作。所谓批量操作，技术上就是指这些 service 的输入参数是一个内表，而非单条数据。如果您做过 CRM 开发，可以类比 CRM_ORDER_MAINTAIN 这个 function module，其所有输入参数都是内表结构。C4C 的 BO 提供的 service 的接口定义也完全采用了这种支持批量操作的设计。

上述不好的例子，编译出来的 ABAP 代码的伪代码如下：(因为 C4C 的后台代码没有开放给 Partner 和客户，我只能提供伪代码)。可以看出尽管 BO 的 action 是执行批量操作，但是这种写法并没有发挥批量操作的作用，每次在循环内部作为输入参数的内标在第二行被清空，造成每次调用 BO action 时输入参数只有一条记录。

而正确的例子，编译后生成的伪代码为：

能清楚地看到 BO action 的执行已经放到循环外部了。

如何批量执行 BO Retrieve

当我们在 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 方法，批量读取数据。

如何批量执行 BO Create

对于基础的 Create 操作，见下列代码第 54 行，只支持基于单个节点的数据创建。

但是对于 CreateWithReference 的场景，则和第二个例子的 Retrieve 场景一样，不仅支持传入单个数据(第 56 行), 也支持传入一个集合(第 58 行)。

这两种不同的输入，会导致编译生成的 ABAP 代码分别进入 CREATE_WITH_REF_1 和 CREATE_WITH_REF_N 的执行逻辑，产生性能差异。

要获取更多 Jerry 的原创技术文章，请关注公众号"汪子熙"。