Fehleranalyse im Delta-Verfahren (SAP BW)

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.