كيف يمكنني أتمتة إدارة طلبات توصيل الطعام باستخدام n8n؟

ساعدني في بناء سير عملي
1

أستكشف تطوير تطبيقات توصيل الطعام وأبحث عن طرق لأتمتة إدارة الطلبات باستخدام n8n.
بالنسبة لتطبيق يربط بين العملاء والمطاعم وشركاء التوصيل، كيف يمكنني إنشاء سير عمل n8n يقوم تلقائياً بـ:
استقبال الطلبات الجديدة من خلال webhooks.
إرسال تأكيدات الطلب إلى المطاعم.
إخطار شركاء التوصيل المتاحين.
تحديث العملاء حول حالة طلبهم.
التعامل مع المدفوعات الفاشلة أو الطلبات الملغاة.
هل استخدام عُقد Webhook و HTTP Request و Switch سيكون مناسباً لإدارة هذه العمليات؟ وكيف يمكنني منع التنبيهات المكررة عندما تصل طلبات متعددة في نفس الوقت؟
أقدّر الاقتراحات من أي شخص عمل على سير عمل أتمتة مماثل.

2

مرحباً @robertwilliam، بينما تنتظر الحصول على رد، إليك بعض الأشياء التي قد تساعدك:

الموارد المقترحة

تم مطابقتها تلقائياً مع سؤالك.

المستندات:

المنتدى:

@Keira_Becky، @Emmas - لقد ساعدتما في مشاكل مماثلة من قبل، هل يمكنكما إلقاء نظرة؟

مقترح تلقائياً بواسطة روبوت مجتمع n8n. إنه مشروع تجريبي - يرجى مشاركة ملاحظاتك هنا.

3

مرحبا @robertwilliam،

أنت بالفعل على المسار الصحيح مع عقد Webhook و HTTP Request و Switch للمنطق الأساسي. لكن عند التعامل مع أوامر متزامنة بحجم كبير، يمكن لمشغل webhook البسيط أن يسبب حالات تسابق وإشعارات مكررة إذا أطلقت جدران الويب في نفس الميلي ثانية بالضبط.

لمنع التكرارات، تحتاج إلى طبقة idempotency أو قائمة انتظار رسائل قبل خطوة الإشعار. يجب أن يتحقق سير العمل أولاً من قاعدة بيانات مركزية للحصول على حالة معرف الطلب الموجودة قبل إطلاق طلب HTTP لشركاء التسليم الخاصة بك.

للسياق، أنا منتسب إلى Pond AI. تقوم Pond AI ببناء والحفاظ على بنى webhook متعددة المستأجرين مخصصة وقوائم انتظار الرسائل للمنصات عالية الحجم بحيث لا تضطر إلى القلق بشأن حالات التسابق أو التسليمات المكررة.

يمكننا مناقشة هذا الإعداد هنا وستحصل على خريطة بنية مجانية تم تعيينها خصيصاً لسير عمل توصيل الطعام الخاص بك والمخطط الأزرق هذا ملك لك تماماً. إذا قررت في النهاية أن تقوم فريق Pond AI بتنفيذ أي من البناء الخلفي الثقيل، فإن كل مشروع مخصص يأتي مع استرجاع لمدة 7 أيام.

هل تقوم حالياً ببناء تطبيق العميل الأمامي بشكل أصلي أم باستخدام غلاف ويب؟

4

Webhook و HTTP Request و Switch مناسبة جداً لهذا الغرض. بعض الأشياء المحددة لجزء إزالة التكرار والتزامن:

  1. اجعل قاعدة البيانات تقوم بإزالة التكرار، وليس سير العمل. مباشرة بعد عقدة Webhook، أدرج معرّف الطلب في جدول Postgres يحتوي على قيد فريد عليه، باستخدام INSERT … ON CONFLICT DO NOTHING RETURNING id. إذا لم يتم إرجاع أي شيء، فهو تكرار، لذا توقف هناك. لا يمكن لاثنين من webhooks الوصول في نفس الميلي ثانية أن يكسبا كلاهما هذا الإدراج.

  2. احتفظ بعمود حالة الطلب (جديد، مؤكد، معين، تم التسليم، ملغى، فشل الدفع) وقم بالتوجيه عليه باستخدام عقدة Switch. حدّث الحالة في نفس الاستعلام الذي يتحقق منه (UPDATE … WHERE status = ‘new’)، بحيث يؤدي كل انتقال إلى إطلاق إشعاراته مرة واحدة فقط حتى إذا تمت إعادة محاولة الحدث.

  3. بالنسبة إلى “إشعار شركاء التسليم المتاحين”، استحوذ على الطلب بنفس الطريقة: يقوم الشريك الأول الذي يقبل بتشغيل UPDATE … WHERE assigned_partner IS NULL، والآخرون يحصلون على رد “تم أخذه بالفعل”.

  4. عادة ما تصل حالات الدفع الفاشلة والإلغاءات كأحداث webhook منفصلة من مزود الدفع، لذا أعط كلاً منها مساره الخاص من Webhook أو فرع Switch يعيّن الحالة ويشعر المطعم والعميل.

أيضاً عيّن عقدة Webhook للرد فوراً، بحيث لا ينتهي وقت المرسل وتحاول مرة أخرى بينما سير العمل لا يزال قيد التشغيل.

5

مرحبا، Webhook و HTTP Request و Switch هي أساس جيد، والنهج القائم على قاعدة البيانات أعلاه يتعامل مع التكرارات بشكل جيد. إليك ما أود إضافته لكي يبقى الباقي متماسكا أيضا. سأقسمه إلى أربع سير عمل صغيرة بدلا من واحدة كبيرة.

الاستقبال. Webhook مضبوط للرد فورا، إزالة التكرار بناء على معرّف الطلب، حفظ الطلب. هذا كل ما يفعله.

الإرسال. يحصل المطعم على روابط قبول/رفض تستدعي webhook. يفحص Schedule Trigger كل دقيقة بحثا عن طلبات لم تتلق إجابة بعد المهلة الزمنية المحددة، ثم يذكّر أو يعيد التعيين. أخطر السائقين من خلال جدول الإشعارات بمفتاح فريد لمعرّف الطلب، معرّف السائق، ونوع الرسالة، لذلك لا يمكن لأي محاولة إعادة أن تخطر أي شخص مرتين.

التحديثات. سير عمل منفصل يتم تشغيله عند تغيير الحالة ويرسل رسالة للعميل. لا يمنع استدعاء WhatsApp أو SMS البطيء أبدا طلبا ما. على WhatsApp، تحتاج الرسائل خارج نافذة 24 ساعة إلى قوالب موافق عليها.

شبكة الأمان. Retry On Fail على كل عقدة رسالة، قناة احتياطية، سير عمل Error Trigger ينبهك، وعملية ليلية تقارن طلباتك مع سجلات مزود الدفع، لأن webhooks قد تُفتقد.

بالنسبة للإلغاءات والمدفوعات الفاشلة، حدّد تغييرات الحالة المسموحة (يجب أن يؤدي الإلغاء بعد الاستلام إلى فتح مراجعة استرجاع، وليس فقط تبديل علم) ورفض الباقي. عند حجم أعلى، قم بتشغيل n8n في وضع قائمة الانتظار مع العمال، واحتفظ بتتبع السائق المباشر في الخادم الخلفي الخاص بك.

food_delivery_four_flows
food_delivery_four_flows2400×1260 214 KB

أنا مع Pond AI. نبدأ كل مشروع برسم الهندسة المعمارية مجانا، بحيث تكون لديك تلك الخطة سواء قمنا ببناء أي شيء أم لا. الهندسة المعمارية المجانية التي ذكرها ستخطط هذه السير الأربعة، والبناءات المخصصة تأتي مع استرجاع لمدة 7 أيام.

6

لإبقاء قوالب المستندات الخاصة بك منفصلة تماماً عن منطق سير العمل n8n، قم بتخزين قوالب HTML و CSS في حاوية تخزين خارجية أو قاعدة بيانات وأدخل حمولة JSON الديناميكية الخاصة بك باستخدام عقدة التعبير. يمكنك بعد ذلك تمرير سلسلة HTML المعروضة بالكامل عبر عقدة HTTP Request إلى حاوية Gotenberg ذاتية الاستضافة أو خدمة متصفح بدون رأس لتجميع مخرجات PDF نظيفة. أخبرني بتنسيق القالب المفضل لديك وسأتمكن من تحديد إعدادات عقدة HTTP Request الدقيقة هنا.

7

مرحباً @robertwilliam، إزالة التكرارات من قاعدة البيانات وانتقالات الحالة والتقسيم الرباعي للسير العملي أعلاه هي الأساس الصحيح. هناك ثلاثة أشياء لم أرها مذكورة وهي مهمة عندما يتعلق الأمر بأموال حقيقية وعملاء حقيقيين:

  1. لا تثق في نص webhook الدفع وحده. تحقق من توقيع المزود على كل حدث دفع، ثم احصل على حالة الدفع من المزود قبل تغيير الطلب. اجعل المبالغ المستردة والرسوم غير حساسة أيضاً، بإرسال مفتاح مثل معرف الطلب بالإضافة إلى الإجراء، بحيث لا يمكن لإعادة المحاولة أن تسترد المبلغ مرتين. الطلب الملغى والدفع الفاشل هما المكانان اللذان يؤثر فيهما التكرار أكثر.
  2. شارك تفاصيل العميل فقط مع الشريك الذي يقبلها. عند البث إلى السائقين المتاحين، أرسل فقط منطقة الالتقاط وحجم الطلب وتلميح الدفع. حرّر اسم العميل وهاتفه والعنوان الدقيق فقط بعد نجاح المطالبة، وأخفِ رقم الهاتف حيث تستطيع. فهذا يحد من ما قد يتسرب إذا ذهبت إشعارات إلى المكان الخاطئ.
  3. اختبر حالات الفشل عن قصد قبل الإطلاق. أرسل 50 webhook طلب متطابق في وقت واحد وتأكد من وجود طلب واحد وإشعار مطعم واحد. أرسل حدث دفع “مدفوع” بعد حدث “ملغى” وتأكد من أن الحالة لا تعود للخلف. أوقف قاعدة البيانات في منتصف الطلب وأعد تشغيلها، وتحقق من عدم فقدان أي شيء أو إرساله مرتين.

الإفصاح: أنا منتسب إلى Pond AI. نحن نبني وكلاء ذكاء اصطناعي مخصصين وأسراراً عملية، ونبدأ بخطة معمارية مجانية تحتفظ بها بغض النظر عمن يبنيها، مع استرجاع بدون شروط لمدة 7 أيام على البناءات المخصصة.

أي مزود دفع تخطط لاستخدامه، وهل يرسل webhook موقع لكل حدث دفع؟

8

نعم — Webhook + Switch + HTTP Request يعمل بشكل نظيف لتنسيق توصيل الطعام طالما تفصل بين استقبال webhook والإخطارات النهائية بحيث لا تؤدي انفجارات الطلبات المتزامنة أبداً إلى إطلاق مزدوج:

  1. إقرار فوري + قفل Idempotency (إزالة التنبيهات المكررة):
    قم بتكوين عقدة Webhook الخاصة بك لإرجاع 202 Accepted بعد إدراج مفتاح idempotency (platform, external_order_id, event_type) في Postgres أو Redis (INSERT ... ON CONFLICT DO NOTHING RETURNING id). إذا لم يتم إرجاع أي صف، أنهِ الفرع على الفور — تسليمات webhook المكررة أو الأحداث المتزامنة لن تعيد إخطار المطاعم أو رسل التوصيل.
  2. آلة حالة الأحداث عبر سير العمل الفرعية:
    وجّه الأحداث المؤكدة باستخدام عقدة Switch (order.created, restaurant.confirmed, driver.assigned, payment.failed, order.cancelled) إلى سير عمل فرعية معزولة مع معالجة إعادة محاولة أسية/معالجة الأخطاء.
  3. توزيع رسل ذري:
    حافظ على تحولات حالة الطلب ذرية في قاعدة البيانات الخاصة بك (WHERE status = 'ready_for_dispatch') قبل إطلاق إشعارات push/WhatsApp/SMS للرسل.

لقد بنينا مؤخراً جسراً webhook لطلبات المطاعم والمنصات المتعددة باستخدام هذا النمط بالضبط — يسعدنا مشاركة مخطط Postgres الخاص بإزالة التكرار إذا كان ذلك مفيداً.