对于call back这类型问题的调优
(1) 检查客户注册的FM在event上是否合理
For each change of a flat 1Order object there is an AFTER_CREATE (first time) or AFTER_CHANGE event raised. For many purposes it is not important to distinguish between AFTER_CREATE and AFTER_CHANGE when registering a callback for a flat object. But you need to register for both if you want to cover all changes. For complex objects there is usually a AFTER_CREATE, AFTER_CHANGE and AFTER_DELETE event. The event does not refer to the objects as a whole but to a single record of the object. For example if a new partner is added to the document an after create event is raised for that partner. As part of an AFTER_CHANGE event the before and after values (also referred to as old and new values) of the object are published. For an AFTER_CREATE event only the new value is meaningful whereas for an AFTER_DELETE event only the old value is meaningful. The old/new values allow the optimization of the callback logic by exactly checking which fields have changed (see also compression logic). The AFTER_DELETE event is also used to delete a document in the buffer (event ORDER->AFTER_DELETE) or a document item (ORDERADM_I->AFTER_DELETE).
(2) 在执行时间上如果选择immediately以外三种类型， 就可以采用compression的策略来减少调用次数
A very important field for the performance tuning of the event handler is “Call Callback” which allows to implement a “compression” logic. Compression allows you to control how often the callback is called which can be very important in terms of performance.
Compression means that multiple events result in fewer (limiting case: one) callback execution. Compression can only work if the execution time is not immediately.
(3) 在callback里做filter，只对相关类型进行处理， 如果不相干， 则退出，节约调用时间
Another very important guideline to keep the performance impact of your callbacks minimal is that before running any kind of logic inside the callback function module a filtering should be done whether the event is relevant. One way to do this is to use the event information passed to the callback function through the event handler. In particular you can do an old/new comparison on field level using the old/new structures for the event. Or if the event is only relevant for a certain transaction type then you should read the current transaction type using the header guid passed to the callback function and exit the callback if it is not relevant
General rules to follow when writing event handler callbacks:
(1) Never use the ABAP statements COMMIT or COMMIT WORK within a callback.
(2) Never trigger database updates inside a callback (exception: execution time save)
(3) Never call CRM_ORDER_MAINTAIN inside a callback (exception: execution time before_save). Instead call the appropriate object maintain function module to change data in the buffer (eg. CRM_ORDERADM_H_MAINTAIN_OW) -----这一点比较常见，客户经常调用general 的CRM_OREDER_MAINTAIN
最后利用好工具来检查
For completeness it shall be mentioned that there is an event trace available which can be activated with user parameter CRM_EVENT_TRACE. The result can be displayed using report CRM_EVENT_TRACE. You may find it useful to experiment but don’t feel discouraged if you find the rather huge output confusing. It is more important to focus on the concepts and to understand the events you care about.
要获取更多Jerry的原创文章，请关注公众号"汪子熙":
