Skip to end of metadata
Go to start of metadata

See below the architecture diagram for the Delta Extraction. The colors of the swim lanes indicate under which responsibility the corresponding object falls. The "CRM Enterprise Search" objects are displayed in red (the modeling part a bit darker). Light blue entities fall under the responsibility of the Enterprise Search team.

For better understanding, please investigate into the ES Initial Extraction process first, since some of the basic concepts may be described there more clearly.

The delta extraction requires the application to write change pointers with every creation, modification and deletion of the underlying object. These change pointers (containing basically the key information) are collected and the delta load which should run frequently (say every 10 minutes) checks whether there is at least one change pointer is there. If this is the case the delta extraction is responsible for reading the data and for distinguishing between modifications and deletions. Please note that the information provided by the change pointer in this respect is ignored, an entity is deleted if it is requested but not returned.

Please note that the report will always start the delta load, in case an initial load was done before. One may brutally force the process to be an Initial Load by changing the Parameter LV_DELTA_INDEXING to blank (CL_ESH_ADM_CRT_LOAD_ADMIN_TOOLCM004 / INDEX_OBJECT_DATA before the execution of gr_load_controller->index_object_data).

Delta Load of Technical Objects (TOs) is not supported.


Main Parts  

The main parts of the delta load work as in the Initial Load. The Delta Load needs no key retrieval, since the required keys are handed over from the Enterprise Search.

Please take a look at the description of the ES Initial Extraction for a better understanding.

Deletion handling  

The Initial Load does not know/support deletions, this is only possible with the Delta Load. The Enterprise Search also provides information which key was inserted, modified and/or deleted. Nevertheless we ignore this information, since it may be not or no more accurate. Instead we try to fetch the data on all keys we got. If the data set is not returned by the Genil, we treat it as deleted. Deletion handling is done in the "Process_Deletion" method of CL_CRM_ES_BO_EXTR. Due to required mapping of key information to attribute information, it contains some complexity and some risks. So Deletions should be always tested accurately.