SAP ABAP老司机平时是怎么做代码审查的
SAP ABAP老司机平时是怎么做代码审查的
In line 27:strange callstack.Why from API layer directly to local class level? In line 28:LCL_REQUEST_MANAGER=>PROCESS called 139 times and consumes 4 seconds. Even taking sub nodes into consideration, why 139 times? Need to compare in our own system and perhaps debug in Lenovo sandbox system. In line 29: lt_processable: 148 times. In line 31: CL_CRM_UIU_BT_TOOLS=>SAVE. Check whether it is called within LOOP. Total time: 3.86 seconds In line 32: LCL_REQUEST_MANAGER=>PROCESS_REQUESTS why it is called 7 times? In line 42:Call Func. CRM_ORDER_SAVE: it took 2.5 seconds to save a service order via API! In line 67:CL_BSP_PAGE_CONTEXT=>IF_BSP_PAGE_CONTEXT~ELEMENT_PROCESS: this UI element render method is called 407 times and consumes 2.2 seconds. In line 78: why the API is called again although control is handed over back to UI layer? In line 79: Call Func. CRM_ORDER_SAVE_PREPARE_MULT_OW 1.6 seconds for CRM_ORDER_SAVE_PREPARE_MULT_OW In line 92: Call M. CL_CHTMLB_CONFIG=>IF_BSP_ELEMENT~DO_AT_BEGINNING:why DO_AT_BEGINING triggers expensive Genil READ again? In line 98: Call Func. CRM_ACTION_DETERM_COMPL_DOC – is this standard action implementation: could it be disabled? In line 101: Call Func. CRM_ORDER_READ_OW – why is it called? In line 107: Call M. CL_CRM_INTLAY_BTIL=>READ_ORDERS is called 138 times In line 117: Submit Report SAPMSSY4 : synchronous or Asynchronous call? In line 118: Call M. CL_BSP_WD_CONTEXT_NODE_TV=>GET_T_TABLE: 0.8 seconds for a pure UI layer operation!? In line 127: Call Func. CRM_ORDER_UPLOAD_SINGLE why is it called? In line 130: Call M. ZL_BT116H_S_OVVIEWSET_IMPL=>ZCHECK_VENDOR_ADDRESS:Lenovo BAdI implementation to check vendor address( 0.6 second) Any space to improve? In line 131: Call M. CL_IM_CRM_BUS20001_UPLOAD=>IF_EX_ORDER_SAVE~CHANGE_BEFORE_UPDATE – standard BAdI implementation. Could it be deactivated? In line 134: Program SAPMSSY4 synchronous or Asynchronous call? In line 135: why it does dynpro related record? In line 138: Perform LOCAL_UPDATE_TASK - could it be avoided? In line 139: Call M. CL_CRM_PARTNERSET_RUN_BTIL=>IF_CRM_RUNTIME_BTIL~READ_ATTRIBUTES - why partner set related function is called here? In line 144: Call M. CL_CHTMLB_CONFIG_TABLE=>IF_HTMLB_TABLEVIEW_ITERATOR~RENDER_CELL_START – a large number of calls In line 160: Call M. CL_CONTEXT_MANAGER_PPF=>CONSTRUCTOR-constructor consumes 0.3 seconds In line 162: Perform(Ext) BAL_DB_INTERNAL_IN_UPDATE_TASK - application log: 0.3 seconds In line 170: Select PPFTTRIGG 0.2 seconds In line 173: Call M. CL_BSP_WD_CONTEXT_NODE_TV=>GET_V_T_TABLE get value help: 0.27 seconds In line 175: Call M. CL_CRM_INTLAY_BTIL=>GET_DATA:a large number of GET_DATA called In line 180 :Call M. CL_EX_ORDER_SAVE=>IF_EX_ORDER_SAVE~CHECK_BEFORE_SAVE - 0.259 seconds for BAdI implementaton call In line 181: Call M. CL_SF_MAIL_PPF=>SET_TRIGG - is mail send functionality really necessary?
- From trace I can confirm that Service order save is done in a synchronous way in webclient UI. 同步操作哦。
And there is a business function to enable Asynchronous search. If the Asynchronous search has no impact, the 0.8 seconds could be deducted from the total 7.6 seconds to save in Webclient UI.
It is necessary to clarify that, the 7.6 times consists of both the execution on Webclient UI layer, the Genil layer and API Layer.
In pricing Validation scenario, it is most likely to directly call API ( CRM_ORDER_SAVE ) to persist the order. For this API call, it took 2.5 seconds in Lenovo production system to finish the save.
Of course we need to seek the improvement in both UI save and API save, nevertheless I think we should clearly communicate about the difference between this 7.6 seconds and 2.5 seconds.
Furthermore, the save API is mass-handling enabled, which means the total number of saving N order at one time != N * 2.5 seconds.
I update my progress today: 工作进度汇报。
I have written a report using BOL API to save service order. Tested in BG3 but I don’t have a development user to create it in sandbox system.
I will try to ask for an user with enough authorization. Then I use SAT to do a trace in sandbox system on transaction CRMD_ORDER( search out one service order, change its description and save ).
In sandbox system there are 238322 entries in order header table. 1.9 second for Modify API 3.3 second for Save API
To do: Need to figure out what action implementation is done here. ( 1.7 second )
I have gone through the source code of ZL_BT116H_S_OVVIEWSET_IMPL. The basic feeling is the custom code is not so good, although some of them may not have a BIG impact on performance. Some examples:
There are some useless code in order save. The highlighted code are always executed during order save but the final result lv_category is never used later. So it could be deleted.
“REINVENT the wheel”: There are quite lots of looping at the BOL collection to find the very bol entity by application code, even in the nested WHILE statement. However, this function is already provided by framework. I just test in BG3 that framework solution is several times faster than implemented by application.
For the order save, several methods are executed in the same session, however the same check logic is done in every method related to save again and again.
In sap standard implementation, the best practice is to buffer the check result to avoid later repeated call.
As I said those bad coding style may not impact the overall performance too much since all of the custom coding only cost 29% of total time, but just from my point of view there is indeed improvement space regarding their custom code.