Show TOC

Tab Page: UpdatingLocate this document in the navigation structure


On the Update Parameters tab page, specify the update mode, the type of update in the data targets, error handling when loading and updating the data further, and time selection for time-dependent data.

Update Mode

You can choose from the following functions in the Scheduler:

Full update

A full update requests all data that corresponds to the selection criteria you determined in the scheduler.


In a certain period of time specified in the scheduler, 100,000 data records are accumulated. With a full update, all 100 000 data records are requested.

Using the Scheduler menu, you can indicate a request with full-update mode as Repair Full Request. This request can be updated into every data target, even if the data target already contains data from an initialization run or delta for this DataSource/source system combination, and has overlapping selection criteria.


Note: Using the full repair request to reload the data into the DataStore object after selectively deleting data from the DataStore object can result in inconsistencies in the data target. Updating this request can lead to duplicate data records in the data record when the repair request selections do not agree with the selections from selectively deleting from the DataStore object.

For information about selectively deleting from a DataStore object, seeDataStore Object Content.

Delta update

A delta update only requests data which has appeared since the last delta.


Before you can request a delta update, you must first initialize the delta process.

A delta update is only possible for loading from SAP source systems.

If a delta fails (status 'red' in the monitor) or the overall status of the delta request has been set to red manually, the next data request will be performed in repeat mode. A repeat request extracts the incorrect or incompletely loaded data from the failed delta request, along with any new data since the original request. A repeat can only be requested in the dialog. If data from the failed delta request has already been updated to the data targets, delete the data from the data targets affected. If you cannot delete the data from the data targets, duplicate data records may be produced when the repeat request is performed.

Initializing the delta process

To request deltas, you need to have initialized the delta process.

For selection criteria that do not overlap, several initialization criteria are possible for initializing the delta process when scheduling InfoPackages for data from an SAP system. This gives you the option of loading the relevant data for the delta process, step by step into the Business Information Warehouse. For example, you can load the data into BW for cost center 1000 in the first step, and the data for cost center 2000 in the second.

A delta requested after several initializations contains the super set of all the successful initial selections as a selection condition. This selection condition cannot be changed any more for the delta after this. In this example, data is loaded into BW for cost centers 1000 and 2000 with a delta.

The selections for initialization are made in the scheduler on the Select Data tab page.

You can display all initializations for a DataSource in the scheduler by choosing Scheduler → Initialization Selection for Source System. You can see whether an initialization selection has been executed and what the status of the initialization request is. From this dialog box, you can also transfer initialization selections into the scheduler, and delete selected initializations again. Choosing the pushbutton Initialization Request Status brings you to the monitor, where you can check the data request.


Deleting initializations that have been run and registered in delta administration from the delta administration

If you delete initializations from the delta administration, the delta administration is reset in the BW system as well as in the source system. You can only request deltas again if you have run a new initialization for this DataSource/source system combination.


If you delete initializations from the delta administration, no data is deleted in the BW system.

Note for DataStore objects:

If the delta process for your DataSource requires serialization, after deleting the initialization and performing a new initialization, you can no longer update this init request into the previously supplied DataStore objects as with all subsequently requested delta requests. This is because the old inits and deltas still exist there.

The system recognizes that there are now new inits and deltas that are not yet updated in the DataStore object and requires that they be updated. However, the selections of the new inits overlap with the selections of the old inits that still exist in the DataStore object, so that the new inits cannot be updated.

If the delta process for the DataSource requires serialization, the system does not activate the newly loaded inits or deltas in the DataStore object.

After init administration has been deleted, you also then have to delete the data that was loaded with these inits and their subsequent deltas into the supplied DataStore objects from the DataStore objects, before you can activate new inits and deltas.

For test purposes, you can initialize the delta process without transferring data. In the Update Parameters tab page, select the corresponding indicator. When the initialization simulation runs, BW and the source system create the help entries in all required tables, but do not load data. Afterwards, the monitor displays a loaded record. The init simulation request appears in all data targets into which data was updated, but only contains the help entries.


Delta initialization can only be simulated for DataSources from SAP source systems if the DataSource supports this. The corresponding indicator only appears in the Update tab page when this is the case.

Generic DataSources that you have set a generic delta for also support simulation of delta initialization.

The option of simulating delta initialization is generally offered for loading processes from other source systems (for example, file or non-SAP systems).

Converting Initialization InfoPackages on Delta InfoPackages

This function allows you to use an InfoPackage in one process chain for initialize the delta process and to perform the delta transfer. Conversion to the delta transfer is performed automatically after initialization. More information:Including InfoPackages for Delta Processes in Process Chains.

Early Delta Initialization

With early delta initialization, you have the option of writing the data into the delta queue or into the delta tables for the application during the initialization request in the source system. This means that you are able to execute the initialization of the delta process (the init request), without having to stop the updating of data in the source system. You can only execute an early delta initialization if the DataSource extractor called in the source system with this data request supports this.


Extractors that support early delta initialization were delivered with Plug-Ins as of Plug-In (-A) 2002.1.

You cannot run an initialization simulation together with an early delta initialization.

Build Initial Non-Cumulative

This update method is only available when you want to load data into a data target that contains a non-cumulative key figure.

Choose this update mode when loading non-cumulative data into BW for the first time. More information:Transferring Non-Cumulative Data into the BW System.

Error Handling

Error handling options allow you to define the system behavior for the following processing steps:

  • Transfer rules
  • Update rules
  • Master data, text, and hierarchy updates
  • InfoCube updates
  • Referential integrity of an InfoObject against master data tables or DataStore objects on the communication structure level.

Time Selection For Time-Dependent Data

Selections for the data that is to be requested with an InfoPackage is specified in the scheduler on the Data Selection tab page. The time selections for time-dependent data are specified on the Update tab page. The DATETO and DATEFROM fields, as well as the fields that are assigned to the 0DATETO and 0DATEFROM InfoObjects, are therefore not available as selection fields on the Data Selection tab page.


Time-dependent DataSources that use generic data extraction:

The time dependency of a DataSource that uses generic data extraction is identified by containing selectable fields with the names DATETO and DATEFROM. If the table that you want to extract data from displays the time-dependency with field names other than DATETO / DATEFROM (DATBI / DATAB for example ), you have to create a database view that maps these fields to DATETO / DATEFROM. If the DataSource already exists, it needs to be regenerated. Otherwise, changes in the database view will not be carried over to the generated extraction structure.

Time-dependent DataSources for Business Content:

In DataSources that are delivered in Business Content, time-dependency can also be displayed with other field names. The corresponding fields then need to be assigned to InfoObjects 0DATETO and 0DATEFROM. This guarantees that they are treated in exactly the same way in terms of selection as fields with field names DATETO and DATEFROM are treated during generic extraction.

Various options are available for selecting time-dependent data that you want to load into the BW:

  • Fixed time interval
  • Creating a routine

    You use this routine to specify complex time selections for the data that you want to request. For example, when you only want to load the data for specific times that cannot be determined by an interval or a variable.

  • Using variables (seeVariables)

    Variables are placeholders for values and are replaced with concrete values when data is requested. For example, you use the variable 0CMONTH to load the data for the current calendar month.


The way that selections are filled at runtime depends on theprocessing type for the variable. For time selections, you cannot use any variables that use a replacement path or require manual input.

The system does not check for data type and length when selecting variables. If errors occur, they are not found until the runtime of the data request. However, you can display the selections for a particular variable by choosing Check. The system displays the restrictions that would apply when data is requested in a table. If the variable cannot be used to determine the selection conditions, an error is produced and the display is terminated.


You should only create variables (inBEx Query Designer) for time selection if you want to use the resulting selection condition in several InfoPackages.Use a routine for time selection if a simple interval or existing variables are not sufficient.