In the previous series of blogs the read and update on Opportunity header fields are discussed. In this blog another scenario will be explained: create scenario on Opportunity header fields. I will again use Closing Date (and description field) for example.
Execute the following report:
REPORT ZORDER_CREATE.
DATA: lt_input_fields TYPE crmt_input_field_tab,
ls_input_field LIKE LINE OF lt_input_fields,
ls_field_name LIKE LINE OF ls_input_field-field_names,
lv_guid TYPE guid_16,
lt_orderadm_h_com TYPE crmt_orderadm_h_comt,
ls_orderadm_h_com LIKE LINE OF lt_orderadm_h_com,
ls_com_structure TYPE string,
lv_selection_needed TYPE crmt_boolean,
lt_save TYPE crmt_object_guid_tab,
lt_saved TYPE crmt_return_objects,
lt_opp_h TYPE CRMT_OPPORT_H_COMT,
ls_opp_h LIKE LINE OF lt_opp_h,
ls_saved LIKE LINE OF lt_saved.
START-OF-SELECTION.
CALL FUNCTION 'GUID_CREATE'
IMPORTING
ev_guid_16 = lv_guid.
PERFORM call_order_maintain.
PERFORM call_order_save.
FORM call_order_maintain.
CLEAR: ls_orderadm_h_com, ls_input_field, lt_input_fields.
ls_orderadm_h_com-guid = lv_guid.
ls_orderadm_h_com-description = 'created by code on:' && sy-timlo.
ls_orderadm_h_com-process_type = 'OPPT'.
ls_orderadm_h_com-mode = 'A'.
APPEND ls_orderadm_h_com TO lt_orderadm_h_com.
ls_input_field-ref_guid = lv_guid.
ls_input_field-ref_kind = 'A'.
ls_input_field-objectname = 'ORDERADM_H'.
ls_field_name-fieldname = 'DESCRIPTION'.
APPEND ls_field_name TO ls_input_field-field_names.
ls_field_name-fieldname = 'MODE'.
APPEND ls_field_name TO ls_input_field-field_names.
ls_field_name-fieldname = 'PROCESS_TYPE'.
APPEND ls_field_name TO ls_input_field-field_names.
APPEND ls_input_field TO lt_input_fields.
ls_opp_h-ref_guid = lv_guid.
ls_opp_h-expect_end = '20170401'.
APPEND ls_opp_h TO lt_opp_h.
CLEAR: ls_input_field.
ls_input_field-ref_guid = lv_guid.
ls_input_field-ref_kind = 'A'.
ls_input_field-objectname = 'OPPORT_H'.
APPEND 'EXPECT_END' TO ls_input_field-field_names.
APPEND 'STARTDATE' TO ls_input_field-field_names.
INSERT ls_input_field INTO TABLE lt_input_fields.
CALL FUNCTION 'CRM_ORDER_MAINTAIN'
EXPORTING
IT_OPPORT_H = lt_opp_h
CHANGING
ct_orderadm_h = lt_orderadm_h_com
ct_input_fields = lt_input_fields
EXCEPTIONS
OTHERS = 99.
IF sy-subrc = 0.
WRITE:/ 'Order maintain function is done successfully.'.
ENDIF.
ENDFORM.
FORM call_order_save.
INSERT lv_guid INTO TABLE lt_save.
CALL FUNCTION 'CRM_ORDER_SAVE'
EXPORTING
it_objects_to_save = lt_save
iv_update_task_local = abap_true
iv_no_bdoc_send = abap_true
IMPORTING
et_saved_objects = lt_saved
EXCEPTIONS
document_not_saved = 1.
IF sy-subrc <> 0.
WRITE: / 'Opportunity created failed'.
ELSE.
READ TABLE lt_saved INTO ls_saved INDEX 1.
WRITE: / 'Opportunity created successfully, id:' , ls_saved-object_id.
ENDIF.
COMMIT WORK AND WAIT.
ENDFORM.Once executed, a new Opportunity will be created.
Just like FILL_OW, CHANGE_OW, MERGE_OW, SAVE_EC and READ_OB which are already discussed below, there are another kinds of function module responsible for creation in One Order, whose naming convention is CRM*CREATE_OW.
Execute the report in this blog via SAT to study how CREATE_OW works.
Two CREATE_OW are involved in the create scenario:
(1) CRM_ORDERADM_H_CREATE_OW
(1) The main logic within this header administrative information creation function module is to create status object.
in CRM_STATUS_OBJECT_CREATE, lots of status related internal table are populated as buffer, and they will be persisted to database table by subroutineSTATUS_UPDATE once commit work is called.
Take internal table jest_buf for example, we will check whether we could find the corresponding entry for below record later in table CRM_JEST with objnr = 6C0B84B759DF1EE7848DA711530A4C22.
(2) CRM_ORDERADM_H_PUT_OB is called to put the header administrative data into corresponding object buffer:
This header administrative data does not contain any transaction specific field like Closing Date in Opportunity header, which will be handled by CRM_OPPORT_H_*_OW function module instead.
(2) CRM_OPPORT_H_CREATE_OW
From the gross execution time of this function module (only 10 microseconds) we can assume that no heavy logic is written within it.
In fact it only inserts the following three fields to OPPORT_H object buffer and that’s all.
The left logic are done in CRM_OPPORT_H_CHANGE_OW which has already been discussed in this blog: Logic of CHANGE_OW function module in One Order.
After report is executed successfully, go to table CRM_JEST and query objnr with guid 6C0B84B759DF1EE7848DA711530A4C22, and there is indeed one entry which are created by CRM_STATUS_OBJECT_CREATE inCRM_ORDERADM_H_CREATE_OW.
You may have doubt that in this test report, Opportunity start date is not specified explicitly, why finally it has value 2017-03-24?
It is hard code in CRM_OPPORT_H_MERGE_OW, if no value specified by consumer.
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
要获取更多 Jerry 的原创文章，请关注公众号 ” 汪子熙 ”: