Tab Page: Updating 

Use

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

The following update functions are available 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, see DataStore 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.

Initialization of 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 BI for cost center 1000 in the first step, and the data for cost center 2000 in the second step.

A delta requested after several initializations, contains the super set of all the successful initial selections as a selection condition. This selection condition can then no longer be changed for the delta. In this example, data is loaded into BI 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 BI 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.

Note:

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

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.

In this case, after init administration has been deleted, you also 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, BI 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, for which you have set a generic delta, also support the 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).

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 BI for the first time. For more information, see Transferring Non-Cumulative Data into the BI System.

Error Handling

Error handling options allow you to determine system behavior with 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.

how the system behaves.

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. Note the following: If, in the table from which you want to extract data, time-dependency is displayed in fields with names other than DATETO / DATEFROM (for example, DATBI / DATAB), you have to create a database view that maps these fields to DATETO / DATEFROM. If the DataSource was already created, regenerate it. Otherwise, changes in the database view will not be transferred into the generated extraction structure.

Time-dependent DataSources for Business Content:

In DataSources that are delivered in Business Content, time-dependency can also be partially displayed with field names other than DATETO and DATEFROM.

If the DataSource in BI is a DataSource 3.x (object type R3TR ISFS), by assigning the corresponding fields to the InfoObjects 0DATETO and 0DATEFROM, transfer rule maintenance can ensure that the selection of the DataSource is handled in precisely the same way as for generic extraction of the fields with field names DATETO and DATEFROM..

If the DataSource exists as object type R3TR RSDS, this kind of assignment is not possible.

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

●      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 (see Variables)

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 the processing 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.

We recommend that you create variables (in the BEx Query Designer) for time selection only if you want to use the resulting selection condition in several InfoPackages. Use a routine for time selection, if a simple interval or variables that already exist are not sufficient.