Gérer les problèmes intermittents de formatage de payload webhook avec le mappage JSON dynamique dans n8n

Questions
1

Salut à tous,

Je rencontre un goulot d’étranglement logique avec un flux de travail d’automatisation et j’aimerais voir comment d’autres gèrent les données de webhook désordonnées en entrée.

Le scénario : J’ai un service externe qui envoie des données via webhook pour déclencher un flux de travail n8n. Cependant, la structure de la charge utile JSON entrante change occasionnellement en fonction du type d’événement — parfois les clés sont imbriquées, et d’autres fois elles sont renvoyées sous forme de tableaux plats.

Ce que j’ai essayé : J’utilise actuellement des nœuds IF standard et un nœud Code exécutant du JavaScript pour vérifier l’existence des clés avant de les mapper aux nœuds HTTP Request suivants. Mais quand un changement de schéma se produit de manière inattendue, cela provoque des erreurs d’exécution en aval.

Quelqu’un a-t-il construit un motif propre et résilient pour normaliser les schémas de webhook fluctuants dans n8n avant de passer les données aux applications en aval ? Utilisez-vous des sous-flux de travail spécifiques de gestion des erreurs ou une analyse d’expression avancée ?

J’apprécie tout aperçu ou bonne pratique que vous pouvez partager !

2

Salut @Maaz Bienvenue !
Le modèle résilient consiste à arrêter de brancher sur la charge utile brute et à la normaliser une seule fois, dans un seul nœud Code juste après le Webhook, en une schéma fixe sur lequel chaque nœud en aval peut compter. Forcez la forme et lisez les clés de manière défensive, de sorte qu’un changement de schéma ne touche jamais qu’à ce seul nœud au lieu de casser les nœuds HTTP Request :

const p = $json.body ?? $json;
const rows = Array.isArray(p) ? p : (Array.isArray(p.items) ? p.items : [p]);

return rows.map(r => ({
  json: {
    id:    r.id    ?? r.data?.id ?? null,
    email: r.email ?? r.data?.customer?.email ?? null,
    type:  r.event ?? r.type ?? 'unknown',
    raw:   r,
  }
}));

Les ?. et ?? sont la partie qui achète la résilience : ils lisent les clés imbriquées ou manquantes sans lever d’exception, donc un champ déplacé ou absent devient null au lieu d’être une erreur grave. À partir de là, branchez sur le type normalisé avec un nœud Switch plutôt que des IF enchaînés (chaque branche émettant toujours les mêmes champs), réglez On Error sur Continue (en utilisant la sortie d’erreur) sur les nœuds HTTP Request afin qu’un mauvais élément aille vers une branche d’erreur au lieu d’arrêter l’exécution, et pointez le flux de travail vers un flux de travail Error Trigger dédié sous Options > Settings afin que tout ce qui s’échappe encore soit détecté et signalé.