قاعدة دورة الحياة
قواعد دورة الحياة هي أسهل طريقة لإضافة الأتمتة إلى الحل الذي تقدّمه. وتتكوّن قواعد دورة الحياة من جزأين: أحداث دورة الحياة وإجراءات دورة الحياة.
تُنشأ أحداث دورة الحياة كلما حدث أي تغيير في النظام. على سبيل المثال، عند تحديث عميل محتمل — حيث يمثّل العميل المحتمل عملية — يُنشأ حدث باسم process:update:post ويحمل تفاصيل التغيير.
لذلك، يمكننا كتابة قواعد لتنفيذ إجراءات دورة الحياة تلقائيًا استنادًا إلى أحداث دورة الحياة. على سبيل المثال، يمكننا القول: كلما جرى تحديث عميل محتمل، أرسل إشعارًا إلى المسؤول المعيّن له. في هذه الحالة، send-notification هو إجراء دورة الحياة الذي نريد تنفيذه.
باختصار، إليك قاعدة دورة حياة
`عند تحديث عميل محتمل، أرسل إشعارًا إلى المسؤول المعيّن له `
- حدث دورة الحياة -> عند تحديث عميل محتمل
- إجراء دورة الحياة -> إرسال إشعار إلى المسؤول المعيّن
شروط الحدث
غالبًا ما نرغب في إضافة بعض الشروط لتحديد متى نريد تشغيل قاعدة. وبمتابعة المثال السابق، سيكون من المفيد أكثر إخطار المسؤول المعيّن لعميل محتمل عند حدوث تحديثات مهمة عليه. على سبيل المثال
When a lead's state changes to converted, send an email to the assignee
أضفنا هنا شرطًا إضافيًا هو "عندما تتغير حالة العميل المحتمل إلى تم التحويل". تُطبّق هذه الشروط أو المعايير الإضافية من خلال شروط الأحداث التي يمكننا إضافتها إلى أي قاعدة. وتتبع الشروط قواعد الصياغة القياسية لمحرك القواعد
تعريف الإجراء
تعريف الإجراء هو المكان الذي نضبط فيه المعلمات الدقيقة اللازمة لتنفيذ إجراء. على سبيل المثال، هنا
When a lead's state changes to converted, send an email to the assignee
نريد تحديد محتوى البريد الإلكتروني على النحو التالي
{ "emailSubject": "{{process.data.lead_id}} has been conveerted", "emailBody": "Hi {{user.firstName}}, congratulations your lead {{process.data.lead_id}} is now converted."}يمكننا هنا ضبط الإجراء بدقة وفقًا لسياق الحدث، وهو في هذه الحالة تحديث عميل محتمل. في تعريف الإجراء، ستتمكن من الوصول إلى جميع البيانات المتعلقة بالتحديث، مثل تفاصيل العملية وتفاصيل المستخدم وغيرها...
الوسم
ينبغي إسناد وسوم قواعد دورة الحياة إلى عنصر meta ذي صلة، مثل procedure أو entity أو statetask.
متزامن/غير متزامن
يمكن معالجة القواعد بالتزامن مع الحدث أو بشكل غير متزامن. لا يوجد حاليًا ضمان لترتيب تنفيذ القواعد غير المتزامنة.
تعبئة البيانات
نحتاج في كثير من الأحيان إلى تعبئة الحدث الأصلي للحصول على معلومات إضافية. وتتمثل أبرز المخاوف المتعلقة بتعبئة البيانات فيما يلي:
- زمن الاستجابة - كثرة عمليات التعبئة = كثرة جلب البيانات = قواعد أبطأ
- قواعد أكثر تعقيدًا
تتم حاليًا عملية تعبئة البيانات على 3 مستويات
- process-event
- تُعبّأ جميع أحداث المهام باستخدام
populatedTask - process-action
- تُعبّأ جميع الأحداث التي تتضمن تعريف populatePath الصحيح في موضعها، ويُعدّل كائن الحدث الأصلي
- تنفيذ الإجراء
- تُعبّئ الإجراءات الفردية نفسها البيانات أيضًا، عادةً في مفتاح يُسمى
_meta
قائمة الأحداث
- api-check:post
- booking:update:post
- call:create:post
- call:create:pre
- call:update:post
- email:received:post
- form-response:create:post
- process:allocate:post
- process:create:post
- process:create:pre
- process:state-change:post
- process:update:post
- process:update:pre
- record:create:post
- record:update:post
- task:create:post
- task:create:pre
- task:update:post
- task:update:pre
- upload-job:complete:post
- user:login:post
- user:logout:post
- webhook:inbound:post
قائمة الإجراءات
- process:start
- record:create
- record-process:create
- process:complete
- process:update
- process:bulk-update
- process:find-one-and-update
- task:create-from-statetask
- task:allocate
- task:bulk-update
- record:find-and-update
- script:run
- task:webhook-task-external
- process:webhook-process-external
- call:webhook-call-external
- task:webhook
- process:bulk-find-and-complete
- process:update-using-rule
- process:modify-query
- external-api:call
- call:link-record-and-process
- notify:email
- notify:sms
- notification:create
- external-data-store:push