如何进行C4C Cloud Application Studio做ABSL开发中性能方面的最佳实践，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
不好的例子:
第一行和第四行有两个循环，然后在第二次循环里调用一个比较耗时的ServiceRequest BO的item 节点上定义的标准action FinishFulfilmentProcessing。代码的时间复杂度为o(n2)
正确的做法：
优化的原理就是，C4C和其他很多基于Netweaver的SAP产品一样，其BO的核心service都支持批量操作。所谓批量操作，技术上就是指这些service的输入参数是一个内表，而非单条数据。如果您做过CRM开发，可以类比CRM_ORDER_MAINTAIN这个function module，其所有输入参数都是内表结构。C4C的BO提供的service的接口定义也完全采用了这种支持批量操作的设计。
上述不好的例子，编译出来的ABAP代码的伪代码如下：(因为C4C的后台代码没有开放给Partner和客户，我只能提供伪代码)。可以看出尽管BO的action是执行批量操作，但是这种写法并没有发挥批量操作的作用，每次在循环内部作为输入参数的内标在第二行被清空，造成每次调用BO action时输入参数只有一条记录。
而正确的例子，编译后生成的伪代码为：
能清楚地看到BO action的执行已经放到循环外部了。
当我们在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的执行逻辑，产生性能差异。
看完上述内容，你们掌握如何进行C4C Cloud Application Studio做ABSL开发中性能方面的最佳实践的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
