تصميم سير العمل في N8n: توجيه موقع واحد من WhatsApp إلى حجز الركوب والتوصيل الغذائي والتجميع الخاص

[Thabang_Makalela]

مرحبا بالجميع،
أنا أقوم ببناء سير عمل WhatsApp في n8n يتعامل مع خدمات متعددة من نفس موقع الرسالة الواردة:

• حجز الركوب (نقطة الالتقاط والإفلات)
• توصيل الطعام
• التجميع الخاص
  التحدي الذي أواجهه هو الحفاظ على موقع WhatsApp الأصلي (“latitude”/“longitude”) أثناء الاستعلام عن جداول Google للرحلات أو الطلبات أو التجميعات النشطة. بعد عقد مثل Find Active Ride أو Find Active Order، يحل مخرج Google Sheets محل حمولة webhook الأصلية، لذلك عندما يصل سير العمل إلى فرع الخدمة الصحيح، لا تكون إحداثيات الموقع الأصلية متاحة.
  أبحث عن أفضل بنية معمارية قابلة للتوسع لتوجيه رسالة موقع واحدة إلى خدمات متعددة مع الحفاظ على الحمولة الأصلية. هل ستستخدم عقد Merge أو Code nodes أو Execute Workflow أو مخازن البيانات أو نمط تصميم آخر؟
  سأكون ممتنا لأي نصائح من مطوري n8n ذوي الخبرة. شكرا!

وصف المشكلة/الخطأ/السؤال

ما هي رسالة الخطأ (إن وجدت)؟

يرجى مشاركة سير العمل الخاص بك

(حدد العقد على لوحتك واستخدم اختصارات لوحة المفاتيح CMD+C/CTRL+C و CMD+V/CTRL+V لنسخ ولصق سير العمل.)

مشاركة المخرجات التي أرجعتها العقدة الأخيرة

معلومات حول إعداد n8n الخاص بك

• إصدار n8n:
• قاعدة البيانات (الافتراضي: SQLite):
• إعداد n8n EXECUTIONS_PROCESS (الافتراضي: own, main):
• تشغيل n8n عبر (Docker, npm, n8n cloud, desktop app):
• نظام التشغيل:

[kjooleng]

مرحباً @Thabang_Makalela

بما أنك تتعامل مع ثلاث خدمات مختلفة (Ride و Food و Collection)، فإن وضع كل هذه المنطق في سير عمل واحد سيؤدي في النهاية إلى لوحة رسم “فوضوية”. العمارة الأكثر قابلية للتوسع هي نمط Router → Service.

العمارة:

• سير عمل الموجه الرئيسي:

  1. يستقبل webhook من WhatsApp.
  2. يتحقق من الموقع.
  3. يستخدم Switch Node لتحديد الخدمة (Ride مقابل Food مقابل Collection).
  4. يستخدم Execute Workflow Node لاستدعاء سير عمل فرعي محدد (مثل Service_Ride_Booking).
  5. حاسم: مرر حمولة json الكاملة كمدخل لسير العمل الفرعي.

• سير عمل الخدمات الفرعية:

  • يبدأ كل سير عمل فرعي مع Execute Workflow Trigger.
  • يستقبل الموقع، ويقوم بالبحث في Google Sheets، ويتعامل مع منطق الأعمال.
  • بما أن الموقع يتم تمريره كمدخل أولي، فإنه يكون متاحاً دائماً في بداية العملية الفرعية.

[nathan3]

نقطة جيدة حول فصل Router → Service للحفاظ على قابلية الصيانة على المدى الطويل. شيء واحد يستحق الإضافة لأي شخص يريد إعدادًا أبسط في البداية: حتى في سير عمل واحد مسطح (بدون فصل Execute Workflow)، لا تحتاج فعلاً إلى عقد Merge أو Code لنقل الموقع للأمام.

n8n يحافظ على مخرجات كل عقدة متاحة للتنفيذ بأكمله، وليس فقط ما يبدو عليه “العنصر الحالي” عند نقطة معينة. لذا في المصب - بما في ذلك داخل كل فرع Switch - يمكنك الإشارة مباشرة إلى عقدة الحافز الأصلية بدلاً من العنصر الحالي:

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

(استبدل الاسم باسم عقدة الحافز الفعلية لديك). يتم حل هذا بشكل صحيح حتى بعد أن يقوم Find Active Ride / Find Active Order بالكتابة فوق العنصر الحالي، طالما تحافظ على إقران عنصر عادي واحد لواحد على طول الطريق (تجنب عقد Code التي تبني عناصر جديدة تماماً بدون pairedItem، تجنب عقد Merge التي قد تكسر النسب).

إذن: سير عمل واحد + مراجع $('WhatsApp Trigger') يحل مشكلة “الحمولة تتم الكتابة فوقها” بدون أي توجيه إضافي. فصل Router → Service أعلاه لا يزال الخيار الأفضل بمجرد أن تصبح الفروع معقدة بما يكفي لتريد سير عمل فرعي معزول وقابل للاختبار بشكل مستقل.

[Thelma_Robinson]

يُعتبر النهج الجيد هو الحفاظ على بيانات webhook الأصلية قبل إرسال سير العمل إلى عقد خاصة بالخدمة. في n8n، يمكن استخدام عقدة Set لتخزين حقول الموقع، أو عقدة Merge لدمج الحمل الأصلي مع نتائج Google Sheets لاحقًا، مما يساعد في الحفاظ على قيم خطوط العرض والطول. سيساعد تنظيم كل فرع خدمة بمعالجة بيانات واضحة أيضًا على جعل سير العمل أسهل للتوسع والتصحيح. بالنسبة للفرق التي تخطط لخدمات متعلقة بالطعام، وجدت أيضًا مصدرًا مفيدًا حول قائمة Olive Garden التي قد توفر بعض الإلهام.

[colemaffeo6]

تعديل صغير لكن مهم في طريقة ('WhatsApp Trigger')$: استخدم .first() بدلاً من .item هنا.

.item يتم حله من خلال إقران العناصر، وفي اللحظة التي تعيد فيها عملية البحث عن Sheets عدداً مختلفاً من العناصر عما أرجعته الحافزة، ينقطع هذا الإقران — تحصل إما على إحداثيات الصف الخاطئة أو خطأ “لا يمكن تحديد العنصر المراد استخدامه”، وعادة ما يظهر لاحقاً عند إضافة فرع، وليس الآن. إن webhook الخاص بـ WhatsApp هو رسالة واحدة لكل تنفيذ، لذا فإن $('WhatsApp Trigger').first().json.location.latitude لا لبس فيه ويبقى صحيحاً بغض النظر عما تفعله الفروع.