Conception de flux de travail N8n : acheminer une localisation WhatsApp vers la réservation de trajets, la livraison de nourriture et la collecte spéciale

Aidez-moi à Construire mon Flux de Travail
1

Salut à tous,
Je construis un flux de travail WhatsApp dans n8n qui gère plusieurs services à partir du même message de localisation entrant:

  • :taxi: Réservation de trajet (lieu de départ et d’arrivée)
  • :hamburger: Livraison de nourriture
  • :package: Collecte spéciale
    Mon défi est de conserver la localisation WhatsApp d’origine (« latitude »/« longitude ») tout en interrogeant Google Sheets pour les trajets actifs, les commandes ou les collectes. Après des nœuds comme Find Active Ride ou Find Active Order, la sortie de Google Sheets remplace la charge utile du webhook d’origine, donc au moment où le flux de travail atteint la branche de service correcte, les coordonnées de localisation d’origine ne sont plus disponibles.
    Je recherche la meilleure architecture évolutive pour acheminer un message de localisation unique vers plusieurs services tout en conservant la charge utile d’origine. Utiliseriez-vous des nœuds Merge, des nœuds Code, Execute Workflow, des magasins de données, ou un autre modèle de conception?
    Tous les conseils des développeurs n8n expérimentés seraient très appréciés. Merci!

Décrivez le problème/l’erreur/la question

Quel est le message d’erreur (le cas échéant)?

Veuillez partager votre flux de travail

(Sélectionnez les nœuds sur votre toile et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le flux de travail.)

Partagez la sortie renvoyée par le dernier nœud

Informations sur votre configuration n8n

  • Version n8n:
  • Base de données (par défaut: SQLite):
  • Paramètre EXECUTIONS_PROCESS de n8n (par défaut: own, main):
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau):
  • Système d’exploitation:
2

Salut @Thabang_Makalela

Puisque vous gérez trois services distincts (Ride, Food, Collection), mettre toute cette logique dans un seul workflow finira par créer un canvas « en spaghetti ». L’architecture la plus évolutive est un modèle Router → Service.

L’Architecture :

  • Workflow Principal Router :

    1. Reçoit le Webhook WhatsApp.
    2. Valide la localisation.
    3. Utilise un Switch Node pour déterminer le service (Ride vs. Food vs. Collection).
    4. Utilise le Execute Workflow Node pour appeler un sous-workflow spécifique (p. ex., Service_Ride_Booking).
    5. Crucial : Passez la charge utile json complète en tant qu’entrée du sous-workflow.

  • Sous-workflows de Service :

    • Chaque sous-workflow démarre avec un Execute Workflow Trigger​.
    • Il reçoit la localisation, effectue la recherche Google Sheets et gère la logique métier.
    • Puisque la localisation est transmise en tant qu’entrée initiale, elle est toujours disponible au début du sous-processus.
3 « J'aime »
3

Bon point sur la séparation Router → Service pour maintenir les choses maintenables à long terme. Une chose qui vaut la peine d’ajouter pour ceux qui veulent d’abord une configuration plus simple : même dans un flux de travail unique et plat (sans séparation Execute Workflow), vous n’avez pas vraiment besoin de nœuds Merge ou Code pour faire avancer la localisation.

n8n garde la sortie de chaque nœud accessible pour toute l’exécution, pas seulement ce que l’« élément actuel » ressemble à un moment donné. Ainsi, en aval — y compris à l’intérieur de chaque branche Switch — vous pouvez référencer directement le nœud de déclenchement original au lieu de l’élément actuel :

{{ $('WhatsApp Trigger').item.json.location.latitude }}
{{ $('WhatsApp Trigger').item.json.location.longitude }}

(remplacez le nom par le nom réel de votre nœud de déclenchement). Cela se résout toujours correctement après que Find Active Ride / Find Active Order aient écrasé l’élément actuel, tant que vous maintenez un appairage normal un-à-un des éléments (évitez les nœuds Code qui construisent de nouveaux éléments sans pairedItem, évitez les nœuds Merge qui casser la traçabilité).

Donc : flux de travail unique + références $('WhatsApp Trigger') résout le problème de « la charge utile se fait écraser » sans aucun routage supplémentaire. La séparation Router → Service ci-dessus reste le meilleur choix une fois que les branches deviennent assez complexes pour vouloir des sous-flux de travail isolés et indépendamment testables.

3 « J'aime »
4

Une bonne approche consiste à préserver les données webhook originales avant d’envoyer le flux de travail dans des nœuds spécifiques au service. Dans n8n, utiliser un nœud Set pour stocker les champs de localisation, ou un nœud Merge pour combiner la charge utile originale avec les résultats de Google Sheets par la suite, peut aider à maintenir les valeurs de latitude et de longitude. Structurer chaque branche de service avec une gestion claire des données facilitera également la mise à l’échelle et le débogage du flux de travail. Pour les équipes planifiant des services liés à l’alimentation, j’ai également trouvé une ressource utile sur les options du menu :spaghetti: d’Olive Garden qui pourrait fournir quelques idées.

5

Petite mais importante modification de l’approche $(‘WhatsApp Trigger’) : utiliser .first() plutôt que .item ici.

.item se résout par l’appairage d’éléments, et au moment où votre recherche Sheets retourne un nombre d’éléments différent de celui du déclencheur, cet appairage se casse — vous obtenez soit les coordonnées de la mauvaise ligne, soit une erreur « impossible de déterminer quel élément utiliser », et cela s’affiche généralement plus tard quand vous ajoutez une branche, pas maintenant. Un webhook WhatsApp envoie un message par exécution, donc $(‘WhatsApp Trigger’).first().json.location.latitude est sans ambiguïté et reste correct peu importe ce que les branches font.