Registerkarte: Fortschreibung 

Verwendung

Auf der Registerkarte Fortschreibungsparameter legen Sie den Fortschreibungsmodus, die Art der Verbuchung in die Datenziele, die Fehlerbehandlung beim Laden und Weiterverbuchen der Daten sowie die Zeitselektionen für zeitabhängige Daten fest.

Fortschreibungsmodus

Im Scheduler stehen Ihnen folgende Update-Funktionen zur Verfügung:

Full-Update

Ein Full-Update fordert alle Daten an, die den von Ihnen im Scheduler festgelegten Selektionskriterien entspricht.

In einem im Scheduler bestimmten Zeitraum fallen 100 000 Datensätze an. Bei einem Full-Update würden alle 100 000 Datensätze angefordert werden.

Einen Request mit Fortschreibungsmodus Full-Update können Sie über das Menü Scheduler als Reparatur-Full-Request kennzeichnen. Dieser Request ist in jedes Datenziel verbuchbar, auch wenn dieses schon Daten aus einem Initialisierungslauf oder Deltas zu dieser DataSource/Quellsystem-Kombination enthält und überlappende Selektionsbedingungen hat.

Wenn Sie den Full-Reparatur-Request beispielsweise verwenden, um nach dem Selektiven Löschen von Daten aus dem DataStore-Objekt erneut die Daten ins DataStore-Objekt zu laden, müssen Sie beachten, dass dies zu Inkonsistenzen im Datenziel führen kann. Wenn die Selektionen des Reparatur-Requests nicht mit den Selektionen beim selektiven Löschen aus dem DataStore-Objekt übereinstimmen, kann das Einbuchen dieses Requests z.B. zu doppelten Datensätzen im Datenziel führen.

Informationen zum selektiven Löschen aus einem DataStore-Objekt finden Sie unter Inhalt des DataStore-Objekts.

Delta-Update

Ein Delta-Update fordert jeweils nur die Daten an, die seit dem letzten Delta angefallen sind.

Bevor Sie einen Delta-Update anfordern können, müssen Sie erst die Initialisierung des Deltaverfahrens durchführen.

Ein Delta-Update ist nur für das Laden aus SAP Quellsystemen möglich.

Wenn ein Delta fehlgeschlagen ist (Status rot im Monitor) oder der Gesamtstatus des Delta-Requests manuell auf rot gesetzt wurde, so wird die nächste Datenanforderung im Repeat-Modus durchgeführt. Bei einer Repeatanforderung werden die falsch oder unvollständig geladenen Daten der fehlerhaften Deltaanforderung sowie die seither angefallenen Daten extrahiert. Ein Repeat kann nur im Dialog angefordert werden. Sind die Daten des fehlerhaften Delta-Requests bereits in Datenziele fortgeschrieben worden, löschen Sie die Daten aus den betreffenden Datenzielen. Wenn Sie die Daten nicht aus den Datenzielen löschen, kann dies beim Repeat zu doppelten Datensätzen führen.

Initialisierung des Deltaverfahrens

Die Initialisierung des Deltaverfahrens ist Voraussetzung für das Anfordern von Deltas.

Zur Initialisierung des Deltaverfahrens beim Einplanen von InfoPackages für Daten aus einem SAP-System ist für verschiedene, nicht überlappende Selektionsbedingungen mehr als eine Initialisierungsselektion möglich. Somit haben Sie die Möglichkeit, die für das Delta-Verfahren relevanten Daten schrittweise in das Business Information Warehouse zu laden. Sie können beispielsweise in einem ersten Schritt die Daten zur Kostenstelle 1000 und in einem zweiten Schritt die Daten zur Kostenstelle 2000 ins BI laden.

Das nach mehreren Initialisierungen angeforderte Delta enthält als Selektionsbedingung die Obermenge aller erfolgreicher Init-Selektionen. Diese Selektionsbedingung kann für das Delta dann nicht mehr verändert werden. Im Beispiel würden bei einem Delta Daten zu den Kostenstellen 1000 und 2000 ins BI geladen werden.

Die Selektionen für eine Initialisierung werden im Scheduler auf der Registerkarte Daten selektieren vorgenommen.

Im Scheduler können unter Scheduler à Initialisierungselektion für Quellsyst. alle Initialisierungen zu einer DataSource angezeigt werden. Es wird Ihnen angezeigt, ob eine Initialisierungs-Selektion ausgeführt wurde und welchen Status der Initialisierungsrequest hat. Sie können von diesem Dialogfenster aus auch Initialisierungs-Selektionen in den Scheduler übernehmen und ausgewählte Initialisierungen wieder löschen. Über die Drucktaste Status des Initialisierungsrequests gelangen Sie in den Monitor und können die Datenanforderung überprüfen.

Löschen von durchgeführten und in der Deltaverwaltung registrierten Initialisierungen aus der Deltaverwaltung

Wenn sie Initialisierungen aus der Deltaverwaltung löschen, wird die Deltaverwaltung im BI sowie im Quellsystem zurückgesetzt. Sie können dann erst wieder Deltas anfordern, wenn für diese DataSource/Quellsystem-Kombination eine neue Initialisierung durchgeführt worden ist.

Beachten Sie:

Wenn sie Initialisierungen aus der Deltaverwaltung löschen, werden keinerlei Daten im BI gelöscht.

Beachten Sie für DataStore-Objekte:

Wenn das Delta-Verfahren Ihrer DataSource Serialisierung vorschreibt, können Sie nach dem Löschen der Initialisierung und einer Neu-Initialisierung diesen Init-Request ebenso wie alle danach angeforderten Delta-Requests nicht mehr in die vorher versorgten DataStore-Objekte einbuchen, da in diesen die alten Inits und Deltas noch vorhanden sind.

Das System erkennt, dass es mittlerweile neue Inits und Deltas gibt, die noch nicht im DataStore-Objekt verbucht sind, und verlangt deren Verbuchung. Andererseits überschneiden sich die Selektionen der neuen Inits mit den Selektionen der alten Inits, die noch im DataStore-Objekt vorhanden sind, so dass die neuen Initis nicht eingebucht werden können.

Wenn das Delta-Verfahren der DataSource Serialisierung vorschreibt, aktiviert das System die neu geladenen Inits bzw. Deltas nicht im DataStore-Objekt.

In diesem Fall müssen Sie nach dem Löschen der Init-Verwaltung auch die Daten, die mit diesen Inits und darauffolgenden Deltas in die versorgten DataStore-Objekte geladen wurden, aus diesen DataStore-Objekten löschen, bevor Sie neue Inits und Deltas aktivieren können..

Zu Testzwecken können Sie eine Initialisierung des Delta-Verfahrens ohne Datenübertragung ausführen. Markieren Sie dazu auf der Registerkarte Fortschreibungsparameter das entsprechende Kennzeichen. Wenn die Initialisierungssimulation läuft, werden im BI und im Quellsystem die Hilfseinträge in allen benötigten Tabellen gemacht, jedoch ohne Daten zu laden. Im Monitor wird anschließend ein geladener Satz angezeigt. Der Init-Simulationsrequest erscheint in allen Datenzielen, in die fortgeschrieben wurde, enthält aber nur die Hilfseinträge.

Eine Simulation der Delta-Initialisierung ist für DataSources aus SAP Quellsystemen nur möglich, wenn die DataSource dies unterstützt. Nur in diesem Fall wird das entsprechende Kennzeichen auf der Registerkarte Fortschreibung angeboten.

Generische DataSources, für die Sie ein generisches Delta festgelegt haben, unterstützen die Simulation der Delta-Initialisierung ebenfalls.

Für Ladeprozesse aus weiteren Quellsystemen (z.B. Datei oder Fremdsystem) wird die Möglichkeit einer Simulation der Delta-Initialisierung generell angeboten.

Early-Delta-Initialisierung

Mit der Early-Delta-Initialisierung haben Sie die Möglichkeit, bereits während der Initialisierungsanforderung im Quellsystem die Daten in die Delta-Queue bzw. in die Deltatabellen der Anwendung zu schreiben. Sie können somit die Initialisierung des Delta-Verfahrens, d.h. den Init-Request, durchführen, ohne die Verbuchung der Daten im Quellsystem stoppen zu müssen. Die Möglichkeit, eine Early-Delta-Initialisierung durchzuführen, steht Ihnen nur zur Verfügung, wenn der mit dieser Datenanforderung im Quellsystem aufgerufene Extraktor der DataSource  dies unterstützt.

Extraktoren, die die Early-Delta-Initialisierung unterstützen, werden frühestens mit Plug-In (-A) 2002.1 ausgeliefert.

Sie können keine Initialisierungssimulation mit einem Early-Delta zusammen ausführen.

Anfangsbestand aufbauen

Dieser Fortschreibungsmodus steht Ihnen nur zur Verfügung, wenn Sie in ein Datenziel laden wollen, das eine Bestandskennzahl enthält.

Diesen Fortschreibungsmodus wählen Sie, wenn Sie erstmals Bestandsdaten ins BI laden. Weitere Informationen finden Sie unter Übertragung von Bestandsdaten ins BI-System.

Fehlerbehandlung

Die Optionen der Fehlerbehandlung geben Ihnen die Möglichkeit, das Verhalten des Systems bei den Verarbeitungsschritten

·         Übertragungsregeln

·         Fortschreibungsregeln

·         Stammdaten-, Text- und Hierarchie-Update

·         InfoCube-Update

·         referentielle Integrität eines InfoObjects gegen Stammdatentabellen oder DataStore-Objekte auf der Ebene der Kommunikationsstruktur

zu bestimmen.

Zeitselektion für zeitabhängige Daten

Selektionen für die mit einem InfoPackage anzufordernden Daten werden im Scheduler auf der Registerkarte Datenselektion festgelegt. Die Zeitselektionen für zeitabhängige Daten werden hingegen auf der Registerkarte Fortschreibung festgelegt. Die Felder DATETO und DATEFROM sowie die Felder, die den InfoObjects 0DATETO und 0DATEFROM zugeordnet sind, stehen daher nicht als Selektionsfelder auf der Registerkarte Datenselektion zur Verfügung.

Zeitabhängige DataSources, die generische Datenextraktion nutzen:

Die Zeitabhängigkeit einer DataSource, die generische Datenextraktion nutzt, ist dadurch gekennzeichnet, dass sie selektierbare Felder enthält, deren Feldnamen DATETO und DATEFROM heißen. Daher ist folgendes zu beachten: Wenn in der Tabelle, aus der extrahiert werden soll, die Zeitabhängigkeit mit anderen Feldnamen als DATETO / DATEFROM dargestellt wird (z.B. DATBI / DATAB), muss ein Datenbank-View angelegt werden, der diese Felder auf DATETO / DATEFROM abbildet. Falls die DataSource schon vorher angelegt war, muss sie nachgeneriert werden. Sonst werden Änderungen des Datenbank-Views nicht in die generierte Extraktstruktur übernommen.

Zeitabhängige DataSources des Business Content:

In DataSources, die im Business Content ausgeliefert werden, wird die Zeitabhängigkeit teilweise auch mit anderen Feldnamen als DATETO und DATEFROM dargestellt.

Solange die DataSource im BI als DataSource 3.x (Objekttyp R3TR ISFS) existiert, kann in der Pflege der Übertragungsregeln durch eine Zuordnung der entsprechenden Felder zu den InfoObjects 0DATETO und 0DATEFROM erreicht werden, dass sie bezüglich der Selektion genauso behandelt werden wie bei der generischen Extraktion die Felder mit den Feldnamen DATETO und DATEFROM.

Wenn die DataSource im Objekttyp R3TR RSDS vorliegt ist eine solche Zuordnung nicht möglich.

Für die Auswahl von zeitabhängigen Daten, die Sie ins BI laden wollen, stehen Ihnen verschiedene Möglichkeiten zur Verfügung:

●      Festes Zeitintervall

●      Anlegen einer Routine

Mit Hilfe der Routine können Sie komplexe Zeitselektionen für die anzufordernden Daten festlegen, z.B. wenn Sie nur die Daten bestimmter Zeiten laden wollen, die sich nicht durch ein Intervall oder eine Variable festlegen lassen.

●      Verwendung von Variablen (siehe Variablen)

Variablen dienen als Platzhalter für Werte und werden erst bei einer Datenanforderung durch konkrete Werte ersetzt. Mit Hilfe der Variablen 0CMONTH  können Sie beispielsweise die Daten des aktuellen Kalendermonats laden.

Wie die Selektionen zur Laufzeit befüllt werden, hängt von der Verarbeitungsart der Variablen ab. Sie können für die Zeitselektionen keine Variablen verwenden, die einen Ersetzungspfad benutzen oder manuelle Eingabe erfordern.

Beim Auswählen der Variable prüft das System nicht auf Datenart und –länge. Fehler werden ggf. erst zur Laufzeit der Datenanforderung erkannt. Sie können sich jedoch für eine bestimmte Variable über  Prüfen die Selektionsabgrenzung anzeigen lassen. Das System zeigt in einer Tabelle die Abgrenzungen an, die bei einer Datenanforderung festgestellt würden. Falls die Variable nicht für die Festlegung der Selektionsbedingungen geeignet ist, wird mit einem Fehler abgebrochen.

Wir empfehlen, Variablen (im BEx Query Designer) zum Zweck der Zeitselektion nur dann anzulegen, wenn Sie die damit ausgedrückte Selektionsbedingung in mehreren InfoPackages verwenden wollen. Verwenden Sie ansonsten zur Zeitselektion, falls ein einfaches Intervall oder bereits vorhandene Variablen nicht ausreichen, eine Routine.