استودیو — Gatewayها

انتخاب Gateway مناسب

برای تصمیم «اگر مدت مرخصی مجاز بود، به تأییدکننده بفرست»، از Exclusive استفاده کنید. برای ارسال هم‌زمان دو رونوشت مستقل، Parallel مناسب است. اگر ارسال هر رونوشت به یک انتخاب جداگانه در فرم وابسته است، Inclusive را انتخاب کنید. برای تصمیم کارگروه، مانند پذیرفته‌شدن استخدام با رسیدن رأی تأیید به حد نصاب، Complex را تنظیم کنید.

ساخت و اتصال Gateway

1. در استودیوی فرآیند، لوزی Gateway را از ابزارهای بوم اضافه کنید یا آن را از منوی ادامه عنصر قبلی بسازید.
2. Gateway را انتخاب کنید و از منوی تغییر نوع، نوع موردنیاز را برگزینید. نشان داخل لوزی را بررسی کنید.
3. مسیر ورودی را از گام قبلی به Gateway وصل کنید.
4. برای هر نتیجه یا شاخه، یک Sequence Flow خروجی به گام مقصد رسم کنید. جهت پیکان باید به مقصد باشد.
5. عنوان Gateway را براساس تصمیم بنویسید؛ مانند «بررسی مدت مرخصی». عنوان مسیرها را براساس نتیجه بنویسید؛ مانند «تأیید»، «بررسی مجدد» یا «ارسال رونوشت به مدیریت».
6. تنظیمات اختصاصی Gateway و مسیرهای خروجی آن را تکمیل و ذخیره کنید؛ سپس خود فرآیند را ذخیره کنید.

نکته — عنوان و منطق مسیر: عنوان عنصر، عنوان مسیر و شرط مسیر سه چیز جدا هستند. نوشتن «تأیید» روی خط، به‌تنهایی هیچ شرطی ایجاد نمی‌کند. همچنین وجود دو خط خروجی از یک گام، جای تنظیم نوع Gateway و منطق تصمیم را نمی‌گیرد.

اگر خروجی به UserTask می‌رسد، دریافت‌کننده آن از سطح دسترسی Lane تعیین می‌شود. Gateway مشخص می‌کند کدام مسیر انتخاب شود؛ تنظیم فرم، ورودی و خروجی داده و اقدامات کاربر در Taskها و Activityها انجام می‌شود.

تنظیمات مشترک: انتخاب عنصر، تغییر عنوان و توضیحات و ذخیره تغییرات از پنل استودیو انجام می‌شود. روش کار با پنل و اتصال عناصر در استودیوی فرآیند آمده است؛ شرط مسیر، ارتباط جمع‌کننده و حد نصاب اقدامات را در بخش نوع Gateway مربوط تکمیل کنید.

Exclusive؛ ادامه از یک مسیر

Exclusive برای تصمیمی به‌کار می‌رود که باید یک نتیجه داشته باشد. دو روش کاربردی آن، تصمیم خودکار از روی داده و تصمیم براساس اقدام کاربر هستند. پیش از تنظیم Gateway مشخص کنید تصمیم را کاربر با انتخاب اقدام می‌گیرد یا سامانه با بررسی مقدار متغیر.

تصمیم خودکار با شرط

در تصمیم خودکار، ابتدا داده لازم را آماده کنید. برای نمونه، ServiceTask فاصله تاریخ شروع و پایان مرخصی را محاسبه می‌کند و نتیجه را در متغیر فرآیند قرار می‌دهد. Exclusive مقدار این متغیر را می‌خواند و نتیجه مناسب را انتخاب می‌کند.

1. گام تولید داده را پیش از Gateway قرار دهید و خروجی آن را در متغیر مناسب ذخیره کنید.
2. تنظیم مسیر موردنظر را از تنظیمات Gateway باز کنید.
3. بخش تنظیمات شروط را باز کنید.
4. مقدار سمت شرط را از متغیر مربوط انتخاب کنید؛ اگر داده داخل ساختار فرم یا سرویس است، مسیر همان عضو را مشخص کنید.
5. عملگر مقایسه را انتخاب و مقدار مقایسه را وارد کنید.
6. سایر مسیرها و در صورت نیاز مسیر پیش‌فرض را تکمیل کنید.

مثال — اثر شرط در ارجاع: با قاعده حداکثر ۱۰ روز، درخواست ۴روزه به کار جانشین می‌رسد؛ درخواست ۱۴روزه از مسیر عدم تأیید به پایان می‌رود و کاری برای جانشین ایجاد نمی‌کند.

نکته — انتخاب مقدار قابل مقایسه: مقدار خروجی باید با مقایسه تناسب داشته باشد. اگر متغیر شامل خروجی یک سرویس است، عدد موردنیاز را از عضو درست آن بخوانید؛ مقایسه کل مجموعه خروجی با عدد، جای انتخاب مقدار را نمی‌گیرد. همین موضوع برای فیلدهای داخل داده فرم نیز برقرار است.

Exclusive یک مسیر را برای ادامه انتخاب می‌کند. برای اجرای چند مسیر شرطی به‌صورت هم‌زمان، از Inclusive استفاده کنید.

تصمیم براساس اقدام UserTask

وقتی کاربر باید هنگام ثبت فرم «تأیید» یا «عدم تأیید» را انتخاب کند، UserTask را به Exclusive متصل و مسیر هر اقدام را تعریف کنید. در این روش، انتخاب اقدام کاربر مشخص می‌کند کدام خروجی دنبال شود؛ لازم نیست تصمیم را دوباره با یک فیلد فرم بازسازی کنید.

1. UserTask بررسی را به Exclusive وصل کنید.
2. خروجی‌های Gateway را به مقصدهای تأیید، برگشت یا سایر نتایج موردنیاز متصل کنید.
3. برای هر خروجی، اقدام مربوط را ایجاد یا انتخاب کنید. عنوان اقدام باید برای کاربر روشن باشد.
4. مسیرها را در حالت تصمیم براساس اقدام نگه دارید و برای آن‌ها شرط داده تعریف نکنید.
5. در تنظیمات UserTask، نوع نمایش اقدامات را مشخص کنید؛ برای نمونه نمایش به‌صورت لیستی از دکمه‌ها.
6. فرم را با یک کاربر دریافت‌کننده باز کنید و بررسی کنید هر اقدام به مقصد خودش می‌رود.

برای حلقه اصلاح، خروجی «بررسی مجدد» یا «عدم تأیید» را به همان UserTask ثبت اطلاعات وصل کنید. داده رکورد باید در ورودی کار برگشتی تنظیم شده باشد تا کاربر بتواند درخواست قبلی را اصلاح کند. صرف رسم خط برگشت، نگاشت داده فرم را انجام نمی‌دهد.

تصمیم از روی فیلد فرم

گاهی کاربر نتیجه بررسی را در خود فرم ثبت می‌کند؛ برای مثال یک Checkbox تأیید را علامت می‌زند و سپس فرم را ذخیره می‌کند. در این طراحی، خروجی UserTask باید در متغیر ذخیره شود و Exclusive مقدار همان فیلد را بررسی کند.

1. فیلد نتیجه بررسی را در فرم آماده کنید؛ در گام ثبت اولیه آن را مخفی و در گام تأییدکننده قابل مشاهده و ویرایش قرار دهید. سایر اطلاعاتی که بررسی‌کننده نباید تغییر دهد، فقط‌خواندنی باشند.
2. حالت UserTask بررسی را روی ویرایش قرار دهید تا ثبت Checkbox ممکن باشد. خروجی این گام را دوباره در همان متغیر داده فرم، مانند @@SavedData، ذخیره کنید تا مقدار جدید به تصمیم برسد.
3. در شرط مسیر، عضو مربوط را از FormData انتخاب کنید.
4. برای مسیر تأیید، مقدار منطقی فیلد را با true مقایسه کنید و مسیر عدم تأیید را پیش‌فرض قرار دهید. در این الگو، هر نتیجه‌ای که شرط تأیید را نداشته باشد به مسیر عدم تأیید می‌رود.
5. داده‌های حالت تأیید، عدم تأیید و مقدار خالی احتمالی را در نظر بگیرید تا هیچ درخواست بدون مسیر نماند.

در این طراحی کاربر نتیجه را با فیلد فرم تعیین و فرم را ثبت می‌کند؛ دکمه‌های اقدام مستقل تأیید و عدم تأیید جای خود را به ثبت فرم می‌دهند. اگر به جای مسیر پیش‌فرض برای عدم تأیید، شرط false می‌نویسید، وضعیت مقدار خالی یا نامعتبر را نیز جدا پوشش دهید.

تعیین مسیر پیش‌فرض

مسیر پیش‌فرض زمانی استفاده می‌شود که شرط هیچ‌یک از مسیرهای دیگر برقرار نباشد. برای نمونه، اگر درخواست واجد شرط مجازبودن مدت مرخصی نبود، آن را به مسیر عدم تأیید بفرستید.

1. خط خروجی موردنظر را انتخاب کنید.
2. از منوی تغییر نوع اتصال، آن را به مسیر پیش‌فرض تبدیل کنید.
3. نشانه خط مورب نزدیک ابتدای مسیر را بررسی کنید.
4. مقصد مسیر را مشخص کنید و برای آن عنوان روشن بنویسید.
5. برای این مسیر شرط جداگانه نسازید؛ شرط‌های تصمیم را روی مسیرهای غیرپیش‌فرض تنظیم کنید.

اگر هیچ شرطی برقرار نشود و مسیر پیش‌فرض هم نداشته باشید، Exclusive مسیر مناسبی برای ادامه نخواهد داشت و اجرای فرآیند می‌تواند با خطا متوقف شود. مسیر پیش‌فرض را براساس تصمیم کسب‌وکار تعیین کنید؛ «عدم تأیید» یا «ارجاع برای بررسی» انتخاب‌های وابسته به طراحی شما هستند.

شرح ارجاع هر نتیجه

برای اینکه دریافت‌کننده بداند درخواست چرا به او رسیده است، بخش تنظیمات اعلان شرح ارجاع مسیر را باز و استفاده از شرح ارجاع سفارشی را فعال کنید. متن را متناسب با نتیجه بنویسید؛ برای مثال علت رد یا تأیید بررسی. در پنلی که نوع شرح سفارشی را ارائه می‌کند، نوع مناسب را هم انتخاب کنید.

شرح ارجاع، پیام همراه نتیجه است و شرط تصمیم را تغییر نمی‌دهد. برای مثال پیام «مرخصی تأیید شد» نباید روی مسیری قرار گیرد که قاعده آن عدم تأیید است.

Exclusive Gateway: شروط خروجی، اولویت و Default Flow

در Exclusive Gateway تصمیم شرطی، هر مسیر خروجی با عنوان Action یا شناسه Sequence معرفی می‌شود. فیلد اولویت کنار خروجی قرار دارد؛ از ترتیب نمایش Actionها، ترتیب ارزیابی شرط را نتیجه نگیرید. دکمه if… سازنده شرط همان خروجی را باز می‌کند. شرط یک مسیر را در پنل خروجی همان مسیر تنظیم و سپس تغییرات Gateway را ذخیره کنید.

سازنده شرط، گروه منطقی AND و امکان افزودن یا حذف شرط/گروه دارد. طرف ورودی می‌تواند Variable و مسیر داده آن باشد. عملگرهای نمایان شامل برابر، نابرابر، بزرگ‌تر، بزرگ‌تر مساوی، کوچک‌تر، کوچک‌تر مساوی، بین دو مقدار، شامل، شامل نباشد، شروع با، پایان با، خالی و خالی نباشد هستند. نوع داده طرفین را با عملگر هماهنگ کنید.

شرح ارجاع سفارشی در بخش جداگانه پایین همین پنجره تنظیم می‌شود. تا وقتی کلید آن خاموش است، نوع و متن آن غیرفعال‌اند. این توضیح جانشین شرط مسیر نمی‌شود.

خروجی بدون شرط و اعتبارسنجی Action

وقتی حداقل یک خروجی Gateway بدون شرط وجود دارد، اعتبارسنجی می‌تواند تعیین «نوع نمایش اقدامات» در User Task را مطالبه کند. در این وضعیت، اتصال مسیرها، Actionهای آنها و نوع نمایش User Task را مطابق سناریوی Action Based کنترل کنید.

تعیین Default Flow

برای تبدیل یک اتصال به مسیر پیش‌فرض، Sequence Flow را انتخاب کنید و از «Change element» گزینه «Default flow» را بزنید. علامت خط مورب روی ابتدای مسیر، مسیر Default را مشخص می‌کند. این نشانگر با رنگ Action یا اولویت عددی یکسان نیست.

مسیر پیش‌فرض برای حالتی است که مسیر شرطی دیگری انتخاب نمی‌شود. آن را با خروجی بدون شرطِ سناریوی Action Based اشتباه نگیرید؛ تصمیم توسط کاربر و تصمیم توسط داده، تنظیمات مرتبط خود را دارند.

مقدار ثابت، Variable و Boolean در شرط Gateway

در یک طرف یا هر دو طرف شرط می‌توان مقدار ثابت یا Variable داشت. برای شرط Boolean، قرارداد این تنظیمات مقادیر 0 و 1 است؛ متن‌های True و False جایگزین آن نیستند. انتخاب Variable بدون مسیر، تنها سلول اول داده آن را می‌خواند؛ برای داده چندردیفی یا Property مشخص، مسیر صریح لازم است.

نام‌های FormData و ServiceData به بزرگی و کوچکی حروف حساس‌اند. index آرایه از صفر آغاز می‌شود و برای یک ردیف مشخص باید نوشته شود. ستاره فقط جایی لازم است که مقدار Property واقعاً رشته JSON باشد، نه برای هر Object تو در تو.

راهنمای سمت راست شرط، نمونه‌های V_VariableName:ServiceData[0]['PropertyName'] و V_VariableName:FormData['PropertyName'] را نیز معرفی می‌کند. پیشوند این ورودی متنی با نمایش @@ در کنترل انتخاب Variable یکی فرض نشود. در هر کنترل از قالب همان کنترل و Preview مقدار استفاده کنید.

تشخیص Action Based و Condition Evaluation Based

Exclusive Diverging فقط یک خروجی را انتخاب می‌کند. انتخاب می‌تواند بر پایهٔ اقدام کاربر یا ارزیابی شرط باشد. حالت Action Based فقط زمانی برقرار است که Gateway پس از User Task قرار بگیرد و هیچ‌کدام از Sequence Flowهای خروجی آن Condition نداشته باشند. در این حالت، اقدام‌های خروجی به دکمه‌های Form همان User Task تبدیل می‌شوند و دکمهٔ انتخاب‌شده مسیر را مشخص می‌کند.

اگر حتی یک خروجی Condition داشته باشد، Gateway شرطی است؛ قرارگرفتن آن پس از User Task این قاعده را تغییر نمی‌دهد. در حالت شرطی، هر خروجی عادی باید شرط داشته باشد و خروجی بی‌شرط تنها با نقش صریح Default معتبر است. مخلوط‌کردن خروجی شرطی با خروجی بی‌شرطِ غیرDefault، هنگام ذخیره اعتبارسنجی می‌شود.

Default، مسیر else در Gateway شرطی

شرط‌های خروجی ابتدا ارزیابی می‌شوند. Default برای حالتی است که هیچ مسیر شرطی انتخاب نشده باشد؛ خودش Condition ندارد. آن را برای مسیر جایگزین واقعی، مانند ارجاع به بررسی دستی در صورت تطبیق‌نداشتن قواعد، تنظیم کنید. علامت اسلش روی Sequence Flow مشخص می‌کند کدام خروجی Default است؛ برچسب متنی «پیش‌فرض» به‌تنهایی این نقش اجرایی را ایجاد نمی‌کند.

نمایش اقدام و شرح آن در User Task

در حالت Action Based، عنوان اقدام انتخاب‌شده برای هر Sequence Flow در Form کاربر نمایش داده می‌شود. اگر اقدامی انتخاب نشده باشد، شناسهٔ Sequence Flow دیده می‌شود؛ برای دکمه‌ای که کاربر باید آگاهانه انتخاب کند، عنوان روشن مانند «تأیید» یا «بازگشت برای اصلاح» تعریف کنید.

در User Task پیش از Exclusive بی‌شرط، بخش «نوع نمایش اقدامات» روش ارائهٔ گزینه‌ها را تعیین می‌کند و تنظیم آن لازم است: «به صورت لیست انتخابی»، «به صورت تک انتخابی» یا «به صورت لیستی از دکمه‌ها». این انتخاب، ظاهر تصمیم کاربر را تغییر می‌دهد و جای شرط‌های Gateway را نمی‌گیرد.

برای یک اقدام بی‌شرط نیز می‌توانید شرح ارجاع سفارشی تعریف کنید. پنل خروجی را باز کنید، «استفاده از شرح ارجاع سفارشی» را فعال و نوع و متن شرح را تنظیم کنید. موفقیت، هشدار و خطا نوع نمایش شرح‌اند؛ درج شرح خطا به معنی ایجاد Exception فنی یا فعال‌شدن Error Boundary نیست. وجود پنل «تنظیمات شروط» یا دکمهٔ if نیز به‌تنهایی Gateway را شرطی نمی‌کند؛ باید Condition واقعی تعریف شده باشد.

مقدارهای لازم برای هر عملگر شرط

برای هر شرط، مسیر دادهٔ سمت چپ، عملگر و مقدارهای موردنیاز همان عملگر را تعیین کنید. سمت مقابل نیز می‌تواند مقدار ثابت یا Variable باشد؛ وجود دو Variable در یک مقایسه مجاز است. نوع داده و مسیر خواندن FormData یا ServiceData را با مقدار واقعیِ ثبت‌شده تطبیق دهید.

پس از تعریف اولین شرط، خروجی‌های دیگر را نیز کامل کنید. برای خروجی جایگزین، Sequence Flow را انتخاب و از Change Type آن را به Default تبدیل کنید؛ خالی‌گذاشتن شرط بدون تعیین Default کافی نیست.

دو نوع تصمیم در یک فرآیند مرخصی

یک فرآیند می‌تواند هم Exclusive مبتنی بر Condition داشته باشد و هم Exclusive مبتنی بر Action. محل Gateway و شیوه تنظیم مسیرها تعیین می‌کند کاربر چه رابطی ببیند.

در الگوی سوم، فیلد نتیجه را در گام درخواست‌کننده پنهان و در گام بررسی‌کننده قابل ویرایش کنید. User Task بررسی باید در حالت Edit باشد و خروجی به همان Variable مورد استفاده شرط برگردد. برای فیلد Bit، مقدار جاری 0/1 را مبنا قرار دهید؛ نمایش true/false در تصاویر قدیمی، قرارداد این مثال جاری نیست.

اگر مرحله مدیر را پیش از جانشین اضافه می‌کنید، سه نتیجه «تأیید»، «برگشت برای اصلاح» و «عدم تأیید کامل» را جدا کنید: تأیید به بررسی بعدی، برگشت به درخواست‌کننده و عدم تأیید کامل به End مربوط برسد. با کپی‌کردن User Task، تنظیم‌هایی مانند لغو، ارجاع گروهی و شرح ارجاع نیز نیاز به بازبینی دارند؛ کپی شکل به معنی تنظیم خودکار مسئولیت مرحله جدید نیست.

Parallel؛ اجرای همه شاخه‌ها

Parallel زمانی مناسب است که پس از رسیدن فرآیند به یک نقطه، همه شاخه‌های مشخص‌شده باید اجرا شوند. در مثال مرخصی، بعد از تأیید می‌توان یک کار مشاهده تأییدیه برای درخواست‌کننده و یک کار دیگر برای مدیریت ایجاد کرد. انجام یکی از این کارها، جای انجام دیگری را نمی‌گیرد.

دو نقش Parallel را در طراحی مشخص کنید: Gateway منشعب‌کننده مسیرها را آغاز می‌کند؛ Gateway جمع‌کننده پایان مسیرها را هماهنگ می‌کند. در این الگو، منشعب‌کننده چند خروجی دارد و جمع‌کننده خروجی واحدی برای ادامه مشترک دارد.

ساخت دو شاخه هم‌زمان

1. در محل شروع هم‌زمانی، Gateway از نوع Parallel قرار دهید.
2. خروجی مسیر تأیید را به آن وصل کنید.
3. برای هر کار مستقل یک خروجی جدا رسم کنید؛ مانند مشاهده تأییدیه توسط درخواست‌کننده و مشاهده تأییدیه توسط مدیریت.
4. فرم، حالت نمایش و ورودی داده هر UserTask را تنظیم کنید. اگر فرآیند باید منتظر انجام آن کار بماند، رونوشت را در UserTask غیرفعال کنید؛ رونوشت پس از ارسال، مسیر را بدون انتظار برای ثبت کاربر جلو می‌برد.
5. دریافت‌کنندگان هر کار را با Lane مربوط مشخص کنید.
6. اگر ادامه فرآیند باید پس از پایان همه کارها باشد، یک Parallel دیگر در نقطه جمع‌شدن قرار دهید و خروجی هر کار را به آن وصل کنید.
7. خروجی جمع‌کننده را به گام مشترک بعدی یا End وصل کنید. برای مسیرهای خروجی UserTaskها نیز اقدام روشن، مانند «اتمام از سمت مدیریت» و «اتمام از سمت درخواست‌دهنده»، تعریف کنید.

در Parallel برای انتخاب بین شاخه‌های خروجی شرط نمی‌نویسید؛ همه خروجی‌ها باید ادامه پیدا کنند. اگر شروع یکی از شاخه‌ها اختیاری است، نوع تصمیم را به Inclusive تغییر دهید و شرط آن شاخه را تنظیم کنید.

انتظار برای پایان شاخه‌ها

جمع‌کننده اجازه نمی‌دهد نخستین شاخه تمام‌شده به‌تنهایی ادامه مشترک را جلو ببرد. برای آزمون این رفتار، یکی از کارهای موازی را انجام دهید و وضعیت مسیر مشترک را ببینید؛ سپس کار دیگر را انجام دهید و ادامه بعد از جمع‌کننده را بررسی کنید.

تعداد مسیرهای وصل‌شده به جمع‌کننده را با شاخه‌های طراحی‌شده تطبیق دهید. اتصال یک ورودی اضافه که در اجرای عادی به جمع‌کننده نمی‌رسد، می‌تواند باعث انتظار باقی‌مانده شود. همچنین صرف قرار دادن لوزی جمع‌کننده در بوم کافی نیست؛ همه خطوط ورودی و خط خروجی باید متصل باشند.

نکته — شاخه‌های تودرتو: اگر داخل یکی از مسیرهای موازی دوباره چند شاخه ایجاد می‌کنید، ابتدا شاخه‌های داخلی را در جمع‌کننده مربوط به خودشان به هم برسانید؛ سپس نتیجه آن بخش را به جمع‌کننده مسیرهای بیرونی وصل کنید. به این ترتیب، مرز هر بخش هم‌زمانی در مدل روشن می‌ماند.

تفاوت با رونوشت UserTask

در Parallel، شاخه‌ها فعالیت‌های مستقل مدل هستند؛ می‌توانید برای هرکدام فرم، Lane و ادامه جدا تعیین کنید. تنظیم رونوشت داخل UserTask بخشی از رفتار همان کار است. برای طراحی دو مسیر مستقل که باید پایانشان هماهنگ شود، کارها و اتصال‌های آن‌ها را در بوم مدل کنید.

Parallel: همهٔ خروجی‌ها و سپس همهٔ ورودی‌ها

Parallel Diverging با یک ورودی، همهٔ خروجی‌های متصل را فعال می‌کند. شرطی ارزیابی نمی‌کند و به تنظیم Condition احتیاج ندارد. برای کارهایی از آن استفاده کنید که باید در هر اجرای آن نقطه همگی آغاز شوند؛ اگر بعضی شاخه‌ها فقط با شرط لازم می‌شوند، منطق Inclusive را بررسی کنید.

Parallel Converging برای رسیدن جریان از همهٔ ورودی‌های متصل به خودش منتظر می‌ماند و سپس مسیر مشترک را ادامه می‌دهد. برخلاف Inclusive Converging، انتخاب Gateway مبدأ در پنل آن لازم نیست؛ تعداد ورودی‌های متصل، انتظار را مشخص می‌کند. مسیرهایی را به آن وصل نکنید که در یک اجرای معمول هرگز فعال نمی‌شوند، زیرا انتظار آن ورودی همچنان باقی خواهد ماند.

پس از اصلاح شرط‌های خروجی، پنل هر خروجی را ذخیره و سپس «ذخیره تغییرات» پنل Gateway را نیز انجام دهید تا تنظیم کامل در مدل ثبت شود.

Parallel Gateway: انشعاب و همگرایی

Parallel واگرای مسیرهای موازی را فعال می‌کند. در نمونه، مسیر دریافت Signal و مسیر ارسال Notification هر دو از یک Gateway منشعب می‌شوند. پنل آن عنوان، توضیحات و «تنظیمات رفتارها و عملکردها» دارد و جدول شرط مستقل برای هر خروجی در این نما وجود ندارد.

Parallel همگرا برای پیوستن شاخه‌هاست. رسیدن یک شاخه به آن به معنی کامل شدن همه شاخه‌ها نیست؛ مسیر انتظار Signal در مثال باید نیز به نقطه همگرایی برسد. مدل را طوری طراحی کنید که شاخه مورد انتظار امکان رسیدن داشته باشد و در شاخه‌ای دیگر برای همیشه متوقف یا پایان داده نشود.

Inclusive؛ اجرای شاخه‌های دارای شرط

Inclusive برای انتخاب یک یا چند شاخه از میان خروجی‌ها به‌کار می‌رود. همه شاخه‌های دارای شرط برقرار فعال می‌شوند. برای نمونه، فرم دو انتخاب مستقل دارد: ارسال رونوشت به درخواست‌کننده و ارسال رونوشت به مدیریت. کاربر می‌تواند یکی یا هر دو را انتخاب کند.

تنظیم منشعب‌کننده و شرط‌های مستقل

1. داده تصمیم را در فرم یا گام قبلی آماده و خروجی آن را در متغیر ذخیره کنید.
2. در محل انتخاب شاخه‌ها، Inclusive قرار دهید.
3. برای هر شاخه خروجی مستقل رسم کنید و آن را به کار مربوط وصل کنید.
4. تنظیم شرط هر خروجی را باز کنید و مقدار همان انتخاب را بخوانید.
5. در مثال رونوشت به درخواست‌کننده، فیلد CopyForRequester از داده فرم با true مقایسه می‌شود. برای رونوشت مدیریت، فیلد متناظر خود آن را تنظیم کنید.
6. برای هر شاخه، شرح ارجاع مناسب را در صورت نیاز وارد کنید.
7. رفتار حالت انتخاب‌نشدن هیچ شاخه را با مسیر پیش‌فرض طراحی کنید.

در این الگو، Exclusive انتخاب مناسبی برای اجرای دو شاخه در حالت انتخاب هر دو نیست. Parallel هم انتخاب‌های فرم را نادیده می‌گیرد و همه شاخه‌ها را آغاز می‌کند. Inclusive انتخاب مستقل هر شاخه را حفظ می‌کند.

ارتباط با جمع‌کننده

اگر پس از کارهای انتخاب‌شده ادامه مشترک دارید، در انتهای شاخه‌ها Inclusive جمع‌کننده قرار دهید. خروجی همه شاخه‌های مربوط را به آن متصل کنید؛ سپس خود جمع‌کننده را انتخاب و در فیلد گیت وی مبدا، Gateway منشعب‌کننده همین شاخه‌ها را مشخص کنید. تنظیمات را ذخیره کنید.

جمع‌کننده ادامهٔ شاخه‌هایی را هماهنگ می‌کند که در همان عبور فعال شده‌اند. اگر فقط مسیر درخواست‌کننده فعال باشد، شاخهٔ مدیریتی که ایجاد نشده شرط انتظار نیست؛ اگر هر دو فعال باشند، رسیدن هر دو شاخه به جمع‌کننده لازم است. اگر User Taskهای این شاخه‌ها گزینهٔ «رونوشت» داشته باشند، مسیرشان بدون انتظار برای مشاهدهٔ گیرنده ادامه پیدا می‌کند؛ برای انتظار تا اقدام کاربر، آن‌ها را به‌صورت کار انسانی معمولی تنظیم کنید.

برای حالتی که هیچ رونوشت انتخاب نشده و کار دیگری لازم نیست، خروجی پیش‌فرض منشعب‌کننده را مستقیم به End وصل کنید. این مسیر از جمع‌کننده عبور نمی‌کند، چون هیچ شاخه اختیاری برای انتظار ایجاد نشده است.

منشعب‌کننده و جمع‌کننده متعلق به یک بخش را با هم مرتبط کنید. انتخاب یک Gateway از بخش دیگری از نمودار یا باقی‌ماندن ارتباط قبلی پس از تغییر ساختار، می‌تواند هماهنگی شاخه‌ها را مختل کند.

حفظ دسترسی فیلدهای تصمیم

اگر Checkboxهای رونوشت فقط در مرحله تأیید باید قابل تغییر باشند، دسترسی آن‌ها را در UserTask تنظیم کنید. برای کار مشاهده تأییدیه، این فیلدها را متناسب با نیاز فقط‌خواندنی یا مخفی کنید. سپس اطمینان بگیرید خروجی همان گامی که کاربر انتخاب‌ها را ثبت می‌کند، متغیر مورد استفاده شرط را به‌روز می‌کند.

برای انتخاب‌های بدون ستون جدول، مقدار قبلی با خواندن شناسه رکورد از پایگاه داده برنمی‌گردد. در گام‌های میانی، مقدار فیلد مخفی را از داده فرمِ متغیر قبلی به ورودی همان فیلد بدهید تا ذخیره گام بعدی انتخاب قبلی را با مقدار پیش‌فرض جایگزین نکند. برای مثال انتخاب رونوشت درخواست‌کننده باید هنگام ثبت نظر مدیریت و جانشین حفظ شود.

Inclusive: اجرای همهٔ شرط‌های پذیرفته‌شده

Inclusive Diverging همیشه بر پایهٔ شرط کار می‌کند و حالت Action Based ندارد. در Exclusive، اولین مسیر پذیرفته‌شده انتخاب می‌شود؛ در Inclusive، همهٔ مسیرهایی که شرطشان درست است فعال می‌شوند. برای مثال، یک درخواست ممکن است هم به بررسی مالی و هم به بررسی فنی نیاز داشته باشد؛ هر دو شرط درست می‌شوند و هر دو شاخه پیش می‌روند.

روش ساخت Conditionها همان الگوی تنظیم شرط در Exclusive است. Inclusive نیز می‌تواند Default Sequence Flow داشته باشد، اما Default فقط وقتی انتخاب می‌شود که هیچ‌یک از شرط‌ها پذیرفته نشده باشد. Default را شاخه‌ای تصور نکنید که همراه تمام مسیرهای پذیرفته‌شده اجرا می‌شود.

Inclusive Converging و انتخاب Gateway مبدأ

شاخه‌های فعال‌شده لزوماً هم‌زمان تمام نمی‌شوند: یک شاخه ممکن است فقط Script Task داشته باشد و سریع برسد؛ شاخهٔ دیگر ممکن است منتظر User Task، پیام یا Timer بماند. Inclusive Converging باید منتظر همهٔ شاخه‌های فعال‌شده در همان انشعاب بماند و بعد یک مسیر مشترک را ادامه دهد.

در پنل Converging، گزینهٔ «گیت وی مبدا» را روی Inclusive Diverging متناظر قرار دهید. این ارتباط مشخص می‌کند در آن انشعاب چند خروجی واقعاً پذیرفته شده است. اگر Diverging ده خروجی داشته و دو شرط درست شده‌اند، Converging برای همان دو شاخه منتظر می‌ماند؛ هشت شاخهٔ غیرفعال انتظار تازه‌ای ایجاد نمی‌کنند.

هنگام آزمون، یک داده با تنها یک شرط درست و داده‌ای با چند شرط درست اجرا کنید. در حالت چندشاخه، رسیدن زودتر Script Task نباید گام بعد از Join را پیش از تکمیل شاخهٔ فعالِ منتظر باز کند.

Inclusive Gateway: شروط چند مسیر و انتخاب Gateway مبدأ

Inclusive واگرا می‌تواند با برقرار بودن شروط، یک یا چند مسیر را فعال کند. در پنل، هر خروجی دکمه if… خود را دارد. برخلاف انتخاب انحصاری یک خروجی، چند شرط برقرار می‌توانند چند شاخه بسازند؛ این تفاوت را در طراحی همگرایی لحاظ کنید.

در Inclusive همگرا، «گیت وی مبدأ» را انتخاب کنید. این انتخاب ارتباط همگرایی با انشعابی را مشخص می‌کند که شاخه‌های مربوط را فعال کرده است. عنوان و شناسه Gateway در Dropdown برای تشخیص گزینه درست به کار می‌روند؛ به‌ویژه وقتی چند Inclusive در مدل وجود دارد، تنها به عنوان مشابه اکتفا نکنید.

Complex؛ تصمیم براساس حد نصاب اقدامات

Complex برای تصمیم گروهی به‌کار می‌رود. در مثال جذب نیرو، اعضای کارگروه اطلاعات شخص را بررسی می‌کنند و اقدام خود را ثبت می‌کنند. Gateway سهم هر اقدام را با حد نصاب آن مقایسه می‌کند؛ اگر تأیید به حد نصاب برسد، پرونده به ریاست می‌رود و در نتیجه بررسی مجدد، به ثبت اطلاعات برمی‌گردد.

آماده‌سازی کار رأی‌دهی

1. UserTask بررسی را در Lane اعضای کارگروه قرار دهید و دریافت‌کنندگان را مشخص کنید.
2. فرم و داده ورودی را تنظیم کنید تا اعضا همان پرونده موردنظر را ببینند.
3. در تنظیمات UserTask، تفکیک ارجاع براساس اقدام را فعال کنید.
4. برای سناریویی که ثبت هر اقدام باید وارد محاسبه شود، گزینه براساس هر اقدام را انتخاب کنید.
5. Complex را بعد از UserTask قرار دهید و مسیرهای نتایج را به مقصدهای مربوط وصل کنید.
6. در تنظیمات Complex، UserTask مبدأ رأی‌دهی را انتخاب کنید.

UserTask مبدأ و Lane آن جزئی از تعریف رأی‌گیری هستند. انتخاب افراد یا نقش‌ها تعیین می‌کند تصمیم گروهی از چه جامعه‌ای جمع‌آوری شود. اگر یک کاربر در چند نقش انتخاب‌شده عضو است یا تنظیم اولین کاربر از نقش را تغییر می‌دهید، نتیجه شمارش را همراه تنظیمات Task و Lane بررسی کنید؛ تعریف حد نصاب را جدا از دریافت‌کنندگان در نظر نگیرید.

تنظیم حد نصاب هر اقدام

1. تنظیمات Sequenceهای Complex را باز کنید.
2. ردیف اقدام موردنظر، مانند «تأیید»، را انتخاب کنید.
3. تنظیمات اقدام را باز کنید.
4. عملگر مقایسه سهم اقدام با حد نصاب را انتخاب کنید.
5. روش مقداردهی حد نصاب را تعیین کنید: مقدار ثابت، متغیر یا تابع.
6. مقدار یا منبع آن را وارد و تنظیمات را ذخیره کنید.
7. برای سایر نتایج نیز قاعده لازم را تکمیل کنید.

مثال — حد نصاب در کارگروه سه‌نفره: حد نصاب درصد است. برای مثال «بزرگ‌تر یا مساوی ۵۰» یعنی سهم اقدام تأیید باید دست‌کم به نصف جامعه رأی‌دهی برسد؛ عدد ۵۰ به معنای دریافت ۵۰ رأی نیست. در کارگروه سه‌نفره، سهم هر فرد تقریباً یک‌سوم است و دو رأی تأیید از حد نصاب ۵۰ درصد عبور می‌کنند. می‌توانید برای «بررسی مجدد» هم حد نصاب جدا تعریف کنید؛ در نمونه متقارن، این نتیجه نیز بزرگ‌تر یا مساوی ۵۰ درصد است.

رفتار هنگام دریافت رأی

پس از ثبت هر اقدام در حالت مربوط، شرط‌های Complex بررسی می‌شوند. تا زمانی که هیچ نتیجه‌ای به قاعده تعیین‌شده نرسیده باشد، مسیر نتیجه انتخاب نمی‌شود و رأی‌های بعدی می‌توانند محاسبه را کامل کنند. هنگامی که یک نتیجه پذیرفته شود، فرآیند از خروجی همان نتیجه ادامه می‌یابد و کار رأی‌دهی باقی‌مانده برای آن دور از کارتابل دیگر اعضا خارج می‌شود.

براساس آخرین اقدام در تنظیم UserTask، زمان محاسبه نتیجه را تغییر می‌دهد. در کارگروه سه‌نفره با حد نصاب ۵۰ درصد، حتی پس از دو رأی تأیید، نفر سوم باید اقدام خود را ثبت کند؛ سپس نتیجه از مجموع آرا محاسبه می‌شود. اگر رأی سوم «بررسی مجدد» باشد، دو رأی تأیید همچنان حد نصاب را دارند. این رفتار با Exclusive پس از کار چندنفره، که اقدام نهایی مسیر را تعیین می‌کند، متفاوت است.

رأی‌گیری با دریافت‌کنندگان مبتنی بر نقش

اگر Lane سه نقش داشته باشد و اولین کاربر از نقش غیرفعال باشد، سهم آرا از تعداد کاربران دریافت‌کننده محاسبه می‌شود. در نمونه سه نقش با ۲، ۲ و ۳ عضو، هفت رأی‌دهنده داریم؛ سهم هر رأی تقریباً ۱۴٫۲۸ درصد است و رسیدن به نصف آرا دست‌کم چهار رأی هم‌جهت می‌خواهد. تعداد نقش‌ها را به جای تعداد رأی‌دهندگان در مخرج محاسبه نگذارید.

با فعال‌کردن اولین کاربر از نقش، هر نقش یک واحد رأی خواهد داشت. نخستین عضو هر نقش که اقدام کند، رأی آن نقش را ثبت می‌کند و کار از کارتابل سایر اعضای همان نقش خارج می‌شود. در مثال سه نقش، هر نقش تقریباً یک‌سوم وزن را دارد؛ تعداد اعضای نقش وزن آن را بیشتر نمی‌کند.

زمان تصمیم همچنان تابع هر اقدام/آخرین اقدام است: با براساس هر اقدام، دو نقش با رأی هم‌جهت می‌توانند حد نصاب ۵۰ درصد را کامل کنند؛ با براساس آخرین اقدام، هر سه نقش باید رأی بدهند و سپس نتیجه محاسبه می‌شود. جزئیات تنظیم دریافت‌کنندگان و تفکیک اقدامات در Taskها و Activityها آمده است.

حد نصاب هر اقدام را براساس تصمیم موردنظر تعیین کنید. حد نصاب تأیید و بررسی مجدد لازم نیست همیشه یکسان باشد؛ برای نتیجه‌ای که باید با نخستین رأی مخالف مسیر را برگرداند، حد نصاب آن اقدام باید متناسب با سهم یک رأی تعیین شود.

Complex Gateway: User Task مبدأ و تفکیک ارجاع

Complex Gateway محاسبه Actionها را به User Task مبدأ مرتبط می‌کند. در پنل، ابتدا «Usertask مبدأ» را انتخاب کنید، سپس «تنظیمات Gateway» را باز کنید. فهرست مبدأ نام و شناسه Activityها را نشان می‌دهد تا User Task صحیح قابل تشخیص باشد.

در User Task مبدأ، تنظیم «تفکیک ارجاع براساس اقدام» و حالت «براساس هر اقدام» برای تفکیک پاسخ‌ها معنا دارد. «اولین کاربر از نقش» نیز تعیین می‌کند رسیدگی در سطح نقش چگونه محدود شود. پیکربندی این دو را با تعداد اقدام‌کنندگان موردنظر هماهنگ کنید؛ رأی نقش و رأی تک‌تک کاربران را یکی ندانید.

در تنظیمات شروط Complex، درصد اقدام‌کنندگان برای Actionها با مقادیر ۱ تا ۱۰۰ بیان می‌شود. شرط‌های نمونه ۳۰ و ۷۰ را در همین قرارداد تفسیر کنید. روش تعیین جمعیت مبنا در ترکیب‌های چندنقشی و اولویت هنگام برقرار شدن هم‌زمان چند شرط، باید با سناریوی واقعی و تنظیم ارجاع تطبیق داده شود؛ برای حالت‌های فاقد شاهد اجرایی، تأیید فنی لازم است.

Complex Gateway برای تصمیم بر پایهٔ اقدام کاربران

Complex Gateway در GraphBPMS برای تصمیم‌گیری بر اساس اقدام‌های یک User Task به کار می‌رود؛ برای مثال، رأی‌گیری با اقدام‌های «تأیید» و «انصراف». این Gateway پس از User Task معنا دارد. شرط‌های آن دربارهٔ نتیجهٔ اقدام‌ها و درصد/تعداد آن‌هاست؛ جای یک Gateway شرطی عمومی پس از Service Task یا Gateway دیگر را نمی‌گیرد.

در «Usertask مبداء»، User Task موردنظر را انتخاب کنید. این انتخاب الزامی است و سپس تنظیمات Gateway برای تعریف قواعد در دسترس قرار می‌گیرد. فهرست، نام و شناسهٔ Element را کنار هم نشان می‌دهد؛ اگر چند Task هم‌نام دارید، شناسه را برای انتخاب صحیح بررسی کنید.

تعداد رأی‌ها از چه چیزی به دست می‌آید؟

پیش از تعیین درصد، مشخص کنید چه کسی حق اقدام دارد. تنظیم Lane، روش ارجاع User Task و گزینهٔ «اولین کاربر از نقش» تعداد واحدهای رأی را تعیین می‌کنند. تعداد کل حساب‌های عضو یک نقش همیشه با تعداد رأی‌های لازم یکسان نیست.

برای مثال، اگر پنج نقش مجازند و «اولین کاربر از نقش» فعال است، پنج واحد رأی دارید؛ نخستین اقدام معتبر از هر نقش سهم آن نقش را پوشش می‌دهد، حتی اگر هر نقش صدها کاربر داشته باشد. اگر کاربران را به روش دیگری مخاطب قرار داده‌اید، تعداد واجدان اقدام را مطابق همان تنظیم واقعی محاسبه کنید.

درصد را روی همین مجموعهٔ واجدان اقدام بسنجید. شرط نمونهٔ تأیید بزرگ‌تر یا مساوی ۷۰ درصد است؛ برای ده واحد رأی، هفت تأیید به این آستانه می‌رسد. آستانه می‌تواند مقدار ثابت یا مقدار خوانده‌شده از Variable باشد. عملگر «بزرگ‌تر» با «بزرگ‌تر یا مساوی» یک نتیجه ندارد؛ مرز شرط را عمداً انتخاب کنید.

ارزیابی بعد از هر اقدام یا پس از آخرین اقدام

در User Task مبدأ، زمان ارزیابی را با روش تفکیک ارجاع هماهنگ کنید. در حالت «براساس هر اقدام»، هر Submit معتبر باعث ارزیابی دوبارهٔ قواعد Complex می‌شود. اگر آستانهٔ مسیر برقرار شد، فرآیند می‌تواند پیش از پاسخ همهٔ افراد ادامه پیدا کند.

در مثال ده رأی با آستانهٔ ۷۰ درصد، پس از هفت تأیید ممکن است مسیر تأیید باز شود. در این حالت انتظار نداشته باشید سه نفرِ هنوز اقدام‌نکرده حتماً رأی، توضیح یا داده‌ای در همان انتظار ثبت کرده باشند؛ عبور زودهنگام با جمع‌آوری کامل نظر همه افراد یکسان نیست. این توضیح به معنی حذف لاگ رأی‌های قبلاً ثبت‌شده نیست.

در حالت «براساس آخرین اقدام»، ابتدا همهٔ واحدهای واجد اقدام باید پاسخ دهند و سپس قواعد ارزیابی می‌شوند. این روش برای جمع‌آوری کامل اقدام‌های موردانتظار مناسب است، اما حتی اگر نتیجه عددی پس از هفت پاسخ روشن باشد، تا اقدام نفر آخر منتظر می‌ماند. اگر آن فرد کارتابل خود را باز نکند، فرآیند در انتظار باقی می‌ماند.

Complex Gateway: انتخاب شروط و وزن Actionها

برای Complex Gateway ابتدا User Task مرتبط را انتخاب کنید و تنظیمات Actionهای مسیر را باز کنید. در پنجره «تنظیمات Sequence»، هر Action می‌تواند قاعده محاسباتی داشته باشد و سامانه بر اساس تعداد اقدام‌کنندگان، یکی از مسیرها را انتخاب می‌کند. جدول شامل نام اقدام، عملگر، نوع ورودی و مقدار ورودی است.

در مثال، دو Action «انصراف» و «تأیید» با عملگر «بزرگ‌تر مساوی باشد» و نوع ورودی «مقدار ثابت» دیده می‌شوند؛ مقادیر به‌ترتیب ۳۰ و ۷۰ هستند. ردیف «تأیید» انتخاب شده است. دکمه «تنظیمات اقدام»، جستجو، فیلتر ستون‌ها، Checkbox انتخاب ردیف، «ذخیره» و «بستن» اجزای همین صفحه‌اند.

مرز مساوی در حد نصاب رأی

عملگر را با تعداد رأی‌دهندگان آزمون کنید. در کارگروه سه‌نفره، دو رأی هم‌جهت حدود ۶۶٫۶۷ درصد است و هر دو شرط «بزرگ‌تر از ۵۰» و «بزرگ‌تر یا مساوی ۵۰» را می‌پذیرد. این آزمون تفاوت دو عملگر را آشکار نمی‌کند. در کارگروه چهار‌نفرهٔ هم‌وزن، دو رأی دقیقاً ۵۰ درصد است؛ شرط دوم برقرار و شرط اول هنوز برقرار نیست.

مخرج این مثال، کل چهار رأی‌دهندهٔ لازم است. اگر رأی بر اساس «اولین کاربر از نقش» محاسبه می‌شود، واحد رأی را مطابق نقش‌های دریافت‌کننده تعیین کنید و سپس همین آزمون مرزی را انجام دهید. سهم اقدام‌های متفاوت را با هم جمع نکنید؛ یک تأیید و یک بررسی مجدد، دو رأی تأیید نیست.

مرز Complex Converging در این موتور

در رفتار توضیح‌داده‌شدهٔ GraphBPMS، Complex Diverging فقط یک Sequence خروجی را برای ادامه انتخاب می‌کند. بنابراین Complex Converging، مشابه همگرایی Exclusive، برای انتظار شاخه‌های موازیِ همین تصمیم کاربرد اجرایی ندارد و در این سامانه استفاده نمی‌شود. این قاعده مربوط به موتور GraphBPMS است؛ برای هماهنگ‌کردن چند شاخهٔ واقعاً فعال، نوع Gateway را مطابق منطق انشعاب همان مدل انتخاب کنید.

بررسی نتیجه تصمیم و رفع اشکال

پس از ذخیره فرآیند و فعال‌کردن نسخه موردنظر، چند درخواست آزمایشی با داده متفاوت اجرا کنید. برای Exclusive، حداقل یک نمونه از هر مسیر و یک نمونه از مسیر پیش‌فرض را بررسی کنید. برای Inclusive، حالت انتخاب یک، هر دو و هیچ شاخه را بسنجید. برای Parallel، کارها را با ترتیب متفاوت تمام کنید. برای Complex، رأی‌ها را با کاربران واقعی دریافت‌کننده ثبت کنید و رسیدن یا نرسیدن به حد نصاب را ببینید.

برای دنبال‌کردن مسیر اجرا و گام‌های انجام‌شده از کارتابل سوابق استفاده کنید. کارهای باقی‌مانده هر گیرنده را در کارتابل ورودی بررسی کنید.