طراح گردش‌کار
طراح گردش‌کار جایی است که مدیران گردش‌کار تعریف‌هایی را می‌سازند که هر اجرا بر پایهٔ آن‌ها پیش می‌رود. Eduba آنچه شما طراحی می‌کنید به BPMN 2.0 واقعی تبدیل می‌کند و روی موتور Flowable تعبیه‌شده اجرا می‌کند (ADR-0048). بوم طراحی انشعابی از مدلر bpmn.io است، با پالت بلوک‌های Eduba و پنل ویژگی‌هایی که از مانیفست بلوک ساخته می‌شود. مرحله‌ها را روی بوم می‌چینید، فرم و مسئول و قوانین هر مرحله را تنظیم می‌کنید و سپس یک نسخه را منتشر می‌کنید تا اجراهای تازه از روی آن ساخته شوند.
طراحی به قابلیت designWorkflow نیاز دارد (مدیر گردش‌کار). انتشار
علاوه بر آن از publishDefinition هم استفاده می‌کند. نقش‌ها و چارت سازمانی
را ببینید.
بوم طراحی
بلوک‌ها را از پالت روی بوم بکشید و مثل هر ویرایشگر BPMN با جریان‌های
ترتیبی و دروازه‌ها به هم وصل کنید. هر بلوکِ غیرانسانی به یک service task
تبدیل می‌شود که یک worker نوشته‌شده با TypeScript (BlockRuntime) آن را اجرا
می‌کند. بلوکی از دستهٔ human به یک user task واقعی BPMN تبدیل می‌شود و
بدون هیچ سیم‌کشی اضافه در کارتابل کارهای من مسئولش ظاهر
می‌شود. با انتخاب هر عنصر، پنل ویژگی‌ها باز می‌شود و برای هر فیلد
تنظیمات بلوک، طبق مانیفستش (config.schema) یک ورودی نشان می‌دهد: متن، عدد،
بولی، فهرست گزینه‌ها و یک انتخابگر مسئول که با دایرکتوری سازمان کار می‌کند
(در ادامه توضیح داده شده).
واگذاری کار به یک نقش
هر فیلد قالب عنصر از نوع assignee، از جمله تنظیم assignee در بلوک human،
به‌صورت یک انتخابگر با شش زبانه نمایش داده می‌شود: نقش، کاربر، گروه،
پویا، قاعده و پیشرفته.
- نقش در نقش‌های سازمان جست‌وجو می‌کند و با انتخاب، مقدار
{ type: 'role', roleId }را می‌نویسد. این حالت رایج مرحله‌ای است که باید به هر کسی که آن نقش را دارد (مثلاً همهٔcheckerها) پیشنهاد شود، نه یک فرد مشخص. موتور در لحظهٔ ساخت توکن انتظار، نقش را از طریق موتور قوانین دسترسی به کاربران نامزد تبدیل می‌کند (ADR-0005 §3). - کاربر و گروه همین‌طور کار می‌کنند و از دایرکتوریِ قابل‌جست‌وجو،
{ type: 'user', userId }یا{ type: 'group', groupId }را می‌نویسند. - پویا یک مسیر منبع می‌گیرد (مثلاً
n3.outputs.reviewerUserId) تا مسئول در زمان اجرا از خروجی یک مرحلهٔ بالادستی تعیین شود. - قاعده به یک
ruleRefاز قوانین دسترسی ارجاع می‌دهد که موتور قوانین آن را تعیین می‌کند. - پیشرفته یک راه جایگزین با JSON خام است، برای مشخصهٔ ترکیبی (
anyیاallاز موارد بالا) یا مقداری که خودتان تایپ می‌کنید. هیچ‌چیزی که تعریف‌های قدیمی‌تر نوشته‌اند از بین نمی‌رود و به‌محض اینکه از هر زبانهٔ دیگر یک زبانه را انتخاب کنید، مقدار ذخیره‌شده به شکل استاندارد شیء ارتقا می‌یابد.
مقدار انتخاب‌شده یک AssigneeSpec است (ADR-0002 §1b)، همان شکلی که هر بلوک
انتظارِ انسانی می‌پذیرد. بنابراین چه مرحله در گردش‌کار والد باشد و چه در بدنهٔ
یک زیرگردشِ تأییدشده (ADR-0076)، رفتارش یکسان است.
SLA و ارجاع بالاتر در مرحلهٔ تصمیم
بلوک human.decision — بلوک عمومی پشت یک مرحلهٔ تصمیم‌گیری (مثلاً استفاده
همان‌طور که هست / بازکاری / اسقاط در MRB، یا تأیید / رد / تعویق در CCB) —
در تنظیماتش یک مهلت SLA و یک نردبان ارجاع بالاتر اختیاری دارد، در کنار
outcomes یا همان نتیجه‌هایی که تصمیم‌گیرنده از میانشان انتخاب می‌کند:
slaAt— مهلت مطلق به قالب ISO-8601، یاslaHours— بودجهٔ نسبی بر حسب ساعت، از لحظه‌ای که انتظار شروع می‌شود. اگر هر دو تنظیم شده باشند،slaAtاولویت دارد.escalation.steps— فهرستی مرتب از پله‌های{ offsetMs, assignee }. هر پله مشخص می‌کند چه مدت پیش از مهلت فعال می‌شود و با یکAssigneeSpec(همان انتخابگر بالا) معلوم می‌کند کار دوباره به چه کسی می‌رسد. ارجاع بالاتر فقط وقتی معنی دارد که گره مهلت هم داشته باشد.
در وضعیت فعلی، این فیلدها در پنل ویژگی‌ها به‌صورت ورودی متن یا JSON ساده
نمایش داده می‌شوند و هنوز ویرایشگر اختصاصی پله‌های نردبان، با افزودن و حذف
ردیف، وجود ندارد. طراح slaHours را به‌صورت عدد وارد می‌کند و برای ارجاع
بالاتر، آرایهٔ steps را به‌صورت JSON ویرایش می‌کند. منطق آن سمت موتور
کاملاً پیاده شده است (مهلت به یک timer boundary event در BPMN تبدیل می‌شود و
ارجاع بالاتر به یک listener که AssigneeSpec را دوباره تعیین می‌کند، طبق
نگاشت مفهوم به BPMN در ADR-0048). فقط سطح طراحی هنوز صیقل نخورده است. این را
رفتار واقعی و فعلی بدانید، نه پیش‌نمایشی از یک رابط نردبانیِ آینده.
آن را با دو کنترل هم‌نام یا شبیه، اما نامرتبط اشتبا ه نگیرید:
- فیلد «ساعت» در کنترل انتظار (یک
timeDurationساده در BPMN) یک تأخیر بی‌قیدوشرط است، بدون مسئول و بدون نردبان؛ SLA نیست. - ارجاع به مدیر روی یک مرحلهٔ ناموفق (بازرس اجرا یا بنر مرحلهٔ ناموفق در جزئیات وظیفه، ADR-0078) این است که فردِ گیرکرده، بعد از اینکه مشکلی پیش آمده، کار را به یک مدیر می‌سپارد. این با تنظیم SLA که طراح می‌نویسد ربطی ندارد و از طراح هم قابل تنظیم نیست.
نسخه‌بندی و انتشار
ویرایش یک تعریف هیچ‌وقت کارهای در جریان را تغییر نمی‌دهد: تعریف نسخه‌بندی می‌شود و هر انتشار یک بازنگری تغییرناپذیر تازه می‌سازد. هر اجرا در تمام عمرش با نسخه‌ای که با آن شروع شده ادامه می‌دهد؛ یعنی زنجیرهٔ تأییدِ در جریان از تغییری که طراح یک ساعت بعد می‌دهد اثر نمی‌گیرد. فقط نسخهٔ منتشرشده قابل شروع است و پیش‌نویس‌ها فقط در طراح دیده می‌شوند.
استفادهٔ مجدد از قطعه‌ها
مرحله‌ای که انتظار دارید در چند تعریف تکرار شود — مثل یک زنجیرهٔ تأیید یا یک
الگوی اطلاع‌رسانی — جایش در کتابخانهٔ زیرگردش است، به‌عنوان
قطعهٔ قابل‌استفادهٔ مجدد، نه اینکه روی هر بوم دوباره کشیده شود. بدنهٔ یک
زیرگردشِ تأییدشده خودش می‌تواند بلوک human داشته باشد. طراح و موتور با آن
دقیقاً مثل مرحلهٔ انسانی در گراف والد رفتار می‌کنند (ADR-0076)، با یک محدودیت
فعلی: هر بدنه به ازای هر نمونهٔ زیرگردش حداکثر یک انتظار انسانیِ در جریان را
پشتیبانی می‌کند.
مطالب مرتبط
- کتابخانهٔ زیرگردش — قطعه‌های قابل‌استفادهٔ مجدد برای تعریف‌هایتان.
- مفاهیم کلیدی — تعریف‌ها، نسخه‌ها و اجراها.
- ایجاد کار — شروع اجرا از روی آنچه منتشر می‌کنید.
- نقش‌ها و چارت سازمانی — نقش‌هایی که انتخابگر مسئول در آن‌ها جست‌وجو می کند.
اشتباهی دیدید؟ درخواست تغییر بدهید.