Fehleranalyse im Delta-Verfahren (SAP BW)

Aus MattWiki

Vorgehensmodell

Vorgehensmodell
1. Reproduktion
↓
2. Top-down-Analyse
↓
3. Detailanalyse
↓
4. Fehlerkorrektur

Top-Down-Analyse

Von der Query / MultiProvider bis zur DataSource die Daten über alle Zwischenebenen verfolgen:

Wo ist der Fehler aufgetreten?

  • Requests fortgeschrieben?
  • Requests für das Reporting verfügbar? → Siehe Administration → Spalte Reporting-Verfügbarkeit der Requests
  • Fehlerstack leer?
  • Daten in den Datentöpfen korrekt vorhanden? → Inhaltsanalyse
  • Daten aus Quelle erfolgreich hoch geschrieben?
  • Verbindungsabbrüche zum Quellsystem?
  • Kurzdumps?
  • System-Log?


Detailanalyse

Welche Daten haben den Fehler am Ort des Auftretens verursacht?


Typische Fehlerquellen

Rote Requests

  • Fehlerursache im Monitor des Requests prüfen
  • Bei Kurzdumps mit Transaktion ST22 die ABAP-Laufzeitfehler überprüfen


Kurzdumps und sonstige Fehler

  • Kurzdumps prüfen: ST22
  • Systemlog prüfen: SM21
  • Anwendungslog prüfen: SLG1


Fehlerhaftes Aggregationsverhalten

Aggregationsverhalten überprüfen:

Aggregation Image-Typ vermeiden Effekt
Überschreiben Keine Additive Images verwenden Werte zu klein
Addition Keine After Images verwenden Werte zu groß


Verbindungsprobleme

Mögliche Probleme in der Anbindung von Quellsystem an das BW-System:

Fehler Mögliche Fehlermeldung
Kommunikationsfehler Fehler beim Öffnen einer RFC-Verbindung
Quellsystemverbindung <System-ID>CLNT<Mandant> nicht verfügbar
Verbuchung von IDocs Fehler beim Verbuchen des IDocs im Business Information Warehouse
Übertragung von IDocs Anforderungs-IDoc: Versendet, nicht angekommen; Fehler bei Datenübergabe an Port

Lösungsansätze

  • Quellsystemverbindung in der RSA1 prüfen → Rechte Maustaste auf Quellsystem → Prüfen
  • Passwörter und Benutzernamen überprüfen: BWREMOTE, ALEREMOTE, etc.

Fortsetzen abgebrochener Delta-Verbuchungen

Deltas müssen immer in der Entstehungs-Reihenfolge abgearbeitet werden.

Delta-Queue enthält immer Daten des aktuellen und des letzten Deltas.

Wird ein Delta-Update nach einem Fehler eingeplant, führt das System automatisch ein Repeat-Delta aus, und holt die letzten Datensätze nochmal.

Bei Delta-Repeat entstehen (immer oder nur manchmal?) doppelte Daten. Lösungsansätze:

  • Delta-Repeat herauslöschen und Daten neu anfordern
  • Vgl. auch SAP Beratungshinweis 873401

Bei Inkonsistenzen mit Delta-Repeats werden auch gerne Reparatur-Full-Requests erstellt.

Dies ist problematisch, da es zu Inkonsistenzen im Delta-Verfahren führen würde.

In dem Fall: Reparatur-Full-Request durchführen → Im InfoPackage Menü Scheduler → Reparatur-Full-Request auswählen

Reparatur-Full-Requests sind unproblematisch, wenn die Daten im Datenziel überschrieben und nicht addiert werden.

Reparatur-Full-Requests bei Logistik-Extraktoren:

Nicht vergessen, Neuaufbautabelle neu zu befüllen.


Simulation und Debugging

Simulation im Datentransferprozess / DTP

Aktivieren im Register Ausführen → Verarbeitungsmodus auf "Seriell im Dialogprozess (Für Debugging)" auswählen.

Ausführen Button ändert sich dadurch zu Simulieren.

Expertenmodus:

  • Öffnet nach Klick auf Simulieren das Dialogfenster "Expertenmodus"
  • Register Filter: Selektion des Wertebereichs
  • Register Zwischenspeicher und Breakpoints: Zu nutzende Zwischenspeicher auswählen.

Die Zwischenspeicher enthalten die Datensätze nach den jeweiligen Verarbeitungsstufen und können im Nachgang über die zugehörigen Buttons im Simulationsrequest eingesehen

Debugging von Datentransferprozessen / DTPs

Breakpoints setzen, um an eine bestimmte Stelle mit Debugger zu springen.

Debugging ist auch von abgeschlossenen Requests (Erfolgreich oder fehlerhaft) möglich → Button Debugging im DTP-Monitor klicken.

Debugging aus DTP-Monitor heraus ist jederzeit möglich.

Simulation im Datentransferprozess ist nur möglich, wenn die Quelldaten noch nicht ins Ziel verbucht wurden.

Abgerufen von „https://otremba.net/w/index.php?title=Fehleranalyse_im_Delta-Verfahren_(SAP_BW)&oldid=802“