OData-Konsole

Der Tab im Überblick

Öffne den Tab OData im DevTools-Panel oder im Side-Panel und bediene die App. Jeder OData-Request erscheint als Zeile; ein $batch klappt in seine Teile auf. Im schmalen Side-Panel fehlen nur die Spalten Zeit und Größe.

1. Vier Ansichten desselben Logs: Requests, Sammlungen, Metadaten und Diagramm.
2. Pausieren hält die Aufzeichnung an, Leeren löscht das Log, Log behalten bewahrt es beim Neuladen.
3. Filter über Pfad, Entity-Set, Status und Fehlertext – auch in Batch-Teilen. Rechts daneben Status (Alle, Fehler, Erfolgreich), Methode und Service.
4. Ein $batch mit Zahl der Teile. Ein Klick klappt ihn auf.
5. Ein Batch-Teil: anklickbar wie ein eigener Request.
6. Ein fehlgeschlagener Request: rote Ampel, 200 → 400 heißt „Hülle 200, Teil 400“, darunter der Fehlertext.

Über der Tabelle steht, ob die Aufzeichnung ab Seitenstart läuft, und der gemessene Overhead pro Request. Mit dem Häkchen Auf … aufzeichnen schaltest du die Aufzeichnung für diesen Host ab oder an; das wirkt ab dem nächsten Laden. Unter der Tabelle stehen die Exporte.

Fehler lesen: Meldung, Transaktions-ID, Fehlerprotokoll

1. In der Tabelle die rote Zeile anklicken. Bei einem $batch öffnet sich der fehlgeschlagene Teil.
2. Im Detail den Tab Fehler wählen.
3. Meldung, Code, Transaktions-ID und Lösungshinweise ablesen. Bei Gateway-Fehlern führt Im Gateway-Fehlerprotokoll öffnen ins /IWFND/ERROR_LOG.

1. Fehler für diesen Request simulieren macht aus dem Request eine Regel der Fehlersimulation ab Pro.
2. Als bekannten Fehler speichern legt die Lösung für das nächste Mal ab, siehe Bekannte Fehler.
3. Meldung aus dem Fehler-Body, darunter Code, Ziel und Details.
4. Transaktions-ID und Zeitstempel für die Suche im Backend.
5. Im Gateway-Fehlerprotokoll öffnen: ein normaler Link auf /IWFND/ERROR_LOG desselben Systems, in einem neuen Tab (SAP GUI für HTML).

Die Konsole versteht Gateway V2 als JSON und XML, V4 von RAP und CAP, ICF-Fehlerseiten als HTML und die Header sap-message bzw. sap-messages. Ein Changeset, das als Ganzes scheitert, markiert alle Teile als Changeset fehlgeschlagen; fehlende Antworten heißen Keine Antwort.

Mit ab Pro stehen über dem Fehler die KI-Einstiege, etwa Fehler erklären – mit deinem eigenen Schlüssel, siehe KI-Assistent. Mit ab Enterprise führt die Karte Absprung ins Backend in die Analyse-Transaktionen desselben SAP-Systems, siehe Absprung ins Backend.

Replay: bearbeiten, Vorschau, senden

1. Request in der Tabelle wählen, im Detail den Tab Replay öffnen.
2. Methode, URL, Header (einer pro Zeile, Name: Wert) und Body anpassen. Header erklären beschreibt jeden Header.
3. Für ändernde Requests Zuerst CSRF-Token holen anhaken.
4. Vorschau klicken. Sie zeigt den genauen Request samt Token-Abruf: „Dieser Request wird aus der Seite gesendet, mit der Sitzung der Seite“.
5. Request senden klicken. Die Antwort erscheint darunter, der Request steht im Log mit dem Kennzeichen Replay.

1. URL des Requests – erlaubt ist nur der Origin der Seite.
2. Zuerst CSRF-Token holen: vorher ein HEAD mit x-csrf-token: Fetch auf den Service.
3. Vorschau zeigt den Request, der gesendet würde. Ohne Vorschau gibt es kein Senden.
4. In Sammlung speichern legt den Request dauerhaft ab, siehe Sammlungen.
5. Request senden schickt ihn mit der Sitzung der Seite. Zurücksetzen stellt den Originalzustand her.

Export ohne Geheimnisse

Exporte entstehen lokal als Datei und enthalten weder Cookies noch Authorization noch CSRF-Tokens: „Exporte bleiben auf diesem Rechner. Cookies und CSRF-Tokens fehlen – die Dateien holen zuerst ein Token.“

Gespeicherte Filter und Sammlungen

Links über der Tabelle steht das Menü der Gespeicherten Filter (anfangs Standard). Sichern, Sichern unter und Verwalten legen Filtersätze aus Status, Service, Methode und Text ab. Als Standard für dieses System wendet einen Filter beim Öffnen der Konsole für diesen Origin an.

Die Ansicht Sammlungen hält gespeicherte Requests. Vor dem Speichern entfernt FrontTailor Cookies, Tokens, Authorization- und CSRF-Header; die URL wird relativ zum Service gespeichert und läuft so auf jedem System mit diesem Service. Ein gespeicherter Request läuft wie ein Replay: erst Vorschau, dann senden. Importieren und Alle exportieren tauschen Sammlungen als JSON-Datei. Filter und Sammlungen aus Team-Paketen erscheinen mit ab Team in einer eigenen Gruppe, siehe Team-Pakete.

Metadaten: Service durchsuchen

1. Service wählen – jeder Service, dessen $metadata aufgezeichnet wurde.
2. Die Zusammenfassung: OData-Version, Entity-Sets, Entity-Typen, Operationen, Annotationen.
3. Suchen in Entity-Sets, Typen, Properties, Aktionen und Annotationen (auch aus externen Annotationsdateien).
4. Die Treffer. Controls zeigt, welche Controls der Seite ein Element binden.

Fehlt ein Service, wurde sein $metadata nicht aufgezeichnet: App bei aktiver Aufzeichnung neu laden.

Diagramm: Entitäten und Navigationen

1. Suche nach Typ, Entity-Set oder Property (Taste /). Daneben die Umgebung (1 oder 2 Schritte), Annotationen und Ebenen (Operationen, Complex- & Enum-Typen, Draft ausblenden).
2. Pfad finden: Von-Typ und Ziel-Typ wählen, $expand kopieren liefert den Navigationspfad.
3. Export: SVG oder PNG der aktuellen Ansicht, oder Mermaid-erDiagram kopieren.
4. In Vollansicht öffnen zeigt das Diagramm in einem eigenen Fenster.

Was aufgezeichnet wird

Die Konsole hängt sich in XMLHttpRequest und fetch der Seite, ändert aber keinen Request und setzt keinen Header. UI5-Ressourcen wie .js oder .properties schaut sie gar nicht erst an. Cookies werden entfernt; Authorization, CSRF-Tokens und andere Geheimnisse werden schon in der Seite durch [redacted] ersetzt. Je Tab hält das Log bis 2.000 Requests oder 50 MB, Bodies bis 512 KB (Request) und 1 MB (Response). Es wird beim Schließen des Tabs gelöscht und beim Neuladen geleert, außer Log behalten ist an.

Typische Probleme