نمط لبناء سير عمل قابل لإعادة الاستخدام في n8n

مرحبا بالجميع،
مع نمو مشروع n8n الخاص بي، لاحظت أن العديد من سير العمل يشاركون نفس المنطق، مثل المصادقة ومعالجة الأخطاء والتحقق من صحة البيانات وإرسال الإخطارات.
في الوقت الحالي، أجد نفسي أنسخ نفس العُقد إلى سير عمل متعددة، مما يجعل الصيانة أصعب. إذا احتجت إلى تحديث جزء من المنطق، فيجب تحريره في عدة أماكن.
على سبيل المثال:Webhook

تحقق من البيانات

مصادقة

منطق العمل

إرسال إشعار
أفكر في نقل المنطق المشترك إلى سير عمل فرعية باستخدام Execute Workflow، لكنني غير متأكد مما إذا كان هذا هو أفضل نهج طويل الأجل.
بالنسبة لأولئك الذين يديرون مشاريع n8n كبيرة:
كيف تنظمون مكونات سير العمل القابلة لإعادة الاستخدام؟
هل تستخدمون سير عمل فرعية للمنطق المشترك، أم تفضلون نمطًا آخر؟
كيف تتعاملون مع الإصدارات عندما يعتمد سير عمل متعددة على نفس سير العمل الفرعي

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

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

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

شارك الإخراج الذي أرجعته العُقدة الأخيرة

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

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

حسناً، هذا هو أفضل نهج، @Decoure_Ryan
بدلاً من تحرير N من سير العمل، تقوم به مرة واحدة فقط.

مرحباً @Decoure_Ryan استخدم Execute Workflow للمنطق المشترك عبر عمليات سير عمل متعددة، مثل:

المصادقة
تحقق صحة البيانات
الإخطارات
معالجة الأخطاء

سير العمل الرئيسي

تنفيذ سير العمل (المنطق المشترك)

متابعة المعالجة

أفضل الممارسات
حافظ على سير العمل الفرعي مركزاً على مسؤولية واحدة
مرر المدخلات والمخرجات بوضوح بين سير العمل
قم بإصدار سير العمل المشترك قبل إجراء تغييرات كسر التوافق
وثّق سير العمل المشترك لسهولة إعادة الاستخدام

حاول تجنب
تكرار نفس العقد عبر العديد من سير العمل
إنشاء سير عمل فرعي متداخل بعمق، مما قد يجعل تصحيح الأخطاء أكثر صعوبة

شكراً لك كثيراً @Niffzy @kjooleng هذا يوضح متى يتم استخدام Execute Workflow بشكل أفضل بكثير