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 theScheduler menu, you can indicate a request with full-update mode asRepair 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

Wednesday, July 17, 2024 L&T Infotech Proprietary

Page 1 of 5
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:

Wednesday, July 17, 2024 L&T Infotech Proprietary

Page 2 of 5
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 notactivate 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 theUpdate
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.

Wednesday, July 17, 2024 L&T Infotech Proprietary

Page 3 of 5
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 handlingoptions 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.

Wednesday, July 17, 2024 L&T Infotech Proprietary

Page 4 of 5
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.

Wednesday, July 17, 2024 L&T Infotech Proprietary

Page 5 of 5