Once an order is saved, our new event callback CRM_SRVO_H_SAVE_EC will be called:

Main logic is in this tool class, method save_header:

In save_header, header and item save is done separately within a LOOP:

A new term “Global Update Buffer”

(1) I introduce a terminology “Global Update Buffer", which consists of three internal table where the corresponding insertion, update and deletion operation for CURRENT ORDER is included.

(2) The “Global update buffer” will be passed into a new update function module for Order Header.
Example, suppose I have made changes on Order description:

the GUB looks like below:

save_single_header consists of three steps

Step1 - Each convert class is responsible to merge its own part of change into GUB.

How can each convert class know whether there is any change in current transaction for its responsible component?
I use the function module CRM_ORDER_UPDATE_TABLES_DETERM to detect the change.

Step2 for those component which does not have any change in current transaction, its object buffer must also be merged into GUB.

Consider this scenario, you changes header shipping data ( set SHIPPING ) but no change in ORDERADM_H. If you don’t merge the object buffer of ORDERADM_H to GUB, the corresponding field for ORDERADM_H will be initial. So when finally update function module is called, the initial fields of ORDERADM_H will be stored into new header table.
This is done in this method:

I add a new method GET_OB in convert class’ interface. The supported component are looped, to merge its object buffer to GUB.

Step3 - call new update function module with merged GUB

Item save has exactly the same logic

Since it is possible that one order can have different item with different item object type,

Here below is an example, I have made changes on item shipping data:

And this is how GUB for item looks like:

要获取更多Jerry的原创文章，请关注公众号"汪子熙":