For project reason I need to figure out the logic how fields in index table CRM_ORDER_INDEX are updated. For example, I have an opportunity with ID 21 and closing date 2017.03.25.

I get its guid 6C0B84B759DF1ED6BDF05763B3DC8841 from CRMD_ORDERADM_H and query CRM_ORDER_INDEX with this guid against field HEADER, 2 records found:

Most of the fields in these two records have the same value except fields like PARTNER_NO, which represent the two involved parties as found in WebUI:

What I am curious about is: the field DATE_2 seems to store the timestamp of Closing Date 2017.03.25 as observed in WebUI. My doubt is, since WebUI only displays the date information, where does this time 22:59:59 come from?

I wrote the following simple report to change Closing Date by code:

PARAMETERS: end TYPE CRMT_OPPORT_H_COM-expect_end DEFAULT '20170319'.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 = end.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.

The SAT trace shows clearly that the index table will also be updated during order save:

The main logic of CRM_ORDER_INDEX_SAVE

(1) call order header from object buffer and DB buffer separately via CRM_ORDERADM_H_READ_OB and CRM_ORDERADM_H_READ_DB to check whether there is really header change. (2) get old index data from DB via CRM_ORDER_INDEX_SELECT_DB. (3) transfer the latest order data from object buffer to index buffer. This is done in subroutine fill_data. Before subroutine is executed, date_1 is initial:

After execution, date_1 is filled with data now. So I can find answer how date_1 is populated later by debugging into fill_data subroutine.

(4) The change mode ( insert, update or delete ) is evaluated in subroutine fill_update_tables by comparing the latest change stored in lt_index_ob ( object buffer ) and original data from DB, lt_index_db.

In this example the determined result is that two records ( stored in table lt_index_update ) must be updated. The comparison logic is described in blog  Logic of SAVE_EC function module in One Order. The real database update is done in update function module CRM_ORDER_INDEX_UPDATE_DU.

Closing Date update logic in CRMD_ORDER_INDEX-DATE_2 It is easy to find the logic by debugging into subroutine fill_data.

The Closing Date in WebUI is stored in CRMD_OPPORT_H-EXPECT_END.

The time of Closing Date is hard coded as 235959 and converted to timestamp based on time zone configured in the backend.

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

Index table CRMD_ORDER_INDEX and its update logic

要获取更多Jerry的原创文章，请关注公众号"汪子熙":