Fehlersimulation

Der Tab im Überblick

Den Tab Fehlersimulation findest du im DevTools-Panel und im Side-Panel, bei vielen Tabs unter Weitere. Oben stehen die Schnellstarts, darunter deine Regeln.

1. Einschalten bei einem Schnellstart legt die Regel an und schaltet sie sofort ein.
2. Neue Regel öffnet den Editor für eine eigene Regel.
3. Die Regelliste – hier noch leer.
4. „Alles bleibt im Browser: Die Regeln gelten nur für diesen Tab, überstehen ein Neuladen und enden mit dem Schließen des Tabs.“

Ein Schnellstart gilt für alle OData-Requests. Über Regel bearbeiten grenzt du ihn auf einen Service oder ein Entity-Set ein.

Was in der App passiert

Solange eine Regel aktiv ist, steht unten in der App das Banner Fehlersimulation aktiv mit der Zahl der Regeln. Ein Klick auf Ausschalten im Banner schaltet alles ab – sofort, die Regeln bleiben ausgeschaltet erhalten.

1. Die App zeigt ihren „Keine Daten“-Text – die Antwort kam von der Simulation, nicht vom Server.
2. Das Banner in der Seite. Ausschalten beendet die Simulation in diesem Tab.

In der OData-Konsole tragen simulierte Antworten das Kennzeichen simuliert (bei $batch: „n simuliert“), das Detail sagt „Simuliert von FrontTailor – Regel …“.

Eine eigene Regel anlegen

1. Im Tab Fehlersimulation auf Neue Regel klicken.
2. Unter Welche Requests Service, Entity-Set, Methode und Ort festlegen – leer heißt „alle“.
3. Unter Was passiert die Wirkung wählen, etwa HTTP-Fehler mit Status 500 und eigener Fehlermeldung.
4. Unter Wie oft Einmal, N-mal oder Immer wählen.
5. Speichern und einschalten. Dann in der App die Aktion auslösen.

1. Entity-Set, z. B. Products; $metadata trifft das Metadatendokument. Leer trifft alle außer $metadata, Service-Dokument und Token-Abruf.
2. Methode: Jede Methode, Lesen (GET), Ändern (POST, PUT, PATCH, MERGE, DELETE) oder eine einzelne. Daneben Wo: direkte Requests, $batch-Teile oder beides.
3. Wirkung, siehe Tabelle unten.
4. Fehlermeldung: Die App zeigt sie wie eine Meldung aus dem Backend. Darunter optional ein Gateway-innererror mit Transaktions-ID und Zeitstempel.
5. Wie oft: gezählt wird pro HTTP-Request, ein $batch zählt einmal.
6. Speichern und einschalten.

Zu jeder Wirkung lässt sich eine Zusätzliche Verzögerung (ms) setzen. Die erste passende Regel gewinnt.

1. Der Fehlerdialog der App mit Status und der Meldung aus der Regel.

Die Regelliste

1. Der Schalter schaltet die Regel ein oder aus. Einschalten startet eine aufgebrauchte Regel neu.
2. Der Status: Aktiv, Aus oder Aufgebraucht.
3. Wie oft die Regel schon geantwortet hat, z. B. „1× simuliert“. Rechts daneben Regel bearbeiten und Regel löschen.

Unter jeder Regel steht ihre Kurzfassung: Methode, Entity-Set, Wirkung und Zählung. Alles ausschalten über der Liste beendet alle Regeln auf einmal.

Regel aus einem echten Request

In der OData-Konsole steht im Detail eines Requests Fehler für diesen Request simulieren. Das öffnet den Editor mit Service, Entity-Set und Methode des Requests; bei einem $batch-Teil zusätzlich mit „nur $batch-Teile“.

$batch und Changesets

Regeln treffen direkte Requests und einzelne $batch-Teile, nie die Hülle. Ein simulierter Teil wird aus dem echten Request entfernt – Änderungen erreichen den Server also nicht. Die übrigen Teile gehen an den Server, seine Antwort wird mit den simulierten Teilen zusammengeführt. Changesets bleiben atomar: Ein Fehler beantwortet das ganze Changeset. Verzögerung, Netzwerkfehler und CSRF wirken auf den ganzen HTTP-Request.

Alle Knöpfe

Typische Probleme