Fork me on GitHub

SAP CRM 性能小技巧

导言

本页面打算收集SAP CRM实施中可以用于避免性能问题的注意事项,重要的事项会由图标标识。

如果你有其他的技巧想要说出来,别犹豫!

性能注意事项

通用

(plus)

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

 

(plus)

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

 

(minus)

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

 

(plus)

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

 

(minus)

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

 

(plus)

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

 

(minus)

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

 

系统设置

(plus)

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


(plus)

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

 

(plus)

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

 

扩展性

(minus)

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


(plus)

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

 

(minus)

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

 

(plus)

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

 

事件处理器

(minus)

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


(plus)

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.

 

(plus)

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

 

(plus)

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

 

报表框架

(plus)

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

 

(plus)

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

 

 

定价, VMC, 产品配置

(plus)

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


(plus)

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

 

(plus)

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

 

(plus)

VMC日志只需要记录错误。

 

(minus)

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

 

CRM功能自定义

(plus)

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


(plus)

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


(plus)

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

 

(plus)

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

 

(plus)

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

 

(plus)

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

 

关于Actions的更多信息,请参考Action profiles in SAP CRM

Web Client UI 框架

 

(minus)

只把需要的视图/assignment blocks放置在UI上面。如果视图/assignment blocks不是经常需要的,使用懒加载模式。


(minus)

不在组件控制器中的DO_PREPARE_OUTPUT方法中使用性能昂贵的代码,因为在每次往返过程中,它都要被处理。


(minus)

不要只是为了防止读取到缓存中未更新的数据而绕过BOL缓存。要寻找数据不一致的原因,并且修改其中的问题。

 

(minus)

不使用复杂的绑定(更新一个节点,将引发多个其它节点的更新,以及/或者一串其它节点)。

 

(plus)

注册事件时,不要忘记解除注册(否则,事件处理器将仍然被调用,甚至在不再需要的情况下)。

 

(minus)

在UI组件中,不使用ALL组件集。否则会消耗不必要的内存。

 

 

 

本文链接:http://www.cnblogs.com/hhelibeb/p/6103685.html

英文原文:Performance Tips and Tricks

 

posted @ 2016-12-30 11:43  氢氦  阅读(1859)  评论(0编辑  收藏  举报