Delta Extraction

With delta extraction, only the data that has changed since the last extraction is loaded into the BW. Data that has already been loaded and has not changed is not extracted and does not need to be deleted before a new load. This improves performance compared with periodic extraction of the entire dataset.

Determining the Delta Dataset

Delta datasets are determined by the selection of CO line items. This is done using the time stamp (COEP-TIMEST). The time stamp specifies the starting time for determining the delta dataset. SAP R/3 always logs two time stamps at once. These time stamps delimit a selection interval for each DataSource (dataset in SAP R/3 or another source system) and each update mode.

The following update modes are used:

Update Mode	Explanation
Delta init	Determines the beginning inventory; can be run multiple times for each DataSource with enhanced selection criteria.
Delta update	Determines and loads the delta dataset.
Full update	Determines and loads the entire dataset. You need to delete the data in the BW before reloading.

The time required to update a line item restricts the timeliness of the data in the delta update and delta init modes.

SAP R/3 requires a certain amount of time to update line items. Since the time stamp is set when the update begins rather than when it is completed, there may be a lag between the time stamp and the actual time of the update event. Because of this lag, some line items may not yet be updated to the database even though their time stamp is within your selection conditions. Consequently, they cannot be selected when you create a delta dataset and are not loaded into the BW.

By specifying a safety time (the time during which line items can be safely updated), you can ensure that line items are extracted and loaded into the BW despite the lag between the time stamp and the update event. Two hours is the standard value for the safety time.

You should only reduce the standard value for the safety time if you are sure that your system can update all line items safely within the new safety time.

You can define the safety time using the BWOM2_V_SAFETY view in the OLTP system as follows:

·        You can use different safety times in minutes for each DataSource.

·        A safety time that does not refer to a DataSource applies to all DataSources for which you have not made a special entry.

A database index (index 4) is provided for the COEP CO line item table via the time stamp (COEP-TIMEST). This time stamp is not active in the standard system. In case of performance problems, you can improve data extraction performance by activating index 4.

COEP line items cannot be changed after they have been created, except for the document text. If the document text is changed in SAP R/3, the COEP-TIMESTMP field is not updated. For this reason, changed document texts cannot be transferred to the BW using delta extraction.

In full update mode, the system cannot select any CO line items based on the time stamp. All line items that are appropriate for the DataSource and that were selected in the InfoPackage are transferred to the BW. A subsequent delta update is not possible, as the system does not log a time stamp.

With commitments, the line items are not simply generated once and then never changed (as with the costs), but are changed on a continuing basis as the commitment is reduced. For this reason it is not sufficient to extract just the new records to the BW. Instead, all changed records must be extracted and the delta against the previously extracted version of each record must be determined. This delta determination takes place in the ODS objects in the BW. In delta mode, therefore, the commitments extractors extract all line items that have changed since the last delta; these line items are extracted in their changed form (after-image). For this reason, commitments line items can only be analyzed through the use of ODS objects.

Deleted records are a special case. If records are deleted in R/3, they are not extracted. For this reason, the records are not deleted in the BW. To solve this problem, after the first delta init is executed all deleted commitments line items are written to a special R/3 table (COOI_PI), and this table is extracted as well.

Reducing the Fields in the Transfer Structure

You can define a transfer structure in the BW for each InfoSource and source system. The transfer structure contains the fields you selected by means of transfer rules to load the corresponding data into the BW.

The transfer structure in the BW corresponds to the extract structure in SAP R/3 or another source system. The extract structure contains the maximum possible number of fields for which you can extract data from a source system and load the data into the BW.

·         To improve performance and minimize the transfer time from the source system into the BW:

·         Decide which fields in the extract structure you require for your reports.

·         Add only those fields to the transfer structure.

·         If the standard transfer structures and InfoSources do not meet your requirements, copy them and then modify them as needed. All delta-update-compatible DataSources are intended as a basis for defining your own InfoSources.

·         If you only want to display aggregated data, do not add the fields document number, posting row, or document row text to your transfer structure.

Loading Actual and Planning Data into the Same InfoCube

You can load actual and planning data into the same InfoCube. You combine data from InfoSources that are compatible with delta updates, and with InfoSources that are compatible with full updates.

SAP provides InfoSources for actual data. These InfoSources contain delta datasets and are thus compatible for delta updates. Only a full update is possible for the following data:

·        Plan values

·        Down payments

·        Overall plan values

·        Variances

·        Accrual calculations

·         If you load actual and plan data into the same InfoCube, you need to restrict the value type (0VTYPE) when you create an InfoPackage in the InfoSources that are compatible with full updates. This prevents actual data from being loaded from these InfoSources, which would result in the actual data being duplicated in the InfoCube.

You can load the actual data from the InfoSources that are compatible with the delta update. This enables you to avoid deleting actual data that already exists in the BW.

·         If you want to load actual and plan data into different InfoCubes (for example, actual data into one InfoCube and plan data into another), you need to restrict the value type (0VTYPE) in the update rules.

·         InfoSources that are compatible with the delta update have a larger number of characteristics. For this reason, they provide more detailed information for the Actual value type than the InfoSources that are compatible with full updates.

·         The additional characteristics provided by the InfoSources compatible with delta updates (such as the material number) are not filled by the system for planning values in the InfoCube.