- 在 SAP CRM Fiori 应用上给 Opportunity
- 从SAP客户主数据里直接创建商机(Opportunity)
- 如何使用代码创建和读取 SAP CRM 订单的 Text 数据
- SAP Fiori 的附件处理(Attachment handl
- SAP CRM Fiori 应用 My Opportunity
- SAP UI5和Angularjs事件处理机制的实现比较
- 如何使用 SEGW 的 redefine 功能对 SAP 标准
- 如何在SAP gateway系统配置路由到后台系统的OData服
- 点击 Fiori Launchpad tile 后报错的处理方法
- SAP Fiori OData gateway 和后台 ABAP
取一个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里摘出来的。
最后也是直接读表。
但是他们的逻辑摘得不够彻底，有一些冗余的代码。我最后写出来代码应该会比他们少。
网友评论