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
- DTP wird gestartet. Fehlerhafte Datensätze werden in den Fehlerstack geschrieben
- Manuelle Korrektur der Daten im Fehlerstack
- Aus DTP einen Fehler-DTP erstellen
- 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)
- RDA
- Daten in hoher Frequenz aus Quellsystem extrahieren
Neuerung | Beschreibung |
---|---|
Offene Requests |
|
Daemon |
|
Bestätigungstabelle |
|
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 |
|
0RECORDMODE
|
BW-System |
|
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
Beleg | Menge |
---|---|
↑
Request-ID | Belege | Menge | 0RECORDMODE |
---|---|---|---|
↑
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
Beleg | Menge |
---|---|
EK1000 | 2000 |
↑
Request-ID | Belege | Menge | 0RECORDMODE |
---|---|---|---|
REQC001 | EK1000 | 2000 | N |
↑
Request-ID | Beleg | Menge | 0RECORDMODE |
---|---|---|---|
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
Beleg | Menge |
---|---|
EK1000 | 1500 |
↑
Request-ID | Belege | Menge | 0RECORDMODE |
---|---|---|---|
REQC001 | EK1000 | 2000 | N |
REQC002 | EK1000 | -2000 | X |
REQC002 | EK1000 | 1500 | <leer> |
↑
Request-ID | Beleg | Menge | 0RECORDMODE |
---|---|---|---|
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
Beleg | Menge |
---|---|
EK1000 | 1500 |
↑
Request-ID | Belege | Menge | 0RECORDMODE |
---|---|---|---|
REQC001 | EK1000 | 2000 | N |
REQC002 | EK1000 | -2000 | X |
REQC002 | EK1000 | 1500 | <leer> |
↑
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
Beleg | Menge |
---|---|
↑
Request-ID | Belege | Menge | 0RECORDMODE |
---|---|---|---|
REQC001 | EK1000 | 2000 | N |
REQC002 | EK1000 | -2000 | X |
REQC002 | EK1000 | 1500 | <leer> |
REQC003 | EK1000 | -1500 | R |
↑
Request-ID | Beleg | Menge | 0RECORDMODE |
---|---|---|---|
<leer> |
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:
- Laden der Daten in die Datenquelle (Standard-DSO) über Full-Update
- Löschen des Datenziels
- 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
- InfoPackage zum Daten laden
- DTP aus PSA in DSO
- ABAP-Programm zur Erstellung der Stornobelege
- 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)