SAP CRM One Order函數SAVE_EC的設計原理

In previous blogs the READ and UPDATE logic of Opportunity header field Closing Date are explained:

Buffer logic in One Order header extension read

Logic of FILL_OW function module in One Order

Logic of CHANGE_OW function module in One Order

In this blog we will research what happens when end user clicks save button after Closing Date is changed in WebClient UI.

This time we use naming convention CRMSAVE_EC to list the function modules which will be responsible to trigger the persistence of the change into corresponding database table.

The corresponding function module for Opportunity header is: CRM_OPPORT_H_SAVE_EC

The research could be done from below report:

Execute the report via tcode SAT, and we can find out that the persistence of Opportunity header field consists of two steps:

(1) CRM_OPPORT_H_SAVE_EC

(2) Update function module CRM_OPPORT_H_UPDATE_DU

The left part of this blog will explain these two steps in more detail.

Step1: CRM_OPPORT_H_SAVE_EC

The reason why CRM_OPPORT_H_SAVE_EC is called during save is because it is registered as callback for event SAVE in order CRMV_EVENT:

Update on 2017-04-24 4:27PM in Walldorf

How this registration information is loaded in the runtime could be found from this wiki page.

This callback function module does not have any logic but directly delegates the call to CRM_OPPORT_H_SAVE_OB, which calls a generic function module CRM_ORDER_TABLE_SAVE to determine the kind of current change ( Insert, Update or Delete ) and call update function module CRM_OPPORT_H_UPDATE_DU to perform database change.

CRM_ORDER_TABLE_SAVE consists of the following steps:

(1) call CRM_OBJECT_NAMES_DETERMINE to get corresponding DDIC object names and update function module name for OPPORT_H.

(2) call CRM_ORDER_UPDATE_TABLES_DETERM to extract the detail changed data. In my example, 1 update operation is detected for OPPORT_H.

The change of closing date specified by code is already included in <RECORDS_TO_UPDATE>:

How this change detection is done?

First Opportunity header object buffer( latest data) is retrieved via CRM_OPPORT_H_GET_MULTI_OB:

Then database buffer is read via CRM_OPPORT_H_GET_MULTI_DB:

By comparison on these two buffer we can know the given opportunity has a change on Closing Date field in header level.

(3) CRM_ORDER_SET_OBJECTS_TO_SAVE

It simply inserts the guid of changed opportunity to be saved into a global internal table gt_guids_to_save.

(4) call update function module CRM_OPPORT_H_UPDATE_DU

Step2: CRM_OPPORT_H_UPDATE_DU

In my example report, the execution of this update function module is triggered by COMMIT WORK AND WAIT.

The corresponding OPEN SQL statement is executed according to changed data in INSERT, UPDATE or DELETE mode.

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_ORDERADM_H_MAINTAIN_OW

|- CRM_ORDERADM_H_CREATE_OW

|- CRM_OPPORT_H_CREATE_OW

Index table CRMD_ORDER_INDEX and its update logic