Exécuter et déboguer un scénario

Lancer

Le bouton de lecture de l’éditeur. Il est désactivé tant qu’il reste des erreurs de validation.

Si le scénario déclare des paramètres sans valeur, Restorm les demande au moment où l’exécution les atteint.

Suivre l’exécution

Le journal d’exécution se remplit au fil de l’eau. Chaque entrée porte un niveau (debug, info, warn, error), un horodatage à la milliseconde, un message, et éventuellement des données structurées.

Deux niveaux de détail :

• par défaut, seules vos propres entrées — celles produites par l’action Log — sont affichées ;
• l’affichage complet ajoute les entrées du moteur : démarrage et fin de chaque boîte, valeurs transitant sur les liaisons, erreurs.

Le bouton de copie du journal produit exactement le même texte que la sortie de la ligne de commande : ce que vous collez dans un ticket est identique à ce que produira la CI.

Suivre un sous-scénario

Quand un scénario en appelle un autre (action Exécuter un scénario), le run du sous-scénario est imbriqué dans le journal du parent, entre le démarrage et la fin de la boîte. Cliquez une ligne de log issue du sous-scénario : sa vue s’ouvre en surimpression au-dessus du graphe parent — son graphe complet et un lien « Éditer le scénario ».

Le clic centre d’abord la surimpression sur la boîte qui a produit la ligne ; le bouton d’ajustement de la vue affiche le sous-scénario en entier.

Historique des runs

Les exécutions sont archivées à côté du projet, dans le même fichier que l’historique des réponses. Par défaut : les 50 dernières exécutions, 2 000 entrées de journal par exécution, avec une durée de vie de 30 minutes.

Arrêter

Le bouton d’arrêt interrompt l’exécution. Les attentes en cours (Attendre, Attendre jusqu’à, Minuteur) s’interrompent proprement, les connexions ouvertes sont fermées et les actions de code en cours sont abandonnées.

Exécuter une seule boîte

Les boîtes de type requête peuvent être exécutées isolément, sans lancer tout le scénario : c’est le moyen rapide de vérifier qu’un appel part bien avant de câbler le reste.

Déboguer

Le journal comme premier réflexe

Ajoutez des actions Log aux endroits stratégiques : c’est le console.log du graphe, et c’est ce que vous retrouverez en CI.

Les notifications

L’action Toast affiche un message dans l’interface. Utile pendant la construction — sans effet en mode headless, où l’exécution continue normalement.

L’inspecteur pas à pas

L’édition Pro donne accès au débogage pas à pas : points d’arrêt sur les boîtes, avancée contrôlée, inspection des valeurs en transit. Voir Plans et capacités.

Les erreurs

Toute boîte (sauf Sortie, Maintenant et Retry) a un port error. Une boîte qui échoue sans que son error soit câblé fait échouer l’exécution.

Deux motifs utiles :

• Retry — enveloppe une frontière d’erreur : les échecs en aval sont rattrapés et relancés selon la stratégie configurée (fixe, linéaire, exponentielle), avec une sortie exhausted quand les tentatives sont épuisées.
• Throw — échoue délibérément, avec un message. C’est ce qu’il faut pour faire échouer un job de CI sur une condition métier.

Piloter par MCP

Un agent IA peut lancer et surveiller un scénario (édition Pro) : run_scenario (avec params, interactive, blocking), get_scenario_run_status (qui renvoie le journal, les demandes de saisie en attente et l’arbre des sous-runs), list_scenario_runs, stop_scenario_run et answer_scenario_input. Voir Outils MCP.