Health und Morgencheck

Der Health-Tab

Öffne in den DevTools (F12) das Panel FrontTailor oder das Side-Panel und wähle Health. Die Statusleiste oben rechnet aus dem Mitschnitt der OData-Konsole: Sie sendet keinen eigenen Request, sondern wertet aus, was die App ohnehin mit ihrem Backend spricht. Im Side-Panel ist sie kompakt.

1. Backend-Latenz: Median und p95 der letzten 50 abgeschlossenen Requests.
2. Fehlerrate: Anteil der Antworten mit Status ab 400, Status 0 oder Netzwerkfehler – auch einzelne Teile eines $batch.
3. Sitzung: geschätzte Restzeit oder letzte Aktivität vor ….
4. Anmeldung & CSRF: 401 und 403 der letzten zwei Minuten und abgelehnte CSRF-Token.
5. Request anzeigen springt in die OData-Konsole und wählt den fehlgeschlagenen Request aus.

Wiederholungen aus der OData-Konsole zählen nicht mit. Ist die OData-Aufzeichnung für den Host abgeschaltet (Richtlinie oder eigene Entscheidung), sagt der Tab das, statt leere Werte zu zeigen.

Sitzung und Token

Wann die Server-Sitzung abläuft, weiß der Browser nicht: Das Cookie ist HttpOnly, und FrontTailor liest keine Cookies. Die Karte Sitzung & Token schätzt deshalb:

• den Timeout aus der Konfiguration des Launchpads (dieselbe Einstellung, mit der das Launchpad seinen Abmelde-Dialog steuert) – mit Erinnerung und automatischer Abmeldung, falls gesetzt;
• den Startpunkt aus dem letzten erfolgreichen Backend-Request;
• eine neue Backend-Sitzung, wenn sich sap-contextid zwischen zwei Requests ändert.

Die Restzeit ist als Schätzung gekennzeichnet; ICF, Approuter oder Identity Provider können eigene Timeouts haben. Ohne Launchpad steht dort nur „Kein Launchpad: Der Sitzungs-Timeout ist im Browser nicht sichtbar.“ Ist das ABAP-Add-on installiert (Backend-Service), kommt der Timeout aus dem System statt aus dem Launchpad. Einen abgelehnten CSRF-Token (403 mit x-csrf-token: Required) meldet die Karte ausdrücklich: Sitzung oder Token sind abgelaufen, die App muss ein neues Token holen.

Synthetischer Check

Eine Klickfolge einmal aufzeichnen und bei Bedarf wiederholen – etwa nach einem Deployment, um Ladezeiten zu vergleichen. Die Aufzeichnungsleiste ist dieselbe wie in den Tabs Problem melden und Scaffolding; alle drei sehen dieselbe Aufzeichnung.

1. Klicke in der Aufzeichnungsleiste Aufzeichnen. Die Leiste zählt Schritte und Zeit (höchstens 200 Schritte und 10 Minuten).
2. Klicke dich in der App durch den Ablauf. Es zählen nur echte Klicks des Benutzers; eingegebener Text wird nur aufgezeichnet, wenn du Eingegebenen Text aufzeichnen (maskiert) anhakst.
3. Klicke Stoppen. Die Karte Synthetischer Check listet die Schritte.
4. Wähle den Timeout pro Schritt (5, 10 oder 30 s) und klicke Check ausführen.

1. Die Schritte mit Status, Wartezeit bis zum Control, Ladezeit und Anzahl der Requests.
2. Das Ergebnis: Check bestanden in … oder Check nach … fehlgeschlagen.
3. Check ausführen spielt die Folge im aktuellen Tab ab, beginnend am selben Location-Hash.

Pro Schritt sucht der Check das Control, klickt es an und wartet, bis die Seite 500 ms ruhig ist. Findet er ein Control nicht (Control nicht gefunden) oder läuft die Zeit ab (Zeitüberschreitung), überspringt er die übrigen Schritte. Generierte IDs wie __button3 sind nach einem Neuladen oft anders; der Tab markiert solche Schritte mit generierte ID.

Der Morgencheck

Statt jeden Morgen zehn Apps von Hand zu öffnen: Eine Prüfliste öffnet sie nacheinander in einem Hintergrund-Tab, wartet, bis jede zur Ruhe kommt, und schließt sie wieder. Nichts läuft, bevor du klickst.

1. Wähle den Tab Morgencheck und klicke Liste anlegen – oder Mit dieser App beginnen, dann steht die aktuelle App schon drin.
2. Trage Apps ein: eine URL oder eine Launchpad-Intent wie SalesOrder-display. Für Intents braucht die Liste die Launchpad-URL. Aktuelle App hinzufügen übernimmt die Seite des Tabs.
3. Speichern, dann Check starten. FrontTailor fragt im selben Klick einmal pro System nach Zugriff; Apps von Systemen ohne Zugriff bleiben grau.
4. Der Bericht füllt sich App für App. Abbrechen beendet den Lauf nach der laufenden App.

1. Launchpad-URL (für Intents) – dort öffnet der Check jede Intent der Liste.
2. Apps öffnen in: Hintergrund-Tab oder eigenem Fenster. Browser bremsen Timer in Hintergrund-Tabs; ein eigenes Fenster misst näher am echten Start. Vergleiche nur Läufe derselben Art.
3. Die Apps der Liste, bis zu 30, je mit Name, Ziel und optional den Schritten einer gespeicherten Aufzeichnung.
4. Aktuelle App hinzufügen. Sitzungsgebundene Parameter wie sap-iapp-state entfernt FrontTailor dabei, Benutzer und Passwort in URLs beim Speichern.

Bericht und Ampel

1. Lauf: Auswahl früherer Läufe mit ihrer Bilanz (grün, gelb, rot).
2. Eine rote App mit Grund – hier HTTP 404. Details klappt fehlgeschlagene Requests und UI5-Log-Fehler auf, App öffnen öffnet sie.
3. Der Vergleich mit dem letzten Lauf derselben Liste, etwa heute 2,7 s, jetzt 832 ms – zwei Läufe am selben Tag vergleicht er mit „heute“ und „jetzt“.
4. Export: Als Markdown kopieren, An Issue Reporter und Dateien als Markdown, CSV und HTML.

Beim Vergleich zählt der Bericht fehlgeschlagene Requests als neu oder behoben. Exporte maskiert FrontTailor mit den PII-Regeln des Issue Reporters; An Issue Reporter öffnet den Tab „Problem melden“ mit Titel und Beschreibung, gesendet wird erst nach Vorschau und Klick.

Tägliche Erinnerung

In der Karte Tägliche Erinnerung schaltest du Täglich erinnern ein, wählst die Uhrzeit (05:00 bis 12:00 im Viertelstundenraster) und auf Wunsch Nur Montag bis Freitag. Zur Uhrzeit erscheint eine Sonne ☀ am FrontTailor-Symbol und ein Hinweis im Tab. Der Check startet nicht von selbst, und es geht nichts hinaus; die Sonne verschwindet mit dem nächsten Lauf.

Prüflisten lassen sich über Team-Sync im Team verteilen; sie tragen dann das Kennzeichen Team. Läufe werden nicht geteilt. Listen und die letzten sieben Läufe je Liste bleiben im Browser, Request-Adressen ohne Query-String.

Typische Probleme