Quelltext der Seite 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 &rarr; 
** 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 &rarr; 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 &rarr; "Iniitialisierungsselektion für Quellsystem" erneut angeschaut werden.

Zum Neustarten des Delta-Verfahrens kann die Initialisierungsselektion gelöscht werden. &rarr; 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

&rarr; Vergangenheitsdaten müssen mit Full-Request bzw. Full-Repair-Request geladen werden.
&rarr; 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 &rarr; 
** 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 &rarr; Deaktivieren mit: "Alle neuen Daten requestweise abholen" im DTP

Option "DeltaInit ohne Daten" im DTP ist Transportrelevant &rarr; 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:

{| class="wikitable"
! 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 '''
# 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 &rarr; Einstellungen Fehler


== Realtime Data Acquisition / RDA (todo) ==
todo


== Felder ROCANCEL und 0RECORDMODE ==
{| class="wikitable"
! 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 '''
{| class="wikitable"
! Beleg !! Menge
|-
|  || 
|}

&uArr;

''' Change Log '''
{| class="wikitable"
! Request-ID !! Belege !! Menge !! 0RECORDMODE
|-
|  || 
|}

&uArr;

''' Neue Daten / Aktivierungs-Queue '''
{| class="wikitable"
! 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 '''
{| class="wikitable"
! Beleg !! Menge
|-
| EK1000 || 2000
|}

&uArr;

''' Change Log '''
{| class="wikitable"
! Request-ID !! Belege !! Menge !! 0RECORDMODE
|-
| REQC001 || EK1000 || 2000 || N 
|}

&uArr;

''' Neue Daten / Aktivierungs-Queue '''
{| class="wikitable"
! Request-ID !! Beleg !! Menge !! 0RECORDMODE
|-
| <strike> REQU001 </strike> || <strike> EK1000 </strike> || <strike> 2000 </strike>  || <strike> <leer> </strike>
|}


# 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 '''
{| class="wikitable"
! Beleg !! Menge
|-
| EK1000
| <strike> 2000 </strike> 
1500
|}

&uArr;

''' Change Log '''
{| class="wikitable"
! Request-ID !! Belege !! Menge !! 0RECORDMODE
|-
| REQC001 || EK1000 || 2000 || N 
|-
| REQC002 || EK1000 || -2000 || X 
|-
| REQC002 || EK1000 || 1500 || <leer> 
|-
|}

&uArr;

''' Neue Daten / Aktivierungs-Queue '''
{| class="wikitable"
! Request-ID !! Beleg !! Menge !! 0RECORDMODE
|-
| <strike> REQU002 </strike> || <strike> EK1000 </strike> || <strike> 1500 </strike>  || <strike> <leer> </strike>
|}


# 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 '''
{| class="wikitable"
! Beleg !! Menge
|-
| EK1000 || 1500
|}

&uArr;

''' Change Log '''
{| class="wikitable"
! Request-ID !! Belege !! Menge !! 0RECORDMODE
|-
| REQC001 || EK1000 || 2000 || N 
|-
| REQC002 || EK1000 || -2000 || X 
|-
| REQC002 || EK1000 || 1500 || <leer> 
|-
|}

&uArr;

''' Neue Daten / Aktivierungs-Queue '''
{| class="wikitable"
! 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 '''
{| class="wikitable"
! Beleg !! Menge
|-
| <strike> EK1000 </strike> || <strike> 1500 </strike>
|}

&uArr;

''' Change Log '''
{| class="wikitable"
! Request-ID !! Belege !! Menge !! 0RECORDMODE
|-
| REQC001 || EK1000 || 2000 || N 
|-
| REQC002 || EK1000 || -2000 || X 
|-
| REQC002 || EK1000 || 1500 || <leer> 
|-
| REQC003 || EK1000 || -1500 || R 
|}

&uArr;

''' Neue Daten / Aktivierungs-Queue '''
{| class="wikitable"
! Request-ID !! Beleg !! Menge !! 0RECORDMODE
|-
| <strike> REQU003 </strike> || <strike> EK1000 </strike> || <leer> || <strike> D </strike>
|}


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.




[[Category:SAP]]
[[Category:SAP BW]]