CRM and CX Blogs by SAP
Stay up-to-date on the latest developments and product news about intelligent customer experience and CRM technologies through blog posts from SAP experts.
cancel
Showing results for 
Search instead for 
Did you mean: 
JerryWang
Advisor
Advisor
4,032
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.




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