Flowpaja
Ce qu'il vous faut
- Un scénario Make.com avec au moins un module qui peut échouer, comme HTTP – Make a request ou Google Sheets
- Un accès aux paramètres du scénario et à l'onglet History
- Un endroit où envoyer des alertes, comme Gmail ou Slack
Pas à pas : ajouter une route d'error handler et choisir un handler
1. Sachez ce qui se passe sans handler
Sans handler, tout dépend du réglage Store incomplete executions. S'il est désactivé, Make applique Rollback : l'exécution s'arrête avec un statut d'erreur et, après 3 erreurs consécutives par défaut (réglage Number of consecutive errors), Make désactive le scénario. Un scénario qui démarre par un déclencheur instantané est désactivé dès la première erreur. Si le réglage est activé, Make stocke l'exécution échouée comme incomplete execution et l'exécution se termine par un avertissement. Les modules qui prennent en charge les transactions, signalés par l'étiquette ACID, comme les modules Data store ou MySQL, annulent leurs modifications. Des modules comme Gmail, Google Sheets ou HTTP ne le font pas : ce qu'ils ont déjà fait reste fait.
2. Ajoutez une route d'error handler
Faites un clic droit sur le module qui peut échouer et choisissez Add error handler. Une route apparaît, qui part du module. Tout ce que vous y placez ne s'exécute que lorsque ce module est en erreur. La route n'a pas besoin de se terminer par un error handler : si rien n'y échoue, Make ignore l'erreur, si bien qu'une route avec seulement un module de notification se comporte comme Skip. Vous pouvez ajouter un filtre sur le premier lien de la route, pour que des erreurs différentes aillent vers des handlers différents.
3. Choisissez l'error handler en bout de route
Voici ce que fait chacun, en termes simples.
Skip (anciennement Ignore) retire le bundle en échec du flux et passe au suivant. L'exécution se termine avec un statut de succès et rien n'est stocké. Utilisez-le quand perdre un élément est acceptable, par exemple une ligne défectueuse dans un lot que vous consignez ailleurs.
Resume remplace la sortie du module en échec par des valeurs que vous fournissez, et le scénario continue après ce module comme s'il avait réussi. Utilisez-le quand une valeur par défaut raisonnable existe, comme « unknown » pour une recherche qui n'a rien renvoyé. Attention : ces valeurs de remplacement se propagent dans tout ce qui suit.
Retry (anciennement Break) retire le bundle en échec du flux et le sauvegarde, avec les étapes restantes, comme incomplete execution, pour qu'il soit relancé plus tard, automatiquement ou à la main. Avec Automatically complete execution activé, vous réglez le nombre de tentatives et l'intervalle entre elles. Les autres bundles continuent, et l'exécution se termine par un avertissement. Utilisez-le quand les données comptent et que l'erreur est probablement temporaire, comme une limite de requêtes ou une panne. Retry exige que Store incomplete executions soit activé dans les paramètres du scénario, et Make signale le handler tant que ce n'est pas fait.
Rollback arrête l'exécution, la marque comme erreur et annule les modifications dans les modules qui prennent en charge les transactions. Il compte dans la limite d'erreurs consécutives. Utilisez-le uniquement si vous écrivez dans quelque chose de transactionnel, comme une base de données où une mise à jour à moitié faite serait pire que rien.
Commit arrête l'exécution et valide les modifications effectuées jusque-là par les modules transactionnels. Les modules restants ne sont pas traités, et l'exécution se termine par un avertissement. C'est le pendant de Rollback, et il est rarement nécessaire pour des scénarios bâtis autour de Google Sheets et de Gmail.
4. Construisez un exemple pratique avec HTTP – Make a request
Supposons que le scénario lise des lignes dans Google Sheets et envoie chacune à une API.
- Dans le module HTTP, réglez Evaluate all states as errors (except for 2xx and 3xx) sur Yes. C'est le libellé de la documentation de Make pour les modules HTTP (legacy) ; la nouvelle app HTTP peut le formuler autrement. Sinon, une réponse 429 ou 500 peut passer pour un succès. Avec ce réglage, le corps de la réponse d'un appel en échec n'est généralement pas disponible sur la route d'erreur.
- Ajoutez une route d'error handler au module HTTP.
- Placez un filtre sur le premier lien de la route pour les limites de requêtes et les erreurs serveur, par exemple code d'état 429 ou 500 et plus. Les noms exacts des champs figurent dans la sortie d'erreur d'un Run once en échec.
- Sur cette route, ajoutez l'error handler Retry avec 3 tentatives et un intervalle de 10 minutes. Le bundle est stocké puis relancé.
- Ajoutez une seconde route pour les erreurs côté client (un 400 ou 404 causé par une ligne défectueuse). Envoyez un e-mail ou un message Slack avec les détails de la ligne et le texte de l'erreur, mappé depuis la sortie d'erreur du module en échec dans le panneau de mapping, et terminez par Skip, pour qu'une ligne mal formée ne retienne pas les autres.
5. Ajoutez un exemple Google Sheets pour la journalisation
Sur la route Skip, avant l'error handler, ajoutez Google Sheets – Add a Row vers une feuille nommée « Errors » avec l'heure {{now}}, le nom du scénario, l'enregistrement concerné et le message d'erreur. Une feuille de journal transforme des échecs invisibles en quelque chose que vous pouvez lire le lendemain matin.
6. Comprenez le lien avec les incomplete executions
Quand Retry stocke un bundle, il apparaît dans l'onglet Incomplete executions du scénario. De là, vous pouvez l'ouvrir, voir l'erreur, corriger la cause et le relancer, ou le supprimer. Avec des nouvelles tentatives automatiques, Make réessaie de lui-même. Si Process data in order est activé, Make reporte les nouvelles exécutions jusqu'à ce que les incomplete executions soient résolues ; consultez donc l'onglet régulièrement. Make ne stocke pas non plus d'incomplete execution quand l'erreur survient dans le premier module, sauf si ce module a un handler Retry. Le stockage des incomplete executions n'est pas illimité ; vérifiez les limites en vigueur pour votre offre.
7. Testez le handler exprès
Cassez quelque chose volontairement : une mauvaise clé d'API ou une URL invalide, lancez une fois et observez quelle route s'exécute. Un handler que vous n'avez jamais déclenché est un handler dont vous ne savez pas s'il fonctionne.
Erreurs courantes et solutions
Retry (Break) ne sert à rien. Store incomplete executions est désactivé dans les paramètres du scénario, donc le bundle n'a nulle part où aller. Activez-le et testez de nouveau.
Les échecs disparaissent sans laisser de trace. Skip (Ignore) a été utilisé sans journal ni alerte. Ajoutez toujours une ligne de journal ou une notification avant l'error handler.
Des données erronées apparaissent en aval après une erreur. Resume a fourni une valeur de remplissage et les modules suivants l'ont traitée comme réelle. N'utilisez Resume qu'avec des valeurs sûres, ou laissez la valeur vide arriver à un filtre qui l'arrête.
Rollback n'a « pas annulé » l'e-mail ni la ligne de la feuille. Rollback n'annule que les modules transactionnels. Gmail, Google Sheets et les appels HTTP simples ne sont pas couverts. Si vous devez éviter un travail partiel, ordonnez les modules de façon que l'étape irréversible vienne en dernier.
Le handler ne s'exécute jamais sur un HTTP 4xx ou 5xx. Le module HTTP traite ces réponses comme des succès. Activez l'option qui évalue comme erreurs tous les états autres que le succès.
Les nouvelles tentatives créent des doublons. Retry relance l'exécution stockée, et si la première tentative avait en partie réussi de l'autre côté, vous obtenez une seconde copie. Là où l'API le permet, envoyez une clé d'idempotence, ou vérifiez d'abord si l'enregistrement existe.