取一个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里摘出来的。
最后也是直接读表。
但是他们的逻辑摘得不够彻底，有一些冗余的代码。我最后写出来代码应该会比他们少。