Diseño de flujo en N8n: Enrutamiento de una ubicación de WhatsApp a reserva de viajes, entrega de comida y colección especial

Ayúdame a Construir mi Flujo de Trabajo
1

Hola a todos,
Estoy construyendo un flujo de trabajo de WhatsApp en n8n que maneja múltiples servicios desde el mismo mensaje de ubicación entrante:

  • :taxi: Reserva de viajes (recogida y destino)
  • :hamburger: Entrega de comida
  • :package: Recopilación especial
    Mi desafío es preservar la ubicación original de WhatsApp (“latitude”/“longitude”) mientras consulto Google Sheets en busca de viajes, pedidos o recopilaciones activas. Después de nodos como Find Active Ride o Find Active Order, la salida de Google Sheets reemplaza la carga útil original del webhook, así que cuando el flujo de trabajo llega a la rama de servicio correcta, ya no están disponibles las coordenadas de ubicación originales.
    Busco la mejor arquitectura escalable para enrutar un único mensaje de ubicación a múltiples servicios mientras preservo la carga útil original. ¿Utilizarías nodos Merge, nodos Code, Execute Workflow, almacenes de datos u otro patrón de diseño?
    Cualquier consejo de desarrolladores de n8n experimentados sería muy apreciado. ¡Gracias!

Describe el problema/error/pregunta

¿Cuál es el mensaje de error (si corresponde)?

Por favor, comparte tu flujo de trabajo

(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)

Comparte la salida devuelta por el último nodo

Información sobre tu configuración de n8n

  • Versión de n8n:
  • Base de datos (predeterminado: SQLite):
  • Configuración de n8n EXECUTIONS_PROCESS (predeterminado: own, main):
  • Ejecutando n8n mediante (Docker, npm, n8n cloud, aplicación de escritorio):
  • Sistema operativo:
2

Hola @Thabang_Makalela

Ya que estás manejando tres servicios distintos (Ride, Food, Collection), poner toda esta lógica en un flujo de trabajo único eventualmente llevará a un canvas de “espagueti”. La arquitectura más escalable es un patrón Router → Service.

La Arquitectura:

  • Flujo de Trabajo Principal del Router:

    1. Recibe el Webhook de WhatsApp.
    2. Valida la ubicación.
    3. Usa un Switch Node para determinar el servicio (Ride vs. Food vs. Collection).
    4. Usa el Execute Workflow Node para llamar a un sub-flujo específico (p. ej., Service_Ride_Booking).
    5. Crucial: Pasa la carga útil completa de json como entrada al sub-flujo.

  • Sub-flujos de Servicio:

    • Cada sub-flujo comienza con un Execute Workflow Trigger.
    • Recibe la ubicación, realiza la búsqueda en Google Sheets y maneja la lógica empresarial.
    • Ya que la ubicación se pasa como entrada inicial, siempre está disponible al inicio del sub-proceso.
3 Me gusta
3

Buen punto sobre la división Router → Service para mantener las cosas mantenibles a largo plazo. Una cosa que vale la pena agregar para anyone que quiera una configuración más simple primero: incluso en un flujo de trabajo plano único (sin división de Execute Workflow), en realidad no necesitas nodos Merge o Code para llevar la ubicación hacia adelante.

n8n mantiene la salida de cada nodo accesible para toda la ejecución, no solo lo que se vea en el “elemento actual” en un punto dado. Entonces downstream - incluso dentro de cada rama Switch - puedes referenciar el nodo trigger original directamente en lugar del elemento actual:

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

(cambia el nombre por el de tu nodo trigger actual). Eso sigue resolviéndose correctamente después de que Find Active Ride / Find Active Order sobrescriban el elemento actual, siempre y cuando mantengas el emparejamiento de elementos uno a uno normal en el camino (evita nodos Code que construyan elementos completamente nuevos sin pairedItem, evita nodos Merge que rompan la lineage).

Entonces: flujo de trabajo único + referencias a $('WhatsApp Trigger') resuelve el problema “la carga útil se sobrescribe” sin ningún enrutamiento extra. La división Router → Service anterior sigue siendo la mejor opción una vez que las ramas se vuelven lo suficientemente complejas como para querer sub-flujos de trabajo aislados e independientemente comprobables.

3 Me gusta
4

Un buen enfoque es preservar los datos originales del webhook antes de enviar el flujo a nodos específicos del servicio. En n8n, usar un nodo Set para almacenar los campos de ubicación, o un nodo Merge para combinar la carga útil original con los resultados de Google Sheets más adelante, puede ayudar a mantener los valores de latitud y longitud. Estructurar cada rama de servicio con un manejo claro de datos también facilitará el escalado y la depuración del flujo. Para equipos que planean servicios relacionados con alimentos, también encontré un recurso útil sobre las opciones del menú de Olive Garden :spaghetti: que puede proporcionar inspiración.

5

Un ajuste pequeño pero importante en el enfoque de $(‘WhatsApp Trigger’): utiliza .first() en lugar de .item aquí.

.item se resuelve a través del emparejamiento de elementos, y en el momento en que tu búsqueda en Sheets devuelve un número diferente de elementos del que devolvió el disparador, ese emparejamiento se rompe — obtienes las coordenadas de la fila incorrecta o un error de „no se puede determinar qué elemento usar", y generalmente aparece más tarde cuando añades una rama, no ahora. Un webhook de WhatsApp es un mensaje por ejecución, así que $(‘WhatsApp Trigger’).first().json.location.latitude es inequívoco y se mantiene correcto sin importar lo que hagan las ramas.