Pourquoi la gestion d'erreur est critique

Une séquence d'automatisation sans gestion d'erreur est une bombe à retardement. Quand elle échoue — et elle échouera — elle peut laisser des données dans un état incohérent, bloquer les ressources (connexions Oracle ouvertes, fichiers lockedés) ou simplement s'arrêter silencieusement sans qu'on le sache.

Une bonne gestion d'erreur dans une séquence d'automatisation suit la même règle qu'en base de données : soit on commit, soit on rollback. Jamais d'état intermédiaire non déterminé.

on_error par action

Chaque action peut définir son comportement en cas d'erreur via on_error :

{
  "type": "oracle_query",
  "query": "SELECT * FROM sejours",
  "on_error": "stop"        // stop | continue | retry | goto:label
}

// Valeurs possibles :
// "stop"         → arrêter la séquence (défaut)
// "continue"     → ignorer et passer à l'action suivante
// "retry"        → réessayer (config retry séparée)
// "goto:cleanup" → sauter à l'action labelisée "cleanup"
// "rollback"     → déclencher le bloc rollback

Retry exponentiel

{
  "type": "http_get",
  "url": "https://api.exemple.fr/data",
  "on_error": "retry",
  "retry": {
    "max":         3,
    "delay_s":     2,
    "backoff":     2.0,    // × 2 à chaque tentative : 2s, 4s, 8s
    "jitter":      true,   // éviter les tempêtes de retry synchronisées
    "on_exhausted":"goto:fallback"
  }
}
// Tentative 1 : 2s ± jitter
// Tentative 2 : 4s ± jitter
// Tentative 3 : 8s ± jitter → goto:fallback

Checkpoint et reprise

Le checkpoint sauvegarde l'état de la séquence à un point précis. Si la séquence s'interrompt (crash, panne réseau), elle repart du dernier checkpoint au prochain lancement :

[
  {"type": "oracle_query", "output_var": "data"},

  // Checkpoint après l'étape coûteuse
  {
    "type": "checkpoint",
    "label": "after_query",
    "save_vars": ["data"]
  },

  // Si la séquence repart depuis le checkpoint,
  // "data" est rechargée — la requête Oracle ne tourne pas de nouveau
  {"type": "file_write_csv", "data": "{{data}}"}
]

Rollback déclaratif

{
  "sequence": "main_sequence.json",
  "rollback": [
    {"type": "oracle_execute", "query": "DELETE FROM import_tmp WHERE batch_id=:bid",
     "bind": {"bid": "{{batch_id}}"}},
    {"type": "file_delete", "path": "{{temp_file}}"},
    {"type": "smtp_send", "to": "ops@entreprise.fr",
     "subject": "Séquence échouée : rollback effectué"}
  ]
}
// Le bloc rollback s'exécute automatiquement si on_error="rollback"

Alertes conditionnelles

{
  "type": "condition",
  "if": "len({{data}}) < 100",
  "then_actions": [
    {
      "type": "smtp_send",
      "to": "ops@entreprise.fr",
      "subject": "⚠ Données anormalement faibles : {{data|length}} lignes",
      "body": "La requête a retourné {{data|length}} lignes (attendu > 100). Vérifier."
    }
  ],
  "else_actions": []
}

Patterns combinés

// Pattern : séquence transactionnelle robuste
[
  {"type":"oracle_begin_transaction"},
  {"type":"checkpoint", "label":"after_begin"},
  {"type":"oracle_execute", "query":"INSERT ...",
   "on_error":"rollback", "retry":{"max":3, "delay_s":5}},
  {"type":"oracle_commit"},
  {"type":"smtp_send", "subject":"Import terminé : {{rows}} lignes"}
]

Conclusion

La gestion d'erreur dans AutomationSequence V8 est déclarative — on exprime le comportement voulu dans le JSON sans écrire de try/catch Python. La combinaison on_error + retry exponentiel + checkpoint + rollback couvre tous les patterns de résilience d'une séquence de production. Le journal HMAC documente chaque erreur, chaque retry et chaque rollback pour l'audit.

⚙️
PRODUIT LIÉ
AutomationSequence V8.0
← Article précédent Article suivant →