标题：SAP CRM One Order函数CRM_FILL_OW的设计原理
There are totally 60 function modules in One order with naming convention CRM_FILL_OW:
They are NOT used in read scenario but in modify scenario. For example once you change the Closing Date of a given opportunity in WebUI ( from 2017-02-15 to 2017-02-16 )
The function module for Opportunity header extension, CRM_ORDERADM_H_FILL_OW, is called with the following callstack:
As its name FILL_OW indicates, it is responsible to FILL the latest input by consumer into so called object work area( OW ) for later use.
In order to make the research life easier I write the following report to trigger this FILL_OW function module call from backend:
It’s very clear now the logic of this FILL_OW consists of four main parts:
(1) field check done in FM CRM_OPPORT_H_FIELDCHECK_FC
This check function module further calls two function modules:
a. CRM_ORDER_GENERAL_CHECKS_FC
This check could be switched off by function module CRM_ORDER_SET_ACTIVE_OW.
A customer exit if_ex_crm_order_fieldcheck and a new BAdI definition crm_order_fieldcheck_new is allowed for customer to implement their own check logic and called within this check function module.
b. CRM_FIELDCHECK_CALL
This FM will call dedicated check function module for a given field registered in system table CRMC_FIELDCHECK:
(2) CRM_OPPORT_H_READ_OB
The logic of this FM is already explained in blog: Buffer logic in One Order header extension Read.
(3) CRM_ORDER_INPUT_DATA
This FM is responsible to move the latest value entered by consumer ( is_opport_h_com in line 65 ) to object work area ( postfix WRK in variable ls_opport_h_wrk in line 68 ). You can observe in the debugger that before this FM is executed, object work area still contains the old value 2017-02-15 read from FM CRM_OPPORT_H_READ_OB in step 2.
Inside this FM there is a check to avoid the field is being changed unnecessarily ( specified new value = old value ) or by mistake ( the field validation fails ).
This is a screenshot how ls_opport_h_wrk looks like after this third step is executed:
(4) CRM_OPPORT_H_MERGE_OW
Opportunity header extension specific fields are filled in this FM.
The following fields are populated in this FM with related business logic.
probability
phase_since
assistant_phase
exp_weighted_revenue
salescycle
Once all these four steps are done successfully, CRM_OPPORT_H_FILL_OW has now generated a consistent object work area and stored in ls_opport_h_wrk.
This object work area will be put to object buffer for later save usage via FM CRM_OPPORT_H_PUT_OB.
Further reading
I have written a series of blogs to explain how One Order API works. The blogs are written based on a simple scenario: read, change and save field “Closing Date” in Opportunity header level.
Buffer logic in One Order header extension Read
Change Scenario
CRM_ORDER_MAINTAIN
|- CRM_ORDER_MAINTAIN_MULTI_OW
|- CRM_ORDER_MAINTAIN_SINGLE_OW
|- CRM_ORDER_H_MAINTAIN_OW
|- CRM_OPPORT_H_MAINTAIN_OW
|- CRM_OPPORT_H_CHANGE_OW
|- CRM_OPPORT_H_READ_OB
|- CRM_OPPORT_H_FILL_OW
|- CRM_OPPORT_H_CHECK_OW
|- CRM_OPPORT_H_PUT_OB
|- CRM_OPPORT_H_PUBLISH_OW
Save Scenario
CRM_ORDER_SAVE
|- CRM_ORDER_SAVE_OW
|- CRM_EVENT_SET_EXETIME_MULTI_OW
|- CRM_OPPORT_H_SAVE_EC
|- CRM_ORDER_TABLE_SAVE
|- CRM_OBJECT_NAMES_DETERMINE
|- CRM_ORDER_UPDATE_TABLES_DETERM
|- CRM_ORDER_SET_OBJECTS_TO_SAVE
CRM_OPPORT_H_UPDATE_DU
Create Scenario
CRM_ORDER_MAINTAIN
|- CRM_ORDER_MAINTAIN_MULTI_OW
|- CRM_ORDER_MAINTAIN_SINGLE_OW
|- CRM_ORDER_H_MAINTAIN_OW
|- CRM_ORDERADM_H_MAINTAIN_OW
|- CRM_ORDERADM_H_CREATE_OW
|- CRM_OPPORT_H_MAINTAIN_OW
|- CRM_OPPORT_H_READ_OB
|- CRM_OPPORT_H_CREATE_OW
|- CRM_OPPORT_H_CHANGE_OW
