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:
REPORT zoneorder_modify.
CONSTANTS: gv_guid TYPE crmt_object_guid VALUE '6C0B84B759DF1ED6BDF05763B3DC8841'.
DATA: lt_opport_h TYPE crmt_opport_h_comt,
ls_opport_h LIKE LINE OF lt_opport_h,
lt_change TYPE crmt_input_field_tab,
ls_change LIKE LINE OF lt_change,
lt_saved TYPE crmt_return_objects,
lt_exception TYPE crmt_exception_t,
lt_to_save TYPE crmt_object_guid_tab,
lt_not_to_save TYPE crmt_object_guid_tab.
ls_opport_h-ref_guid = gv_guid.
ls_opport_h-expect_end = '20170217'.
ls_change = VALUE #( ref_guid = gv_guid ref_kind = 'A' objectname = 'OPPORT_H' ).
APPEND 'EXPECT_END' TO ls_change-field_names.
APPEND ls_change TO lt_change.
APPEND ls_opport_h TO lt_opport_h.
CALL FUNCTION 'CRM_ORDER_MAINTAIN'
EXPORTING
it_opport_h = lt_opport_h
CHANGING
ct_input_fields = lt_change
EXCEPTIONS
error_occurred = 1
document_locked = 2
no_change_allowed = 3
no_authority = 4.
APPEND gv_guid TO lt_to_save.
CALL FUNCTION 'CRM_ORDER_SAVE'
EXPORTING
it_objects_to_save = lt_to_save
iv_update_task_local = abap_true
IMPORTING
et_saved_objects = lt_saved
et_exception = lt_exception
et_objects_not_saved = lt_not_to_save
EXCEPTIONS
document_not_saved = 1.
WRITE: / sy-subrc.
COMMIT WORK AND WAIT.
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_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_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_OPPORT_H_MAINTAIN_OW
Index table CRMD_ORDER_INDEX and its update logic
要获取更多Jerry的原创文章,请关注公众号"汪子熙":
相关文章
- SAP Fiori @OData.publish 注解的工作原理解析
- SAP CRM Fiori 应用的 offline 离线支持开发笔记
- 使用 mock 数据在本地运行 SAP Fiori Elements 应用的工作原理
- 几种 SAP ABAP OData 服务的性能评估和测试工具介绍试读版
- SAP ABAP 系统同微软 Office 套件进行 Desktop Integration 的工作原理
- SAP CRM Survey调查问卷的模型设计原理解析
- SAP CRM中间件Request download的警告信息:message Object is in status Wait
- SAP CRM事务码COMMPR01无法搜索Individual Object
- SAP S/4HANA Material Fiori应用根据扩展字段搜索的实现原理
- SAP S/4HANA key user tool extensibility原理
- SAP Marketing Cloud Contact 模型的导入配置和数据合并原理
- 如何在 SAP UI5 应用里显示 PDF 文件试读版
- SAP UI5 应用的 OData 元数据请求的发送原理分析
- SAP UI5 初学者教程之六 - 了解 SAP UI5 的模块(Module)概念试读版
- 如何在Chrome开发者工具里找出SAP Fiori frontend server的systen ID
- SAP Fiori Elements - smart field id generation
- SAP Fiori globalization实现原理分析
- SAP Fiori pageSet请求的处理原理
- SAP UI5和Angular的函数防抖(Debounce)和函数节流(Throttle)实现原理介绍
- 3. SAP ABAP OData 服务诊断工具 /IWFND/ERROR_LOG 的使用方法