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.

Zwischenspeicher

• enthalten die Datensätze nach den jeweiligen Verarbeitungsstufen
• 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.

Das generierte Programm einer Transformation kann aus der Transformation heraus über Menü Zusätze → Generiertes Programm anzeigen angezeigt werden.

Darin können Breakpoints gesetzt werden. Ist einfacher, als direkt mit dem Debugger zu starten und sich über die ganzen Standard-Programme hinweg bis zum Programmcode der Transformation durchzuhangeln.

Name	Bedeutung
Feldsymbol <_ys_SC_1>	Quellstruktur / Source
Feldsymbol <_ys_TG_1>	Zielstruktur / Target
Feld _curr_fule-ruleid	Regel-ID der Transformation
Feld _curr_fule-stepid	Schrittnummer in der Regel

Die Regel-ID kann dem Fehlerprotokoll entnommen werden.

Debugging-Berechtigungen

User muss das Berechtigungsobjekt S_DEVELOP (ABAP Workbench) haben mit folgender Ausprägung:

Aktivität	01 (Hinzufügen oder Erzeugen), 02 (Ändern), 03 (Anzeigen
Paket	*
Objektname	*
Objekttyp	DEBUG
Berechtigungsgruppe ABAP/4-Programm	*