Delta-Verarbeitung im BW (SAP BW)

Quelle: Delta-Management in SAP NetWever BW (Knapp, 2011)

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

→ 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	Fehlermanagement 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

Felder ROCANCEL und 0RECORDMODE

0RECORDMODE ist in jedem DSO vorhanden und notwendig, da es die Information über die Image-Art enthält.

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.

0RECORDMODE 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.

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

↑

Aktivierungs-Queue (Neue Daten)

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

↑

Aktivierungs-Queue (Neue Daten)

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

Vorgang 2: Belegänderung

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>

↑

Aktivierungs-Queue (Neue Daten)

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>

↑

Aktivierungs-Queue (Neue Daten)

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

↑

Aktivierungs-Queue (Neue Daten)

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.

Das Delda-Verfahren hierfür ist ODS (in Tabelle RODELTAM). Es erzeugt New-, Before-, After- und Reverse-Images und ist damit cubefähig.

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.

Delta-Mechanismen für Stammdaten

Stammdaten können prinzipiell wie Bewegungsdaten extrahiert werden, z. B. eine generische DataSource über die Transaktion RSO2 anlegen.

Stammdatenänderungen werden als Modified-Version gespeichert (OBJVERS = M). Der Attributänderungslauf übernimmt die Änderungen dann in die aktiven Stammdaten (OBJVERS = A).

Attributänderungslauf ist sowas ähnliches, wie Daten aktivieren im Standard-DSO.

Delta-Harmonisierung mit Full-Updates

Wenn eine Datenquelle nur Full-Updates unterstützt, kann das Delta-Verfahren ODS genutzt werden (New, Before, After und Reverse Images).

Gefahr von Inkonsistenzen, wenn die Datenquelle keine Stornokennzeichen liefert, z. B.: Datensätze im Quellsystem werden gelöscht und nicht mit Stornokennzeichen versehen.

Lösungsansätze für fehlende Stornokennzeichen:

Löschen des Datenziels vor dem Update

Dies ist das einfachere Vorgehen.

Im DTP in das Reporting-Objekt wird das Kennzeichen "Delta nur einmal abholen" gesetzt.

Vorgehen

Prozesskette mit folgender Struktur erstellen:

1. Laden der Daten in die Datenquelle (Standard-DSO) über Full-Update
2. Löschen des Datenziels
3. Ausführen des DTPs

Im letzteren DTP muss das Kennzeichen "Delta nur einmal abholen" gesetzt sein. Damit wird nur der zuletzt in die DTP-quelle geladene Request in das Datenziel verbucht.

Nachteile

• Delta-Information wird im Standard-DSO in einer Vielzahl an Requests vorgehalten, die aus Full-Updates bestehen
• Hoher Speicherplatzbedarf
• Daher nicht für große Applikationen nicht empfehlenswert

Erzeugen eigener Stornobelege

Problem bei fehlenden Stornobelegen: Aktivierung von Daten sorgt für inkonsistenten Datenstand, da gelöschte Datensätze nicht entfernt werden.

Lösungsansatz: Ein Programm zwischen Datenbeladung (in die Aktivierungs-Queue) und Aktivierung der Daten.

Prozesskette für automatische Erstellung und Verarbeitung der Stornobelege

1. InfoPackage zum Daten laden
2. DTP aus PSA in DSO
3. ABAP-Programm zur Erstellung der Stornobelege
4. Aktivierung der DSO-Daten

Aufbau des Programms zur Stornobelegerstellung

• Prüfung, ob jeder Datensatz in den aktiven Daten in der Aktivierungs-Queue vorhanden ist.
• Falls nicht vorhandene Datensätze: Datensatz in die Aktivierungs-Queue einfügen mit 0RECORDMODE X (Delete Image)