SAP CRM 性能小技巧

缓存读取类访问，特别是在性能关键的地方，比如字段检查，这时要避免数据库查询。

尝试把所有的东西放在同一个CRM_ORDER_MAINTAIN调用当中，以避免不必要的开销。编辑多文档的时候也是一样，需要被替换为一个调用。

不要无限制地使用SAP内部API，比如，只读取需要的数据就可以，而不是整个业务。

总是把性能放在心上，特别是在实现经常被调用的代码的时候。这也包括，要事先预计好代码被调用的情况。

.在维护业务后，不要忘记使用CRM_ORDER_INITIALIZE函数，以释放缓存的内存。

  ABAP Programming and Performance Notes  要考虑到通用的性能指导方针（避免嵌套循环、数据库的反复查询）更多信息请看：ABAP Programming 和 Performance Notes。

处理行项目的时候，不要通过header guid 使用函数CRM_ORDERADM_I_READ_OB（比如行项目层级的事件回调），这对性能来说极为关键，特别是在处理大量项目的时候。
在仅仅是读取当前项目所在层级的时候，应使用函数CRM_ORDERADM_I_STRUCT_READ_OB。

阅读note 1162685 以获取有关CRM WebClient UI设置的通用信息。

阅读note 1162605 ，关于如何改善CRM WebClient UI使用中的网络性能。

阅读note 1281896 以获取有关CRM WebClient UI共享内存大小设置的信息。

不在字段检查中放置性能昂贵的代码。

为增强进行运行时性能评估（考虑到包含API调用的整个运行期间，并不是只有附加的代码会导致性能问题，问题也有可能是不适当的API调用所导致的）。

不使用生成的表扩展处理垃圾数据。

在生成扩展时，你可以考虑关闭通用的检查、实现一个专门的检查，以提高性能。

不要将行项目交叉地放到各个立即执行的回调函数中，而是应该放在文档处理的结尾处。

Always keep the concept of secondary transaction categories ("Nebenbus") in your mind. Make sure that newly registered EC function modules only run for the desired objects.

只有在真的需要某个值的时候，才应该在事件处理器回调中请求数据。

使用CRMD_TRACE来找到事件处理器回调注册（应当被放置）的正确位置。

 搜索用户指定字段的时候，考虑扩展合适的索引表。阅读note 1527039.

 要考虑到权限检查也是查询过程的一部分，并详细观察查询权限检查对数据库查询带来的影响。

尽可能降低价格处理的复杂性：考察多种情况，检查不常用的情况类型，限制价格处理的访问数量，使用合适的请求禁止某些在处理中不需要的情况。

查阅note 1269480 获取有关配置、VMC和IPC的性能问题。

查询note 1005457 获取VMC设置(Java 堆).

VMC日志只需要记录错误。

CRM IPC定价公式实现的基本准则：
- 不要进行表访问。自建表的读取不会被IPC缓存，因此应当在CRM服务端实现定价准备步骤。 I
- 在用户出口（user exit）的实现中，避免运行时错误（空指针异常）。
- 在用户出口处避免使用循环。

Actions：保持条件尽可能的简单，不管它是一个计划（scheduling condition）或者是初始条件（starting conditions）。这使得Actions条件和报表查询的速度更快。

Actions：对复杂的计划和起始条件使用各自的BAdI EVAL_SCHEDCOND_PPF 或EVAL_STARTCOND_PPF来实现，这样可以获得比使用基于工作流的条件更高的性能。基于条件的工作流通常会由一个解释器来解释并且访问数据，这会成为性能的关键。

Actions: 操作：对不同的业务场景使用不同的PPF配置。这可以让运行时变快，因为检查的条件和更少，配置的需要加载的Actions也更少。

Actions: 状态检查应当被视为计划条件建模，而不是初始条件。被计划条件填满的Actions，会在应用初始化其删除之前持续存在。在某些情况下，这可以导致不必要的PPF选择报表的长时间运行。
一个初始条件应该只是导致导致action运行的延迟，条件的其它部分必须是计划条件的一部分。

预约:在日期配置信息中移除不需要的日期，例如如果你没有使用账单计划的话

修改文档：检查是否可以无效化某个文档的修改功能。（可以通过业务类型自定义使其无效，标识是‘No Change Docunments’）