Escolar Documentos
Profissional Documentos
Cultura Documentos
www.ko-india.com
www.ko-india.com
Calendar day This seems like a good candidate, what with most data tables having fields like Change date. It is. However, before using it, we need to understand how BW/S-API uses it. Let us say AEDAT is the field in the view from which we are extracting the delta. For one, S-API filters data based on system date, and extracts data up to today only (if there is no safety interval specified). Another thing to note (both for timestamp and date) is that the delta pointer stores the calendar day (and system timestamp) values in the pointers, not the largest value in the extracted data. To clarify this, Let us say we run the extraction of 08/04 (MM/DD), records will be selected up to AEDAT value of 08/04. Let us say, we had records for 08/01, and 08/02, and these were extracted successfully. The pointer in RSA7 will not have 08/02, but 08/04. For any reason, if there are now records added with value of 08/03 (because they are updated from some other system and there is a one day delay), these would not be extracted in the next run. Next run would extract data for 08/05 onwards, and you may wonder how come you got data up to 08/02 and then for 08/05 but the 08/03 data is not selected. But that is logical, as it is CALDAY, not AEDAT that essentially is being used by the system to store the pointer. Also, if you put data for a future date expecting it to be selected (as it is higher than current pointer value), that will also not work. In effect, S-API will apply filter as AEDAT GT pointer_value AND AEDAT le current_date. One limitation is that you can get data only up to a date, so it can bring delta only once a day. Another thing to note is what happens if records are posted on the same date after extraction has happened? These records will not be selected. To avoid this, it makes sense to only extract data up to yesterday. This is achieved by setting the safety interval limit (upper) to 1, which adjusts the selection to up to current date minus one.
Timestamp
Timestamp seems to be the most obvious preference, since you can get the latest delta to BW. However, in most cases, it is not easy to find a timestamp field (you do have change_date and change_time fields, but not one field with change_date and time in most tables). You also need to be aware of the fact that SAP applies system-timestamp values for selecting the data. So, similar to example above, Let us say you are extracting at 20060804000000, you get all data up to 2006080400000. This value is stored in the pointer (20060804000000). However, your source table is getting updated by a timestamp value of another system (say by getting it from a file, or, from RFC call, whatever) and is not in sync with SAP server time. Now, after this extraction, another record comes to the underlying table which has a timestamp value of 20060803230001 (because it is coming from PuertoRico instead of Hawaii, say). Now, this record is not going to be extracted in the next delta (or any delta afterwards), because its timestamp value is lower than the pointer from the last extraction. The case where the timestamp field is being updated with a value/field other than the source system current timestamp is a different issue than that of the system taking a finite amount of time in updating the record; the later being handled by using safety interval limits.
www.ko-india.com
Upper limit (5), lower limit (1) [specified in safety intervals] Case 1 Numeric pointer (last extracted value 10011; Data in underlying table (Max value = 10025) ) Data would be extracted from a min-value of 10010 (lower limit adjusts the last counter 10011 by specified value 1) max-value of 10020 (after adjustment for upper safety limit by 5). The current pointer would now indicate 10020 in RSA7. Case 2 Timestamp (Last extracted value 20060804113000; current system time: 20060805080000) Next extraction will select records from timestamp value 20060804112959 (after adjusting 1 second as specified in lower limit) to timestamp value 20060805075955 (adjusting it by 5 seconds as specified in upper limit). Similar would be the case for calendar days, however, since there is not a likelihood of records overlapping over days, the limits are not used for such delta type. For more understanding of these limits, do an F1 on these fields in RSO2. It also explains why and when one may need to specify these limits. Since the lower safety interval limit adjusts the lower selection value of the delta identifier field, it could be possible that some records are brought twice. One needs to be mindful of this fact (and so it shall go to an overwrite type of ODS first), and for this reason, it is only available if the datasource is defined as new status for changed records and not for additive delta.
This sets the delta property of the datasource. Depending on its value, the datasource may by incompatible to certain data targets. For example, if it is additive delta (ROOSOURCE-DELTA = ADD), it may not be fit for updating into an ODS with overwrite. For New image option, the field ROOSOURCE-DELTA is set to AIE.
www.ko-india.com
What do I get my function module to work with in case of delta (in addition to template FM)?
This is not in scope of this document. However, in brief one point is worth mentioning. You get your selections coming from the info-source (or RSA3) in the internal table I_T_SELECT when the first call to FM is made. What is not obvious is that you are also getting the selection for the delta-pointer field in this same table, being added by S-API. Let us say, you specified AEDAT as the delta identifier field. Your infopackage is sending a request to select data based on CO_CODE and CURR_TYPE fields. You will get corresponding entries in I_T_SELECT table with the selection values for CO_CODE and CURR_TYPE fields which you can read and accordingly select data in your FM. In addition, I_T_SELECT will also have selection values for AEDAT. This would have been appended by S-API, and it would be based on the current pointer entry that you see in RSA7, and current date (in case of CALDAY type delta). Similar would be the case for any other type of delta-identifier field.
www.ko-india.com
You can try updating the delta pointer fields (in table ROOSGENDLM) prior to extraction to do a different delta selection (for example for a delta that you accidentally deleted, and you want to bring it again). This, as the heading suggests, entails some risk and shall be tried with required caution (and loads of testing).