Generic delta problems

hai guys,
in generic delta having  3 options like numaric pointer ,
time stamp and 0calday
i have confusin when did select perticur option
plz let me know
waiting for reply
murali

Hi,
In case we dont have a business content datasource and the standard table also dont contain any field to register the latest change in time/day/numeric pointer ( for example sd billing plan data ) for that we need to go building a data source following the standard lo queue delta mechanism. To provide dela to datasource the association to a target syetm is required to store the dela queue as well as to extraction also.
Could you please through some infomation for doing the same.
Many thanks to all the Great Gurus.
Regards,
Jugal

Similar Messages

  • Generic delta problem : in init load, the request is in yellow.......

    Hi all,
    I have created a table in R/3, and created a Generic data source using this table, and coming to deltas, i have selected Numeric pointer in which I have given the sales document number which comes from the table as the Delta relevant field. And the other things like replication, creation of info source, info package did well and I als got Initialization option in Info Package, but when I schedule the load, its coming in yellow signal and says that 0 records from 0 records, and gives error message as no records in the source system. This is the case if I use Init option in Info package.
    If I use Full load option in info pack, every thing is fine and I am able to extract the data from R/3 with out any problem, the load is getting succeeded.
    The only problem is with deltas. Is there anything else to do on R/3 side to enable the delta mechanism? or is it required to use functional module to enable the deltas ( I read this in some posts)? Please give me some solution.
    Thanks
    Ganesh

    Hi,
    There is no need to make any settings of delta...in general..it should work as similar as your full load....try to locate the problem area..and revert...
    Advise, check if there are any previous init. and delete...otherwise create a new
    infopackage and try..
    Cheers,
    Pattan.

  • Generic delta problem

    Hi all,
    If suppose we don,t have delta facility in generic extraction on R/3 for Master Data. how can we maintain the delta for that one in BW.
    Thanks & Regards,
    Sri

    hi Sri,
    suppose we don't ...
    i think you can try flexible update for master data and via ods, create ods with same structure and key as the master data, create infosource for the ods, upload data to the ods.
    and set the master data as 'infoprovider', create update rules assign from the ods. so the 'delta' is handled by ods. hope this helps.

  • Problem with functioning Generic Delta

    Hi Expert !
    I Have Created a Generic Delta and has Scheduled the Delta Load By Means of Process Chain In BI Side.
    Although it is showing Green(OK) status for the respected Request at PSA(saying No Data Exists FOR PSA) and ODS Lavel but no data is loaded at ODS.
    although the data for the same crieria is available in R/3 side.
    please share your idea what is reason behind........
    Regards
    Prakash

    Hii I have created Generic Delta On Function Module, also i had checked in RSA3 and it is showing data. Also I have checked the Function Module and the field on which i had created Delta, the Delta Parameters is coming.
    I am not able to find what actually the problem is........
    Please share your idea if you have any.
    Regards
    Prakash

  • Urgent: Problems in Generic Deltas by Function Module

    Hi BW Experts,
    My requirement is to extract text from CRM to BW using Zfunction module, copy of RSAX_BIW_GET_SIMPLE_DATA
    which works fine for full loads but the problem arises only when i go for generic deltas. My code in FM for Deltas is:
    LOOP AT s_s_if-t_select INTO l_s_select.
    CASE l_s_select-fieldnm.
    WHEN 'ZDATE'.
    s_date_from = l_s_select-low.
    s_date_to = l_s_select-high.
    WHEN OTHERS.
    ENDCASE.
    ENDLOOP.
    IF s_date_from IS INITIAL.
    s_date_from = '20060401'.
    ENDIF.
    IF s_date_to IS INITIAL.
    s_date_to = '99991231'.
    ENDIF.
    OPEN CURSOR WITH HOLD S_CURSOR FOR
    SELECT * FROM STXH
    WHERE TDOBJECT = 'CRM_ORDERH'
    AND TDID = 'A002'
    AND TDSPRAS = sy-langu
    and TDLDATE between s_date_from and s_date_to
    or tdfdate between s_date_from and s_date_to.
    ENDIF.
    FETCH NEXT CURSOR S_CURSOR
    APPENDING CORRESPONDING FIELDS
    OF TABLE wa_stxh
    PACKAGE SIZE S_S_IF-MAXSIZE.
    TDFDATE is creation date and TDLDATE is changed on
    My extract structure contains Zdate(TDLDATE), Ztext1,2,3, Key field and langu in RSO2 I have selected calday in generic delta and Zdate as field Nm and upper limit as 1 and lower limit as space in settings and new status for changed records button.
    Did I missed something because when i check in RSA7 i didnot see any changed records under totals column and i tried to load without it into BW than i didnot received single record evenafter changes.Would anyone suggest me the good solution for it I appreciate it in advance. I have seen lot of posts in SDN but I didnot find this type of secenario anywhere.
    Thanks in advance
    Regards
    Kishore

    Kishore,
    go through the thread... which i provided for Generic DS using function for CRM Texts.
    Re: Urgent: Extraction through function module
    Any questions please let me know. If you have any questions update the thread with your mail id.
    Replace the code with ...
    LOOP AT S_S_IF-T_SELECT INTO L_S_SELECT WHERE FIELDNM = 'ZDATE'.
    MOVE-CORRESPONDING L_S_SELECT TO L_R_TDLDATE.
    APPEND L_R_TDLDATE.
    ENDLOOP.
    OPEN CURSOR WITH HOLD S_CURSOR FOR
    SELECT * FROM STXH
    WHERE TDOBJECT = <Text Object>
    AND TDID = <Text ID >
    AND TDSPRAS = sy-langu
    AND (TDLDATE IN L_R_TDLDATE
    or TDFDATE IN L_R_TDLDATE).
    ENDIF. "First data package ?
    Fetch records into interface table.
    named E_T_'Name of extract structure'.
    FETCH NEXT CURSOR S_CURSOR
    APPENDING CORRESPONDING FIELDS
    OF TABLE wa_stxh
    PACKAGE SIZE S_S_IF-MAXSIZE.
    L_R_TDLDATE will be calculted by the system. Internally, system will save the Last Delta date(you need to enable this field for Generic delta).
    all the best.
    Regards,
    Nagesh Ganisetti.

  • Generic delta has problem with delts pointer time stamp

    Hi All,
    We have generic delta data source with Delte pointer as Time stamp. We have not used any safety limits. We are loading the data to DSO and using Additive delta. But the problem is when delta flag is set, there might be a case where some records still being inserted to table with lower time stamp. These records are not being fetched in next delta.
    We are planning to keep a safety upper limit of 5 min so that those records can not be missed. But we have a doubt as it is a Additive delta duplicate records will be loaded. If we make the delta to 'new status to changed records', it is going to work?? Any other things we have to check when we make this changes??
    Thanks
    Haaris

    Hi
    If you had selected additive delta then you can load data to DSo with addition mode only. No overwrite possible.
    If you want to select new or changed status then you can load to DSO with overwrite mode only.
    Additive or changed delta depends on your requirement because if you want to add data to the DSO then you can go ahead with additive otherwise you have to use DSO with overwrite mode only.
    You can either give safety upper limit or lower limit but if you give safety lower limit then you can only load data to DSO with overwrite mode because there could be some duplicate records.
    Hope it clarifies.
    Regards
    Sadeesh

  • Problem in getting Generic Delta records to BW

    Hi BW Gurus,
    I have got one issues with which I have been struggling a lot for several days . i.e
    I am extracting data from R/3 using Generic Extractor (View) from CATSCO and CATSDB. At the time of delta, I tried using Personal  No with Time Stamp giving Upper limit as 1800 seconds. I executed Infopackage in BW immediately. But it didn't work out. So plz guide me how I can get Delta Records to BW. Or should I do any  necessary factors apart from these in Generic Delta Screen (RSO2).
    It is very urgent.
    I will be thankful for solving this issue.

    Hey I am "Intros" again,,
    I am sorry man for giving the wrong T-code mistakenly in my last reply..
    To solve the proble...the whole process is same what I told u before..
    But... you got to go to T-Code :  BD87   , then execute the IDocs manually to bring them in to BW
    identify your IDocs which are missing in Monitor screen, then goto BD87 and select those IDocs and click execute... )you can search the IDoc's based on selection conditions)
    I hope this will help u...
    cheers man..
    ---Intros

  • Problem in extracting Generic Delta Records

    Hi BW Experts,
    I have an issue. I am using Generic Extractor using View from Tables CATSCO and CATSDB. At the time of  Generic Delta, I am using the field PERNR(Personal Number) to use Generic Delta. I am using Time Stamp. For this I have selected Safety Interval Upper Limit 100 seconds.But now I am testing whether we get delta records or not. But I am not getting records to BW. They are changed in R/3. So please guide me whether I should use Calday or Time Stamp . How can  I get delta records to BW.For testing , I am executing InfoPackage immediately after changes in R/3 like for two or three minutes. Once I will be sure on getting records to BW, then I can move to Production where we execute process chain at 1:00 a.m
    there I can use Calday giving Safety Interval Upper Limit as 1 day. Considering the above factors please guide me .
    I will be thankful for solving my issue.

    PERNR doesn't contain a date right?  so timestamp tells the system PERNR is a date field...  That will never work.
    What kind of value does PERNR contain, is it an incremental value that adds up at every new entry?
    Generic delta needs a field that changes in a way that can be predicted.

  • Incorrect TimeStamp in Generic Delta (UTC Issue)

    Hi,
    I have a problem regarding a generic delta extractor. The pointer stored in rsa7 (ROOSGENDLM table) is not UTC but system time. As standard tables store the timestamp using UTC format the delta extractor is not picking up the correct data.
    Do you know a solution for this?

    Hi,
    Thanks for your reply. However I think that unfortunately this solution is not enough
    For example:
    I execute a delta. My TimeStamp is registered as UTC +2: 20080612160000. (Here I have the error, it should be in UTC)
    Now I modify a record in R3 and it is registered with timestamp UTC: 20080612140000.
    If I execute a delta it will take all the records higher than 20080612160000. Therefore my modification will never be uploaded.

  • Generic delta

    Hi experts
    i have problem in loading generic delta , Generic delta have three parameters
    1.Time Stamp
    2.Numeric pointer
    3.Calender day
    and also upperlimit and lower limit
    can any one explain me about this parameters and how it works in generic delta
    Thanks in in advance

    hi,
    Yes we have these 3 delta types.
    timestamp is used when the requiement of data load is depends on time ie hourly based.
    0calday is is used when the requiement of data load is depends on date ie daily based.
    Numeric pointer is uesed if u want to load delta based on some fields like sales order,material order.
    Lower limit and upper limit used for not to miss the records.
    regards,
    kundan

  • Doubt Reg Generic Delta "Safety Interval" Setting

    Hi Experts,
    I have a doubt regarding Setting "Safety Interval Upper Limit" and Lower limit in RSO2 for generic delta.
    What does this setting imply?
    If I do setting for calender day say both 1 then wht will be difference between delta before setting amd after setting?
    Plz explain in terms other tham help provided...
    Points will be awarded to say thanks..
    Thanks in advance,
    Sorabh

    Hi Sorabh,
    Here some SAP informations:
    Safety Interval Upper Limit of Delta Selection
    This field is used by DataSources that determine their delta generically using a repetitively-increasing field in the extract structure. The field contains the discrepancy between the current maximum when the delta or delta init extraction took place and the data that has actually been read. Leaving the value blank increases the risk that the system could not extract records arising during extraction. Example: A time stamp is used to determine the delta. The time stamp that was last read is 12:00:00. The next delta extraction begins at 12:30:00. In this case, the selection interval is 12:00:00 to 12:30:00. At the end of extraction, the pointer is set to 12:30:00.  A record - for example, a document- is created at 12:25 but not saved until 12:35. It is not contained in the extracted data but, because of its time stamp, is not extracted the next time either.
    For this reason, the safety margin between read and transferred data must always be larger than the maximum length of time that it takes to create a record for this DataSource (with a time stamp delta), or it must display an interval that is sufficiently large (for determining delta using a serial number).
    Safety Interval Lower Limit
    This field contains the value taken from the highest value of the previous delta extraction to determine the lowest value of the time stamp for the next delta extraction. For example: A time stamp is used to determine a delta. The extracted data is master data: The system only transfers after-images that overwrite the status in the BW. Therefore, a record can be extracted into the BW for such data without any problems.
    Taking this into account, the current time stamp can always be used as the upper limit when extracting: The lower limit of the next extraction is not seamlessly joined to the upper limit of the last extraction. Instead, its value is the same as this upper limit minus a safety margin. This safety margin needs to be big enough to contain all values in the extraction which already had a time stamp when the last extraction was carried out but which were not read. Not surprisingly, records can be transferred twice. However, for the reasons above, this is unavoidable.
    Extracted Data Delta Type
    The system uses the delta type to determine how extracted data is to be interpreted in BW, and into which data targets it can be posted.
    A distinction is made between the following:
    1. Additive delta
    The key figures for extracted data are added up in BW. DataSources with this delta type can supply data to ODS objects and InfoCubes.
    2. New status for changed records
    Each record to be loaded delivers the new status for the key figures and characteristics. DataSources with this delta type can write to ODS objects or master data tables.
    Check also examples in "How to... Create Generic Delta" under www.service.sap.com/bi.
    Ciao.
    Riccardo.

  • Generic Delta: Init, Full Upload and Deltas...

    Dear All,
    Last week on 10.04.2014 I've created "Generic DataSource with Generic Delta" and used CalDay as Delta-Specific Field and lower limit kept to blank and upper limit to 1. On 11.04.2014 I've initialized the Delta with Data Transfer using Process Chain: Time 1:15 p.m (Note: Posting was on)
    see below screen shot:
    Result: Process Chain was scheduled to immediate and it executed and initialized the delta and brought records as well. See below screen shot of RSA7:
    Q: 1: Why generic delta current status is 10.04.2014, as I'v scheduled delta through process chain on 11.04.2014 @ 20:50: and why Total column is showing 0 records? Even I've checked Display Data Entries with Delta Repetition, but could not find any records?
    Following is the InfoPackages which I created for Delta Loads and used in another Process Chain for Delta scheduled (daily @ 20: 50).
    Following is the DTP used into Delta Process Chain:
    On 12/04/2014 when I checked my InfoCube, and found that same number of records being loaded again despite InfoPackage and DTP were created as Delta, see screen shot:
    On 12/04/2014 See below PSA table:
    On 14/04/2014 when I checked InfoCube and I saw deltas being loaded successfully: see below screen shot:
    On 14/04/2014 see below PSA table:
    On 14/04/2014 see below RSA7 BW Delta Queue Maintenance screen shot:
    Q: 2: Why am I unable to load the Delta records on the day(11/04/2014) when I initialized it with Data and why same number of records being loaded again on 11/04/2014?
    Q: 3: On 11/04/2014, around 1:15 p.m I've initialized Delta with Data successfully and the same day (11/04/2014) was my first load of delta records (Time: 20: 50), could this be a problem? as the posting period was on when I initialized and I tried to load the delta on the same day?
    Q: 4: Why the pointer is showing me Current Status: 12/04/2014 today and this time around I can find last delta records from "Display Data" option with Delta Repetition?
    Q: 5: Have I missed something in the design or data flow?
    Q: 6: How can I verify deltas records accuracy on daily basis; is it from RSA3?
    or How can I verify daily deltas with ECC delta records?
    Q: 7: What is the best practice when you load full data and initialized delta and schedule deltas for Generic DataSources with CalDay as delta specific field?
    I will appreciate your replies.
    Many Thanks!!!
    Tariq Ashraf

    I clearly got ur point.....But
               If i have situation like ....." I loaded the LO data from R/3 with Init delta......then i loaded 5 loads of delta too.......due to some error in data now i am trying to load all th data......In this case if i do Full upload it is going to bring all the data till 5 th delta load .......If i do Init delta again it is going to bring the same data as full upload..........In LO while loading both Full load or delta init load we need to lock R/3 users....I believe we can load delta even after full upload by using "Init delta without data transfer"............So that wont be the barrier....then what is the difference or how should i figure out which load should i do.............If i am wrong please correct me.......
    Thanks

  • Generic Delta extraction by Function module issue

    Hello Experts,
    Please help !!!
    I have problem for delta extraction by Function module.  For the full load, I wrote function module based on RSAX_BIW_GET_DATA_SIMPLE. It works fine.
    But I would like to have the delta load enabled. Therefore, I modified the datasource, add a delta specific field u2018ztimestampu2019, which type is calendar day.
    Then I create a function module based on template u2018RSAX_BIW_GET_DATAu2019, as this support the upload mode. But when I test this datasource in RSA3, no matter itu2019s full load or initial delta load, it always send me an error, u201CErrors occurred during the extractionu201D.
    I had some debug, and found that there is no value  for i_isource when my function module is called. Therefore it raised the exception.
    But I do not have the chance to debug my code for the delta logic, can somebody help to check?
    I also check the entries in ROOSOURCE,
    For my datasource ZTRNREC_FM_DELTA, The DELTA value is u2018AIEu2019, and extraction method is u2018F2u2019, should I change them to DELTA= u2018Du2019 and extraction method to u2018F1u2019? Where to change?
    FUNCTION ZRSAX_TRAININGREC_DELTA.
    ""Local Interface:
    *"  IMPORTING
    *"     VALUE(I_REQUNR) TYPE  SBIWA_S_INTERFACE-REQUNR
    *"     VALUE(I_ISOURCE) TYPE  SBIWA_S_INTERFACE-ISOURCE OPTIONAL
    *"     VALUE(I_MAXSIZE) TYPE  SBIWA_S_INTERFACE-MAXSIZE OPTIONAL
    *"     VALUE(I_INITFLAG) TYPE  SBIWA_S_INTERFACE-INITFLAG OPTIONAL
    *"     VALUE(I_UPDMODE) TYPE  SBIWA_S_INTERFACE-UPDMODE OPTIONAL
    *"     VALUE(I_DATAPAKID) TYPE  SBIWA_S_INTERFACE-DATAPAKID OPTIONAL
    *"     VALUE(I_PRIVATE_MODE) OPTIONAL
    *"     VALUE(I_CALLMODE) LIKE  ROARCHD200-CALLMODE OPTIONAL
    *"     VALUE(I_REMOTE_CALL) TYPE  SBIWA_FLAG DEFAULT SBIWA_C_FLAG_OFF
    *"  TABLES
    *"      I_T_SELECT TYPE  SBIWA_T_SELECT OPTIONAL
    *"      I_T_FIELDS TYPE  SBIWA_T_FIELDS OPTIONAL
    *"      E_T_DATA STRUCTURE  ZTRN_REC_TIME OPTIONAL
    *"      E_T_SOURCE_STRUCTURE_NAME OPTIONAL
    *"  EXCEPTIONS
    *"      NO_MORE_DATA
    *"      ERROR_PASSED_TO_MESS_HANDLER
    The input parameter I_DATAPAKID is not supported yet !
    Example: InfoSource containing TADIR objects
    Auxiliary Selection criteria structure
      DATA: l_s_select TYPE sbiwa_s_select.
    Maximum number of lines for DB table
      STATICS: l_maxsize TYPE sbiwa_s_interface-maxsize,
              S_S_IF TYPE SRSC_S_IF_SIMPLE,
              S_COUNTER_DATAPAKID LIKE SY-TABIX.
    Parameter I_PRIVATE_MODE:
    Some applications might want to use this function module for other
    purposes as well (e.g. data supply for OLTP reporting tools). If the
    processing logic has to be different in this case, use the optional
    parameter I_PRIVATE_MODE (not supplied by BIW !) to distinguish
    between BIW calls (I_PRIVATE_MODE = SPACE) and other calls
    (I_PRIVATE_MODE = X).
    If the message handling has to be different as well, define Your own
    messaging macro which interprets parameter I_PRIVATE_MODE. When
    called by BIW, it should use the LOG_WRITE macro, otherwise do what
    You want.
    Initialization mode (first call by SAPI) or data transfer mode
    (following calls) ?
      IF i_initflag = sbiwa_c_flag_on.
    Initialization: check input parameters
                    buffer input parameters
                    prepare data selection
    The input parameter I_DATAPAKID is not supported yet !
    Invalid second initialization call -> error exit
        IF NOT g_flag_interface_initialized IS INITIAL.
          IF 1 = 2. MESSAGE e008(r3). ENDIF.
          log_write 'E'                    "message type
                    'R3'                   "message class
                    '008'                  "message number
                    ' '                    "message variable 1
                    ' '.                   "message variable 2
          RAISE error_passed_to_mess_handler.
        ENDIF.
    Check InfoSource validity
        CASE i_isource.
          WHEN 'ZTRNREC_FM_DELTA'.
          WHEN OTHERS.
            IF 1 = 2. MESSAGE e009(r3). ENDIF.
            log_write 'E'                  "message type
                      'R3'                 "message class
                      '009'                "message number
                      i_isource            "message variable 1
                      ' '.                 "message variable 2
            RAISE error_passed_to_mess_handler.
        ENDCASE.
    Check for supported update mode
        CASE i_updmode.
          WHEN 'F'.
          WHEN 'D'.
          WHEN 'R'.
          WHEN OTHERS.
            IF 1 = 2. MESSAGE e011(r3). ENDIF.
            log_write 'E'                  "message type
                      'R3'                 "message class
                      '011'                "message number
                      i_updmode            "message variable 1
                      ' '.                 "message variable 2
            RAISE error_passed_to_mess_handler.
        ENDCASE.
    Check for obligatory selection criteria
        APPEND LINES OF i_t_select TO g_t_select.
    Fill parameter buffer for data extraction calls
        g_s_interface-requnr    = i_requnr.
        g_s_interface-isource   = i_isource.
        g_s_interface-maxsize   = i_maxsize.
        g_s_interface-initflag  = i_initflag.
        g_s_interface-updmode   = i_updmode.
        g_s_interface-datapakid = i_datapakid.
        g_flag_interface_initialized = sbiwa_c_flag_on.
    Fill field list table for an optimized select statement
    (in case that there is no 1:1 relation between InfoSource fields
    and database table fields this may be far from beeing trivial)
        APPEND LINES OF i_t_fields TO g_t_segfields.
      ELSE.                 "Initialization mode or data extraction ?
    Data transfer: First Call      OPEN CURSOR + FETCH
                   Following Calls FETCH only
      LOOP AT G_T_SELECT INTO L_S_SELECT
            WHERE FIELDNM = 'ZTIMESTAMP'.
      ENDLOOP.
          IF G_COUNTER_DATAPAKID = 0.
            IF L_S_SELECT-LOW = '' AND L_S_SELECT-HIGH = ''.
            OPEN CURSOR WITH HOLD G_CURSOR FOR
                SELECT (g_t_fields)
                FROM ZTRN_REC_TIME.
            ELSE.
              OPEN CURSOR WITH HOLD G_CURSOR FOR
                SELECT (g_t_fields)
                FROM ZTRN_REC_TIME
                WHERE ZTIMESTAMP >= L_S_SELECT-LOW
                  AND ZTIMESTAMP  <= L_S_SELECT-HIGH.
            ENDIF.
          ENDIF.
      FETCH NEXT CURSOR G_CURSOR
                   APPENDING CORRESPONDING FIELDS
                   OF TABLE E_T_DATA
                   PACKAGE SIZE S_S_IF-MAXSIZE.
        IF SY-SUBRC <> 0.
          CLOSE CURSOR G_CURSOR.
          RAISE NO_MORE_DATA.
        ENDIF.
        S_COUNTER_DATAPAKID = S_COUNTER_DATAPAKID + 1.
      ENDIF.
    ENDFUNCTION.
    I found some similar issue in this forum by link
    Generic Extractor Delta Function Module code, but still I could not get clear answer.
    Can you please help me:
    1)     why there is no value for i_source , how to fix it?
    2)     For the delta logic for ztimestemp, is it correct?
    3)     Need I modify the entries in ROOSOURCE ?
    Thanks a lot !!!

    Hello Andre,
            Thanks a lot for your help. I did some change , but still does not work. Could you please help check.
    Now the source code are the following, It's based on the RSAX_BIW_GET_DATA_SIMPLE, as you confirm that this also supply the update mode (full, initial delta, delta).
    FUNCTION RSAX_BIW_GET_DATA_TRAININGREC1.
    ""Local Interface:
    *"  IMPORTING
    *"     VALUE(I_REQUNR) TYPE  SRSC_S_IF_SIMPLE-REQUNR
    *"     VALUE(I_DSOURCE) TYPE  SRSC_S_IF_SIMPLE-DSOURCE OPTIONAL
    *"     VALUE(I_MAXSIZE) TYPE  SRSC_S_IF_SIMPLE-MAXSIZE OPTIONAL
    *"     VALUE(I_INITFLAG) TYPE  SRSC_S_IF_SIMPLE-INITFLAG OPTIONAL
    *"     VALUE(I_READ_ONLY) TYPE  SRSC_S_IF_SIMPLE-READONLY OPTIONAL
    *"     VALUE(I_REMOTE_CALL) TYPE  SBIWA_FLAG DEFAULT SBIWA_C_FLAG_OFF
    *"  TABLES
    *"      I_T_SELECT TYPE  SRSC_S_IF_SIMPLE-T_SELECT OPTIONAL
    *"      I_T_FIELDS TYPE  SRSC_S_IF_SIMPLE-T_FIELDS OPTIONAL
    *"      E_T_DATA STRUCTURE  ZTRN_REC_TIME OPTIONAL
    *"  EXCEPTIONS
    *"      NO_MORE_DATA
    *"      ERROR_PASSED_TO_MESS_HANDLER
    Auxiliary Selection criteria structure
      DATA: L_S_SELECT TYPE SRSC_S_SELECT.
    Maximum number of lines for DB table
      STATICS: S_S_IF TYPE SRSC_S_IF_SIMPLE,
    counter
              S_COUNTER_DATAPAKID LIKE SY-TABIX,
    cursor
              S_CURSOR TYPE CURSOR.
    Select ranges
    RANGES:
            L_R_ZTIMESTAMP FOR ZTRN_REC_TIME-ZTIMESTAMP.
    Initialization mode (first call by SAPI) or data transfer mode
    (following calls) ?
      IF I_INITFLAG = SBIWA_C_FLAG_ON.
    Initialization: check input parameters
                    buffer input parameters
                    prepare data selection
    Check DataSource validity
        CASE I_DSOURCE.
          WHEN 'ZTRNREC_FM'.
          WHEN OTHERS.
            IF 1 = 2. MESSAGE E009(R3). ENDIF.
    this is a typical log call. Please write every error message like this
            LOG_WRITE 'E'                  "message type
                      'R3'                 "message class
                      '009'                "message number
                      I_DSOURCE   "message variable 1
                      ' '.                 "message variable 2
            RAISE ERROR_PASSED_TO_MESS_HANDLER.
        ENDCASE.
        APPEND LINES OF I_T_SELECT TO S_S_IF-T_SELECT.
    Fill parameter buffer for data extraction calls
        S_S_IF-REQUNR    = I_REQUNR.
        S_S_IF-DSOURCE = I_DSOURCE.
        S_S_IF-MAXSIZE   = I_MAXSIZE.
    Fill field list table for an optimized select statement
    (in case that there is no 1:1 relation between InfoSource fields
    and database table fields this may be far from beeing trivial)
        APPEND LINES OF I_T_FIELDS TO S_S_IF-T_FIELDS.
      ELSE.                 "Initialization mode or data extraction ?
    Data transfer: First Call      OPEN CURSOR + FETCH
                   Following Calls FETCH only
    First data package -> OPEN CURSOR
        IF S_COUNTER_DATAPAKID = 0.
          LOOP AT S_S_IF-T_SELECT INTO L_S_SELECT WHERE FIELDNM = 'ZTIMESTAMP'.
          MOVE-CORRESPONDING L_S_SELECT TO L_R_ZTIMESTAMP.
          APPEND L_R_ZTIMESTAMP.
          ENDLOOP.
    Determine number of database records to be read per FETCH statement
    from input parameter I_MAXSIZE. If there is a one to one relation
    between DataSource table lines and database entries, this is trivial.
    In other cases, it may be impossible and some estimated value has to
    be determined.
         IF L_S_SELECT-LOW = '' AND L_S_SELECT-HIGH = ''.
            OPEN CURSOR WITH HOLD S_CURSOR FOR
            SELECT (S_S_IF-T_FIELDS)
            FROM ZTRN_REC_TIME.
            ELSE.
            OPEN CURSOR WITH HOLD G_CURSOR FOR
            SELECT (S_S_IF-T_FIELDS)
            FROM ZTRN_REC_TIME
            WHERE ZTIMESTAMP >= L_S_SELECT-LOW
            AND ZTIMESTAMP <= L_S_SELECT-HIGH.
         ENDIF.
        ENDIF.                             "First data package ?
    Fetch records into interface table.
      named E_T_'Name of extract structure'.
        FETCH NEXT CURSOR S_CURSOR
                   APPENDING CORRESPONDING FIELDS
                   OF TABLE E_T_DATA
                   PACKAGE SIZE S_S_IF-MAXSIZE.
        IF SY-SUBRC <> 0.
          CLOSE CURSOR S_CURSOR.
          RAISE NO_MORE_DATA.
        ENDIF.
        S_COUNTER_DATAPAKID = S_COUNTER_DATAPAKID + 1.
      ENDIF.              "Initialization mode or data extraction ?
    ENDFUNCTION.
    I think it already includes the important statements you suggested.
    I test this FM in RSA3, for the Full load mode, it works fine. Also if I checked the debug mode in execution , it will stop in the code and let me debug.
    But when I choose other mode, like 'initializion of the delta transfer'  or simulation of initial delta, I always get error 'error occurs  during the extraction' .. even I choose debug mode, but it could not enter the code for debug..
    Till now I did not see any parameter or value for the upload mode..
    Another questions is that, in RSO2, I define Ztimestamp as my delta field.. But , can I add other field as selection condition in the datasource definition, and has its range table in this function module ?
    Should I change the entries in ROOSOURCE for this datasource ??
    Please let me know your feedback, do you have some concret example for generic delta extraction ?
    Thanks a lot !

  • Generic delta extraction using function module

    Hi.
    I have a generic datasource , extraction being performed by a function module. The extraction works fine in full update mode. The extract structure has a timestamp field.
    I have enabled generic delta using this field(i.e., marked this field in RSO2). I understand that with this setting, I should be able to get delta data when I do a delta request. But it does not seem to happen.
    I checked the ROOSPRMSC table for the last(local) timestamp stored there. Now when I do the delta upload I expect to see only those records which are younger than the stored timestamp of last upload.
    But I still get the entire set of records.
    Questions are :
    1. Do I need to explicitly code for fetching the delta in the extractor ?
    2. If not, what could be the reason why generic delta is not working ?
    Thanks and regards,
    Anuradha

    Hi GFV,
    I read-up all the forum entries on this topic but could not find anything specifically dealing with my problem. I have browsed through the how-to paper on generic delta as well.
    I am quite sure that we don't need any special coding in the extrator for generating delta generically. Even the how-to paper does not mention that.
    I have used the FM RSAX_BIW_GET_DATA_SIMPLE as a template
    for my extractor(as suggested by F1 help in RSO2). This FM does not even have the i_updmode flag in its interface. 
    Thus this function module always does full extraction and I expect the system to take care of delta using the timestamp field.
    Are these assumptions incorrect ?
    Regards,
    Anuradha

  • Delta Problem while extracting the data by using function module

    Hi Experts,
    I have extracted the data by using Function module, for delta loads I have given Calday and additive delta in Generic delta settings, in BW side I have initialized the data after that I have given delta update option in infopackage and I made process chain also, every day process chain is running successfully but it is showing zero records, but there is a data in Data source (RSA3), means delta is not working.
    What is the problem,
    Is there any another settings for delta loads,
    Please help me to do this,
    Helpful answer will be appreciated with points,
    Regards,
    Venkat

    Hi,
    Try this delta type :NEW STATUS FOR CHANGED RECORDS.
    More information from Nagesh, this information may help
    1. New status for changed Records.
    2. Additive delta.
    New status for changed records means
    New Order
    order no quantity
    1000 10
    order changed to quntity 8. then 2 records will posted 2 BW in first case.
    1000 -10
    1000 8
    if you come to Additve delta.
    for the same case it will send the same record as
    1000 10
    changed records
    1000 -2
    this is the difference. New status with changed records should be used only in association with ODS not cube becoz we don't have overwrite option.
    Additive delta we can use for ODS and Cubes with update mode Addition.
    Regards,
    Satya

Maybe you are looking for