共计 875 个字符，预计需要花费 3 分钟才能阅读完成。
取一个 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 里摘出来的。
最初也是间接读表。
然而他们的逻辑摘得不够彻底，有一些冗余的代码。我最初写进去代码应该会比他们少。