أتساءل ما إذا كان الحد الأقصى البالغ 50 عقدة في تدفقات العمل (Workflow) سببه تقني و/أو مجرد مسألة شكلية.
أقوم ببناء تدفق عمل باستخدام Meta Ask Agent (المعروف أيضًا باسم Discourse Helper) لمنح نقاط تشجيع تلقائية من مجموعة من الشارات، وألاحظ أن كل تدفق عمل يمكن أن يحتوي على 50 عقدة كحد أقصى.
يُقترح تقسيم تدفق العمل، أو ربما يوجد إعداد مخفي لرفع عدد العقد المتاحة؟
ما النهج المقترح هنا؟ هل يجب أن يعمل كما هو متوقع، أم أن هذا الأمر يتجاوز قدرات الوظيفة، وبالتالي أحتاج إلى بناء إضافة (plugin) لتحقيق هذه الميزة؟
أعتقد أنها مجرد نقطة تقريبية تشير إلى المكان الذي قد تبدأ فيه الأمور في التباطؤ وتصبح صعبة الإدارة في واجهة المستخدم… فإذا اضطررت إلى تصحيح أخطاء 100 عقدة في تدفق عمل واحد، فسيكون الأمر مؤلمًا إلى حد ما.
لدينا عقد “workflow call” و"call workflow" يمكن استخدامها لتقسيم الأمور. يمكنك إعداد تدفق عمل يبدأ بعقدة “workflow call” كعامل تشغيل، واستخدام “call workflow” من تدفق عمل آخر لاستدعاء ذلك التدفق الأول.
لقد وصلتُ إلى حدّ 50 عقدةً لأول مرة مؤخراً أيضاً. في حالتي، كان تقسيم الأمور إلى أجزاء عمليةً بسيطة إلى حدٍّ ما. لكنني فُوجئتُ قليلاً عندما وصلتُ إلى هذا الحد.
كنتُ أعلم بوجود هذا الحد، لكنني لم أشعر فعلياً بأنني وصلتُ إلى 50 عقدةً بعد.
عدّدتُها. فعلتُ ذلك فعلاً.
يمكنني تخيّل رفع الحدّ المبرمج يدوياً قليلاً، لكنني أعتقد أن وجود حدّ مفيد، والرقم الحالي ليس بعيداً جداً عن الرقم المناسب.
لكن هناك أمرٌ واحد… لاحظتُ أن الملاحظات اللاصقة تُحتسب ضمن الحدّ. بدا ذلك غريباً، وأعتقد أنه يجب علينا على الأرجح تغيير ذلك.
هذا الحد عشوائي نوعًا ما، للأسباب التي شرحها @awesomerobot. لن أكون ضد رفعه إلى 100 بدلاً من عدم احتساب الملاحظات اللاصقة. إن حقيقة أن الملاحظات اللاصقة هي في الواقع عقد هو مجرد تفصيل في التنفيذ
حاليًا، تمكنت من إجراء التقسيم بطريقة بسيطة كما ذكر ديف من قبل، لكن ربما في المستقبل ستمنع زيادة الحد من 50 إلى 100 من إنشاء عدد كبير جدًا من سير العمل، مما يساعد على الحفاظ على تنظيمها.
دون أن ندرك ذلك، قد نجد أنفسنا مع 10 أو 20 سير عمل تعمل في نفس الوقت، فالوظيفة تتيح الكثير في ديسكورس، وأرى أن كثيرين منا يستكشفون إمكانياتها.
