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