Tâches planifiées

Version du document : 20260905

Versions de l’app couvertes par ce document :

iOS : >= 3.16

Android : >= 1.8.0

macOS / Windows (bureau) : >= 1.0.21

Une tâche planifiée déclenche un rejeu de requête ou une règle complète de rejeu combiné, selon un Cron ou un intervalle fixe. Utile dès qu’un tap du doigt arrive trop tard : flash sale, seconde d’ouverture, sondage périodique d’un health check.

Cas typique : la fenêtre d’un flash sale ne dure que quelques secondes ; à la main, on la rate presque toujours. On reprend la requête de commande dans l’historique de capture (ou on la compose en Combo Replay), on crée la tâche, on envoie à la seconde juste avant l’ouverture, et on s’arrête tout seul quand le corps dit succès ou « vente terminée ».

Orchestration, injection de dépendances et expressions du Combo Replay : guide du rejeu combiné.

1. Aperçu

Capacité	Rôle
Rejeu de requête	Rejoue un HTTP/HTTPS depuis un snapshot (Method / URL / Header / Body)
Rejeu combiné	Exécute toute la règle combo depuis le snapshot (couches, expressions, injection)
Cron	Expression à 6 champs (secondes comprises) : `seconde minute heure jour mois jour-semaine`
Personnalisé	Répète toutes les N secondes ; on peut plafonner le nombre et la durée (iOS / bureau ont aussi une heure de début)
Arrêt automatique	Deux types seulement : regex sur le body, ou égalité exacte de chaîne sur un champ JSON. Un match désactive le Job ; ce n’est pas une pause
Historique d’exécution	Panneau dédié Execution History, avec Avg / P95 / P99 et taux de succès

2. Démarrage rapide

Capturez d’abord le HTTP/HTTPS à cadencer. Pour un flux, créez et enregistrez une règle Combo Replay.
Ouvrez la liste Scheduled Task, touchez + / Add Scheduled Task.
Renseignez Job Name et le type de cible :
- Request Replay : une requête de l’historique ; query, headers et body restent éditables.
- Combo Replay : une règle existante ; les paramètres de chaque nœud restent éditables.
Choisissez Cron ou Custom, et vérifiez l’aperçu des prochaines exécutions.
Éventuellement, activez Auto Terminate pour coller une réponse « succès / fin » via regex ou champ JSON.
Laissez le Job Enabled, puis :
- iOS / Android : démarrez la capture (VPN). Rien ne part sans capture. Tant que le VPN tourne, ces requêtes atterrissent dans l’historique, et rewrite / scripts s’appliquent.
- Bureau : gardez la fenêtre ApiCatcher ouverte, pas besoin de VPN. Démarrez la capture seulement si rewrite / scripts doivent agir sur le trafic envoyé par le Job.
Ouvrez le Job pour consulter Execution History.

3. Accès et gestion

3.1 Où trouver Scheduled Task

Accueil capture, + en haut à droite → Scheduled Task
Sur Request Replay ou la page d’exécution Combo Replay, le réveil en haut à droite crée le Job à partir de la requête ou de la règle courante

3.2 Créer / modifier / supprimer / activer

Action	Comment
Créer	+ dans la liste, ou Add Scheduled Task à l’état vide
Voir l’historique	Toucher la ligne
Modifier	Glisser vers la gauche → Edit
Supprimer	Glisser vers la gauche → Delete (l’historique de ce Job part avec)
Activer / désactiver	Interrupteur Enabled sur la page d’édition

Un Job neuf est activé par défaut.

En éditant un Job existant, on ne change ni le type de cible ni la requête/règle choisie. On peut encore changer le nom, l’interrupteur, les paramètres du snapshot / des nœuds, la planification et l’arrêt automatique.

4. Ce que le Job exécute

Il n’y a que deux cibles :

Cible du Job	Contenu
Request Replay	Un HTTP ; injection d’expressions possible
Combo Replay	Plusieurs HTTP, dans l’ordre de la règle ; injection de dépendances et d’expressions

Si vous changez la règle Combo Replay et voulez que le Job suive, il faut créer un nouveau Job.

5. Planification

Deux types : Cron / Custom.

La page de réglages prévisualise les prochaines exécutions (5 au plus).

5.1 Cron

L’expression a 6 champs, dans cet ordre :

second  minute  hour  day  month  weekday

Un 7ᵉ champ (année), s’il est là, est ignoré. Moins de 6 champs : impossible de calculer la prochaine heure, donc pas de planification.

Ce n’est pas le crontab Linux à 5 champs. */5 * * * * (toutes les 5 minutes) est invalide ici.

Écriture autorisée :

* : n’importe quelle valeur dans ce champ
? : jour ou jour de semaine « non précisé »
Un nombre : p. ex. seconde 0, heure 9
Pas / dans le champ secondes : 0/30 = toutes les 30 secondes

Valeur par défaut / placeholder :

0 * * * * ?

La seconde 0 de chaque minute.

Exemples :

Expression	Sens
`0 * * * * ?`	Seconde 0 de chaque minute
`0 0 * * * ?`	Minute 0, seconde 0 de chaque heure
`0 0 9 * * ?`	Tous les jours à 09:00:00
`0/30 * * * * ?`	Toutes les 30 secondes

Pour « toutes les N minutes », passez par Custom et mettez l’intervalle à N × 60 secondes.

À côté du champ, l’IA peut générer un Cron à partir du langage naturel. Vérifiez ensuite l’aperçu.

Expression vide ou sans prochaine heure : le Job n’est pas cadencé cette fois. Il n’est pas désactivé pour autant.

5.2 Custom

Pas de champ « heure de fin ». Répétition à intervalle fixe ; arrêt dès que le nombre ou la durée est atteint (contrôle avant chaque exécution).

Champ	Unité	Sens
Intervalle	secondes	Fréquence ; au moins 1
Nombre max d’exécutions	fois	Arrêt à ce nombre
Durée	minutes	Arrêt autant de minutes après la première exécution

Les compteurs vivent en mémoire du moteur. Un redémarrage du processus les remet à zéro. Un Job déjà désactivé ne se rallume pas tout seul. Remettre Enabled reprend le compte à 0.

Nombre ou durée atteint : le Job est enregistré disabled.

6. Arrêt automatique

Nom dans l’UI : Auto Terminate. Un match arrête le Job, qu’il reste des ticks Cron ou des exécutions Custom.

Deux types seulement. Pas d’arrêt sur le code HTTP :

Type	Cible	Règle
Regular expression	Texte du body	Un match n’importe où suffit (pas besoin que tout le body soit égal au motif)
JSON field	JSON de la réponse	La valeur au chemin doit être strictement égale (chaîne) à Match value

Compléments :

Plusieurs conditions = OU.
Combo Replay peut désigner un nœud observateur ; on ne regarde que son résultat.
La comparaison JSON est une égalité de chaînes : le nombre 200 demande la valeur 200 ; booléens true / false.

Un match désactive le Job. Le Job et l’historique restent ; rien n’est supprimé.

7. Quand ça tourne vraiment

Les limites OS imposent un processus différent selon la plateforme.

iOS

Ça tourne dans le processus VPN. Il faut démarrer la capture.

Situation	Ça continue ?
Capture on, app principale en arrière-plan	Oui
Capture on, app principale balayée, VPN encore là	Oui
Capture arrêtée	Tous les timers annulés ; stop
Le système récupère le processus VPN (mémoire)	Stop ; relancer la capture recharge les Jobs activés
Capture off	Ne tourne pas. L’enregistrement n’écrit que la base ; planification au prochain démarrage de capture

Timeout 15 secondes. VPN allumé : le replay passe par le MITM local (127.0.0.1:8888), donc rewrite et scripts s’appliquent, et le même trafic peut apparaître dans l’historique de capture.

Android

Ça tourne dans le service VPN. Il faut démarrer la capture.

Situation	Ça continue ?
Capture on, app seulement en arrière-plan (notification de premier plan encore visible)	En général oui
Capture arrêtée	`stop()` ; coroutines annulées ; compteur / première heure en mémoire vidés
Forcer l’arrêt de l’app	VPN et processus meurent ; les Jobs s’arrêtent
Économie d’énergie qui tue le processus	Stop ; si le service de premier plan redémarre et appelle `start()`, les Jobs encore Enabled sont replanifiés

Timeouts connexion / lecture : 30 secondes chacun. Même MITM local, donc souvent visible dans l’historique de capture.

Bureau

Ça tourne dans le processus de l’app. Tant qu’il vit, ça tourne ; quitter arrête.

Situation	Ça continue ?
Fenêtre ouverte (minimisable)	Oui
Capture off	Oui
Quitter l’app	Stop

Timeout d’une requête : 30 secondes ; chaque nœud Combo Replay : 5 secondes. Le trafic passe par le proxy système. Si la capture locale est on, rewrite / scripts s’appliquent et l’historique peut les montrer.

Exécution Combo Replay (identique sur les trois)

Couches selon les dépendances ; une couche en parallèle ; la suivante attend.
Nœud hors 2xx (ou envoi en échec) : les couches suivantes sont sautées (pas de requête).
Expressions, injection et variables globales du snapshot s’exécutent.

8. Historique d’exécution et stats

Touchez le Job pour ouvrir Execution History (pas l’éditeur).

Les stats du haut agrègent toutes les exécutions de ce Job (un tic du timer = une ligne, pas un HTTP) :

Avg / P95 / P99 : durée de chaque exécution (fin − début de cet enregistrement), puis moyenne et 95ᵉ / 99ᵉ percentiles, affichés en millisecondes
Success Rate / Success / Failure : une exécution ne compte succès que si toutes ses requêtes ont réussi ; un nœud combo en échec fait échouer toute l’exécution. On compte ensuite sur tout l’historique

Touchez une ligne pour voir la requête envoyée. En Combo Replay, d’abord la liste des nœuds, puis le détail.

En haut à droite, on vide l’historique de ce Job. Supprimer le Job emporte l’historique.

Les données sont dans leur propre table, pas dans History / Request History. Comme plus haut, avec la capture allumée le même trafic se retrouve souvent dans l’historique principal.

Ces lignes n’ont pas de badge « tâche planifiée » ; elles ressemblent à des captures ordinaires.

9. Scénarios

Scénario 1 : marteler l’API de commande avant le flash sale

Capturer l’API de commande, vérifier body / headers (horodatage vivant : ${method.timestamp()} sur un nœud combo).
Créer la tâche sur cette requête ou cette règle.
Custom : début quelques secondes avant (obligatoirement dans le futur), intervalle 1 seconde.
Auto terminate : champ JSON code égal à 200, ou regex de succès / fin.
iOS / Android : démarrer la capture à l’avance. Bureau : laisser la fenêtre ouverte.

Scénario 2 : health check toutes les minutes

Cron suffisant sur les trois plateformes :

0 * * * * ?

Pas d’auto terminate. Ça tourne à la minute jusqu’à désactivation manuelle, ou arrêt de la capture (mobile) / fermeture de l’app (bureau).

Scénario 3 : régression cadencée login + API métier

Dans Combo Replay : login → API métier, injection du token.
Créer la tâche à partir de cette règle.

10. FAQ

Q : J’ai enregistré, rien ne part.
A : iOS / Android : démarrer la capture. Bureau : laisser l’app ouverte. Vérifier Enabled, Cron à 6 champs, et que l’aperçu calcule une prochaine heure.

Q : Un Job Custom passe disabled dès l’enregistrement.
A : Une heure de début déjà passée : le moteur désactive sans exécuter une seule fois. Mettre une heure future, réactiver, enregistrer.

Q : J’ai changé la règle Combo Replay, le Job n’a pas bougé.
A : C’est voulu. Le Job garde le snapshot de la création. Supprimer et recréer.

Q : Pourquoi ces requêtes apparaissent aussi dans l’historique principal ?
A : Sur mobile, VPN allumé, le replay planifié passe par le MITM local et s’enregistre comme une capture normale. Le rapport dédié est dans Execution History. L’historique principal n’étiquette pas les tâches planifiées.

Q : Auto terminate sur le statut 200 ne fait rien.
A : Il n’y a pas d’arrêt sur le code HTTP. Champ JSON (ex. code == 200) ou regex sur le body.

Q : Pourquoi certains nœuds combo n’ont pas été envoyés ?
A : Comme en exécution manuelle : après un non-2xx sur une couche précédente, les suivantes sont sautées. Un observateur sauté n’a pas de body, l’arrêt automatique ne matche pas.

Q : Les Jobs survivent à la désinstallation / au vidage des données ?
A : Jobs et historique sont locaux. Ils disparaissent.

Q : Faut-il laisser les règles de rewrite allumées ?
A : Sur mobile, ces requêtes passent par le MITM. Si un mock / drop / modify colle à l’URL, le Job envoie déjà la version altérée. Réponse bizarre : regarder d’abord rewrite et scripts.