تدفق الخدمة

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

مرحبا، أحتاج إلى مساعدة تقنية في مراجعة سير عمل في n8n.

أنا أقوم ببناء سير عمل تسجيل/تحديث عملاء WhatsApp باستخدام n8n + Google Sheets + Z-API.

يبدأ سير العمل في WF001 ثم يستمر في WF002.

القرار التصميمي المهم هو أنني لا أريد استخدام عمود “ETAPA” في Google Sheets.

بدلاً من ذلك، يجب أن يحدد WF002 مكان وجود العميل في المحادثة من خلال تحليل البيانات الموجودة في صف Google Sheets.

المحادثة لديها هذه الخطوات:

  1. يقبل العميل التسجيل/التحديث
  2. يقدم العميل مقاس حذائه
  3. يجيب العميل على M04، وهي فئة المنتج المفضلة
  4. يجيب العميل على M05، وهو سؤال آخر في سير العمل
  5. يعالج سير العمل الرد النهائي ويرسل الرسائل المتبقية

في WF002، يوجد عقدة Switch/Rules تسمى:

“Identificar momento da conversa”

تحتوي حالياً على قواعد تحاول تحديد:

NUMERACAO
M04
M05
INTERESSE
RESPOSTA_M05

تستخدم القواعد الحقول الموجودة في Google Sheets، مثل:

  • Numeração
  • Categoria Preferida
  • Última resposta
  • بيانات العميل الموجودة الأخرى

حاولنا سابقاً عدة تعديلات على سير العمل هذا، لكن الاختبارات لم تعمل بشكل موثوق.

قبل إجراء أي تغييرات أخرى، أريد أن أفهم العمارة الصحيحة في n8n.

أسئلتي هي:

  1. هل من الصحيح استخدام عقدة Rules/Switch لتحديد خطوة المحادثة الحالية بناءً على حقول Google Sheets الموجودة، دون إنشاء عمود ETAPA؟

  2. هل يمكن لسير العمل أن يحدد بشكل موثوق ما إذا كانت رسالة WhatsApp الواردة هي إجابة العميل على السؤال 1، السؤال 2، السؤال 3، وما إلى ذلك، باستخدام بيانات Google Sheets الموجودة فقط؟

  3. هل هناك أي مشاكل في استخدام تعبيرات تشير إلى عقدة أخرى، مثل:
    $(‘Preparar Resposta Recebida’).item.json
    داخل شروط Switch/Rules؟

  4. لدينا حالياً عدة عقد Wait:

    • 10 ثوان
    • 60 ثانية بعد M04
    • 60 ثانية بعد M05
    • 5 ثوان بين M06 و M07
    • 5 ثوان بين M07 و M08

بعض عقد Wait هذه مخصصة فقط لإنشاء تأخير بين الرسائل، بينما عقد Wait لمدة 60 ثانية مخصصة لمنح العميل وقتاً لإرسال رد آخر قبل أن يبحث سير العمل عنه.

هل يمكن لعقد Wait هذه أن تسبب مشاكل مع تنفيذات webhook، أو التنفيذات المتزامنة، أو فقدان سير العمل لسياق العميل/خلطه؟

  1. ما هي عمارة n8n الموصى بها لهذا النوع من محادثات WhatsApp، حيث يمكن لكل عميل أن يرد في أوقات مختلفة وتبدأ كل رسالة WhatsApp جديدة تنفيذ webhook جديد؟

  2. هل هناك طريقة أفضل لتحديد حالة المحادثة دون استخدام عمود ETAPA؟

يمكنني تقديم لقطات شاشة لسير العمل وتكوين Rules وWait nodes وعقد Google Sheets وعقد Z-API HTTP Request.

أود أن أفهم العمارة الصحيحة قبل تغيير سير العمل مرة أخرى، لأننا قد أجرينا بالفعل عدة تغييرات دون الحصول على نتائج موثوقة.

2

يمكن لمفتاح التبديل على حقول الورقة الموجودة أن يعمل، لكن فقط إذا كانت تلك الحقول عبارة عن آلة حالة حقيقية: فارغة مقابل مملوءة، بترتيب ثابت. إذا كان حجم الحذاء وM04 وM05 قد تكون فارغة لأسباب مختلفة، فسيخمن المفتاح الخطوة الخاطئة.

الفاصل الأكبر هو عقد الانتظار بالإضافة إلى تنفيذ webhook جديد على كل رسالة WhatsApp. انتظار 60 ثانية ليس في انتظار العميل. إنه يحافظ على تنفيذ واحد مفتوح بينما تبدأ رسالة واردة التالية بتنفيذ ثانٍ ضد نفس صف الورقة. هذا هو كيف يختلط سياق العميل.

سأتعامل مع كل webhook واردة كتشغيل جديد: ابحث عن الصف حسب الهاتف، حدد الخطوة التي لا تزال الحقول المطلوبة فيها فارغة (أول فارغة بترتيب ثابت: مقبول، Numeração، Categoria Preferida، M05)، اكتب الإجابة الجديدة، أرسل السؤال التالي، أنهِ التنفيذ. لا انتظر الرد. استخدم الانتظار فقط كتأخير قصير بين رسالتين صادرتين في نفس التشغيل.

$(‘Preparar Resposta Recebida’).item.json داخل المفتاح سهل الكسر عندما يكون أكثر من تنفيذ واحد قيد الرحلة. فضّل $(‘Preparar Resposta Recebida’).first().json أو، بشكل أكثر أماناً، اكتب النص الوارد على العنصر قبل المفتاح حتى يقرأ المفتاح $json.

ما سيحسمه: صف ورقة واحد لهاتف اختبار واحد، ثلاث رسائل واردة مرسلة بفاصل دقيقة واحدة، ولقطة شاشة للصف بعد كل رسالة. إذا امتلأت الحقول بالترتيب ولم يتم لمس عميل ثانٍ، فالعمارة صحيحة. إذا كتب تشغيلان نفس الصف في نفس الوقت، فإن تداخل الانتظار/webhook هو الفشل.

3

مرحباً @Sueli

حدسك حول العمارة صحيح — استخراج الحالة من حقول جداول Google الموجودة أنظف من عمود ETAPA، لكن مزيج عقدة Switch + عقدة Wait هو حيث ينهار الموثوقية تحت حركة WhatsApp الحقيقية.

أعد تصميم WF002 لاستخراج حالة المحادثة من منطق وجود الحقل (Numeração فارغ = الخطوة 1، مملوء لكن Categoria فارغ = الخطوة 2، إلخ) — حتمي، بدون مراجع بين العقد

استبدل عقد Wait بإعادة دخول مدفوعة بـ webhook بحيث تبدأ كل رسالة WhatsApp من جديد وتقرأ حالة الورقة الحالية

حذف $('NodeName').item.json داخل قواعد Switch — هذا ينكسر عند إعادة التنفيذ

أضف مفتاح idempotency لكل رقم هاتف للتعامل مع الرسائل المتزامنة بأمان

وثيقة العمارة الكاملة + إعادة بناء WF001/WF002 العاملة مع حالات الاختبار