Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 10

Time Stamp,Calday & Numeric Pointer in Generic

Delta
Time Stamps in SAP source tables where the date and time of an activity are concatenated together into a
single 15-digit field. For example, 11-Dec-2009 @ 1:00:00.0 PM would be designated in a Time Stamp defined field
as 200912111300000 (YYYYMMDDHHMMSSS format).

Calendar Day in SAP source source tables is defined as a data type of D or DATS. It contains 8-digits for the date
in YYYYMMDD format.

Numeric Pointer in SAP source tables is a field that contains a numeric pointer. For example, the Sales Order
Number on the Sales Order Header table (VBAK-VBELN) would be considered a potential Numeric Pointer for
generic delta, even though it has been defined as a character (data type of C or CHAR) of 10-bytes because it
contains all numeric data. This type of generic delta can only be used for new records. It will not be able to
determine if changes have been made to an existing Number Pointer field.

For a numeric pointer to work, there are two prerequisites:

The pointer field (normally an ID) must be continuously increasing. So a record created
right now must always have a higher ID than the one created say an hour ago
No updates to existing records

One thing that should be pointed out about using the built-in generic delta functionality. It only allows identification of
one field to use for delta. In a substantial amount of cases, however, there are more than one field that need to be
used for determining delta (e.g. Created On and Changed On dates). In these cases, this delivered functionality for
creating generic delta cannot be used and you will have to create a Function Module to not only programmatically

handle the delta logic, it would also have to be used as the source for the generic DataSource as well (even if you're
just extracting data out of one SAP source table).

How to enable Delta Mechanism for Generic Extractors

3 Types of Delta Mechanism for Generic Extraction


1. CALDAY 2. Time Stamp 3.Numaric Point
Delta Mechanism with CALDAY: I have a table VBAK VBELN, ERDAT, AUDAT, NETWR
We can set up delta mechanism based on CALDAY (Data Source Capability) when we have changed Date
filed in data source
AUDAT will give latest changed date

VBELN

4965

ERDAT

AUDAT

NETWR

01.01.2006

01.01.2006

5000

4966

02.01.2006

02.01.2006

1000

4967

05.02.2006

05.02.2006

15000

4968

06.07.2007

06.07.2007

20000

4965

01.01.2006

09.07.2007

9000

If we run Initialization Delta on 03.01.2006 It will Pick 4965 & 4966


If we run Delta on 05.02.2006 at night 12o clock it will Pick 4967 records (previously loaded records date
>& TILL 05.02.2006 date)
If we run Delta on 10.07.2007 It will Pick 4968 & 4965
Limitations of Delta Mechanism with CALDAY: Multiple Deltas cannot be run on same day because it will
not consider time factor. If the Delta Mechanism set up with CALDAY we can run delta only once per day
at the end of day
2. Delta Mechanism with Time Stamp: Since Delta is Time stamp; we can run the delta number of times. If
you setup Delta with Time Stamp we need to have Time Stamp Field in the source (UPD_TMSTMP)
3.Delta Mechanism with Numeric Point: If we set the delta based on numeric Point, it can only recognizes
the newly added records but not the modified records
Safety Interval: Lets assume your delta run on Sunday, Thursday and Saturday. And you last run was on
Sunday and next Run is on Thursday.
In this case if you have set the lower limit to 1, the delta run of Thursday will fetch data from Saturday till
Thursday.
"Delta management can take the lower limit from the last extraction.
The lower limit for safety interval contains the value that needs to be taken from the highest value of the
previous extraction to obtain the lowest value of the following extraction." E.g: You can say Lower limit =
Highest value of last extraction- safety interval.

Example: Lower Limit = 2, Upper Limit = 1

Example: Lower Limit = 0, Upper Limit = 0

Tips:

If delta field is Date (Record Create Date or change date), then use Upper Limit of 1 day. This will load
Delta in BI as of yesterday. Leave Lower limit blank.
If delta field is Time Stamp, then use Upper Limit of equal to 1800 Seconds (30 minutes). This will load
Delta in BI as of 30 minutes old. Leave Lower limit blank.

NOTE: Safety interval should be set so that no document is missed even if it was not stored in the DB
table when the extraction took place.

Select Delta type:


New status for changed records (I.e. after-image); this can be used with Data target DSO (AIE).
Additive Delta (I.e. aggregated data records) (ADD); Compatible with Info cube & DSO

Delta-Specific Field for Generic DataSource

Q)I have defined a Generic DataSource for Transaction data on R/3-Side.


This DataSource is based on View/Table EKKO (Purchasing Document Header) for some specific customer
requirements. Delta-Specific Field is AEDAT (Calend. Day). Safety Interval Upper Limit is set 1 Cal. Days. No Safety
Interval Lower Limit has been defined. "New Status for Changed Records" has been marked.

When we see this DataSource in Extractor Checker (RSA3), this data source

Extracted all delta data where AEDAT is not blank.

When I see the content of table EKKO, I can find few records where AEDAT is blank.
These records are missing in Extractor Checker.

How I can solve this problem? Which delta-specific field can be used in
this generic Datasource? Should I define an additional Generic DataSource with
Delta-Specific Field BEDAT (as BEDAT is filled when AEDAT is blank in table EKKO)?

Answer1 :

Hi,

In order to capture delta on EKAB table, you will have to create two generic datasource, one having a delta on
"BEDAT" i.e. "Purchase Order Date" and other having a delta on "AEDAT" i.e. "Changed On". This is because when a
record gets created in this table, "BEDAT" is populated and "AEDAT" is blank. When a change occurs, "AEDAT" is
populated. So, your first generic datasource will capture the records created and the second will capture the records
changed.

As AEDAT is delta field it will take up only those records for which AEDAT date is greater that last execution date.
Record for which AEDAT is coming blnk for them it is obvious that their date will be 00.00.0000 which can not be
greater than any date. hence it is missing those records

Generic Delta with FM using two date fields


Hello -

We want to do a delta load using a generic extractor based on two fields - ERDAT, AEDAT.
If AEDAT is initial, use ERDAT; else, use AEDAT.

Questions:
1/ Is this possible using a generic extractor
2/ How do I use a FM with Gen Delta option (asks for Table not FM)
3/ Will I have to do delta management myself (i.e., keep track of the last delta date, and do AEDAT/ERDAT > last
delta date)

Answer :

1/ Yes, you can create a single delta enabled generic DS built on 2 date fields
2/ Function Module Created : Z_SAX_BIW_GET_DATA_SIMPLE, and extract structure: ZOXECX0114 ---> Of course
this will be your own
3/ Delta built on dummy date : ZZDLDAT
4/ Here I am extracting from AFRU using 2 dates:
FUNCTION Z_SAX_BIW_GET_DATA_SIMPLE.
*"---""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 ZOXECX0114 OPTIONAL
*" EXCEPTIONS
*"
NO_MORE_DATA
*"
ERROR_PASSED_TO_MESS_HANDLER
*"----

Example: DataSource for table SFLIGHT


TABLES: AFRU, ZOXECX0114.

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_AUFNR FOR AFRU-AUFNR,


L_R_VORNR FOR AFRU-VORNR,
L_R_RUECK FOR AFRU-RUECK,
L_R_ZZDLDAT FOR AFRU-ERSDA.

data: x.
*

while x is initial.
endwhile.

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 'ZAFRU2'.
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.


DELETE S_S_IF-T_FIELDS WHERE FIELDNM = 'ZZDLDAT'.
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.

Fill range tables BW will only pass down simple selection criteria
of the type SIGN = 'I' and OPTION = 'EQ' or OPTION = 'BT'.
LOOP AT S_S_IF-T_SELECT INTO L_S_SELECT WHERE FIELDNM = 'AUFNR'.
MOVE-CORRESPONDING L_S_SELECT TO L_R_AUFNR.
APPEND L_R_AUFNR.

ENDLOOP.
LOOP AT S_S_IF-T_SELECT INTO L_S_SELECT WHERE FIELDNM = 'VORNR'.
MOVE-CORRESPONDING L_S_SELECT TO L_R_VORNR.
APPEND L_R_VORNR.
ENDLOOP.
LOOP AT S_S_IF-T_SELECT INTO L_S_SELECT WHERE FIELDNM = 'RUECK'.
MOVE-CORRESPONDING L_S_SELECT TO L_R_RUECK.
APPEND L_R_RUECK.
ENDLOOP.
LOOP AT S_S_IF-T_SELECT INTO L_S_SELECT WHERE FIELDNM = 'ZZDLDAT'.
MOVE-CORRESPONDING L_S_SELECT TO L_R_ZZDLDAT.
APPEND L_R_ZZDLDAT.
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.
OPEN CURSOR WITH HOLD S_CURSOR FOR
SELECT (S_S_IF-T_FIELDS) FROM AFRU as itm
WHERE itm~AUFNR IN L_R_AUFNR AND
itm~VORNR IN L_R_VORNR AND
itm~RUECK IN L_R_RUECK AND
(
( itmLAEDA EQ '00000000' AND itmERSDA IN L_R_ZZDLDAT )
OR
( itmLAEDA NE '00000000' AND itmLAEDA IN L_R_ZZDLDAT )
).

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.
ENDFUNCTION.

"Initialization mode or data extraction ?

You might also like