Re: Data Source: 0CRM_PROD_OBJ_LIST

Question

Dear All
We are using CRM data source:0CRM_PROD_OBJ_LIST(Delta) and ODS 0CRM_OL.
Issue: Data is loaded in to PSA correctly but when it is staged to ODS it is skipping some of the records.
Between this PSA and ODS their is a Start routine in Update rule.
Update rule name; 4ETV81OKAKCXHUFPSRYXMIVAT
Code in Start routine is attached.
1. Can Some one please check whether it is standard or Z? Because I had debugged the program I found no problem in it.
Sorry to attach the code here it is just to verify.
YPES: BEGIN OF new_data_structure,
         item_guid(32) TYPE c,
         item_changed_ts(8) TYPE p,
         recordmode TYPE c,
       END OF new_data_structure.
    This global table contains information about relevant update
    records. This table is filled when the first data package is
    processed
DATA:  gt_new_data TYPE SORTED TABLE OF new_data_structure
       WITH NON-UNIQUE KEY item_guid item_changed_ts recordmode.
DATA: IN    TYPE F,
      OUT   TYPE F,
      DENOM TYPE F,
      NUMER TYPE F.
data: rate like tcurr-UKURS.
constants: c_msgty_e value 'E'.
$$ end of global - insert your declaration only before this line   -
The follow definition is new in the BW3.x
TYPES:
  BEGIN OF DATA_PACKAGE_STRUCTURE.
     INCLUDE STRUCTURE /BIC/CS0CRM_PROD_OBJ_LIST.
TYPES:
     RECNO   LIKE sy-tabix,
  END OF DATA_PACKAGE_STRUCTURE.
DATA:
  DATA_PACKAGE TYPE STANDARD TABLE OF DATA_PACKAGE_STRUCTURE
       WITH HEADER LINE
       WITH NON-UNIQUE DEFAULT KEY INITIAL SIZE 0.
FORM startup
  TABLES   MONITOR STRUCTURE RSMONITOR "user defined monitoring
           MONITOR_RECNO STRUCTURE RSMONITORS " monitoring with record n
           DATA_PACKAGE STRUCTURE DATA_PACKAGE
  USING    RECORD_ALL LIKE SY-TABIX
           SOURCE_SYSTEM LIKE RSUPDSIMULH-LOGSYS
  CHANGING ABORT LIKE SY-SUBRC. "set ABORT <> 0 to cancel update
$$ begin of routine - insert your code only below this line        -
fill the internal tables "MONITOR" and/or "MONITOR_RECNO",
to make monitor entries
**declaration
DATA: lt_active_data TYPE TABLE OF /bi0/acrm_ol00.
DATA: ls_active_data TYPE /bi0/acrm_ol00.
  DATA: lt_active_data TYPE TABLE OF DATA_PACKAGE_structure.
  DATA: ls_active_data TYPE DATA_PACKAGE_structure.
  DATA: lv_fsname(60) TYPE c.
  DATA: lv_psa_name TYPE rsodstech.
  DATA: lv_dso_tabname TYPE tabname.
  DATA: ls_new_data TYPE new_data_structure.
  DATA: ls_new_data_pre TYPE new_data_structure.
  DATA: ls_DATA_PACKAGE TYPE DATA_PACKAGE_structure.
  DATA: help_index LIKE sy-tabix.
  FIELD-SYMBOLS: <fs_minfo_requnr> TYPE ANY.
  FIELD-SYMBOLS: <fs_minfo_datapakid> TYPE ANY.
  FIELD-SYMBOLS: <fs_minfo_updmode> TYPE ANY.
  FIELD-SYMBOLS: <fs_minfo_logsys> TYPE ANY.
**constants
  CONSTANTS:  lc_dso_name TYPE rsdodsobject VALUE '0CRM_OL'.
**end of declaration
**fetch request number
  lv_fsname = 'g_s_minfo-requnr'.
  ASSIGN (lv_fsname) TO <fs_minfo_requnr>.
**fetch data package number
  lv_fsname = 'g_s_minfo-datapakid'.
  ASSIGN (lv_fsname) TO <fs_minfo_datapakid>.
**fetch update mode
  lv_fsname = 'g_s_minfo-updmode'.
  ASSIGN (lv_fsname) TO <fs_minfo_updmode>.
**fetch source system
  lv_fsname = 'g_s_minfo-logsys'.
  ASSIGN (lv_fsname) TO <fs_minfo_logsys>.
**delete all data_package entries that...
**...are not object list elements
**...are dummy deletion records
**...are erroneous
  DELETE DATA_PACKAGE WHERE flag NE 'O'.
OR
                           recordmode EQ 'D'.
**delta handling only processed for update modes 'delta' and 'repeat'
  IF <fs_minfo_updmode> = 'D' OR <fs_minfo_updmode> = 'R'.
data selection and deletion handling only for the first data package
    IF <fs_minfo_datapakid> = '000001'.
   fetch technical name of actual PSA table
   with I_SELTYPE = 'D' (Date)
      CALL FUNCTION 'RSAR_ODS_NAME_GET'
        EXPORTING
          i_logsys                = <fs_minfo_logsys>
          i_isource               = '0CRM_PROD_OBJ_LIST'
          i_istype                = 'D'
          i_date                  = sy-datum
        I_VERSION               =
          i_seltype               = 'D'
        I_SEGMENT_ID            =
        IMPORTING
        E_ODSNAME               =
          e_odsname_db            = lv_psa_name
        E_ODS_TABTYPE           =
        E_S_ODS                 =
        E_T_ODSFIELDS           =
        E_PARTITIONED           =
        EXCEPTIONS
          parameter_failure       = 1
          no_ods_found            = 2
          no_fields_to_ods        = 3
          OTHERS                  = 4
      IF sy-subrc = 0.
     select new data from PSA Table
        SELECT * FROM (lv_psa_name)
        INTO CORRESPONDING FIELDS OF TABLE gt_new_data
     only select data from actual request
     ...do not select erroneous records
     ...do not select object list records
        WHERE request      = <fs_minfo_requnr> AND
              bwsttecsys2  NE '10' AND
              flag_pl_ol   NE 'P'.
        IF sy-subrc = 0.
       delete adjacent duplicates in gt_new_data
          DELETE ADJACENT DUPLICATES FROM gt_new_data
          COMPARING ALL FIELDS.
       get technical name of active DSO table
          CALL METHOD cl_rsd_odso=>get_tablnm
            EXPORTING
              i_odsobject   = lc_dso_name
              i_tabt        = rsdod_c_tabt-active
            IMPORTING
              e_tablnm      = lv_dso_tabname
           E_TTYPENAME   =
           E_VIEWNM      =
           E_CHNGLOGNM   =
           E_INFOSOURCE  =
           E_DATASOURCE  =
            EXCEPTIONS
              OTHERS        = 1.
          IF sy-subrc <> 0.
            lv_dso_tabname = '/bi0/acrm_ol00'.
          ENDIF.
       select active data from ODS A-Table for relevant items
          SELECT * FROM (lv_dso_tabname)
          INTO CORRESPONDING FIELDS OF TABLE lt_active_data
          FOR ALL ENTRIES IN gt_new_data
          WHERE crm_itmgui = gt_new_data-item_guid.
       delete older after images, only keep the latest one
          LOOP AT gt_new_data INTO ls_new_data.
            IF ls_new_data-item_guid EQ ls_new_data_pre-item_guid AND
               ( ls_new_data-item_changed_ts NE
  ls_new_data_pre-item_changed_ts OR
            for dummy deletion records on item level there could be
            several entries with same value of item_changed_ts
            because the changing date is not updated in case of
            deletion of an item
            in this case we only keep the dummy deletion record
            itself
               ls_new_data-recordmode = 'D' ).
              help_index = sy-tabix - 1.
              DELETE gt_new_data INDEX help_index.
            ENDIF.
            MOVE ls_new_data TO ls_new_data_pre.
          ENDLOOP.
       Now we delete all dummy deletion records in gt_new_data
          DELETE gt_new_data WHERE recordmode = 'D'.
       modify data of gt_active_data for field 'RECORDMODE' = 'D'
       deletion records are written to the data package (Index 1)
          LOOP AT lt_active_data INTO ls_active_data.
            ls_active_data-recordmode = 'D'.
            MOVE-CORRESPONDING ls_active_data TO ls_DATA_PACKAGE.
            INSERT ls_DATA_PACKAGE INTO DATA_PACKAGE INDEX 1.
          ENDLOOP.
       delete records of older after images
       do not consider deletion records
          LOOP AT DATA_PACKAGE INTO ls_DATA_PACKAGE
               WHERE recordmode NE 'D'.
            help_index = sy-tabix.
         relevant for update?
            READ TABLE gt_new_data WITH KEY
              item_guid = ls_DATA_PACKAGE-crm_itmgui
              item_changed_ts = ls_DATA_PACKAGE-crm_itchts
              BINARY SEARCH
              TRANSPORTING NO FIELDS.
         if not relevant, delete it!
            IF sy-subrc <> 0.
              DELETE DATA_PACKAGE INDEX help_index.
            ENDIF.
            CLEAR ls_DATA_PACKAGE.
            CLEAR help_index.
          ENDLOOP.
        ENDIF.
      ENDIF.
for data packages > 000001
    ELSE.
   delete records of older after images
      LOOP AT DATA_PACKAGE INTO ls_DATA_PACKAGE.
        help_index = sy-tabix.
     relevant for update?
        READ TABLE gt_new_data WITH KEY
          item_guid = ls_DATA_PACKAGE-crm_itmgui
          item_changed_ts = ls_DATA_PACKAGE-crm_itchts
          BINARY SEARCH
          TRANSPORTING NO FIELDS.
     if not relevant, delete it!
        IF sy-subrc <> 0.
          DELETE DATA_PACKAGE INDEX help_index.
        ENDIF.
        CLEAR ls_DATA_PACKAGE.
        CLEAR help_index.
      ENDLOOP.
    ENDIF.
  ENDIF.
if abort is not equal zero, the update process will be canceled
  ABORT = 0.
$$ end of routine - insert your code only before this line         -
ENDFORM.
Analysis on it:
   1. I read in the SAP help that u201CBefore you perform a delta update for this ODS object, ensure that data previously loaded into the ODS object is activated. Otherwise the delta update could lead to inconsistencies.u201D  (http://help.sap.com/saphelp_tm80/helpdata/en/ba/21423fc657e07fe10000000a114084/frameset.htm). But I had seen in the ODS
(0CRM_OL) manage that number of requests are activated at once so I had deleted the ODS requests and reloaded one by one by activating them sequentially.
Till the request which has got problem that is SID of request 90949 (PSA) dated 06/09/2011. After loading the said request the contract number (0000132672) was still missing in the ODS. Then I had debugged the 9 data package of 90949 in which the contract number 0000132672 was present. I found that after the code for Start routine is completed the contract number was still existing in the internal table. But that is not updated into the New(Queue)  Table of ODS.
Unable to debug the background job which is generated while updating the data from PSA to ODS, as no real data found at that time. 
Code Process in Start Routine (It will use both the active table of ODS and PSA data (of relevant request )):
Conclusion: There is no problem in Start routine. (Seems it is standard routine (need to be confirmed)).
2.       Found in Sap help that u201CWhen you use this InfoSource to load data into the ODS objects Product Lists (0CRM_PL) and Object Lists (0CRM_OL), you must set the processing method Only PSA with the option Update Subsequently in Data Targets in the corresponding InfoPackage. The update rules for the above ODS objects use a global table in their start routine to enable delta updates for this extractor. Once the data to be loaded has been distributed to multiple data packages, the contents of this global table are only retained if you have set the above processing method. If you set any other processing method, the contents of this global table are deleted between processing of data packagesu201D (http://help.sap.com/saphelp_bw33/helpdata/en/05/bb423fd9575003e10000000a114084/frameset.htm).
For this to implement need to delete data from ODS and from PSA so as to load the data with new info package (Process type Only PSA update sub sequential).
Edited by: sreekanth goud on Oct 25, 2011 8:02 AM

Answer 1

Hi Sreekanth,
First check whether you ur DSO had the right combination of key fields,once u r sure about it,check the start routine,please send the code. it's heavy to see.
Thanks & Regards
Rams Thota