سؤال

أرغب في معرفة المشكلات المحددة التي قمت بها - القارئ - التي حلت باستخدام محركات سير العمل وما هي المكتبات/الأطر التي استخدمتها إذا لم تقم بتدحرجك. أود أيضًا أن أعرف متى لم يكن محرك سير العمل هو الخيار الأفضل ، وإذا/كيف اخترت شيئًا أكثر بساطة ، مثل تطبيق قائمة المهام/قائمة العمل/إدارة المهام باستخدام آلات الحالة.

أسئلة:

  • ما هي المشكلات التي استخدمتها محركات سير العمل لحلها؟
  • ما هي المكتبات/الأطر التي استخدمتها؟
  • متى يكفي إدارة آلة الحالة/المهام مثل النظام؟
  • المكافأة: كيف فعلت/هل تميز بين ادارة المهام و محرك سير العمل?

أنا أبحث عن تجارب مباشرة.

بعض الموارد التي راجعتها:

هل كانت مفيدة؟

المحلول

أنا متحيز أيضًا ، لأنني المؤلف الرئيسي لـ مسار الحجر.

لقد قمت بتطوير طلبات سير العمل لوزارة الخارجية الأمريكية ، ومركز جنيف لإزالة العروض الإنسانية ، والعديد من عملاء Fortune 500 ، ومؤخراً نظام المدارس العامة في واشنطن العاصمة. في كل مرة رأيت فيها "محرك سير العمل" الذي حاول أن يكون المرجع الرئيسي للعمليات التجارية ، رأيت مؤسسة تقاتل نفسها للعمل حول الأداة. قد يكون هذا بسبب حقيقة أن هذه الحلول كانت دائمًا بائعًا/منتجًا ، ثم ينتهي به الأمر مع فريق تكتيكي من "الاستشاريين" الذين يتغذون باستمرار ... ولكن بسبب هذا ، أميل إلى الرد بشكل سلبي عندما أسمع فوائد الأدوات القائمة على العملية التي تعد بـ "مركزية تعريفات سير العمل في مكان واحد وجعلها قابلة للتكرار".

بعد قولي هذا ، أنا أحب Ruote إلى حد كبير - لقد كنت أتابع هذا المشروع لبعض الوقت ، ويجب أن أحتاج إلى هذا النوع من الحلول ، فستكون الأداة التالية التي سأرغب في تجربتها. لدى Stonepath غرض مختلف تمامًا عن Ruote - حيث يكون Ruote مفيدًا لروبي بشكل عام ، ويهدف Stonepath إلى Rails ، وهو إطار الويب المكتوب باللغة اليقظة. حيث يدور Ruote حول العمليات التجارية الطويلة العمر وتعريفاتها المرتبطة بها ، فإن StonePath يدور حول إدارة سير العمل والمهام القائمة على الدولة. بصراحة ، أعتقد أن التمييز من الخارج قد يكون خفيًا-في كثير من الأحيان يمكن تمثيل نفس أنواع العمليات التجارية في كلتا الحالتين-يميل النموذج القائم على الدولة والمهام إلى رسم خريطة لنموذجتي العقلية.

اسمحوا لي أن أصف أبرز ما في سير العمل القائم على الدولة. باختصار ، تخيل سير عمل يدور حول معالجة شيء مثل قرض الرهن العقاري أو تجديد جواز السفر. بينما تتحرك الوثيقة "حول المكتب" ، تسافر من ولاية إلى أخرى. تخيل لو كنت مسؤولاً عن المستند ، وطلب منك رئيسك كل بضع ساعات في تحديث الحالة ، وأراد إجابة موجزة ... ستقول أشياء مثل "إنه في إدخال البيانات" ... "نحن نتحقق بيانات اعتماد مقدم الطلب الآن "..." نحن ننتظر مراجعة الجودة "..." لقد انتهينا "... وهكذا. هذه هي الدول في سير العمل القائم على الدولة. ننتقل من ولاية إلى أخرى عبر التحولات - مثل "الموافقة" ، "تطبيق" ، ركلة "،" إنكار "، وهكذا. هذه تميل إلى أن تكون أفعال عمل. مثل هذه الأشياء مصممة طوال الوقت في البرامج كآلة حالة .

الجزء التالي من سير العمل القائم على الحالة/المهام هو إنشاء مهام. المهمة هي وحدة عمل ، عادةً مع تاريخ الاستحقاق وتعليمات المناولة ، تربط عنصر عمل (تطبيق القرض أو تجديد جواز السفر ، على سبيل المثال) ، بالمستخدمين "في المربع". يمكن أن تحدث المهام بالتوازي مع بعضها البعض أو التسلسل ، ويمكننا إنشاء مهام تلقائيًا عندما ندخل الحالات ، وإنشاء مهام يدويًا حيث يدرك الناس أن العمل يحتاج إلى القيام به ، ويتطلب أن تكتمل المهام قبل أن نتمكن من الانتقال إلى حالة جديدة. كل هذا النوع من السلوك اختياري ، وجزء من تعريف سير العمل.

يمكن أن يسير حفرة الأرنب أعمق بكثير من هذا ، وكتبت مقالًا عن ذلك للمسألة رقم 4 من Pragpub ، مجلة Pragmatic Programmer. تحقق من رابط REO أعلاه للحصول على ملف PDF محدث من هذه المقالة.

في العمل مع StonePath في الأشهر القليلة الماضية ، وجدت أن النموذج النموذجي يعتمد على الدولة بشكل جيد حقًا لبنية الويب المريحة - على وجه الخصوص ، فإن المهام والتحولات في الحالة تخطط بشكل جيد كموارد متداخلة. نتوقع أن نرى الكتابة المستقبلية مني حول هذا الموضوع.

نصائح أخرى

أنا متحيز ، أنا أحد مؤلفي روت.

البديل 1) آلة الحالة المرفقة بمورد (وثيقة ، ترتيب ، فاتورة ، كتاب ، قطعة أثاث).

البديل 2) آلة الحالة متصلة بمورد افتراضي يسمى مهمة

البديل 3) محرك سير العمل تفسير تعريفات سير العمل

الآن يتم وضع علامة على سؤالك "BPM" يمكننا توسيعنا إلى "إدارة العمليات التجارية". كيف يحدث هذا النوع من الإدارة في كل من المتغير؟

في المتغير 1 ، تنتشر عملية الأعمال (أو سير العمل) في التطبيق. يفرض آلة الحالة المرتبطة بالمورد بعض جوانب سير العمل ، ولكن فقط تلك المتعلقة بالمورد. قد تكون هناك موارد أخرى مع آلة الحالة الخاصة بهم بعد نفس عملية الأعمال.

في المتغير 2 ، يمكن تركيز سير العمل حول مورد المهام وتمثيله بواسطة آلة الحالة حول هذا المورد.

في المتغير 3 ، يتم سن سير العمل عن طريق تفسير مورد يسمى تعريف تدفق العمل (أو تعريف عملية الأعمال).

ماذا يحدث عندما تتغير عملية الأعمال؟ هل يستحق امتلاك محرك سير العمل حيث تكون العمليات التجارية موارد قابلة للإدارة؟

تحتوي معظم مكتبات آلة الولاية على حالات واحدة + تحولات. محركات سير العمل هي ، معظمها ، على فترات تعريف تعريف تدفق سير العمل ، وتسمح لركوب عمل مختلفة متعددة بالعمل معًا.

ماذا ستكون تكلفة تغيير سير العمل؟

المتغيرات ليست حصرية بشكل متبادل. لقد رأيت العديد من الأمثلة حيث يغير محرك سير العمل حالة الموارد المتعددة التي يحرسها بعضها من آلات الدولة.

أستخدم أيضًا Variant 3 + 2 كثيرًا ، للمهام البشرية: محرك سير العمل ، في بعض النقاط عند تشغيل مثيل العملية ، قم بتسليم مهمة (Workitem) إلى مشارك بشري (يتم إنشاء مهمة للموارد ووضعها في حالة "جاهزة") .

يمكنك قطع شوط طويل مع Variant 2 وحده (متغير مدير المهام).

يمكن أن نذكر أيضًا البديل 0) ، حيث لا يوجد آلة حالة ، لا يوجد محرك سير عمل ، وعملية الأعمال (ES) منتشرة و/أو متشددين في التطبيق.

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

في مشروع سابق كنت أعمل عليه ، أضفت بعض قواعد نوع سير العمل إلى مجموعة من النماذج الحكومية في صناعة Healhcare.

يجب ملء النماذج من قبل المستخدم النهائي ، واعتمادًا على بعض الإجابات ، من المقرر ملء النماذج الأخرى في وقت لاحق. كانت هناك أيضًا أحداث خارجية من شأنها إلغاء النماذج المجدولة أو جدولة الأحداث الجديدة.

تدفق العينة:

تم قبول المريض -> نموذج التقييم الأولي -> نموذج المراجعة الفصلية -> مات المريض -> إلغاء مراجعة -> نموذج تقييم إفراز الجدول الزمني

استندت العديد من القواعد الأخرى إلى أشياء مثل عمر المريض ، حيث تم قبولهم وما إلى ذلك.

كان هذا تطبيق ASP.NET ، وكانت القواعد أساسا جدول في قاعدة البيانات. أضفت البرمجة النصية ، لذلك سيتم تشغيل البرنامج النصي عند إكمال النموذج لتحديد ما يجب القيام به بعد ذلك. كان هذا تصميمًا فظيعًا ، وكان من الممكن أن يكون مثاليًا لمحرك سير العمل المناسب.

الشيك Rails_workflow GEM - أعتقد أن هذا قريب مما تبحث عنه.

أنا واحد من مؤلفي محرك سير العمل الإيقاع تطورنا في أوبر. الفرق بين الإيقاع وأغلبية محركات سير العمل الحالية هو أنه يركز على المطور ومرن للغاية وقابل للتطوير (لعشرات الآلاف من التحديثات في الثانية وما يصل إلى مليارات من تدفقات العمل المفتوحة). تتم كتابة سير العمل كبرامج موجهة للكائنات ويضمن المحرك أن يتم الحفاظ على حالة كائنات سير العمل بما في ذلك مداخن مؤشرات الترابط والمتغيرات المحلية بالكامل في حالة فشل المضيف.

ما هي المشكلات التي استخدمتها محركات سير العمل لحلها؟ يتم استخدام الإيقاع لأية تطبيق للواجهة الخلفية التي تعيش بعد رد طلب واحد. أمثلة الاستخدام هي:

  • وظائف كرون موزعة
  • إدارة خطوط أنابيب ML/البيانات
  • الرد على أحداث الأعمال. على سبيل المثال أحداث الرحلة في أوبر. يمكن لسير العمل أن يتراكم الحالة بناءً على الأحداث المستلمة وتنفيذ الأنشطة عند الضرورة.
  • نشر الخدمات على mesos/ kubernetes
  • تنفيذ خط أنابيب CI
  • التأكد من اكتمال مكالمات الخدمة المتعددة عند استلام الطلب. مشتمل قصة طويلة تنفيذ نمط
  • إدارة مهام العمال البشري (على غرار Amazon mturk)
  • معالجة وسائل الإعلام
  • توجيه تذكرة دعم العملاء
  • معالجة الطلب
  • خدمة الاختبار مماثلة لخدمة Chaosmonkey

وغيرها الكثير

تعتمد مجموعة حالات الاستخدام الأخرى على نقل محركات سير العمل الحالية لتشغيلها على الإيقاع. من الناحية العملية ، يمكن تشغيل أي لغة مواصفات سير عمل محرك موجودة لتشغيلها على الإيقاع. هناك العديد من أنظمة Uber الداخلية التي تم نقلها. وبهذه الطريقة ، يمكن لخدمة الواجهة الخلفية واحدة تشغيل أنظمة سير عمل متعددة المجال.

ما هي المكتبات/الأطر التي استخدمتها؟

الإيقاع هي خدمة تحتوي على ذاتي مكتوبة مع Go With اذهب و جافا مكتبات جانب العميل. التبعية الخارجية الوحيدة هي التخزين. يتم دعم قواعد بيانات كاساندرا و SQL.

يدعم الإيقاع أيضًا تكرار منطقة الصليب غير المتزامن (باستخدام مصطلحات AWS).

متى يكفي إدارة آلة الحالة/المهام مثل النظام؟

داخل فريق Uber يتم إدارة خدمة الإيقاع من قبل فريقنا. وبالتالي فإن النفقات العامة لبناء أي إدارة مخصصة لآلة الحالة/المهام أعلى دائمًا من استخدام الإيقاع. خارج الشركة ، يجب إعداد الخدمة والتخزين. إذا كان لديك بالفعل قاعدة بيانات SQL ، فسيكون نشر الخدمة تافهة من خلال صورة Docker. يستخدم Docker أيضًا لتشغيل خدمة الإيقاع المحلية للتطوير على جهاز كمبيوتر شخصي أو كمبيوتر محمول.

لقد قمت بتدحرج محرك سير العمل الخاص بي لدعم المعالجة التدريجية للمستندات - الفهرسة ، وإرسالها لمعالجة الصور (نعمل مع Redaction SW) ، إذا لزم الأمر إرسال إلى التحقق من الصحة ، ثم التحرير وأخيراً الشحن إلى العميل. في حالتنا ، لدينا حمولة شاحنة من المستندات للمعالجة ، لذلك نحتاج في بعض الأحيان إلى تشغيل كل خدمة بشكل منفصل للتحكم في التسليم واستخدام الموارد. بسيطة في المفهوم ولكن عالية الأداء والمعالجة الموزعة اللازمة ، ولم نتمكن من العثور على أي منتج على الرف الذي يتناسب مع الفاتورة بالنسبة لنا.

لدي خبرة في استخدام activiti محرك BPMN 2.0 للتعامل مع عمليات نقل البيانات عالية الأداء وعالي الإنتاجية في بنية تحتية لعقد الشبكة. كانت المهمة الأساسية هي السماح بتكوين ومراقبة عمليات النقل هذه والتحكم في كل عقدة شبكة (أي طلب NODE1 بإرسال ملف بيانات إلى Node2 عبر طبقة نقل محددة).

يمكن أن يكون هناك الآلاف من العمليات التي تعمل في وقت واحد وعشرات عام أو مئات الآلاف من العمليات في اليوم.

كانت هناك مجموعة من تعريفات العمليات المختلفة ولكن لم يكن مطلوبًا بالضرورة أن يقوم مشغل النظام بإنشاء مهام سير عمل مخصصة. لذلك كانت حالة الاستخدام الأساسي لمحرك BPM نفسه هي أن تكون قوية وقابلة للتطوير والسماح بمراقبة كل تدفق العملية.

في النهاية ، نجح الأمر بشكل أساسي ، لكن ما تعلمناه من هذا المشروع هو أن منصة BPMN ، أو بالأحرى محرك Activiti على وجه التحديد ، لم يكن أفضل رهان لنظام الإنتاجية العالية.

وكانت التحديات الرئيسية هي تحديد أولويات تنفيذ المهمة ، وقفل DB ، وإعادة تنفيذ إعادة تسمية القلة المتعلقة بـ BPM نفسها. لذلك اضطررنا إلى تطوير معالجة مخصصة لها ، على سبيل المثال:

  • معالجة إعادة المحاولة في BPM للحالات التي لم يكن فيها عقدة لم يكن لها عامل مجاني لمهمة معينة ، أو عندما لم تكن العقدة تعمل على الإطلاق.
  • تنفيذ مهام النقل الموازية في عملية واحدة وتزامن النتائج (النجاح/الفشل).

لا أعرف ما إذا كانت محركات BPMN الأخرى ستكون أكثر ملاءمة لمثل هذا السيناريو لأن BPMN مخصصة في الغالب لمهام الأعمال طويلة الأمد التي تتضمن تفاعل المستخدم حيث ربما لا يكون الأداء هو نفس المشكلة كما كان في حالتنا.

أنا واحد من مؤلفي imixs-workflow. Imixs-Workflow هو محرك سير عمل مفتوح المصدر يعتمد على BPMN 2.0 ومدمج بالكامل في مكدس تقنية Java EE.
أقوم بتطوير محركات سير العمل بنفسي منذ أكثر من 10 سنوات. سأحاول الإجابة على سؤالك باختصار:

> ما هي المشكلات التي استخدمتها محركات سير العمل لحلها؟

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

  • إرسال إشعار
  • عرض المهام المفتوحة
  • تعيين مهمة لشخص ما
  • وصف المهمة الحالية

من قائمة الوظائف هذه ، يمكنك أن ترى أنني أتحدث عن سير العمل المتمحور حول الإنسان. باختصار: يجيب محرك سير العمل المتمحور حول الإنسان على الأسئلة: من المسؤول عن مهمة ومن يحتاج إلى أن يتم إبلاغه بعد ذلك؟ وهذه هي الأسئلة النموذجية في متطلبات العمل.

> ما هي المكتبات/الأطر التي استخدمتها؟

قبل 5 سنوات بدأنا في إعادة تنفيذ محرك IMIXS-Workflow مع التركيز على BPMN 2.0. BPMN هو المعيار المشترك لنمذجة العملية. والشيء المثير بالنسبة لي هو أننا كنا قادرين فجأة على وصف العمليات التجارية الشديدة المعقدة التي يمكن تصورها وتنفيذها. أوصي الجميع باستخدام BPMN لنمذجة العمليات التجارية.

> متى يكفي إدارة آلة الحالة/المهام مثل النظام؟

آلة الحالة البسيطة كافية إذا كنت تريد فقط تتبع حالة كائن العمل. هذا هو الحال عندما تبدأ في تقديم سمة "الحالة" في نموذج الكائن الخاص بك. ولكن في حال كنت بحاجة إلى عمليات تجارية بمسؤوليات وتسجيل والتحكم في التدفق ، فإن آلة الحالة لم تعد كافية.

> المكافأة: كيف/هل قمت بالتمييز بين إدارة المهام ومحرك سير العمل؟

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top