مرحباً!
أنا حالياً أستخدم Node-RED للأتمتة وأفكر في الهجرة إلى n8n. لدي عُقَد مخصصة مبنية، على سبيل المثال باستخدام واجهة برمجة تطبيقات node red - بعضها مكتوب بصيغة .js/.html وبعضها عبارة عن تدفقات فرعية. يتم تجميعها جميعاً في حزمة npm. أعلم أنه يمكننا إنشاء عُقَد مخصصة في n8n باستخدام TypeScript، لذا لا أعتقد أن هناك مشكلة بالنسبة للعُقَد التي بصيغة JS/HTML، لكن ماذا عن العُقَد التي تكون عبارة عن تدفقات فرعية؟ هل هناك طريقة محددة للهجرة بها إلى سير عمل فرعي في n8n؟ بعضها معقد، وبعضها مجرد طلبات HTTP وما إلى ذلك. أتساءل عما إذا كانت هناك خيار مشابه للخيار في Node-RED للحصول على جميعها في حزمة npm، أم يجب أن أحصل على حزمة npm للعُقَد المترجمة إلى TS ثم سحب العُقَد التي تكون عبارة عن تدفقات فرعية إلى مثيلات n8n عبر التحكم بالإصدار؟ خطة N8n → Enterprise إذا قررنا الهجرة.
وموضوع آخر، هل تعتقد أن هناك طريقة للهجرة السريعة للعُقَد/سير العمل من node-red إلى n8n دون القيام بذلك يدوياً؟
أقدّر مساعدتك حقاً! شكراً!
مرحباً @oesterreicher-0417 ، أهلاً بك في مجتمع n8n!
لقد قمت بعدة عمليات ترحيل من Node‑RED إلى n8n وأفضل تعيين يعمل بشكل عملي هو:
– عقد JS/HTML مخصصة → عقد n8n مخصصة (TypeScript، موزعة كحزمة npm)
– سير العمل الفرعي → سير العمل الفرعي في n8n، يُدار كسير عمل عادي ومُصدّر عبر Git/التحكم بالإصدارات بدلاً من npm.
بالنسبة لسير العمل الفرعي: في n8n سأنشئ سير عمل واحد لكل “كتلة بناء”، وأبدأه بمشغل Execute Sub‑workflow، وأستدعيه من سير العمل الآخر باستخدام Execute Sub‑workflow. هذا يعطيك تقريباً نفس إعادة الاستخدام التي تملكها في Node‑RED، لكن مع عقود إدخال/إخراج أوضح.
لا يوجد محول مؤتمت من Node‑RED إلى n8n بقدر علمي، لذا أسرع نهج رأيته هو:
-
نقل منطق API منخفض المستوى إلى حزمة عقدة مخصصة واحدة،
-
إعادة بناء سير العمل الفرعي عالي القيمة كسير عمل فرعي،
-
ثم إعادة تطبيق سير العمل الفردي فوق هذه الكتل الإنشائية الجديدة.
إذا كنت مستعداً لمشاركة مثال صغير عن سير عمل فرعي/عقدة مخصصة، يسعدني أن أوضح ما سيبدو عليه المعادل الدقيق في n8n قبل أن تلتزم بعملية الترحيل كاملة.
شكرًا جزيلًا! @nguyenthieutoan عندما يتعلق الأمر بالمسارات الفرعية (sub-workflows)، كنت أيضًا أفكر في استخدام محفزات webhook لبعضها وتنفيذها من خلال محفزات مسارات عمل أخرى لبعضها الآخر، حسب الوظيفة. على سبيل المثال، كتلة بناء تسجيل الدخول ستستخدم webhook، بينما استعلام SQL سيستخدم محفز “يتم التنفيذ بواسطة مسار عمل آخر”. السؤال الحقيقي هو الإصدار (حزم npm سهلة بالطبع - أنا أتحدث عن BBs التي تكون مسارات فرعية) وآليات التوزيع عبر عدة مثيلات n8n. أما بخصوص العقد المخصصة، أفترض أننا سنستخدم مستودع خاص على GitHub (وحزمة rpm) تحتوي على جميع العقد المخصصة في حزمة واحدة وأعتقد أن خط أنابيب CI/CD سيقوم بدمجها في صور Docker الخاصة بـ n8n ودفع هذه الصور إلى AWS ECR على سبيل المثال، ثم سنستخدم ArgoCD لتوزيعها عبر الـ pods.
هل لديك أي اقتراحات حول كيف ستبدو هذه عندما يتعلق الأمر بعقد node-red هذه كمسارات فرعية؟
شكراً! أصبح الأمر أكثر وضوحاً بالنسبة لي الآن، وسأأخذ هذه النقاط بعين الاعتبار بالتأكيد
مرحباً بك في مجتمع n8n @oesterreicher-0417
هذه الوثيقة ستساعدك Sub-workflow conversion | n8n Docs
سيتعين عليك تعديل أنواع الإدخال/الإخراج يدويًا في عقد Start و Return؛ هناك دعم محدود للذكاء الاصطناعي والدوال مثل first() و last() و all() قد تحتاج إلى مراجعة بعد التحويل.
وأفترض أنه من الممكن ربط حسابك على n8n أو نسختك به؟ إلى مستودع GitHub يحتوي على سير عمل فرعي وسيتم سحبها إلى n8n؟ هذا متاح فقط على خطة Enterprise وحساب من نوع المسؤول، أليس كذلك؟ @nguyenthieutoan @tamy.santos
هل هناك طريقة لعدم استخدام ArgoCD على سبيل المثال؟ ألا يمكن تجميع سير العمل الفرعي كعُقد مثل في NodeRed؟ ما هي أفضل طريقة لتوزيعها عبر النسخ (سير العمل الفرعي الذي يتم تنفيذه بواسطة سير عمل آخر لتشغيل)؟
شكراً مقدماً!
ميخائيل، في الغالب نعم، لكن ليس بالضبط “للمؤسسات فقط”: التحكم بالإصدار في n8n هو ميزة Business/Enterprise والاتصال يتم تكوينه من قبل المالك/المسؤول. اعتبره مزامنة سير العمل/البيئة، وليس كمدير حزم لسير العمل الفرعي.
للتوزيع، قسّم الأجزاء: العُقد المخصصة للكود الذي تريد إصداره وتثبيته عبر الحالات؛ سير العمل الفرعي لتنسيق العمليات التي قد تقوم الفرق بتحريره في n8n. التفصيل الرئيسي هو شكل الحالة: هل هذه حالة n8n واحدة مشتركة مع المشاريع، أم حالات منفصلة للعملاء/الفرق تحتاج جميعها إلى الحفاظ على نفس إصدارات الكتل المتزامنة؟
لم نتخذ هذا القرار بعد. على الأغلب، سيكون لكل مطور نسختته الخاصة به التي يطور عليها التدفقات.
إذا كان لكل مطور مثيل منفصل، فإن الخطر يكمن في انجراف الإصدارات. لا تتعامل مع سير العمل الفرعي على أنه مكتبة مشتركة؛ فستصبح نسخًا محلية بمجرد أن يبدأ الناس في تحريرها.
احتفظ بالأكواد القابلة لإعادة الاستخدام في العقد المخصصة، واجعل ترقية سير العمل/سير العمل الفرعي صريحة: مثيل التطوير -› التصدير المراجع/تغيير التحكم بالمصدر -› المشاركة في الإنتاج/الإنتاج. هل تهبط تدفقات المعتمدة في النهاية في مثيل مركزي واحد، أم أن كل مطور يحتفظ بنسختهم الخاصة؟
@oesterreicher-0417 للإجابة على سؤالك بشكل مباشر: نعم، يمكن لـ n8n الاتصال بمستودع GitHub، لكن هذه ميزة التحكم بالإصدار (Business/Enterprise) وهي مصممة لمزامنة سير العمل بين البيئات (dev → staging → prod)، وليست كمدير حزم.
لتوزيع سير العمل الفرعي عبر الحالات بدون ArgoCD، الطريقة الأخف التي استخدمتها هي تصدير JSON سير العمل الفرعي عبر واجهة برمجة تطبيقات n8n (GET /api/v1/workflows/{id}) واستيراده في كل حالة مستهدفة باستخدام سكريبت صغير أو سير عمل n8n مخصص يستدعي POST /api/v1/workflows على كل حالة. ما تزال تقوم بإصدار JSON في Git، لكن “النشر” هو فقط استدعاء واجهة برمجية بدلاً من خط أنابيب GitOps.
القيد الرئيسي الذي أشار إليه @olmrqs_ops بالفعل صحيح: بمجرد أن يقوم الأشخاص بتعديل سير عمل فرعي محليًا، فإنه ينحرف. سأقفل سير العمل الفرعي المشترك بحيث يكون للوصول للقراءة فقط على حالات dev إن أمكن، أو على الأقل فرض اتفاقية تسمية مثل [SHARED] - WorkflowName حتى يعرف الفريق عدم تعديله في المكان.