對于call back這類型問題的調(diào)優(yōu)

(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) 在執(zhí)行時間上如果選擇immediately以外三種類型， 就可以采用compression的策略來減少調(diào)用次數(shù)

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，只對相關(guān)類型進行處理， 如果不相干， 則退出，節(jié)約調(diào)用時間

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) -----這一點比較常見，客戶經(jīng)常調(diào)用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的原創(chuàng)文章，請關(guān)注公眾號"汪子熙":

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的来自Yang Terry的关于SAP CRM One Order事件回调机制的分享的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。