Delta-Verarbeitung im BW (SAP BW)

Delta-Verarbeitung im BW-System

Fortschreibungsmodi

Mögliche Fortschreibungsmodi:

• Full-Update
• Delta-Initialisierung mit Daten
• Delta-Initialisierung ohne Daten
• Early-Delta-Initialisierung
• Delta-Update

Ein Fortschreibungsmodus gibt, an, wie die Daten aus dem Quellsystem extrahiert werden. Er wird im InfoPackage im Reiter Fortschreibung gepflegt.

Full-Update

• Lädt alle Daten aus Quellsystem
• Filter im Reiter Datenselektion im InfoPackage sind möglich →
  • Generische Datasource: Als Selektionsparameter nur Felder möglich, die das Kennzeichen Selektion in der DataSource tragen
  • Flatfiles, DB Connect, UDI: Selektionsfähigkeit der Felder kann im Register Felder der DataSource eingegeben werden
• Full-Update ist bei Delta-Verfahren immer ausführbar → Bei 3.x-Datenflüssen ist hierfür jedoch ein Reparatur-Full-Request notwendig
• Bei Logistik-Extraktoren muss vor dem Full-Update die Neuaufbautabelle neu aufgebaut werden

Delta-Initialisierung

Die Delta-Initialisierung ist Voraussetzung, um Delta-Updates durchführen zu können. Vor der Initialisierung steht der Punkt "Delta-Update" im InfoPackage im Reiter Fortschreibung nicht zur Verfügung.

Delta-Initialisierung ist

• Datenselektion
• Aufbau der Delta-Queue im SAP-Quellsystem

Bei Angabe von Selektionen während der Initialisierung enthält die Delta-Queue fortan nur Daten, die der Selektion entsprechen. Es ist jedoch möglich, mehrere InfoPackage mit mehreren Selektionen zu erstellen, da alle in die gleiche Delta-Queue laufen.

Initialisierungsselektionen können im InfoPackage unter Menü Scheduler → "Iniitialisierungsselektion für Quellsystem" erneut angeschaut werden.

Zum Neustarten des Delta-Verfahrens kann die Initialisierungsselektion gelöscht werden. → Dies löscht die Delta-Queue im Quellsystem.

Es gibt drei Typen von Delta-Initialisierung:

Delta-Initialisierung mit Daten

• Full-Update gemäß Selektionsparametern
• Selektionsparameter gelten auch für Delta-Queue
• Daten werden zuerst zum BW und erst anschließend in die Delta-Queue übertragen

&rarr In der Zeit zwischen der Übertragung zum BW und dem Bereitstellen der Delta-Queue können Datensätze entstehen, die dann in der Delta-Queue (und in der Folge im BW) fehlen.

Delta-Initialisierung ohne Daten

• Gleiche Funktionsweise, wie Init mit Daten, aber
• Es werden keine Daten nach BW übertragen
• Delta-Queue steht sofort bereit
• Es werden keine Daten erfasst, die vor der Bereitstellung der Delta-Queue erstellt wurden

→ Vergangenheitsdaten müssen mit Full-Request bzw. Full-Repair-Request geladen werden. → Dies Klappt nur mit After-Image-Deltas problemlos

Early-Delta-Initialisierung

• Entspricht Delta-Initialisierung mit Daten in umgekehrter Reihenfolge
• Zuerst Bereitstellung der Delta-Queue
• Anschließend Datenübertragung
• Steht seit Service-API-Release PI_BASIS 2002.1 zur Verfügung

Delta-Update

• Steht nach der Initialisierung zur Verfügung
• Selektiert die Daten seit dem letzten erfolgreichen Delta
• Bei SAP-Quellsystemen kommen die Daten aus der Delta-Queue

InfoPackage in SAP NetWeaver BW 7.30

Kennzeichen "Ipak in PC auf Delta umschalten (F1)" ermöglicht, dass

• eine Delta-Initialisierung (mit Daten, ohne Daten, Early-Delta) statt findet, falls es noch keine mit gleichen oder überlappenden Selektionsparametern gab
• das InfoPackage in der Prozesskette in ein Delta-InfoPackage umgewandelt wird, falls es bereits eine Delta-Initialisierung gab

Delta des Datentransferprozesses / DTPs

Ein DTP kann Daten über Full- oder Delta-Update selektieren:

• Full selektiert grundsätzlich alle Daten aus der Datenquelle.
• Delta-Update = Requestbasiertes Delta →
  • Hat noch kein Delta-Update statt gefunden, selektiert der DTP alle Daten aus der Quelle und merkt sich den Stand der Selektion
  • Bei der nächsten Durchführung werden alle Requests aus der Datenquelle geholt, die noch nicht abgeholt wurden.
  • Mehrere Requests in der Datenquelle werden in einen neuen Request im Ziel verdichtet → Deaktivieren mit: "Alle neuen Daten requestweise abholen" im DTP

Option "DeltaInit ohne Daten" im DTP ist Transportrelevant → Für manuelle DTP-Ausführung lieber den Verarbeitungsmodus "Keine Datenübertragung; Deltastatus in Quelle: Abgeholt" setzen.

Fehlermanagement im Datentransferprozess / DTP

Fehlerstack enthält Daten, die während der Fortschreibung als fehlerhaft gekennzeichnet wurden, z. B. wegen falschem Datenformat. Der Fehlerstack ist Bestandteil des Fehlermanagements und wird im Register Verbuchung im DTP gepflegt.

Folgende Fehlerbehandlungen im DTP sind möglich:

Fehlerbehandlung	Beschreibung
Ausgeschaltet	Keine Fehleranalyse möglich
Keine Verbuchung, kein Reporting	Ferhlermanagement ausgeschaltet, Zwischenspeicher aktiv. Es kann definiert werden, welche Daten in den Zwischenspeicher geschrieben werden.
Verbuchung gültiger Sätze, kein Reporting (Request rot)	Fehlerstack aktiv. Fehlerhafte Sätze werden dort eingefügt. Anschließend können sie analysiert, korrigiert und in das Datenziel nachverbucht werden. Gültige Datensätze werden verbucht, Request wird aber auf Rot gesetzt.
Verbuchung gültiger Sätze, Reporting möglich (Request grün)	Fehlerstack aktiv. Wie vorherige Variante, jedoch Reporting möglich, weil Requests am Ende auf Grün gesetzt werden.

Vorsicht bei Methode "Verbuchung gültiger Sätze, Reporting möglich": Operator muss selbstständig die Fehlerstacks kontrollieren, weil die Verarbeitung einfach weiter läuft ohne den fehlerhaften Daten.

Wenn Fehlermanagement aktiv, können Daten aus Fehlerstack per Fehler-DTP in das Datenziel verbucht werden. Der Fehler-DTP wird aus dem DTP heraus erzeugt über die gleichnamige Schaltfläche.

Ablauf bei eingeschaltetem Fehlermanagement

1. DTP wird gestartet. Fehlerhafte Datensätze werden in den Fehlerstack geschrieben
2. Manuelle Korrektur der Daten im Fehlerstack
3. Aus DTP einen Fehler-DTP erstellen
4. Mit Fehler-DTP Daten in das Datenziel fortschreiben

Schwellwert für Abbruch Wenn mehr als 100 Datensätze fehlerhaft sind, bricht der DTP automatisch ab. Der Schwellwert kann manuell eingestellt werden (unklar, wo).

Einstellungen Fehlerstack

• Sichtbarkeit des Tabellennamens der Tabelle für den Fehlerstack (Transparente Tabelle)
• Definition der Größenkategorie zur Selektion des Tablespace in der Datenbank

Zugriff über Menü Zusätze → Einstellungen Fehler

Realtime Data Acquisition / RDA (todo)

todo

Felder ROCANCEL und 0RECORDMODE

Feld	Ort	Bedeutung
ROCANCEL	Quellsystem / DataSource	Satztyp des gelieferten Images (New, Before, After, Additive, Reverse, Delete (vgl. Delta-Verfahren (SAP BW)#Satztypen) Feldname kann im Quellsystem auch anders lauten.
0RECORDMODE	BW-System	Wird aus Quelle befüllt Ist Bestandteil von DSOs Wird nicht in InfoCubes fortgeschrieben

0RECORDMODE wird in Transformationen in der technischen Gruppe einsortiert. Muss ggf. manuell versorgt werden.

0RECORDNODE wird nur in Tabellen des Changelogs und der Aktivierungs-Queue geführt. In der Aktive-Daten-Tabelle ist es nicht mehr notwendig, da diese den aktuellen Datenstand repräsentieren.

Delta-Harmonisierung

InfoCubes können bestehende Kennzahlen nur addieren. Manche Datenquellen liefern jedoch nur End-Werte (After-Images) statt Differenz-Werten.

In solchen Fällen muss eine Delta-Harmonisierung durchgeführt werden, bei der aus einem nicht-cubefähigen Delta-Verfahrens ein cubefähiges Delta entsteht. Das passiert mittels eines Standard-DSOs.

Kann auch benutzt werden, um aus einem Full-Update ein Delta zu erzeugen.

Beispiel für die Harmonisierung

Es sollen Daten in einem nicht-cubefähigen Delta-Verfahren zum Standard-DSO angeliefert werden, z. B. AIMD, AIED, die nur After-Images enthalten.

Während der Aktivierung sollen sie in ein cubefähiges Delta umgewandelt werden.

Vorgang 1: Neuer Beleg wird aus Quelle geliefert

Step 1:

Beleg EK1000 mit Menge 2000 wird als After-Image in die neuen Daten (Aktivierungs-Queue) geschrieben

Aktive Daten

Beleg	Menge

↑

Change Log

Request-ID	Belege	Menge	0RECORDMODE

↑

Neue Daten / Aktivierungs-Queue

Request-ID	Beleg	Menge	0RECORDMODE
REQA001	EK1000	2000	<leer>

Step 2:

Aktivierung der neuen Daten

• Während Aktivierung wird im Changelog das After-Image mit Recordmode New mit neuer Requestnummer geschrieben
• In die Aktiven Daten wird für den Beleg ein Datensatz mit Menge 2000 eingefügt
• Aktivierungs-Queue wird geleert

Aktive Daten

Beleg	Menge
EK1000	2000

⇑

Change Log

Request-ID	Belege	Menge	0RECORDMODE
REQC001	EK1000	2000	N

⇑

Neue Daten / Aktivierungs-Queue

Request-ID	Beleg	Menge	0RECORDMODE
REQU001	EK1000	2000	<leer>

1. Vorgang 2: Belegänderung
   1. Menge in Beleg EK1000 wird auf 1500 geändert. Dies wird als After-Image in die neuen Daten (Aktivierungs-Queue) geliefert, was also nicht cubefähig ist.

• Neue Daten enthalten das After-Images mit der neuen Menge 1500
• Aktivierung erkennt, dass in den aktiven Daten ein Datensatz besteht
• Aktivierung erstellt im Changelog ein Before-Image mit Menge -2000 und ein After-Image mit Menge 1500
• Der bestehende Datensatz in den aktiven Daten wird auf Menge 1500 geändert
• Aktivierungs-Queue wird geleert

Aktive Daten

Beleg	Menge
EK1000	2000 1500

⇑

Change Log

Request-ID	Belege	Menge	0RECORDMODE
REQC001	EK1000	2000	N
REQC002	EK1000	-2000	X
REQC002	EK1000	1500	<leer>

⇑

Neue Daten / Aktivierungs-Queue

Request-ID	Beleg	Menge	0RECORDMODE
REQU002	EK1000	1500	<leer>

Vorgang 3: Stornierung des Belegs

Step 1:

Aktivierungs-Queue erhält aus der Quelle das Delete-Image für den Beleg EK1000 als nicht cubefähiges Image

Aktive Daten

Beleg	Menge
EK1000	1500

⇑

Change Log

Request-ID	Belege	Menge	0RECORDMODE
REQC001	EK1000	2000	N
REQC002	EK1000	-2000	X
REQC002	EK1000	1500	<leer>

⇑

Neue Daten / Aktivierungs-Queue

Request-ID	Beleg	Menge	0RECORDMODE
REQA003	EK1000	<leer>	D

Step 2: Aktivierung

• Aktivierung erstellt im Changelog ein Reverse-Image mit Menge -1500, womit eine cubefähige Information entsteht
• Der bestehende Datensatz in den aktiven Daten wird gelöscht
• Anschließend wird die Aktivierungs-queue geleert

Aktive Daten

Beleg	Menge
EK1000	1500

⇑

Change Log

Request-ID	Belege	Menge	0RECORDMODE
REQC001	EK1000	2000	N
REQC002	EK1000	-2000	X
REQC002	EK1000	1500	<leer>
REQC003	EK1000	-1500	R

⇑

Neue Daten / Aktivierungs-Queue

Request-ID	Beleg	Menge	0RECORDMODE
REQU003	EK1000	<leer>	D

Im Standard-DSO ist also aus einem nicht-cubefähigen Delta ein cubefähiges Delta entstanden.

Dabei ist jedoch auch Speicherplatz für die PSA, DSOs, Change-Logs, Aggregate und InfoCubes notwendig. Dieser kann mit Transaktion DB02 unter System-ID, Platzübersicht eingesehen werden.

Wird aus dem Standard-DSO ein InfoCube gefüllt, so wird in den InfoCube der Inhalt des Change-Logs fortgeschrieben.

Requests in der Aktivierungs-Queue eines Standard-DSO enthalten eine Requestnummer. Während der Aktivierung im Standard-DSO wird ein zusätzlicher Request ins Change-Log mit einer eigenen Requestnummer geschrieben.