取一个task的attachment header信息(包含4个attachment)都需要0.5秒时间,太慢了。
具体分析:
-
取attachment时,会先call retrieve_task_opt取task header信息,消耗0.1秒。通过之前4个节点的优化经验,这个retrieve是不需要的,此时header信息已经在memory里了,直接使用即可。
-
主要的瓶颈就在取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里摘出来的。
最后也是直接读表。
但是他们的逻辑摘得不够彻底,有一些冗余的代码。我最后写出来代码应该会比他们少。
标签:task,OData,header,API,Fiori,attachment,SAP,FM,CRM From: https://www.cnblogs.com/sap-jerry/p/17519273.html