乐趣区

关于sap:SAP-CRM-Fiori-应用后台-OData-服务性能优化的一些思路

取一个 task 的 attachment header 信息(蕴含 4 个 attachment)都须要 0.5 秒工夫,太慢了。

具体分析:

  1. 取 attachment 时,会先 call retrieve_task_opt 取 task header 信息,耗费 0.1 秒。通过之前 4 个节点的优化教训,这个 retrieve 是不须要的,此时 header 信息曾经在 memory 里了,间接应用即可。
  2. 次要的瓶颈就在取 attachment header 的 cl_crm_documents=>get_info,这个办法只反对取单个 task 的 attachment, 0.26 秒。
    须要找能批量取的 API。

之前的实现里,在取 attachment 时也要取一次 application log.

在优化的版本里,我会把 attachment 读取里取 application log 这段代码删除。

老的实现里间接 call 这个 FM,传单个的 task guid 进去,输入该 task 所有的 attachment。

在这个 FM group 里查找其余是否有 GET + 复数模式的名词 如 GET_OBJECTS,READ_OBJECTS 之类的,然而这个 function group 下没有。

而后发现 single read 的 FM delegate 到了 CL_CRM_DOCUMENTS 这个 class。

然而这个 class 里也没有提供任何批量读的 API,所有办法的 input 全是 is,我须要的是 it。

查看更底层 Knowledge management 的 FM,也没有任何批量读的 API。下图这些加了 S 的,这些复数模式意思是 order->attachment 是 1:N 的关系。

那么就只有本人用 OPEN SQL 读表,造一个 multiple read 的 API 进去了。

CRM-BF-COM 这个 component 是咱们 own 的,我 2014 年的时候做过好几个 correction,所以对外面的代码比拟熟,只须要接下来 debug 回顾一下就 ok。

他们的思路和我差不多,逻辑全副是从规范的 FM 里摘出来的。

最初也是间接读表。

然而他们的逻辑摘得不够彻底,有一些冗余的代码。我最初写进去代码应该会比他们少。

退出移动版