Geplante Aufgaben

Dokumentversion: 20260905

Von diesem Dokument abgedeckte App-Versionen:

iOS: >= 3.16

Android: >= 1.8.0

macOS / Windows (Desktop): >= 1.0.21

Eine geplante Aufgabe führt eine Request-Wiedergabe oder eine komplette Combo-Replay-Regel per Cron oder festem Intervall aus. Typisch, wenn ein Fingertipp zu langsam ist: Flash-Sale-Lasttests, Checks zum Verkaufsstart, periodische Health-Checks.

Typischer Fall: Ein Flash Sale dauert nur Sekunden, per Hand trifft man ihn kaum. Request aus der Capture-Historie holen (oder als Combo Replay bauen), Aufgabe anlegen, kurz vor Start im Sekundentakt senden und per Auto-Abbruch stoppen, sobald der Body „Kauf erfolgreich“ oder „Aktion beendet“ sagt.

Aufbau von Combo Replay, Abhängigkeitsinjektion und Ausdrücke: Combo-Replay-Handbuch.

1. Überblick

Funktion	Bedeutung
Request-Wiedergabe	Eine HTTP/HTTPS-Anfrage aus einem Snapshot (Method / URL / Header / Body)
Combo Replay	Die ganze Combo-Regel aus dem Snapshot (Schichten, Ausdrücke, Injektion)
Cron	6 Felder inklusive Sekunde: `Sekunde Minute Stunde Tag Monat Wochentag`
Benutzerdefiniert	Wiederholung in Sekunden; Begrenzung nach Anzahl und Dauer (iOS / Desktop zusätzlich Startzeit)
Automatisches Beenden	Nur zwei Arten: Regex auf dem Response-Body oder exakter String eines JSON-Felds. Treffer deaktiviert die Aufgabe, pausiert sie nicht
Ausführungsverlauf	Eigenes Panel Execution History mit Avg / P95 / P99 und Erfolgsquote

2. Schnellstart

Zuerst erfassen, damit die HTTP/HTTPS-Anfrage da ist. Für Abläufe Combo-Replay-Regel bauen und speichern.
Liste Scheduled Task öffnen, + / Add Scheduled Task.
Job Name ausfüllen, Ziel wählen:
- Request Replay: eine Anfrage aus der Historie; Query, Header und Body bleiben editierbar.
- Combo Replay: eine vorhandene Regel; Parameter je Knoten bleiben editierbar.
Cron oder Custom wählen und die Vorschau der nächsten Läufe prüfen.
Optional Auto Terminate einschalten und „Erfolg / Ende“ per Regex oder JSON-Feld erkennen.
Aufgabe Enabled lassen, dann:
- iOS / Android: Capture (VPN) starten. Ohne Capture läuft nichts. Solange das VPN offen ist, landen die Requests in der Historie, Rewrite und Skripte greifen.
- Desktop: ApiCatcher-Fenster offen lassen, kein VPN nötig. Capture nur starten, wenn Rewrite / Skripte auf den von der Aufgabe gesendeten Traffic wirken sollen.
Aufgabe öffnen und Execution History ansehen.

3. Einstieg und Verwaltung

3.1 Wo finde ich Scheduled Task?

Capture-Startseite oben rechts + → Scheduled Task
Auf Request Replay oder der Combo-Replay-Ausführungsseite oben rechts die Wecker-Schaltfläche: Job direkt aus der aktuellen Anfrage bzw. Regel

3.2 Anlegen / Bearbeiten / Löschen / Aktivieren

Aktion	Vorgehen
Anlegen	+ in der Liste oder Add Scheduled Task im Leerzustand
Verlauf	Zeile antippen
Bearbeiten	Nach links wischen → Edit
Löschen	Nach links wischen → Delete (löscht den Verlauf dieser Aufgabe mit)
Ein / Aus	Schalter Enabled auf der Bearbeiten-Seite

Neue Aufgaben sind standardmäßig aktiv.

Beim Bearbeiten einer bestehenden Aufgabe lassen sich Zieltyp und die gewählte Anfrage/Regel nicht wechseln. Name, Enabled-Schalter, Snapshot-Parameter / Knoten, Zeitplan und Auto-Terminate bleiben änderbar.

4. Was die Aufgabe ausführt

Es gibt nur zwei Ziele:

Job-Ziel	Inhalt
Request Replay	Eine HTTP-Anfrage; Ausdrucksinjektion möglich
Combo Replay	Mehrere HTTP-Anfragen in der Reihenfolge der Combo-Regel; Abhängigkeits- und Ausdrucksinjektion möglich

Nach Änderungen an der Combo-Regel braucht es einen neuen Job, wenn die Aufgabe die Änderung übernehmen soll.

5. Zeitplan

Zwei Typen: Cron / Custom.

Die Einstellungsseite zeigt die nächsten Läufe (höchstens 5).

5.1 Cron

Der Ausdruck hat 6 Felder, Reihenfolge:

second  minute  hour  day  month  weekday

Ein 7. Feld (Jahr) wird ignoriert. Weniger als 6 Felder: nächster Lauf nicht berechenbar, kein Scheduling.

Das ist nicht das 5-Felder-Crontab von Linux. */5 * * * * (alle 5 Minuten) ist hier ungültig.

Erlaubt:

*: beliebig in diesem Feld
?: bei Tag oder Wochentag „unbestimmt“
Einzelne Zahl: z. B. Sekunde 0, Stunde 9
Schritt / im Sekundenfeld: 0/30 = alle 30 Sekunden

Standard / Platzhalter:

0 * * * * ?

Sekunde 0 jeder Minute.

Beispiele:

Ausdruck	Bedeutung
`0 * * * * ?`	Sekunde 0 jeder Minute
`0 0 * * * ?`	Minute 0, Sekunde 0 jeder Stunde
`0 0 9 * * ?`	täglich 09:00:00
`0/30 * * * * ?`	alle 30 Sekunden

Für „alle N Minuten“ Custom nutzen und das Intervall auf N × 60 Sekunden setzen.

Neben dem Feld kann AI aus Alltagssprache Cron erzeugen. Danach die Vorschau prüfen.

Leerer Ausdruck oder kein nächster Zeitpunkt: dieser Lauf entfällt. Die Aufgabe wird deshalb nicht automatisch deaktiviert.

5.2 Custom

Kein eigenes Endzeit-Feld. Feste Wiederholung; Stopp bei Anzahl oder Dauer (Prüfung vor jedem Lauf).

Feld	Einheit	Bedeutung
Intervall	Sekunden	Wie oft; mindestens 1
Max. Ausführungen	Male	Stopp nach dieser Anzahl
Dauer	Minuten	Stopp so viele Minuten nach dem ersten Lauf

Zähler liegen im Speicher der Engine. Prozessneustart setzt sie zurück. Eine bereits deaktivierte Aufgabe bleibt aus. Enabled wieder an: Zähler ab 0.

Ist Anzahl oder Dauer erreicht, wird die Aufgabe als disabled gespeichert.

6. Automatisches Beenden

UI-Name: Auto Terminate. Ein Treffer beendet die Aufgabe, egal ob Cron noch Termine hat oder Custom-Läufe übrig sind.

Nur zwei Bedingungstypen, kein Stopp nach HTTP-Status:

Typ	Gegenstand	Regel
Regular expression	Response-Body als Text	Treffer irgendwo reicht (kein Vollstring-Match nötig)
JSON field	Response-JSON	Wert am Pfad exakt gleich dem Match-Wert (String)

Hinweise:

Mehrere Bedingungen sind ODER.
Combo Replay kann einen Observer-Knoten setzen; nur dessen Ergebnis zählt.
JSON-Vergleich ist String-Gleichheit: Zahl 200 → Match-Wert 200; Booleans true / false.

Ein Treffer deaktiviert die Aufgabe. Aufgabe und Verlauf bleiben, nichts wird gelöscht.

7. Wann es wirklich läuft

Wegen OS-Grenzen sitzt die Engine je Plattform woanders.

iOS

Läuft im VPN-Prozess. Capture muss laufen.

Situation	Läuft weiter?
Capture an, Haupt-App im Hintergrund	Ja
Capture an, Haupt-App weggewischt, VPN noch aktiv	Ja
Capture gestoppt	Alle Timer weg, Stopp
System räumt den VPN-Prozess (Speicher)	Stopp; Capture erneut starten lädt aktivierte Jobs
Capture aus	Läuft nicht. Speichern schreibt nur die DB; Scheduling beim nächsten Capture-Start

Timeout 15 Sekunden. Mit VPN geht Replay über lokales MITM (127.0.0.1:8888): Rewrite und Skripte greifen, dieselben Requests können in der Capture-Historie auftauchen.

Android

Läuft im VPN-Dienst. Capture muss laufen.

Situation	Läuft weiter?
Capture an, App nur im Hintergrund (Foreground-Benachrichtigung sichtbar)	Meist ja
Capture gestoppt	`stop()`; Coroutinen weg; Zähler / Erstlaufzeit im Speicher leer
App zwangsbeendet	VPN und Prozess tot, Jobs stoppen
Energiesparen tötet den Prozess	Stopp; startet der Foreground-Dienst neu und ruft `start()` auf, werden noch aktivierte Jobs neu geplant

Connect- und Read-Timeout je 30 Sekunden. Ebenfalls lokales MITM, deshalb oft in der Capture-Historie sichtbar.

Desktop

Läuft im App-Prozess. Solange der Prozess lebt, läuft es; Beenden stoppt.

Situation	Läuft weiter?
Fenster offen (minimierbar)	Ja
Capture aus	Ja
App beendet	Stopp

Einzelrequest 30 Sekunden, jeder Combo-Knoten 5 Sekunden. Traffic über Systemproxy. Ist lokales Capture an, greifen Rewrite / Skripte, und die Historie kann dieselben Requests zeigen.

Combo-Replay-Ausführung (alle Plattformen gleich)

Schichten nach Abhängigkeiten; eine Schicht parallel, die nächste wartet.
Knoten nicht 2xx (oder Sendefehler): spätere Schichten übersprungen (kein Request).
Ausdrücke, Injektion und globale Variablen aus dem Snapshot laufen mit.

8. Ausführungsverlauf und Statistik

Aufgabe antippen → Execution History (nicht der Editor).

Die Statistik oben fasst alle Läufe dieser Aufgabe zusammen (ein Timer-Tick = eine Zeile, nicht ein HTTP-Call):

Avg / P95 / P99: Dauer jedes Laufs (Ende − Start dieses Datensatzes), dann Mittel und 95./99. Perzentil, Anzeige in Millisekunden
Success Rate / Success / Failure: ein Lauf zählt nur als Erfolg, wenn alle Requests darin erfolgreich waren; ein fehlgeschlagener Combo-Knoten macht den Lauf zum Fehler. Daraus die Zählung über alle Datensätze

Zeile antippen zeigt den gesendeten Request. Bei Combo Replay zuerst die Knotenliste, dann Details pro Knoten.

Oben rechts: Verlauf dieser Aufgabe leeren. Aufgabe löschen entfernt den Verlauf mit.

Die Daten liegen in einer eigenen Tabelle, nicht in History / Request History. Bei laufendem Capture landen dieselben Requests oft trotzdem in der Haupthistorie.

Dort gibt es kein Scheduled-Task-Kennzeichen; sie sehen aus wie normale Captures.

9. Beispielszenarien

Szenario 1: Bestell-API vor dem Sale hämmern

Bestell-API erfassen, Body / Header prüfen (für Zeitstempel ${method.timestamp()} an einem Combo-Knoten).
Geplante Aufgabe auf diesen Request oder die Combo-Regel.
Custom: Start ein paar Sekunden vor dem Sale (unbedingt in der Zukunft), Intervall 1 Sekunde.
Auto Terminate: JSON code gleich 200 oder Regex auf Erfolg / Ende.
iOS / Android: Capture vorher starten. Desktop: Fenster offen lassen.

Szenario 2: Health-Check jede Minute

Cron auf allen drei Plattformen:

0 * * * * ?

Kein Auto Terminate. Läuft minütlich, bis man deaktiviert oder Capture stoppt (Mobil) / die App beendet (Desktop).

Szenario 3: Login plus Business-API zeitgesteuert

In Combo Replay: Login → Business-API, Token injizieren.
Daraus die geplante Aufgabe anlegen.

10. FAQ

Q: Gespeichert, aber es läuft nichts.
A: iOS / Android: Capture starten. Desktop: App offen lassen. Außerdem Enabled, Cron mit 6 Feldern, Vorschau mit nächstem Zeitpunkt.

Q: Custom-Job ist direkt nach dem Speichern disabled.
A: Startzeit in der Vergangenheit: die Engine deaktiviert ohne einen Lauf. Zukunft setzen, aktivieren, erneut speichern.

Q: Combo-Regel geändert, die Aufgabe nicht.
A: So gewollt. Die Aufgabe hält den Snapshot vom Anlegen. Löschen und neu anlegen.

Q: Warum tauchen die Requests auch in der Haupthistorie auf?
A: Mobil mit VPN: Replay geht durch lokales MITM und wird wie normales Capture gespeichert. Zahlen stehen in Execution History. Die Haupthistorie hat kein Scheduled-Task-Badge.

Q: Auto Terminate auf Status 200 tut nichts.
A: Es gibt keinen Stopp nach HTTP-Status. JSON-Feld (z. B. code == 200) oder Regex auf den Body.

Q: Warum wurden Combo-Knoten nicht gesendet?
A: Wie bei manuellem Combo Replay: nach Nicht-2xx in einer früheren Schicht werden spätere übersprungen. Ein übersprungener Observer hat keinen Body, Auto Terminate trifft nicht.

Q: Bleiben Jobs nach Deinstallieren / Daten löschen?
A: Jobs und Verlauf sind lokal. Beides ist dann weg.

Q: Müssen Rewrite-Regeln dauernd an sein?
A: Mobil gehen geplante Requests durch MITM. Trifft Mock / Drop / Modify die URL, sendet die Aufgabe die veränderte Variante. Bei merkwürdigen Responses zuerst Rewrite und Skripte prüfen.