/
/
/
/
استودیو — Taskها و Activityها
Task مشخص می‌کند در یک نقطه از فرآیند چه کاری انجام شود: کاربر فرمی را تکمیل کند، یک منبع داده اجرا شود، محاسبه‌ای انجام شود، فرآیند دیگری فراخوانی شود یا اجرای جاری منتظر پاسخ بیرونی بماند. اتصال شکل‌ها فقط ترتیب حرکت را تعیین می‌کند؛ برای قابل استفاده شدن هر گام باید نوع آن، داده‌های ورودی و خروجی و تنظیمات اختصاصی‌اش مشخص باشد.
گیرنده کار انسانی از Lane تعیین می‌شود. تصمیم درباره مسیر بعدی می‌تواند به اقدام کاربر یا شرط‌های Gateway وابسته باشد. تنظیمات این دو بخش در Pool و Lane و Gatewayها آمده است؛ این مقاله تنظیماتی را توضیح می‌دهد که در خود Task و ارتباط آن با فرم، متغیر و اقدام انجام می‌شوند.
انتخاب و تنظیم نوع گام
| کار مورد نیاز | نوع گام | نتیجه مورد انتظار |
|---|---|---|
| دریافت، ویرایش یا نمایش داده به کاربر | User Task | فرم با تنظیمات همان گام باز می‌شود و کاربر آن را ثبت یا اقدام مجاز را انتخاب می‌کند. |
| محاسبه، خواندن یا تغییر داده از طریق منبع داده | Service Task | منبع داده با ورودی‌های فرآیند اجرا می‌شود و مسیر خودکار ادامه می‌یابد. |
اجرای منطق محاسباتی با JavaScript یا C# |
Script Task | اسکریپت اجرا و در صورت تنظیم، نتیجه در متغیر نگهداری می‌شود. |
| سپردن بخشی از کار به فرآیند دیگری و ادامه پس از پایان آن | Call Activity | فرآیند مقصد از نقطه شروع انتخاب‌شده اجرا می‌شود و خروجی تعریف‌شده به والد برمی‌گردد. |
| ثبت یک انتظار و ادامه دادن آن با فراخوانی بیرونی | Receive Task | ابتدا منبع داده گام اجرا می‌شود؛ سپس نمونه در انتظار ادامه می‌ماند. |
| واگذاری کار محدود به ابزار همراه در میانه فرآیند | Graph Mobile Task | کارهای همراه به نمونه جاری متصل می‌شوند و پس از اتمام، نتیجه به همان نمونه برمی‌گردد. |
برای ایجاد گام، شکل Activity را روی بوم قرار دهید یا از منوی افزودن کنار عنصر قبلی استفاده کنید. سپس منوی تغییر نوع عنصر را باز کنید و نوع مورد نیاز را انتخاب کنید. شکل عمومی Task را به عنوان یک گام آماده اجرا رها نکنید.
- گام را داخل Lane مربوط قرار دهید و اتصال ورودی و خروجی آن را رسم کنید.
- عنوانی بنویسید که کار گام را روشن کند؛ مانند ثبت درخواست، محاسبه مدت یا دریافت نظر مدیر.
- پنل تنظیمات را باز کنید. عنوان و توضیحات گام با نام متغیر خروجی یا عنوان اجرای فرآیند یکسان نیستند.
- تنظیمات اختصاصی نوع گام را تکمیل کنید.
- اگر خروجی در گام دیگری لازم است، متغیر مقصد را مشخص کنید.
- ذخیره تغییرات پنل را بزنید و سپس کل فرآیند را از نوار ابزار ذخیره کنید. تأیید یک پنجره تنظیمات، جای ذخیره کل نمودار را نمی‌گیرد.
برای استفاده از فرآیند دیگر، Call Activity را انتخاب کنید؛ سپس فرآیند مقصد و نقطه شروع آن را تعیین کنید.
در استفاده از فرآیند دیگر، Call Activity را از Sub-process تشخیص دهید. تنظیم «فرآیند مقصد» و «نقطه شروع» متعلق به Call Activity است. یک نام یا نماد استاندارد BPMN به‌تنهایی قرارداد اجرایی گام را تعیین نمی‌کند.
Business Rule Task و اعتبارسنجی DMN
Business Rule Task امکان انتخاب DMN موجود یا ایجاد DMN جدید را دارد. پس از انتخاب مدل، Decision، ورودی‌های آن و متغیر خروجی را تعیین کنید. ذخیره پنل به انتخاب DMN، انتخاب Decision، مقداردهی همه پارامترهای ارائه‌شده و انتخاب متغیر خروجی نیاز دارد؛ حالت بدون خروجی را به این گام تعمیم ندهید. مجوز استفاده از مدل DMN نیز لازم است. نتیجه تصمیم به ServiceData تبدیل می‌شود و مسیر خودکار ادامه می‌یابد.
متغیرها و مسیر خواندن داده
متغیر را پیش از مصرف تعریف کنید
از مدیریت متغیرهای فرآیند، متغیری با عنوان قابل فهم و نام مشخص بسازید. عنوان در انتخاب‌گرها به کاربر کمک می‌کند؛ نام برای ارجاع به داده استفاده می‌شود. برای مثال، عنوان اطلاعات درخواست ثبت‌شده می‌تواند به متغیر @@SavedData مربوط باشد.
متغیر باید در مسیر اجرا پیش از مصرف مقدار گرفته باشد. تعریف @@SavedData به‌تنهایی داده فرم را در آن قرار نمی‌دهد؛ در UserTask تولیدکننده، خروجی را روی متغیر بگذارید و همین متغیر را انتخاب کنید. در گام بعد از آن بخوانید.
اگر چند گام در یک متغیر خروجی بنویسند، خواندن معمول آن متغیر آخرین مقدار ثبت‌شده را دریافت می‌کند. مقدارهای قبلی را با مقدار جاری اشتباه نگیرید. برای نگه‌داشتن مستقل درخواست اولیه و نتیجه بررسی، دو متغیر جدا تعریف کنید؛ برای انتقال آخرین وضعیت یک درخواست، استفاده مجدد از یک متغیر می‌تواند مناسب باشد.
متغیرهای سیستمی نیز در انتخاب‌گر قرار دارند؛ از جمله شماره فرآیند، شماره ایجاد فرآیند، کاربر فعلی، سمت فعلی، شماره رکورد فعلی فرم و شماره گام جاری. این شناسه‌ها قابل جایگزینی با یکدیگر نیستند. شماره ایجاد فرآیند یک اجرای مشخص را نشانه می‌گیرد؛ شماره تعریف فرآیند مدل ذخیره‌شده را مشخص می‌کند.
خروجی فرم با خروجی سرویس یک ساختار ندارد
وقتی خروجی یک فرم معمولی ثبت می‌شود، اطلاعات رکورد و داده فرم در یک ظرف داده قرار می‌گیرند. ساختار زیر برای توضیح نام اجزاست و شناسه‌ها و فیلدهای آن نمونه‌اند:
{
"FormID": 42,
"FormData": "{\"Id\":42,\"RequestTitle\":\"خرید تجهیزات\",\"ManagerID\":7}"
}
در نمونهٔ خروجی فرم، مقدار FormID با FormData.Id برابر است. این برابری نمونه برای نتیجه‌گیری دربارهٔ همهٔ قراردادها کافی نیست؛ شناسهٔ تعریف Form را از شناسهٔ Record جدا نگه دارید. برای بازکردن رکورد مشخص، مسیر صریح FormData['Id'] و مقدار واقعی آن را بررسی کنید. FormData می‌تواند Object یا در برخی قراردادها رشتهٔ JSON باشد.
خروجی جدولی سرویس معمولاً به صورت ServiceData مصرف می‌شود. برای مثال:
{
"ServiceData": [
{"Id": 10, "FirstName": "Sara", "RoleID": 3},
{"Id": 11, "FirstName": "Ali", "RoleID": 5}
]
}
در این ساختار دو سطر وجود دارد. Index سطر اول 0 و سطر دوم 1 است. انتخاب تمام داده با انتخاب یک ستون از یک سطر تفاوت دارد.
انتخاب ساده یا پیشرفته
| هدف | نمونه مسیر | حاصل |
|---|---|---|
| شناسه رکورد خروجی یک فرم | @@SavedData در حالت ساده |
در قرارداد نمونه برای تعیین Id استفاده شده است؛ مقدار واقعی را کنترل و برای رفع ابهام مسیر صریح FormData['Id'] را بررسی کنید. |
| یک فیلد از خروجی فرم | @@SavedData:FormData['ManagerID'] |
مقدار ManagerID در داده فرم. |
| همه فیلدهای خروجی فرم | @@SavedData:FormData |
محتوای داخلی فرم. |
| اولین مقدار خروجی یک سرویس | @@LookupData در حالت ساده |
اولین ستون اولین سطر؛ فقط وقتی همان مقدار مورد نیاز است استفاده کنید. |
| ستون مشخص از سطر اول سرویس | @@LookupData:ServiceData[0]['RoleID'] |
RoleID سطر اول. |
| ستون مشخص از سطر دوم سرویس | @@LookupData:ServiceData[1]['FirstName'] |
FirstName سطر دوم. |
| همه سطرهای سرویس | @@LookupData:ServiceData |
کل مجموعه داده سرویس؛ مناسب تغذیه زیر‌فرم با ساختار سازگار. |
برای تنظیم مسیر در پنجره مقدار اولیه یا پارامتر، متغیر را انتخاب کنید، متغیر منبع را مشخص کنید و روش پیشرفته را بگذارید. سپس منبع داده را روی FormData یا ServiceData قرار دهید. در ServiceData، Index سطر را تعیین کنید و نام فیلد را در مسیر وارد کنید. با انتخاب همه داده‌ها به مسیر یک فیلد یا Index یک سطر نیاز ندارید.
نام فیلد را از خروجی واقعی منبع داده یا نام فنی کنترل فرم بردارید. عنوان نمایشی نام کاربر ممکن است با نام فنی UserTitle یا FullName متفاوت باشد. حروف بزرگ و کوچک و املای مسیر را حفظ کنید.
خواندن JSON رشته‌ای داخل یک فیلد
گاهی مقدار یک ستون، خودش متنی شامل JSON است. برای مثال:
{
"ServiceData": [
{"Detail": "{\"Age\":30,\"City\":\"Tehran\"}"}
]
}
در این حالت، پس از رسیدن به Detail از جداکننده * برای ورود به JSON رشته‌ای استفاده کنید:
@@LookupData:ServiceData[0]['Detail']*['Age']
این مسیر ابتدا سطر اول، سپس Detail و بعد Age داخل آن را می‌خواند. * را به همه مسیرهای تو‌در‌تو اضافه نکنید؛ کاربرد آن وقتی است که مقدار میانی رشته JSON باشد. برای تشخیص مسیر، نمونه خروجی را با همان ساختار واقعی بررسی کنید.
شناسه‌هایی که نباید با هم جایگزین شوند
| شناسه | چه چیزی را مشخص می‌کند؟ |
|---|---|
| شناسهٔ تعریف فرم | فرم طراحی‌شده و ساختار فیلدهای آن؛ انتخاب همان فرم در دو گام، به‌تنهایی رکورد مشترک ایجاد نمی‌کند. |
| شناسهٔ رکورد فرم | دادهٔ ذخیره‌شدهٔ یک درخواست در آن فرم؛ ورودی Id گام ویرایش باید به این رکورد برسد. |
| شناسهٔ نسخهٔ فرآیند | یک نسخهٔ مشخص از طراحی. |
| شناسهٔ گروه فرآیند | خانواده‌ای که نسخه‌های طراحی در آن قرار دارند. |
| ProcessCreationID | نمونهٔ اجرایی ایجادشده از فرآیند. |
| ReferenceID / LastRefID | ارجاع یا گام جاری/آخرین ارجاع در قرارداد همان عملیات؛ با شناسهٔ نمونه جایگزین نمی‌شود. |
| شناسهٔ عنصر روی مدل | عنصر طراحی در بوم؛ الزاماً همان شناسهٔ عددی نود در گزارش‌های اجرا نیست. |
نام FormID را بدون بررسی قرارداد با شناسهٔ تعریف فرم یا Record یکی نگیرید. نمونهٔ آموزشی برای FormID و Id مقدار یکسان دارد؛ در مصرف‌کننده از مسیر صریح و نتیجهٔ واقعی Variable Log استفاده کنید. اگر FormData رشتهٔ JSON است، ادامهٔ مسیر باید تبدیل رشته را نیز در نظر بگیرد.
UserTask؛ اتصال فرم و انجام کار انسانی
آماده‌سازی فرم و اتصال آن
اگر Form در انتخاب‌گر User Task دیده نمی‌شود، وضعیت «ثبت فرم در فرآیند» را در فرم‌ساز بررسی کنید. راهنمای تصویری آماده‌سازی و انتخاب حالت فرم در بخش تنظیمات جاری User Task همین مقاله آمده است.
تنظیمات فیلدها در UserTask به استفاده از فرم در همان گام مربوط‌اند. می‌توانید یک فرم را در گام ثبت قابل ویرایش و در گام بررسی فقط‌خواندنی نمایش دهید، بدون آنکه برای هر گام یک فرم تازه بسازید.
اگر ساختار فرم را تغییر داده‌اید، پنجره تنظیمات فیلدها را در UserTaskهای استفاده‌کننده دوباره باز کنید، فیلدهای جدید و قدیمی را بررسی کنید و تنظیمات را ذخیره کنید. به‌خصوص پس از افزودن فیلد، صرف قرار داشتن گام در حالت نمایش را جای بازخوانی تنظیمات فیلدهای جدید نگذارید. هنگام تغییر فرم انتخابی نیز فیلدهای منسوخ فرم قبلی و مقداردهی Id را بازبینی کنید.
انتخاب حالت فرم و تعیین رکورد
برای گام ویرایش یا نمایش، Id باید رکورد مورد نظر را مشخص کند. برای استفادهٔ گام‌های بعد، خروجی گام ثبت را در Variable نگه دارید؛ انتخاب حالت Form به‌تنهایی دادهٔ میان گام‌ها را منتقل نمی‌کند.
برای ساخت مسیر ثبت سپس بررسی همان درخواست:
- در UserTask ثبت، فرم را انتخاب و حالت را جدید کنید.
- در تنظیمات خروجی، متغیر و سپس
@@SavedDataرا انتخاب کنید. - در UserTask بعدی همان فرم را انتخاب کنید و حالت را ویرایش یا نمایش بگذارید.
- تنظیمات فیلدها را باز کنید و سطر کلیدی
Idرا انتخاب کنید. - مقدار اولیه Id را از متغیر
@@SavedDataدر حالت ساده بخوانید. - تنظیمات پنجره، تنظیمات Task و کل فرآیند را ذخیره کنید.
در این مثال شناسهٔ Record لازم است. اگر قرارداد حالت ساده در محیط شما همین شناسه را برگرداند می‌توان آن را به Id داد؛ برای رفع ابهام، مقدار و مسیر صریح FormData['Id'] را بررسی کنید. برای گیرندهٔ Lane، شناسهٔ رکورد معمولاً گیرنده نیست و باید فیلد کاربر یا نقش، مانند FormData['ManagerID']، خوانده شود.
تنظیم رفتار فیلدها در هر گام
در تنظیمات فیلدها، فیلد مورد نظر را انتخاب و تنظیمات فیلد را باز کنید. جدول امکان دیدن وضعیت چند فیلد را کنار هم می‌دهد. برای اعمال تنظیم مشترک، فیلدهای سازگار را انتخاب کنید؛ نوع فیلد و تنظیمات پایه فرم می‌توانند گزینه‌های قابل تغییر را محدود کنند.
| تنظیم | روش استفاده |
|---|---|
| نمایش | برای حذف فیلد از نمای همین گام خاموش کنید. پنهان بودن فیلد به معنی حذف مقدار آن از داده نیست. |
| اجباری (در فرم) | برای نیاز به ورود مقدار فعال کنید؛ الزام تعریف‌شده در خود فرم را نیز در نظر بگیرید. |
| فقط خواندنی | مقدار دیده می‌شود ولی کاربر آن را ویرایش نمی‌کند. برای نمایش مقدار ثبت‌شده در گام بررسی مناسب است. |
| فعال | امکان تعامل با کنترل را تعیین می‌کند. غیرفعال کردن با پنهان کردن یکسان نیست. |
| مقدار پیش‌فرض | منبع مقدار اولیه را از ثابت، متغیر یا تابع مشخص می‌کند. |
| فیلتر | در زیر‌فرم‌های قابل فیلتر، ردیف‌هایی را تعیین می‌کند که در این گام به فرم داده می‌شوند. |
| نمایش در جدول فیلد تو‌در‌تو | حضور فیلد فرزند را در جدول زیر‌فرم کنترل می‌کند. |
برای نمونه، فیلد درخواست‌دهنده می‌تواند در گام ثبت از کاربر فعلی مقدار بگیرد و از دید کاربر پنهان باشد. در گام بررسی همان مقدار با نمایش فعال و فقط‌خواندنی نشان داده می‌شود. اگر فیلد یک SelectBox است، مقدار ذخیره‌شده باید با فیلد مقدار منبع داده، مانند UserID، سازگار باشد؛ عنوان نمایشی مانند UserTitle فقط برای نمایش به کاربر است.
محدودیت‌ها و ابزارهای تنظیم فیلد User Task
انتخاب گروهی فیلدهایی با نوع متفاوت برای تنظیم مشترک می‌تواند رد شود. در حالت Add، اگر تنظیمات فیلدها ثبت نشده باشد، پیشنهاد استفاده از تنظیمات پایهٔ فرم ممکن است نمایش داده شود؛ رد پیشنهاد به معنی ذخیرهٔ تنظیمات نیست. گزینه‌های قابل تغییر به نوع کنترل و حالت Form وابسته‌اند. جزئیات ابزارها و امکانات جدول در بخش تصویری تنظیمات جاری فیلد و SubForm آمده است.
در تنظیمات SubForm، ورود Excel، حذف تکی/گروهی، ویرایش در Popup یا داخل جدول، درج در Popup یا داخل جدول، صفحه‌بندی، جستجو، فیلتر و خروجی Excel به‌صورت گزینه‌های جدا مطرحاند. گزینه‌های قابل نمایش به نوع کنترل و حالت فرم وابسته‌اند. در حالت Add کنترل فیلتر SubForm در نسخه مستندشده مخفی است. تب فعال نیز تنظیم جداگانه دارد.
مقدار اولیه و مقدار موجود
مقدار پیش‌فرض را به عنوان فرمان بازنویسی همیشگی داده در نظر نگیرید. در ویرایش یا نمایش رکورد، مقدار غیرخالی موجود با مقدار اولیهٔ گام جایگزین نمی‌شود؛ وقتی فیلد خالی باشد، مقدار اولیهٔ تنظیم‌شده می‌تواند آن را تأمین کند. در حالت جدید بدون Id مبدأ، دادهٔ رکورد قبلی برای مقداردهی اولیه وجود ندارد. اگر Id مبدأ داده‌اید، حالت جدید از دادهٔ همان رکورد برای Clone استفاده می‌کند و هنگام ثبت، رکورد تازه می‌سازد.
برای ساخت درخواست تازه از دادهٔ درخواست قبلی، حالت «جدید» را انتخاب کنید. در Form غیر Tableless می‌توانید Id رکورد منبع را بدهید تا دادهٔ آن برای پرکردن اولیهٔ Form استفاده شود؛ ثبت، رکورد تازه با Id تازه می‌سازد و منبع را Update نمی‌کند. روش دیگر، مقداردهی جداگانهٔ فیلدهای لازم از FormData بدون دادن Id منبع است. اگر هدف تغییر همان درخواست است، حالت «ویرایش» و Id همان رکورد را انتخاب کنید؛ دادهٔ موجود از جدول Form خوانده و ثبت روی همان Record اعمال می‌شود.
برای مقدار ثابت، مقدار اولیه ثابت را انتخاب و مقدار را وارد کنید. برای داده گام قبلی، متغیر را انتخاب و مسیر FormData مناسب را بسازید. برای خروجی منبع داده، ServiceData و سطر/ستون یا همه داده‌ها را انتخاب کنید.
اگر فرم قواعد نمایشی یا عملیات بارگذاری داده دارد، اثر آنها را نیز در نظر بگیرید. داده‌ای که بعداً در مرورگر بارگذاری می‌شود، ممکن است نمای آماده‌شده اولیه را تغییر دهد؛ برای داده‌ای که باید پیش از نمایش از سمت فرآیند فیلتر شود، روش بخش بعد را به کار ببرید.
تأمین داده و فیلتر زیر‌فرم
برای نمایش سابقه یا فهرست مرتبط با درخواست، می‌توانید خروجی ServiceTask را به زیر‌فرم بدهید. نام فیلدهای هر سطر خروجی باید با نام فنی ستون‌های زیر‌فرم مقصد سازگار باشد. انتخاب همه داده‌ها تبدیل خودکار نام ستون‌ها انجام نمی‌دهد.
- پیش از UserTask، ServiceTask دریافت داده را قرار دهید.
- ورودی‌های سرویس، مانند شناسه کاربر درخواست‌دهنده، را از متغیر مناسب تأمین کنید.
- خروجی سرویس را در متغیری مانند
@@PastReqVacationsذخیره کنید. - در تنظیمات فیلدهای UserTask، خود فیلد والد زیر‌فرم را انتخاب کنید.
- مقدار اولیه را از متغیر، پیشرفته، منبع ServiceData و همه داده‌ها بگذارید. مسیر حاصل در این مثال
@@PastReqVacations:ServiceDataاست. - در صورت نیاز، تنظیمات فیلتر SubForm را باز کنید؛ فیلد، عملگر و مقدار شرط را تعیین و ذخیره کنید.
- نمایش و قابلیت ویرایش ستون‌های فرزند را جداگانه بررسی کنید.
برای نمونه، درخواست‌دهنده می‌تواند همه سوابق خود را ببیند و مدیر فقط ردیف‌هایی را ببیند که تأیید برابر ۱ دارند. شرط گام مدیر را روی گام درخواست‌دهنده کپی نکنید، مگر اینکه محدودیت یکسانی لازم باشد.
منبع زیر‌فرم می‌تواند خروجی یک فرم دیگر نیز باشد. در این حالت، متغیر خروجی آن فرم را انتخاب کنید، منبع را FormData بگذارید و همه داده‌ها را فعال کنید؛ مسیر نمونه @@SavedData:FormData است. نام فنی فیلدهای فرم مبدأ باید با ستون‌های زیر‌فرم مقصد یکسان باشد. داده یک فرم، یک رکورد برای زیر‌فرم فراهم می‌کند و شرط فیلتر روی همان رکورد نیز اعمال می‌شود؛ اگر شرط برقرار نباشد، آن رکورد نمایش داده نمی‌شود.
فیلتر این مرحله باید داده‌ای برای پردازش داشته باشد. اگر زیر‌فرم بدون جدول باشد و داده آن تازه پس از بازشدن فرم از یک Provider یا عملیات فرم دریافت شود، هنگام آماده‌سازی UserTask داده‌ای وجود ندارد تا همین فیلتر بر آن اعمال شود. برای این روش، داده را قبلاً در اختیار فرآیند قرار دهید یا از مقدار اولیه زیر‌فرم تأمین کنید. ردیف‌های ردشده در این فیلتر به نمای فرم این گام داده نمی‌شوند.
در تنظیم فیلد زیر‌فرم، گزینه‌های مربوط به نمایش جدول، جستجو، خروجی Excel و عملیات درج/ویرایش/حذف را متناسب با نقش همین گام انتخاب کنید. فرم بررسی سابقه لزوماً نباید امکان تغییر سوابق را داشته باشد. اگر در گام دیگری گزارش لازم نیست، نمایش خود زیر‌فرم را در آن گام خاموش کنید.
در طراحی مقدار اولیه کنترل‌هایی مانند CheckBox، تنظیم پایه فرم برای داشتن مقدار پیش‌فرض را نیز بررسی کنید. خاموش بودن قابلیت مقدار اولیه در تعریف فیلد می‌تواند مانع نتیجه‌ای شود که از تنظیم پیش‌فرض فرآیند انتظار دارید. ترتیب اعمال تنظیمات را هم در نظر بگیرید: ابتدا تنظیمات پایه فرم، سپس تنظیمات گام فرآیند، و پس از آماده‌شدن فرم، قواعد نمایشی و عملیات بارگذاری سمت فرم می‌توانند بر ظاهر یا داده اثر بگذارند. راه‌حل یک تعارض، تکرار بی‌هدف ذخیره فرآیند نیست؛ باید محل و زمان مقداردهی فیلد مشخص شود.
اگر بارگذاری گزارش در خود فرم به یک فیلد تأیید وابسته است، مقدار آن فیلد را نیز متناسب با مرحله تنظیم کنید. در گام ثبت اولیه هنوز تأییدی انجام نشده است؛ مقدار خالی را با خیر یکی نگیرید. در گام بررسی، مقدار اولیه مورد نیاز را در تنظیمات همان UserTask بدهید و فعال‌بودن قابلیت مقدار اولیه در تعریف CheckBox را بررسی کنید. این روش با فیلترکردن مجموعه داده پیش از تحویل به فرم تفاوت دارد؛ برای محدودکردن داده ارسالی از فرآیند، از روش ServiceTask و فیلتر SubForm استفاده کنید.
مثال کامل: ثبت و ویرایش همان رکورد در دو گام
یک آغاز، دو User Task و یک پایان را به‌صورت خطی متصل کنید. گام اول برای ثبت درخواست و گام دوم برای بررسی همان درخواست است. در هر دو گام همان تعریف فرم را انتخاب کنید؛ گام اول در حالت افزودن و گام دوم در حالت ویرایش قرار می‌گیرد.
- متغیر
@@SavedDataرا برای خروجی گام اول تعریف کنید. - خروجی User Task اول را روی همین متغیر قرار دهید و تنظیمات عنصر را ذخیره کنید.
- در گام دوم، ورودی فیلد
Idرا از همان متغیر تأمین کنید. وقتی انتخاب‌گر ساده خروجی فرم را می‌پذیرد، همان گزینهٔ ساده را انتخاب کنید؛ برای خواندن عضو خاص یک ساختار، مسیر پیشرفته را متناسب با ساختار واقعی خروجی تنظیم کنید. - دسترسی Lane دوم را برای گیرندهٔ واقعی آزمون تنظیم و مدل را در نسخهٔ مورد نظر ذخیره کنید.
- در گام اول یک عنوان مشخص وارد و اقدام ادامه را اجرا کنید. در گام دوم همان عنوان و شناسهٔ رکورد را کنترل کنید.
- یکی از مقادیر را در گام دوم تغییر دهید. نتیجه باید ویرایش همان رکورد باشد؛ افزایش تعداد رکوردها نشانهٔ بررسی‌نشدن حالت افزودن یا ورودی Id است.
عنوانی مانند «مشاهدهٔ فرم» در بالای صفحه به‌تنهایی حالت دسترسی را تعیین نمی‌کند؛ حالت نمایش، افزودن یا ویرایش و مجوز فیلدها را از تنظیمات واقعی گام کنترل کنید.
Form قابل استفاده در User Task
User Task محل تعامل کاربر با Form در گردش Process است. ابتدا Form را در فرم‌ساز آماده و از Action «ثبت فرم در فرآیند» برای استفاده در Process ثبت کنید؛ سپس آن را در انتخاب‌گر Form پنل User Task برگزینید. این ثبت، آماده‌کردن تعریف Form برای استفاده در Process است و به معنی ثبت رکورد داده یا ذخیره طراحی Process نیست.
انتخاب‌گر موردبحث، Formهای ثبت‌شده برای استفاده در Process را عرضه می‌کند. این شرط را صرفاً معادل فهرست تمام Formهای دارای مجوز عمومی کاربر فرض نکنید؛ مجوزهای کار با طراحی و داده Form موضوع دیگری هستند.
جدید، ویرایش و نمایش سه حالت مستقل Form هستند. در «تنظیمات فیلدها»، کنترل‌های داده و اجزای ساختاری مانند SubForm، TabPanel، Tabهای داخل آن و Container نیز دیده می‌شوند؛ بنابراین تنظیم رفتار یک گام می‌تواند ساختار نمایش Form را هم پوشش دهد.
این نقطه تعامل با فرم در بعضی سامانه‌ها Form Task نامیده می‌شود؛ نام همین Node در GraphBPMS، User Task است.
آماده‌سازی Form و انتخاب حالت User Task
Form موردنظر باید برای مصرف در Process ثبت شده باشد. در فهرست فرم‌ساز، عملیات «ثبت فرم در فرآیند» و ستون «ذخیره در فرآیند» وضعیت این آماده‌سازی را نشان می‌دهند. پس از تغییر ساختار Form، هماهنگی تعریف مورد استفاده در Process را کنترل کنید.
در پنل UserTask، عنوان و توضیحات Node، انتخاب Form و حالت Form را تعیین کنید. دکمه «تنظیمات فیلدها» رفتار فیلدها در همین گام و دکمه «تنظیمات چندزبانه» زبان نمایش را تنظیم می‌کند. خروجی را می‌توان بدون خروجی یا در Variable ثبت کرد.
| حالت | منظور |
|---|---|
| جدید / Add | ورود اطلاعات برای ایجاد Record جدید؛ رفتار Action بازگشت بدون ثبت، در مقاله Sequence Flow جدا توضیح داده شده است. |
| ویرایش / Edit | کار روی Record موجود؛ شناسه Record باید به‌درستی تأمین شود. |
| نمایش / View | مشاهده داده در حالت نمایش؛ عنوان نمایشی خود Form تعیین‌کننده این Mode نیست. |
ذخیره تنظیمات Node و ذخیره کل Process دو مرحله‌اند. پس از تغییر Form، خروجی Variable و مسیرهای مصرف آن را نیز کنترل کنید؛ داده قدیمی لزوماً با ساختار جدید سازگار نیست.
↑ بازگشت به فهرست آموزشحالت جدید همراه Id: ساخت رکورد تازه از دادهٔ رکورد موجود
در Form غیر Tableless، فیلد Id می‌تواند شناسهٔ یک Record موجود را از Variable بگیرد. اگر حالت Form «جدید» باشد، دادهٔ آن رکورد برای پرکردن اولیهٔ Form استفاده می‌شود؛ اما ذخیره، رکورد منبع را ویرایش نمی‌کند. سامانه رکورد جدید با Id جدید می‌سازد. این روش برای Clone دادهٔ یک رکورد به درخواست یا رکورد تازه کاربرد دارد.
برای نمونه، Id رکورد منبع را در Variable نگه دارید، آن را به فیلد شناسهٔ User Task بدهید و حالت را «جدید» انتخاب کنید. کاربر دادهٔ پرشده را می‌بیند و می‌تواند متناسب با این گام تغییر دهد؛ با ثبت Form، داده در Record تازه نوشته می‌شود و Record منبع باقی می‌ماند. در مقابل، حالت «ویرایش» همراه Id همان رکورد موجود را باز و تغییرات ثبت‌شده را روی همان رکورد اعمال می‌کند.
این کاربرد Id را به Form Tableless تعمیم ندهید؛ Tableless رکورد ذخیره‌شدهٔ متناظر برای این عملیات ندارد. همچنین گزینهٔ بازگشت بدون ثبت اطلاعات Form روی Action مربوط، موضوع مستقل است و قواعد ثبت در همان Action را تغییر می‌دهد.
↑ بازگشت به فهرست آموزشحالت نمایش: عبور بدون ثبت دادهٔ Form
حالت «نمایش» دادهٔ رکورد مشخص‌شده را برای مشاهده باز می‌کند. ثبت دادهٔ Form در این حالت انجام نمی‌شود؛ حتی تغییر دستکاری‌شدهٔ سمت کلاینت و ارسال Submit، مجوز ویرایش رکورد ایجاد نمی‌کند. ادامهٔ Process از این گام را با ثبت یا Update دادهٔ Form یکی ندانید.
↑ بازگشت به فهرست آموزشمثال مرحله‌ای: آماده‌سازی فرم درخواست مرخصی
برای دنبال‌کردن ارتباط Form، Variable و Lane، یک فرم درخواست مرخصی با انتخاب درخواست‌کننده، تاریخ و ساعت شروع و تاریخ و ساعت پایان در نظر بگیرید. فیلدهای لازم را اجباری و Form را برای استفاده در Process ثبت کنید. انتخاب تقویم شمسی برای نمایش کنترل، قالب داده‌ای را که سرویس محاسبه زمان انتظار دارد تغییر نمی‌دهد؛ مقدار خروجی تاریخ را در Variable Log بررسی کنید.
- در User Task ثبت درخواست، حالت
Newرا انتخاب کنید و شناسه درخواست‌کننده را از@@CurrentUserIDمقدار دهید. - در SelectBox درخواست‌کننده، مقدار ذخیره‌شونده باید UserID باشد؛ نام و نام خانوادگی، متن نمایشی همان مقدار است. مقدار نمایش را به‌جای شناسه در Lane استفاده نکنید.
- اگر Provider انتخاب‌گر پارامتر اختیاری کاربر دارد، قرارداد آن را طوری تنظیم کنید که با پارامتر خالی فهرست مجاز کاربران و با پارامتر پر، کاربر همان شناسه را برگرداند. این رفتار متعلق به Provider مثال است و از صرف اختیاری‌بودن یک پارامتر نتیجه نمی‌شود.
- برای جلوگیری از انتخاب تاریخ گذشته، حداقل تاریخ را با مقدار پویای زمان جاری تنظیم کنید؛ یک تاریخ ثابتِ روز طراحی، در روزهای بعد همچنان همان تاریخ ثابت می‌ماند. نام تابع زمان جاری را از انتخاب‌گر تابعِ همان فیلد بردارید.
- اگر درخواست‌کننده در اولین گام نباید نام خود را تغییر دهد، کنترل آن را در همان User Task پنهان یا فقط‌خواندنی کنید. در گام بررسی، آن را نمایان و فقط‌خواندنی قرار دهید.
- خروجی فرم را در Variable نگه دارید تا گام بررسی همان درخواست و گام سرویس همان تاریخ‌ها را مصرف کند.
این تنظیم‌های هر User Task، استفاده‌های دیگر همان Form را به‌صورت عمومی تغییر نمی‌دهند. برای مثالی که بررسی‌کننده باید فقط نظر خود را بنویسد، حالت Edit و فقط‌خواندنی‌بودن فیلدهای اصلی درخواست را ترکیب کنید. حالت View برای نمایش فرم است و داده Form را ثبت نمی‌کند.
پس از تغییر ساختار Form
اگر Form انتخاب‌شده یا فیلدهای آن تغییر کرد، تنظیمات تمام User Taskهای استفاده‌کننده را بازبینی کنید. در رابط قدیمی، ردیف فیلدهای حذف‌شده یا متعلق به Form قبلی با رنگ قرمز قابل تشخیص بود؛ این ردیف‌ها را با فیلدهای فعال اشتباه نگیرید و تنظیم‌های منسوخ را پاک کنید. سپس فیلدهای جدید، نگاشت Id، مقدارهای پیش‌فرض و خروجی هر گام را ذخیره کنید. بازبینی UI فیلدهای تازه، مجوزی برای ذخیره Form در حالت View ایجاد نمی‌کند.
جدول تنظیمات فیلدها و تنظیمات گروهی
در جدول فیلدها، عنوان و نوع هر فیلد و وضعیت نمایش، اجباری بودن در Form، فقط‌خواندنی، فعال، فیلتر، نمایش در جدول فیلد تو‌در‌تو و مقدار پیش‌فرض دیده می‌شود. ردیف‌های SubForm و فرزندان آن از هم جدا هستند. Checkbox انتخاب ردیف برای اعمال تنظیم بر فیلد یا چند فیلد است.
| کنترل | نحوه استفاده |
|---|---|
| تنظیمات فیلد | بازکردن تنظیم فیلد یا فیلدهای انتخاب‌شده. |
| تنظیمات عمومی | تنظیمات عمومی مرتبط با فیلدها. |
| بازنشانی تنظیمات فیلد | برگرداندن تنظیمات؛ دامنه پیام تأیید را بررسی کنید، زیرا تغییرات گروهی می‌توانند تنظیم چند فیلد را از بین ببرند. |
| فیلتر زیر ستون‌ها | پیداکردن فیلد بر اساس نام، نوع یا وضعیت. |
| ناحیه هاشورخورده | آن گزینه برای نوع فیلد همان ردیف کاربرد یا امکان تنظیم ندارد. |
| علامت تیک و × | وضعیت روشن و خاموش هر ویژگی، مستقل از انتخاب ردیف. |
در مثال فیلد کلید Id مخفی، غیرفعال و فقط‌خواندنی است و اجباری نیست. اینها وضعیت نمونه‌اند؛ فیلد کلید را با فیلد داده معمولی یکسان فرض نکنید.
برای مقدار اولیه، چهار حالت «بدون مقدار اولیه و خالی»، «ورود مقدار اولیه از متغیر»، «ورود مقدار اولیه ثابت» و «ورود مقدار اولیه از تابع» وجود دارد. برای روش متغیر، Variable، ساده/پیشرفته، نوع داده و مسیر را مطابق ساختار واقعی انتخاب کنید. «تأیید» تنظیم پنجره و «لغو» انصراف از آن است.
↑ بازگشت به فهرست آموزشمقدار اولیه فیلد Bit
برای فیلد انتخاب‌شده چهار روش مقدار اولیه وجود دارد: بدون مقدار اولیه و خالی، از متغیر، ثابت، و از تابع. نمونهٔ فیلد Bit، مقدار ثابت را با برچسب null نشان می‌دهد. آن را با مقدار بولی false یکی نگیرید؛ وضعیت مورد انتظار را صریح انتخاب و در اجرای فرم بررسی کنید.
مسیر پیشرفته مقدار اولیه و محدودیت اعمال پیش‌فرض
در مقداردهی اولیه از متغیر، حالت «پیشرفته» امکان انتخاب منبع FormData و واردکردن مسیر ذخیره‌سازی را می‌دهد. گزینهٔ «همه داده‌ها» جدا از مسیر یک فیلد قرار دارد. هشدار پنجره تصریح می‌کند که مقدار پیش‌فرض تنها وقتی نمایش داده می‌شود که فیلد فرم بدون مقدار باشد. نمونهٔ ['FieldName'] را با نام واقعی فیلد جایگزین کنید.
SubForm: قابلیت‌های جدول و مقدار اولیه
تنظیمات SubForm علاوه بر ویژگی‌های عمومی، امکانات جدول داخلی را جدا کنترل می‌کند. در مثال نمرات، نمایش، فعال بودن، خروجی Excel، جستجو، فیلتر ستون، درج و ویرایش پنجره‌ای و حذف تکی روشن‌اند؛ ورود از Excel، درج و ویرایش سطری، صفحه‌بندی و حذف چندتایی خاموش‌اند. این وضعیت‌ها انتخاب‌های مدل نمونه هستند و مقدار پیش‌فرض عمومی محصول محسوب نمی‌شوند.
| قابلیت | اثر در جدول SubForm |
|---|---|
| ورود داده از Excel / خروجی Excel | کنترل جداگانه ورود و خروج اطلاعات. |
| جستجو در Grid / فیلتر با ستون | جستجوی جدول و محدودکردن داده بر اساس ستون. |
| درج داده پنجره‌ای / سطری | روش ورود Record جدید. |
| ویرایش داده پنجره‌ای / سطری | روش ویرایش Record موجود. |
| Grid دارای صفحه‌بندی | کنترل نمایش صفحه‌بندی داده. |
| حذف داده تو‌در‌تو تکی / چندتایی | کنترل حذف یک ردیف یا چند ردیف. |
| نمایش در جدول فیلد تو‌در‌تو | کنترل نمایش ستون‌های فرزند؛ این گزینه روی ردیف‌های داخلی SubForm دیده می‌شود. |
مقداردهی از SubForm خروجی یک User Task
در حالت پیشرفته FormData، مسیر آرایه SubForm مبدأ را وارد کنید. نمونه مسیر ['SubformFieldsThatHasEqualFieldsByTypesAndNames'] است. نام‌ها و نوع فیلدهای داده مبدأ باید با ساختار مقصد تطبیق داده شوند؛ نام نمونه را به عنوان نام ثابت محصول به کار نبرید.
مقداردهی از همه ردیف‌های سرویس
اگر داده اولیه از مجموعه ردیف‌های سرویس است، ServiceData و «همه داده‌ها» را انتخاب کنید. در این حالت مسیر خالی و Index غیرفعال نمایش داده می‌شوند و کل داده انتخاب‌شده مبنای مقداردهی است؛ انتخاب ردیف صفر به‌تنهایی همین معنا را ندارد.
فیلتر داده‌های SubForm
نماد قیف روی ردیف SubForm پنجره تنظیمات فیلتر را باز می‌کند. سازنده شرط دارای گروه «و»، علامت + برای افزودن و × برای حذف شرط است. در مثال، «کاربر ثبت‌کننده» برابر @@CurrentUserID قرار داده شده است.
فیلتر داده را با مخفی‌کردن یک ستون اشتباه نگیرید؛ یکی ردیف‌های نمایش‌داده‌شده را محدود می‌کند و دیگری نمایش فیلد را. تنظیم را با «ذخیره» ثبت و سپس در Form اجرایی کنترل کنید.
↑ بازگشت به فهرست آموزشمقدار اولیهٔ SubForm از فرم یا سرویس دیگر
منبع مقدار اولیه لازم نیست همان SubForm در همان Form باشد. می‌توانید دادهٔ یک SubForm دیگر را از خروجی User Task پیشین یا آرایهٔ ردیف‌های ServiceData یک Provider به SubForm مقصد بدهید. فیلدهای لازم مقصد باید در دادهٔ ورودی با همان نام و نوع وجود داشته باشند؛ ترتیب فیلدها شرط تطبیق نیست و وجود ستون‌های اضافی در منبع مانع این تطبیق نمی‌شود.
برای نمونه، اگر SubForm نمرات فیلد متنی LessonName و فیلد عددی LessonScore دارد، خروجی Provider با این دو نام و نوع می‌تواند دادهٔ اولیهٔ آن باشد. در تنظیم مقدار اولیه، ServiceData و «همه داده‌ها» را انتخاب کنید؛ برای منبع FormData، مسیر SubForm حامل ردیف‌ها را بدهید. سازگاری را با دادهٔ واقعاً موجود در Variable بررسی کنید.
اگر یک فیلد Columnless در داده واقعاً منتقل‌شده وجود داشته باشد، برای آن نیز تطبیق نام و نوع را رعایت کنید. Columnless بودن به‌تنهایی تضمین نمی‌کند آن فیلد در همه خروجی‌ها یا ورودی‌ها حاضر باشد؛ محتوای Variable را بررسی کنید.
فیلتر SubForm پیش از رسیدن داده به Form
آیکن قیف SubForm پنجرهٔ فیلتر ردیف‌ها را باز می‌کند. فیلد مقصد، عملگر و مقدار مقایسه را انتخاب کنید؛ مقدار می‌تواند ثابت یا Variable باشد. برای نمایش نمرات متعلق به کاربر جاری، شناسهٔ کاربر ثبت‌کنندهٔ ردیف را با شناسهٔ کاربر جاری مقایسه کنید.
این فیلتر در backend و پایگاه داده اعمال می‌شود. نتیجهٔ ردشده برای نمایش همین SubForm به frontend و DOM فرستاده نمی‌شود؛ رفتار آن صرفاً مخفی‌کردن ظاهری ردیف‌ها پس از بارگیری نیست. این قاعده برای دادهٔ ورودی از Provider یا دادهٔ SubForm منتقل‌شده از گام پیشین نیز در سناریوی آموزش مطرح است.
فیلدهای سیستمی مانند کاربر/نقش ثبت‌کننده و کاربر/نقش ویرایش‌کننده در شرط قابل انتخاب‌اند. مقادیر ویرایش‌کننده ممکن است Null باشند؛ شرط مربوط را مطابق نوع و وضعیت واقعی داده تنظیم کنید. نام و نوع فیلدهای اختصاصی مانند درس و نمره نیز متعلق به طراحی همان Form است.
↑ بازگشت به فهرست آموزشکنترل ستون‌های SubForm در User Task
با جست‌وجوی عنوان یا نام فیلد می‌توان ردیف SubForm و فیلدهای داخلی آن را محدود کرد. ستون «نمایش در جدول فیلد تو‌در‌تو» با نمایش خود فیلد در فرم فرق دارد. ردیف اصلی SubForm کنترل فیلتر دارد و ردیف‌های داخلی نوع‌های Text، Date، Number و Bit را جداگانه نمایش می‌دهند. سلول‌های هاشورخورده در این نما قابل تفسیر به‌عنوان مجوز فعال نیستند.
انتخاب فیلد شرط در فیلتر SubForm
پنجرهٔ «تنظیمات فیلتر SubForm» شرط را از فیلد، عملگر و مقدار می‌سازد. فهرست فیلدها علاوه بر ستون‌های داده می‌تواند تاریخ ثبت ردیف، کاربر و نقش ثبت‌کننده، تاریخ ویرایش و کاربر و نقش ویرایش‌کننده را داشته باشد. علامت جمع شرط و علامت حذف در همین پنجره قرار دارند.
ذخیره شرط SubForm و کنترل نتیجه
پس از انتخاب فیلد، عملگر و مقدار، عبارت کامل را بازبینی کنید. در مثال فیلتر، «تأیید» با مقدار 1 و عملگر «برابر» مقایسه می‌شود. «ذخیره» تنظیم فیلتر را ثبت می‌کند و «بستن» پنجره را می‌بندد. این شرط، شرط نمایش ردیف‌های SubForm است؛ آن را به‌جای شرط انتخاب مسیر Gateway به کار نبرید.
چندزبانه، Tab Panel و موقعیت دکمه‌ها
در «تنظیمات چندزبانه»، زبان پیش‌فرض، چندزبانه بودن، وابستگی به زبان انتخاب‌شده و امکان تغییر زبان توسط کاربر نهایی کنترل می‌شوند. نمونه زبان پیش‌فرض فارسی است و هر سه کلید روشن‌اند. گزینه‌ها را متناسب با ترجمه‌های آماده Form تنظیم کنید.
در تنظیم یک Tab Panel، فیلد «تب فعال (زبانه)» تعیین می‌کند کدام زبانه فعال باشد. نمایش، فعال و فقط‌خواندنی نیز برای همین جزء قابل تنظیم‌اند؛ «تأیید» و «لغو» پایین پنجره قرار دارند.
گزینه «ثابت بودن دکمه‌های عملیاتی در فرم» تنظیم مستقلی است. فعال‌بودن ثبت موقت، انتخاب Tab Panel اقدامات و ثابت‌بودن دکمه‌ها را جداگانه کنترل کنید؛ یکی جانشین دیگری نیست.
تنظیم ساختار نمایش و زبان برای همین گام
تنظیمات User Task می‌تواند وضعیت نمایش، فعال‌بودن، فقط‌خواندنی یا اجباری‌بودن کنترل‌ها را متناسب با این گام تغییر دهد. در TabPanel، Tab فعال اولیه را صریح انتخاب کنید؛ این انتخاب با گزینهٔ نگهداری وضعیت Tab هنگام ذخیرهٔ موقت موضوع متفاوتی است. تنظیم فقط‌خواندنی Container بر کنترل‌های زیرمجموعهٔ آن اثر می‌گذارد.
در تنظیمات چندزبانه، زبان پیش‌فرض، فعال‌بودن چندزبانه، وابستگی ذخیره به زبان انتخاب‌شده و اجازهٔ تغییر زبان توسط کاربر نهایی را جدا تنظیم کنید. انتخاب زبان پیش‌فرض به‌تنهایی همهٔ این رفتارها را تعیین نمی‌کند.
برای مثال می‌توانید فیلد Id را که در تعریف اصلی Form پنهان است، فقط در نمایش همین گام نمایان کنید. در حالت ذخیره وابسته به زبان انتخاب‌شده، ذخیره برای زبان جاری انجام می‌شود؛ این گزینه از اجازه تغییر زبان توسط کاربر جداست.
ثابت‌ماندن قسمت اقدام هنگام Scroll
گزینهٔ «ثابت بودن دکمه‌های عملیاتی در فرم» قسمت شرح ارجاع، Actionها و دکمهٔ ذخیره را هنگام بالا و پایین رفتن Form همراه نمایش نگه می‌دارد. پیش‌فرض آن غیرفعال است؛ در حالت عادی، این قسمت فقط در محل خودش دیده می‌شود. رفتار لازم را متناسب با طول Form و نیاز همین گام انتخاب کنید.
↑ بازگشت به فهرست آموزشاقدام، ارجاع و عنوان اجرا
تعریف اقدام و اتصال آن به مسیر
اقدام انتخابی است که کاربر هنگام تکمیل UserTask انجام می‌دهد؛ مانند تأیید، برگشت برای اصلاح یا عدم تأیید نهایی. نام، رنگ و آیکون، اقدام را در رابط کاربر قابل تشخیص می‌کنند. اثر اجرایی آن از مسیر متصل و تنظیمات آن مسیر به دست می‌آید؛ رنگ قرمز به‌تنهایی فرآیند را لغو نمی‌کند.
- از مدیریت اقدامات فرآیند، اقدام‌های لازم را ایجاد کنید و نام روشن، رنگ و در صورت نیاز آیکون بدهید.
- UserTask و مسیرهای بعد از آن را طراحی کنید. برای تصمیم مبتنی بر اقدام می‌توانید از Gateway مناسب استفاده کنید.
- اتصال مربوط را انتخاب کنید و اقدام متناظر را در تنظیمات آن قرار دهید.
- در UserTask، نوع نمایش اقدامات را انتخاب کنید.
- ترتیب مورد نظر را با اولویت اقدام تنظیم کنید و تنظیمات را ذخیره کنید.
- نام و نتیجه هر اقدام را با مسیر واقعی آن تطبیق دهید؛ برگشت برای اصلاح باید به گام اصلاح برسد و تأیید به مسیر تأیید.
سه شیوه نمایش اقدامات عبارت‌اند از لیست انتخابی، انتخاب تک‌گزینه‌ای و لیستی از دکمه‌ها. در حالت دکمه‌ها، نام و رنگ هر اقدام مستقیماً روی دکمه دیده می‌شود. اولویت را برای ترتیب قابل فهم نمایش تنظیم کنید؛ تصمیم‌گیری Gateway و اولویت مسیرها تنظیمات مربوط به خود را دارند.
وقتی تصمیم Exclusive بر پایه اقدام است، اقدام باید از UserTask مربوط تأمین شود. برای مسیرهای شرطی مبتنی بر داده، شرط را روی مقدار واقعی متغیر بنویسید؛ برای نمونه @@SavedData:FormData['ConfirmSubstitute']. تفاوت تصمیم مبتنی بر اقدام و تصمیم مبتنی بر شرط در Gatewayها توضیح داده شده است.
دریافت شرح ارجاع از اقدام‌کننده
شرح ارجاع متن توضیحی کاربر درباره انتقال کار است؛ مانند علت برگشت یا توضیح تأیید. در UserTask، بخش تنظیمات اعلان شرح ارجاع را باز کنید. کنترل‌های مربوط، نمایش ورودی شرح، نمایش نوع شرح و اجباری بودن شرح را تعیین می‌کنند.
| تنظیم | کاربرد |
|---|---|
| نمایش شرح ارجاع | کادر توضیح را برای اقدام‌کننده فراهم می‌کند. |
| نمایش نوع شرح ارجاع | امکان انتخاب نوع پیام، مانند موفقیت‌آمیز، هشدارآمیز یا اخطار را فراهم می‌کند. |
| اجباری بودن شرح ارجاع در UserTask | برای تکمیل این گام، واردکردن توضیح را لازم می‌کند. |
| اجباری بودن شرح ارجاع در اتصال یک اقدام | توضیح را برای همان اقدام لازم می‌کند؛ مناسب برگشت یا رد با الزام ارائه دلیل. |
نوع شرح، شیوه نمایش پیام را مشخص می‌کند. برای تعیین مسیر تأیید یا رد، اقدام و اتصال‌های فرآیند را تنظیم کنید.
اگر همه اقدام‌ها نیاز به توضیح دارند، الزام را در خود UserTask فعال کنید. اگر فقط برگشت به توضیح نیاز دارد، الزام عمومی گام را خاموش کنید و در تنظیمات اتصال اقدام برگشت، اجباری بودن شرح ارجاع را فعال کنید. نمایش کادر شرح باید برقرار باشد تا کاربر بتواند دلیل را وارد کند. فعال ماندن الزام عمومی باعث می‌شود اقدام تأیید نیز بدون توضیح پذیرفته نشود.
نمایش شرح دریافتی در گام بعد
در UserTask دریافت‌کننده، تنظیمات نمایش شرح ارجاع را فعال کنید. اگر ارجاع قبلی توضیح داشته باشد، کاربر آن را هنگام بازکردن فرم می‌بیند. در نخستین ورود به گامی که هنوز شرحی دریافت نکرده، انتظار نمایش پیام قبلی نداشته باشید.
این تنظیم با کادر دریافت شرح تفاوت دارد: ممکن است یک گام توضیح قبلی را نشان دهد و خودش از کاربر توضیح نخواهد؛ گام دیگری هم توضیح دریافتی را نشان دهد و هم هنگام ارسال، توضیح جدید بگیرد.
برگشت بدون ثبت اطلاعات فرم
برای Action مشخصی که باید بدون ثبت دادهٔ فرم ادامه یابد، «بازگشت بدون ثبت اطلاعات فرم» را روی Sequence Flow همان Action فعال کنید. این رفتار برای User Task در حالت Add یا Edit و Form غیر Tableless مطرح است: در Add رکورد تازه ساخته نمی‌شود و در Edit رکورد موجود با ورودی جاری ویرایش نمی‌شود؛ Variable Log مربوط انجام می‌شود.
این تنظیم فقط همان Action/مسیر را پوشش می‌دهد. دادهٔ جاری ثبت‌شده در Variable Log می‌تواند با مقدار جدول Form تفاوت داشته باشد؛ اگر گام بعد دادهٔ ذخیره‌شدهٔ رکورد را لازم دارد، آن را از رکورد درست بخوانید. این قاعده را به حالت View، فرم Tableless یا Actionهای دیگر تعمیم ندهید. جزئیات و آزمون Add/Edit در Sequence Flow و Actionها آمده است.
ثبت موقت
در UserTaskی که کاربر باید بتواند تکمیل فرم را به زمان دیگری موکول کند، ثبت موقت را فعال کنید. پس از ذخیره تنظیمات، دکمه ثبت موقت در فرم آن گام در دسترس قرار می‌گیرد.
- کاربر فرم را باز و داده‌های قابل ثبت را وارد می‌کند.
- ثبت موقت را می‌زند؛ صرف بستن فرم جای این کار را نمی‌گیرد.
- داده ذخیره می‌شود ولی مسیر به گام بعد نمی‌رود.
- کاربر بعداً کار را از کارتابل خود باز می‌کند و تکمیل را ادامه می‌دهد.
- با ثبت نهایی، همان رکورد تکمیل می‌شود و فرآیند مطابق اقدام انتخابی ادامه پیدا می‌کند.
الزام‌های پایگاه داده همچنان باید رعایت شوند؛ ثبت موقت مجوز ذخیره رکوردی که ستون اجباری آن خالی است نمی‌دهد. همچنین شروع یک فرآیند و رهاکردن نخستین فرم بدون ثبت، با ذخیره واقعی فرم از دکمه ثبت موقت تفاوت دارد. برای یافتن شروع‌های تکمیل‌نشده، کارتابل ثبت موقت را نیز بررسی کنید؛ وجود یک مورد در آن فهرست به‌تنهایی نشان نمی‌دهد همه فیلدهای فرم در پایگاه داده ذخیره شده‌اند.
لغو فرآیند از گام انسانی
با فعال‌کردن لغو فرآیند در UserTask، امکان لغو از همان فرم فراهم می‌شود. کاربر عملیات را انتخاب می‌کند، پیام تأیید را می‌پذیرد و توضیح لازم را وارد می‌کند. نتیجه، خارج شدن کل نمونه جاری فرآیند از چرخه فعال است؛ ارجاع‌ها و انتظارهای مرتبط نباید برای ادامه معمول همان نمونه به کار گرفته شوند.
لغو، حذف فیزیکی تاریخچه نیست. همچنین با اقدام عدم تأیید که ممکن است فقط درخواست را به مرحله اصلاح برگرداند تفاوت دارد. اگر نیاز کسب‌وکار حفظ امکان اصلاح است، یک مسیر برگشت طراحی کنید؛ لغو را برای پایان دادن به ادامه کل درخواست در اختیار کاربر قرار دهید.
ارجاع گروهی
برای ارجاع گروهی Taskهای مجاز، هم مجوز عمومی عملیات در کارتابل و هم اجازهٔ ارجاع گروهی User Task لازم است. Wizard گروه‌های مستقل را براساس نسخه و گام می‌سازد؛ فعال‌بودن یکی از دو مجوز، جای دیگری را نمی‌گیرد.
- در تنظیمات UserTask، ارجاع گروهی را فعال و فرآیند را ذخیره کنید.
- در کارتابل، ردیف‌های مورد نظر را انتخاب کنید.
- از عملیات کارتابل، ارجاع گروهی را باز کنید.
- تعداد ردیف‌های انتخاب‌شده و تعداد ردیف‌های مجاز را مقایسه کنید. پنجره، سازگاری را بر اساس ردیف اول انتخاب‌شده مشخص می‌کند؛ همه ردیف‌های انتخابی الزاماً مجاز نیستند.
- اگر پنجره انتخاب اقدام را ارائه می‌کند، اقدام مورد نظر را انتخاب کنید و توضیحات لازم را وارد کنید.
- ذخیره کنید و تا پایان عملیات منتظر بمانید؛ سپس نتیجه فهرست را بررسی کنید.
پنجره تعداد انتخابی و قابل ارجاع و راهنمای انتخاب اقدام الزامی است را نشان می‌دهد. اگر گام انتخاب‌گر اقدام دارد، انتخاب آن را پیش از ثبت کامل کنید.
شرح ارجاع، متن توضیحی انتقال است؛ نوشتن کلمه تأیید در شرح، جای انتخاب اقدام یا تحقق شرط مسیر را نمی‌گیرد. راهنمای کار با پنجره در ارجاع گروهی آمده است.
پیش از ارجاع گروهی، تصمیم مناسب هر گروه را بررسی کنید. انتخاب چند ردیف، دادهٔ مفقود یا تنظیم ناقص گام‌ها را اصلاح نمی‌کند؛ موارد غیرمجاز کنار گذاشته می‌شوند و شرح هر گروه تابع طراحی همان گام است.
رونوشت برای اطلاع‌رسانی
برای رساندن نتیجه به فردی که لازم نیست جریان اصلی منتظر تأیید او بماند، از UserTask با رونوشت استفاده کنید. فرم رونوشت باید در حالت نمایش باشد. اگر همان رکورد درخواست را نشان می‌دهید، Id را از خروجی درخواست تعیین کنید.
- یک UserTask در Lane گیرنده رونوشت قرار دهید.
- فرم و حالت نمایش را انتخاب کنید.
- Id رکورد مورد نظر را مقداردهی کنید.
- در تنظیمات رونوشت، رونوشت را فعال کنید.
- اتصال بعد از گام را طراحی و تغییرات را ذخیره کنید.
با رسیدن اجرا به این گام، کار برای مشاهده در کارتابل گیرنده قرار می‌گیرد و مسیر بعدی اجرا می‌شود. رونوشت تا رسیدگی گیرنده در کارتابل او باقی می‌ماند. ثبت مشاهده رونوشت قرار نیست دوباره منطق گام بعد را اجرا کند. اگر باید پاسخ گیرنده قبل از ادامه دریافت شود، گام انسانی معمولی را با اقدام لازم طراحی کنید.
چند گیرنده و زمان ادامه مسیر
وقتی Lane به چند کاربر یا چند نقش ارجاع می‌دهد، تفکیک ارجاع براساس اقدام تعیین می‌کند فرآیند چه زمانی تصمیم بعدی را بررسی کند. این بخش را همراه با مبنای دسترسی Lane تنظیم کنید.
| تنظیم | اثر در طراحی |
|---|---|
| براساس هر اقدام | بعد از ثبت هر اقدام، وضعیت لازم برای ادامه ارزیابی می‌شود. در تصمیم‌های درصدی ممکن است هنوز تعداد رأی کافی نباشد. |
| براساس آخرین اقدام | تا تکمیل مجموعه اقدام‌های لازم منتظر می‌ماند؛ سپس تصمیم بعدی بررسی می‌شود. |
| اولین کاربر از نقش | در ارجاع مبتنی بر نقش، اقدام یک عضو برای همان نقش کافی است؛ بقیه اعضای آن نقش لازم نیست دوباره همان سهم نقش را تکمیل کنند. |
اگر سه نقش گیرنده‌اند و اولین کاربر از نقش فعال است، سه نقش سه واحد مستقل‌اند؛ تعداد اعضای هر نقش تعداد واحدها را افزایش نمی‌دهد. اگر یک نفر عضو دو نقش باشد، مشترک بودن شخص، دو نقش را یکی نمی‌کند. اقدام او در یک نقش، سهم نقش دیگر را خودکار تکمیل نمی‌کند.
نتیجه نهایی را از نوع Gateway جدا نکنید. در Exclusive مبتنی بر اقدام و سیاست آخرین اقدام، انتخاب آخرین اقدام‌کننده مسیر را مشخص می‌کند. در Complex با شرط درصدی، آرا تجمیع می‌شوند؛ آخرین رأی لزوماً نظر اکثریت را عوض نمی‌کند. برای مثال، دو تأیید از سه رأی، با یک رأی مخالف آخر به یک تأیید تبدیل نمی‌شود. روش کامل تعیین شرط و درصد در Gatewayها آمده است.
اگر کارِ برگشتی باید فقط به همان فردی برسد که قبلاً در Lane اقدام کرده، گزینه مربوط به نمایش کارتابل ورودی براساس کاربر جاری را در تنظیمات Lane بررسی کنید. این نیاز با سیاست شمارش اقدام‌ها متفاوت است؛ راهنمای آن در Pool و Lane قرار دارد.
عنوان اختیاری اجرای فرآیند
عنوان اختیاری کمک می‌کند کاربر در کارتابل بدون بازکردن تک‌تک فرم‌ها، موضوع اجرای فرآیند را تشخیص دهد. این عنوان با عنوان شکل روی بوم فرق دارد. برای مثال، عنوان شکل بررسی درخواست است ولی عنوان اجرای آن می‌تواند درخواست تجهیزات واحد مالی باشد.
در گامی که باید عنوان اجرای فرآیند تغییر کند، تنظیمات عنوان اختیاری را فعال کنید و متن عنوان را بنویسید. عنوان پس از اتمام همان گام اعمال می‌شود؛ اما فقط متغیرهای ثبت‌شدهٔ گام‌های قبلی برای آن معتبرند، نه خروجی تازهٔ همین گام. برای مثال، نتیجه را در Script Task محاسبه و در Variable ذخیره کنید و تنظیم عنوانی را که آن نتیجه را می‌خواند، در گام بعد قرار دهید. اگر تنظیم روی User Task باشد، پیش از پایان آن گام انتظار عنوان جدید را نداشته باشید.
با افزودن به ادامه عنوان قبلی، متن تازه بدون جداکنندهٔ خودکار به عنوان قبلی متصل می‌شود؛ فاصله، خط جدید یا جداکنندهٔ لازم باید صریح در متن طراح باشد. در حالت جایگزینی، عنوان جدید جای عنوان قبلی را می‌گیرد. افزودن را برای حفظ سابقه عنوان و جایگزینی را برای نمایش وضعیت تازه انتخاب کنید.
برای قرار دادن داده متغیر در متن از قالب‌های زیر استفاده کنید. هر عبارت باید با | شروع و با | تمام شود:
درخواست |V_SavedData:FormData['RequestTitle']|
درخواست‌دهنده: |V_UserInfo:ServiceData[0]['UserTitle']|
نتیجه محاسبه: |V_Calculation|
در نگاشت معمول متغیر، نامی مانند @@SavedData انتخاب می‌شود؛ در قالب عنوان بالا، همان نام پس از V_ آمده است. نام فنی متغیر و مسیر داخلی را دقیق بنویسید. متن پیرامون عبارت‌ها آزاد است.
اگر خروجی فقط شناسهٔ کاربر است و در عنوان نام قابل خواندن می‌خواهید، ابتدا در Service Task اطلاعات همان کاربر را بگیرید و خروجی را ذخیره کنید؛ سپس تنظیم عنوان را در گام بعد قرار دهید و ستون نام را بخوانید. ورودی سرویس باید بر شناسهٔ کاربر مورد نظر فیلتر شود؛ خواندن اولین سطر یک فهرست بدون فیلتر می‌تواند نام فرد دیگری را در عنوان قرار دهد.
دسترسی‌های Runtime و رفتار شرطی User Task
| تنظیم | رفتار |
|---|---|
| امکان تفویض اختیار | مجازبودن واگذاری همین گام؛ با وجود دکمه تفویض در کارتابل متفاوت است. |
| امکان مشاهده تاریخچه فرآیند | دسترسی مشاهده سابقه این گام را کنترل می‌کند. |
| امکان مشاهده روند فرآیند | دسترسی مشاهده نمودار جریان را کنترل می‌کند. |
| ثابت‌بودن دکمه‌های عملیاتی در فرم | تنظیم مربوط به نمایش ثابت مجموعه Actions در فرم. |
| عنوان دکمه ثبت داده فرم | متن دکمه ثبت را برای همین گام تعیین می‌کند. |
فعال‌کردن تفکیک ارجاع در Lane دارای Start در نسخه مستندشده رد می‌شود. در حالت رونوشت، گزینه لغو فرآیند در پنل مخفی می‌شود. خاموشکردن نمایش شرح ارجاع، گزینه نوع شرح و اجباری‌بودن شرح را نیز خاموش می‌کند. نمایش «اولین کاربر از نقش» به مبنای دسترسی Lane وابسته است.
تنظیم TabPanel می‌تواند فعال‌بودن Actions و ثبت موقت در تب‌های منتخب و نحوه ثبت موقت را مشخص کند. در یک زمان فقط یک TabPanel برای Actions فعال می‌شود.
تفکیک ارجاع و دریافت شرح اقدام
با فعال‌کردن «تفکیک ارجاع براساس اقدام»، دو انتخاب «براساس هر اقدام» و «براساس آخرین اقدام» در دسترس است. در حالت آخرین اقدام، کلید «اولین کاربر از نقش» نیز در پنل نمونه نشان داده می‌شود. این تنظیمات بر سناریوهای چندگیرنده اثر دارند و باید با Lane و منطق Gateway هماهنگ شوند.
برای شرح ارجاع، دو نیاز را از هم جدا کنید: نمایش شرح دریافتی از گام قبل و دریافت شرح هنگام اقدام جاری. بخش «تنظیمات نمایش شرح ارجاع» نیاز اول و «تنظیمات اعلان شرح ارجاع» نیاز دوم را کنترل می‌کند. در نیاز دوم، نمایش شرح، نمایش نوع شرح و اجباری بودن شرح سه گزینه جدا هستند.
نمایش متن شرح با رنگ و نوع اعلان آن همراه است؛ متن در بالای فرم می‌تواند توضیح اقدام قبلی باشد. اجباری بودن شرح را به همه Actionها تعمیم ندهید؛ تنظیمات گام و مسیر تصمیم را با هم بخوانید.
↑ بازگشت به فهرست آموزشعنوان اختیاری در مسیرهای برگشتی
اگر مسیر اصلاح چند بار به گامی با «افزودن به ادامه عنوان قبلی» برگردد، اجرای دوباره همان گام می‌تواند همان متن را دوباره به عنوان اضافه کند. برای عنوانی که فقط وضعیت جاری درخواست را بیان می‌کند، جایگزینی مناسب‌تر است؛ برای نگه‌داشتن مراحل در عنوان، قطعهٔ هر بار را معنادار و دارای جداکننده تنظیم کنید. نتیجه را پس از یک رفت و برگشت واقعی، در عنوان همان نمونه کنترل کنید.
↑ بازگشت به فهرست آموزششرح ارجاع و نوع اخطار در فرم اجرایی
در فرم اجرایی، «انتخاب نوع شرح ارجاع» و «توضیحات ارجاع» از اقدام نهایی جدا هستند. نمونهٔ حاضر نوع «اخطار» را نشان می‌دهد و سه دکمهٔ اقدام در بخش «ثبت نهایی» دارد. برای انتخاب مسیر، عنوان اقدام را با تنظیمات اتصال خروجی همان وظیفه تطبیق دهید.
هر اقدام یا آخرین اقدام: چه زمانی مسیر ادامه می‌یابد؟
«براساس هر اقدام» حالت پیش‌فرض است و با رسیدگی اولین دریافت‌کننده، امکان عبور از User Task فراهم می‌شود؛ مسیر برای تکمیل پاسخ تمام دریافت‌کنندگان منتظر نمی‌ماند. «براساس آخرین اقدام» برای حالتی است که رسیدگی همهٔ دریافت‌کنندگان لازم باید تکمیل شود.
اگر دسترسی Lane مبتنی بر نقش است، گزینهٔ «اولین کاربر از نقش» را نیز بررسی کنید. با فعال‌بودن آن، اولین رسیدگی هر نقش به نمایندگی از همان نقش کفایت می‌کند. با غیرفعال‌بودن آن و انتخاب «براساس آخرین اقدام»، همهٔ کاربران نقش‌های دریافت‌کننده باید اقدام کنند. تعداد نقش‌ها با تعداد اعضای آن نقش‌ها یکسان نیست.
این گزینه زمان عبور User Task را تنظیم می‌کند. محاسبهٔ رأی و انتخاب خروجی در Complex Gateway بعدی، تنظیم‌های همان Gateway را نیز دارد؛ رفتار همهٔ ارجاع‌های هم‌زمان را فقط از عنوان یکی از این گزینه‌ها نتیجه نگیرید.
↑ بازگشت به فهرست آموزشثبت داده در انتظار آخرین اقدام
انتظار برای «آخرین اقدام» به معنی عقب‌افتادن همهٔ عملیات ذخیره تا نفر آخر نیست. در سناریوی چندگیرنده‌ای، هر اقدام مجاز می‌تواند عملیات فرم و ثبت خروجی Variable خود را انجام دهد، در حالی که ادامهٔ مسیر هنوز منتظر پاسخ‌های باقی‌مانده است. اگر چند نفر روی همان رکورد یا Variable می‌نویسند، مقدار آخر و تاریخچهٔ ثبت‌ها را با هویت اقدام‌کننده بررسی کنید؛ برای نگه‌داشتن نظرهای مستقل، قرارداد ذخیرهٔ نظرها را جدا از آخرین مقدار مشترک طراحی کنید. رسیدن به نصاب رأی در Complex Gateway موضوع دیگری است.
↑ بازگشت به فهرست آموزشتفکیک ارجاع براساس هر اقدام یا آخرین اقدام
در تنظیمات UserTask، پس از فعال‌کردن «تفکیک ارجاع براساس اقدام»، فهرست روش تفکیک ظاهر می‌شود. دو گزینهٔ قابل مشاهده «براساس هر اقدام» و «براساس آخرین اقدام» هستند. در حالت هر اقدام، ارزیابی ادامه پس از هر پاسخ انجام می‌شود؛ آخرین اقدام تا تکمیل پاسخ‌های لازم منتظر می‌ماند. اگر «اولین کاربر از نقش» فعال باشد، یک پاسخ برای هر نقش کافی است و سایر اعضای همان نقش دیگر سهم جداگانه‌ای ندارند. محاسبهٔ درصد رأی‌ها را با انتخاب آخرین Action یکی ندانید؛ تنظیم Complex Gateway را همراه تنظیم ارجاع User Task بخوانید.
User Task مستقیم بعد از Start و مالکیت شروع‌کننده
اگر Start مستقیماً به User Task برسد، اولین User Task متعلق به همان کاربری است که نمونه را آغاز کرده است. حتی اگر افراد دیگری برای Start Lane مجاز باشند، این فرم اولیهٔ درخواست او برای همهٔ آنها ارجاع عادی نمی‌شود. حالت اجرایی IsAfterStart به همین ارتباط مستقیم اشاره دارد.
اگر شروع‌کننده فرم نخست را رها کند، مورد در کارتابل ثبت موقت او می‌ماند تا شروع‌های نیمه‌کاره کارتابل ورودی را پر نکنند. این قرارگیری به‌تنهایی به معنی ذخیرهٔ دادهٔ Form نیست. User Task دوم، حتی در همان Lane، این استثنای گام نخست را ندارد و مطابق دسترسی عادی گیرندگان Lane در کارتابل ورودی قرار می‌گیرد.
↑ بازگشت به فهرست آموزشرونوشت و تفویض: دو اجازه با نتیجهٔ متفاوت
رونوشت برای User Task با Form در حالت «نمایش» فعال می‌شود. وقتی مسیر به این گام برسد، مورد به کارتابل گیرنده می‌رود و Process بدون انتظار برای رسیدگی او به گام بعد ادامه می‌دهد. ممکن است نمونه پایان یافته باشد و رونوشت آن هنوز در انتظار مشاهده یا رسیدگی بماند.
«امکان تفویض اختیار» اجازهٔ دیگری است: قانون تفویض فقط زمانی می‌تواند روی این User Task اثر بگذارد که طراح آن را فعال کرده باشد. داشتن مجوز عمومی مدیریت تفویض یا ثبت قانون تفویض به‌تنهایی، خاموش‌بودن این گزینه در گام را جبران نمی‌کند.
↑ بازگشت به فهرست آموزشپیشفرض اجازه‌های User Task و مجوز عمومی کاربر
| امکان در طراحی User Task | پیش‌فرض توضیح‌داده‌شده |
|---|---|
| مشاهدهٔ تاریخچهٔ Process | فعال |
| تفویض اختیار | فعال |
| ارجاع گروهی | غیرفعال |
| مشاهدهٔ روند Process | غیرفعال |
این جدول پیش‌فرض تنظیم گام را بیان می‌کند. برای استفادهٔ واقعی، کاربر باید مجوز عمومی همان قابلیت را نیز داشته باشد. فعال‌کردن گزینهٔ User Task به‌تنهایی مجوز عمومی سامانه را به کاربر نمی‌دهد.
تاریخچه، رخدادهای مورد را در پنجرهٔ مربوط نشان می‌دهد. روند، همین عبور اجرایی را روی مدل BPMN نمایش می‌دهد تا مسیر طی‌شده مشخص باشد. مجوز این دو مستقل است؛ امکان دیدن تاریخچه را مجوز مشاهدهٔ مدل و روند ندانید.
↑ بازگشت به فهرست آموزشثبت موقت Form و ثبت موقت در Tabها
با فعال بودن «امکان ثبت موقت فرم»، کاربر می‌تواند داده ناتمام را برای ادامه نگه دارد. ثبت موقت به معنی انتخاب Action نهایی و عبور از گام نیست. در نمای Form، «ثبت موقت» و «ذخیره» دو دکمه مجزا هستند و لینک راهنما کنار ثبت موقت دیده می‌شود.
«تنظیم تب‌ها» برای تنظیم ثبت موقت در Tab Panel به کار می‌رود. Tab Panel موردنظر را انتخاب و با «افزودن» وارد تنظیم کنید. کارت آن، عنوان و نام فنی، Icon حذف، تعداد Tabهای فعال و فهرست Tabها را دارد. برای هر زبانه کلید فعال و حالت ثبت موقت تعیین می‌شود؛ در نمونه حالت «تب بعدی» و امکان انتخاب «دکمه» دیده می‌شود.
راهنمای بخش «تب پنل اقدامات» می‌گوید دکمه‌های عملیاتی به‌صورت پیش‌فرض در انتهای Form نمایش داده می‌شوند. پس از تنظیم Tab Panel، محل نمایش اقدامات را کنترل کنید؛ نمونه توضیح می‌دهد اقدامات روی آخرین زبانه فعال Tab Panel انتخاب‌شده نمایش داده می‌شوند. برای هر زبانه غیرفعال، نتیجه را با وضعیت Form اجرایی تطبیق دهید.
↑ بازگشت به فهرست آموزشثبت موقت در گام جاری و ادامه از همان Inbox
دکمهٔ «ثبت موقت» برای نگهداری دادهٔ Form بدون عبور Process از گام جاری است. کاربر می‌تواند بخشی از کار را انجام دهد، ذخیرهٔ موقت کند و بعد تکمیل را ادامه دهد. برای ادامهٔ گردش، اقدام نهایی گام لازم است.
با زدن این دکمه، مورد در کارتابل ورودی می‌ماند و با آیکن وضعیت متفاوت قابل تشخیص است؛ به کارتابل ثبت موقت منتقل نمی‌شود. کارتابل ثبت موقتِ شروع، مربوط به حالت دیگری است: آغاز نمونه و رهاکردن اولین User Task مستقیم بعد از Start. این دو وضعیت را با هم یکی ندانید.
در Form دارای TabPanel، می‌توان ثبت موقت را برای TabPanel و Tab مشخص تنظیم کرد: دکمهٔ جداگانه روی همان Tab یا ثبت هنگام رفتن به Tab بعد. همچنین می‌توان کنترل ثبت موقت عمومی را نداشت و فقط ثبت موقت تب‌های موردنیاز را ارائه کرد. Tab فعال اولیه و trigger ثبت موقت دو تنظیم جدا هستند.
برای تشخیص مورد موقت در Inbox، نشان پاکت را بررسی کنید: پاکت عادی با نشان وضعیت موقت/تعجب جایگزین می‌شود. ادامه همان ردیف را باز کنید؛ برای تکمیل ثبت قبلی، Process جدید آغاز نکنید.
↑ بازگشت به فهرست آموزشلغو نمونه Process و تفاوت آن با بازگشت
وقتی «امکان لغو فرآیند» برای گام فعال باشد، دکمه «لغو فرآیند» در صفحه Form قابل ارائه است. این دکمه با «بازگشت به کارتابل» فرق دارد: بازگشت صرفاً مسیر مشاهده را تغییر می‌دهد؛ لغو، عملیات مربوط به نمونه جاری Process است.
پنجره هشدار از کاربر درباره حذف اطلاعات جاری مربوط به Process تأیید می‌گیرد و «بله/خیر» دارد. متن هشدار را پیش از انتخاب بخوانید. پنجره توضیحات لغو نیز برای ثبت دلیل وجود دارد و «ذخیره» و «بستن» دارد.
حذف یا لغو اطلاعات فرایندی را به حذف همه Recordهای Form یا اثرهای انجامشده در سیستمهای بیرونی تعمیم ندهید؛ دامنه حذف داده‌های فرایندی و داده‌های کسب‌وکار جداست.
↑ بازگشت به فهرست آموزشلغو ProcessCreation از فرم گام
با فعال‌کردن «امکان لغو فرآیند»، دکمهٔ لغو بالای Form نمایش داده می‌شود. کاربر پس از تأیید، کل نمونهٔ جاری را لغو می‌کند؛ این فرمان صرفاً بستن Form یا رهاکردن ویرایش نیست. شرح لغو می‌تواند در DiscardDescription ثبت شود تا علت آن در گزارش مشخص باشد.
Timerهای میانی و Boundary و کارهای کارتابلی همان نمونه از مدار خارج می‌شوند و وضعیت Finish نمونه پایان‌یافته می‌شود. این پایان از نوع لغو است؛ آن را با موفقیت مسیر عادی یا اجرای خروجی‌های End یکسان ندانید. تاریخچه و شرح لغو برای تشخیص نتیجه باقی می‌مانند.
در اطلاعات اجرایی این لغو، مقدار Finish برابر 1 می‌شود؛ شرح اختیاری لغو از DiscardDescription قابل پیگیری است. این فلگ به‌تنهایی دلیل پایان موفق کسب‌وکار نیست.
ServiceTask؛ اجرای منبع داده
ServiceTask منبع داده را در مسیر فرآیند اجرا می‌کند. این گام می‌تواند اطلاعات بخواند، محاسبه انجام دهد یا داده‌ای را تغییر دهد. بر خلاف UserTask، برای تکمیل این کار فرم انسانی باز نمی‌شود. داده ورودی باید از ثابت‌ها، متغیرهای آماده یا تابع تنظیم‌شده تأمین شود.
انتخاب منبع داده و مقداردهی پارامترها
- نوع گام را Service Task انتخاب و عنوان کار آن را وارد کنید.
- مدیریت منبع داده را باز کنید.
- منبع داده مورد نیاز را انتخاب کنید یا در همان پنجره منبع لازم را ایجاد و تنظیم کنید.
- نام و نوع منبع انتخاب‌شده را در پنل گام بررسی کنید.
- برای هر پارامتر ورودی، منبع مقدار را مشخص کنید: مقدار ثابت، متغیر، تابع یا خالی در صورت قابل قبول بودن برای منبع.
- برای ورودی متغیری، حالت ساده یا مسیر پیشرفته مناسب را تنظیم کنید.
- اگر نتیجه در ادامه لازم است، خروجی گام را روی متغیر مورد نظر قرار دهید.
- تنظیمات پنجره منبع داده، پنل گام و کل فرآیند را ذخیره کنید.
برای نمونه، سرویس محاسبه مدت می‌تواند تاریخ شروع و پایان را از فرم بگیرد:
| پارامتر نمونه سرویس | منبع مقدار |
|---|---|
StartDate |
@@SavedData:FormData['SDateTime'] |
EndDate |
@@SavedData:FormData['EDateTime'] |
نام‌های سمت چپ باید با قرارداد منبع داده‌ای که انتخاب کرده‌اید یکسان باشند. نام‌های سمت راست نیز باید از نام فنی فیلدهای فرم شما گرفته شوند. اگر سرویس یک ستون مدت برمی‌گرداند، مصرف ساده خروجی فقط زمانی درست است که همان ستون، اولین مقدار خروجی باشد؛ برای قرارداد روشن‌تر، نام ستون را در مسیر پیشرفته تعیین کنید.
مصرف نتیجه سرویس
اگر خروجی در متغیر @@DurationData ثبت و به شکل زیر باشد:
{
"ServiceData": [
{"Duration": 3}
]
}
برای شرط Gateway یا مقدار یک فیلد می‌توانید از این مسیر استفاده کنید:
@@DurationData:ServiceData[0]['Duration']
خروجی چندسطره را برای زیر‌فرم با همه داده‌ها مصرف کنید و برای مقدار یک فیلد، سطر و ستون لازم را مشخص کنید. اگر ستون مورد نیاز در نتیجه وجود ندارد، تغییر عنوان نمایشی فیلد مشکل را حل نمی‌کند؛ خروجی واقعی منبع و مسیر باید سازگار باشند.
خروجی خالی، مقدار Null و عملیات بدون نتیجه
بین یک نتیجه که مقدار ستونش Null است و منبعی که اصلاً مجموعه نتیجه برنمی‌گرداند تفاوت وجود دارد. برای مثال، SELECT NULL AS Value همچنان خروجی جدولی با یک ستون دارد. اما منبعی که فقط عملیات تغییر داده انجام می‌دهد و هیچ نتیجه‌ای برنمی‌گرداند، ممکن است خروجی قابل ثبت در متغیر نداشته باشد.
وقتی متغیر خروجی انتخاب کرده‌اید و منبع هیچ نتیجه‌ای برنمی‌گرداند، پیام داده‌های خروجی سرویس نامعتبر است می‌تواند ادامه را متوقف کند. اگر نبودن نتیجه با هدف سرویس سازگار است، گزینه مجاز بودن خروجی Null را در تنظیمات گام فعال کنید. اگر نتیجه برای گام بعد لازم است، قرارداد منبع را اصلاح کنید تا مقدار قابل مصرف برگرداند؛ فعال‌کردن پذیرش Null مقدار گمشده تولید نمی‌کند.
برای سرویسی که صرفاً داده را تغییر می‌دهد، مشخص کنید آیا ادامه واقعاً به خروجی آن نیاز دارد. خروجی غیرضروری را فقط به امید ساخته‌شدن مقدار در متغیر تنظیم نکنید. در مقابل، برای ایجاد یک رکورد یا کار همراه که شناسه آن در ادامه لازم است، بازگرداندن شناسه بخشی از قرارداد سرویس است.
انتخاب ServiceTask یا ScriptTask
اگر کار به خواندن یا تغییر داده در منبع داده وابسته است، ServiceTask محل مناسبی برای نگه‌داشتن قرارداد آن است. اگر داده از قبل در متغیرها حاضر است و فقط محاسبه، تبدیل یا ساخت خروجی لازم دارید، ScriptTask می‌تواند آن کار را انجام دهد. برای یک محاسبه ساده زمانی لازم نیست فقط برای محاسبه به پایگاه داده رفت؛ از سوی دیگر، منتقل‌کردن حجم زیادی از داده برای محاسبه‌ای که در منبع داده قابل انجام است ممکن است مناسب نباشد. انتخاب را بر اساس محل داده و حجم واقعی آن انجام دهید.
برای طراحی مسیر رسیدگی به خطای گام به Eventها مراجعه کنید.
↑ بازگشت به فهرست آموزشService Task؛ از انتخاب منبع داده تا مصرف نتیجه
«مدیریت منبع داده» پنل مشترک Provider را باز می‌کند و امکان انتخاب منبع داده موجود یا ایجاد منبع داده را می‌دهد. نوع منبع می‌تواند کوئری ساده، کوئری پیشرفته، تابع، رویه ذخیره‌شده یا نوع پشتیبانی‌شده دیگری باشد؛ Service Task نتیجه آن را برای ادامه Process دریافت می‌کند.
پس از انتخاب Provider، «مدیریت پارامترها» را باز کنید. هر ورودی را با روش خالی، مقدار ثابت، Variable یا Function مقدار دهید. انتخاب Variable می‌تواند به تمام داده یا بخش مشخصی از FormData/ServiceData متصل باشد. پارامترهای Provider از انتخاب خود Provider جدا هستند؛ منبع داده بدون ورودی‌های لازم آماده اجرا نیست.
در نمونه TaskCreate، رویه ذخیره‌شده اطلاعات لازم برای ایجاد Task همراه را می‌گیرد و TaskID برمی‌گرداند. DefaultData یکی از ورودی‌های نمونه است و می‌تواند از مقدار ثابت یا داده متغیر ساخته شود. در «تنظیمات خروجی»، Variable دریافت‌کننده نتیجه را انتخاب کنید تا TaskID در گام‌های بعدی قابل مصرف باشد.
ترتیب اجرا چنین است: با رسیدن نمونه به Service Task، ابتدا مقدار ورودی‌ها مطابق تنظیمات تولید می‌شود، سپس Provider اجرا می‌شود و در پایان نتیجه در Variable خروجی قرار می‌گیرد. مقادیر پویا در زمان اجرا خوانده می‌شوند؛ نمایش آنها در پنل طراحی به معنی اجرای قبلی Provider نیست.
↑ بازگشت به فهرست آموزشمثال Service Task: محاسبه مدت و کنترل دوباره درخواست اصلاح‌شده
پس از User Task ثبت درخواست، یک Service Task قرار دهید تا فاصله تاریخ شروع و پایان را به روز محاسبه کند. Provider مثال دو ورودی دارد: مقدار شروع از @@SavedData:FormData['SDateTime'] و مقدار پایان از @@SavedData:FormData['EDateTime']. نام فنی این دو فیلد باید با Form واقعی شما برابر باشد؛ عنوان فارسی کنترل جای نام فنی آن نیست.
- پارامترها را از خروجی User Task مقداردهی کنید.
- نتیجه محاسبه را در Variable جداگانه، مانند
@@DurationDataنگه دارید. - پس از Service Task یک Exclusive Gateway بگذارید. مسیر بررسی جانشین را برای مدت کوچک‌تر یا مساوی ۱۰ روز و مسیر دیگر را برای خروج از این سناریو تنظیم کنید.
- به‌جای تکرار شرط بزرگ‌تر از ۱۰، می‌توانید مسیر دوم را Default Flow قرار دهید؛ این مسیر شرط مستقلی ندارد.
- یک درخواست چهارروزه باید وارد بررسی جانشین و درخواست چهارده‌روزه باید وارد مسیر دیگر شود. عدد ۱۰ قانون کسب‌وکار این مثال است، نه محدودیت عمومی GraphBPMS.
- مسیر برگشت برای اصلاح را به User Task درخواست‌کننده وصل کنید و عبور دوباره از Service Task را حفظ کنید. اگر درخواست چهارروزه پس از برگشت به چهارده روز تغییر کند، شرط باید دوباره با داده تازه ارزیابی شود.
پارامتر ورودی سرویس، مقدار خوانده‌شده از Variable است. تغییر یک مقدار در محاسبه Provider، به‌تنهایی رکورد Form مبدأ را ویرایش نمی‌کند. برای تشخیص خطا، داده Form، Variable ورودی و خروجی محاسبه را جدا بررسی کنید.
↑ بازگشت به فهرست آموزشتشخیص خطای Provider در Service Task
در عیب‌یابی ServiceTask، پنجرهٔ جزئیات خطا می‌تواند نام کلاس، متد یا تابع و شماره خط را نشان دهد. بخش «جزئیات خطای پروایدر» شناسه، نام و نوع Provider را جدا می‌کند؛ جدول پارامترهای ورودی نیز نام ورودی، نوع مقداردهی از فرآیند، مقدار ورودی و متغیر یا مقدار ثابت فرآیند را دارد. خالی‌بودن جدول در این مثال به‌تنهایی ثابت نمی‌کند که Provider در همهٔ اجراها بدون ورودی است.
Send Task: مفهوم BPMN و تنظیمات GraphBPMS
در BPMN 2.0، Send Task برای فرستادن Message به Participant بیرون از Process تعریف می‌شود و با ارسال پیام به پایان می‌رسد. نماد آن Task با گوشه‌های گرد و پاکت پُر است. این تعریف مفهومی استاندارد است؛ تنظیمات اجرایی GraphBPMS باید بر اساس قابلیت‌های خود محصول انجام شود. مرجع رسمی OMG، BPMN 2.0.2، بخش Send Task.
در GraphBPMS پنل SendTask از «مدیریت منبع داده» و «مدیریت پارامترها» استفاده می‌کند. برای این Node، منبع داده مرتبط با عملیات ارسال را انتخاب و پارامترهای موردنیازش را مقداردهی کنید. وجود عنوان Send Task به معنی ارسال خودکار ایمیل، پیامک یا انتخاب خودکار کانال ارتباطی نیست؛ عملیات واقعی را منبع داده تنظیم‌شده تعیین می‌کند.
| تنظیم | شرح |
|---|---|
| عنوان و توضیحات | عنوان Node در مدل و توضیح فنی آن. |
| مدیریت منبع داده | انتخاب منبع داده؛ کارت زیر دکمه شناسه، عنوان و نوع منبع را نشان می‌دهد. در نمونه، نوع «پرس و جو (Query)» است. |
| مدیریت پارامترها | مقداردهی ورودی‌های منبع داده با روش‌های متعارف انتساب مقدار. |
| تنظیمات خروجی | انتخاب «بدون خروجی» یا «متغیر». برای خروجی Variable، ساختار ServiceData کاربرد دارد. |
| تنظیمات عنوان (اختیاری) | کنترل عنوان اجرایی سفارشی، در صورت فعال‌سازی. |
| تنظیمات اعلان شرح ارجاع | تنظیم شرح ارجاع متناسب با این گام. |
| ذخیره تغییرات | ثبت پیکربندی این Node. |
- Send Task را انتخاب کنید و عنوان متناسب با عملیات تعیین کنید.
- منبع دادهٔ مناسب عملیات را انتخاب کنید و شناسه، عنوان و نوع آن را کنترل کنید.
- ورودی‌های منبع را در مدیریت پارامترها تنظیم کنید.
- اگر مراحل بعد به نتیجه نیاز دارند، خروجی را در یک Variable قرار دهید.
- تنظیمات اختیاری عنوان و شرح ارجاع را در صورت نیاز تکمیل کنید.
- ذخیره و سپس نتیجه واقعی منبع داده و متغیر خروجی را در محیط تست بررسی کنید.
نیازمند تأیید فنی: تضمین تحویل پیام به گیرنده، Retry اختصاصی ارسال، Timeout و تفاوت داخلی اجرای SendTask با ServiceTask از این تنظیمات به‌تنهایی تعیین نمی‌شود؛ این رفتارها را به Node نسبت ندهید مگر در استقرار مقصد تأیید شوند.
↑ بازگشت به فهرست آموزشReceiveTask؛ انتظار برای ادامه از بیرون
ReceiveTask زمانی مناسب است که کار در فرآیند به نقطه انتظار برسد و یک عملیات بیرونی، مانند دکمه‌ای در کارتابل اختصاصی، آن را ادامه دهد. رسیدن به این گام ابتدا منبع داده تنظیم‌شده را اجرا می‌کند؛ سپس همان نمونه فرآیند منتظر فرمان ادامه می‌ماند.
برای اینکه بیرون از فرآیند بتوان به انتظار درست اشاره کرد، باید شماره ایجاد فرآیند و شماره گام انتظار در اطلاعات قابل مراجعه ثبت شوند. عنوان درخواست به‌تنهایی برای تشخیص نمونه و گام کافی نیست.
ساخت انتظار و ثبت شناسه‌ها
- پیش از ReceiveTask، اطلاعات مورد نیاز درخواست را تولید کنید؛ برای نمونه خروجی یک UserTask را در
@@Reqنگه دارید. - نوع گام را Receive Task انتخاب کنید و عنوانی مانند انتظار پاسخ درخواست بدهید.
- منبع داده گام را برای ثبت یا آماده‌کردن اطلاعات انتظار تنظیم کنید.
- ورودی شماره گام را از
@@CurrentStepsو شماره ایجاد فرآیند را از@@ProcessCreationIDتأمین کنید. - داده‌های تکمیلی مانند عنوان و توضیح درخواست را از متغیر مربوط بدهید.
- اگر شناسه رکورد ثبت‌شده در ادامه لازم است، خروجی منبع داده را در متغیری نگه دارید.
- کاربر معتبر برای ادامه و سایر تنظیمات لازم گام را بررسی و ذخیره کنید.
این دو ورودی سیستمی جزو الزامات تنظیم ReceiveTask هستند؛ حذف یا جایگزینی نادرست آنها می‌تواند موجب رد شدن ذخیره تنظیمات شود. نام پارامترهای منبع داده می‌تواند اختصاصی باشد، اما مقدار شماره گام و شماره ایجاد باید از متغیر سیستمی درست بیاید.
| پارامتر نمونه منبع داده | مقدار |
|---|---|
ProcessStepId |
@@CurrentSteps |
ProcessCreationId |
@@ProcessCreationID |
RequestTitle |
@@Req:FormData['ReqTitle'] |
RequestDescription |
@@Req:FormData['ReqDesc'] |
Accepted |
ثابت 0 برای وضعیت اولیه قرارداد این فهرست |
اجازه ادامه و هویت فراخواننده
گزینه کاربر معتبر یا Valid User، هویتی را مشخص می‌کند که برای ادامه این انتظار مجاز است. آن را با گیرنده Lane یا کاربری که فقط فهرست درخواست‌ها را می‌بیند یکسان فرض نکنید. در ادامه بیرونی، توکن باید مربوط به هویت مجاز باشد؛ نمایش دکمه در فرم به‌تنهایی مجوز ادامه ایجاد نمی‌کند.
برای احراز هویت از روش تعریف‌شده محیط استفاده کنید و خروجی Token را به عملیات ادامه بدهید. وقتی دریافت توکن و ادامه فرآیند دو عملیات جدا هستند، آنها را ترتیبی اجرا کنید؛ ادامه باید بعد از دریافت موفق توکن انجام شود تا با مقدار خالی یا قدیمی فراخوانی نشود.
اتصال دکمه کارتابل اختصاصی به انتظار
یک فرم معمولی می‌تواند فهرست درخواست‌های منتظر را در زیر‌فرم نمایش دهد. در هر ردیف، شناسه نمونه و گام ثبت‌شده را نگه دارید. دکمه ادامه باید مقادیر همان ردیف انتخاب‌شده را ارسال کند.
در منبع سیستمی ادامه فرآیند از طریق مسیج، داده‌های اصلی عبارت‌اند از:
| ورودی | منبع مقدار |
|---|---|
Token |
نتیجه احراز هویت معتبر. |
ProcessCreationId |
شماره ایجاد فرآیند ذخیره‌شده در ردیف انتخابی. |
Step |
شماره گام انتظار ذخیره‌شده در همان ردیف. |
Variables |
در صورت نیاز، فهرست متغیرهایی که همراه ادامه به فرآیند داده می‌شوند. |
برای Variables، ساختار فهرست نام و مقدار را رعایت کنید. مثال زیر صرفاً داده نمونه برای انتقال نتیجه است:
[
{"Name": "@@ExternalResult", "Value": "1"},
{"Name": "@@ExternalNote", "Value": "بررسی تکمیل شد"}
]
متغیرهایی را ارسال کنید که منطق ادامه واقعاً می‌شناسد و مصرف می‌کند. شماره ایجاد یک درخواست را با Step درخواست دیگر ترکیب نکنید. همچنین پس از تکمیل انتظار، همان فرمان را به عنوان یک شروع تازه تکرار نکنید؛ عملیات ادامه به انتظار فعال اشاره دارد.
به‌روزرسانی فهرست پس از ادامه
اگر فهرست اختصاصی با شرط Accepted = 0 داده می‌گیرد، پس از ادامه موفق باید منطق لازم برای تغییر وضعیت رکورد نیز اجرا شود. یک راه، قرار دادن ServiceTask بعد از ReceiveTask است که همان رکورد را با شناسه نگه‌داری‌شده به Accepted = 1 تغییر دهد. سپس فرم فهرست را بازخوانی کند تا ردیف از نتایج شرط اولیه خارج شود.
ناپدیدشدن ردیف در این طراحی حاصل تغییر وضعیت توسط سرویس و بازخوانی فهرست است. فرمان ادامه به‌تنهایی رکورد منبع داده اختصاصی را حذف نمی‌کند. پیام موفقیت سفارشی فرم نیز فقط زمانی نمایش داده شود که نتیجه عملیات موفق بوده است.
برای طراحی انتظار روی یک گام موجود، Message Boundary و برای آغاز نمونه جدید از بیرون، Message Start را در Eventها ببینید. ReceiveTask نقطه انتظار مستقلی در میانه اجرای موجود است.
Send Task، Receive Task و خروجی تهی
Send Task منبع دادهٔ عملیات ارسال را اجرا می‌کند و خروجی انتخاب‌شده را در Variable نگه می‌دارد؛ کانال واقعی ایمیل یا پیامک تابع Provider است. نبود کلید پذیرش Null در یک پنل را به قاعدهٔ ثابت همهٔ نسخهها تبدیل نکنید. برای Send Task و Receive Task، نتیجهٔ تهی و اثر آن هنگام ذخیره در Variable باید با قرارداد Node و استقرار مقصد بررسی شود؛ مصرف‌کنندهٔ بعدی را بدون دادهٔ معتبر رها نکنید.
Receive Task ابتدا Provider را اجرا می‌کند و سپس منتظر ادامه بیرونی می‌ماند. هویت مجاز برای Trigger، Token معتبر، ProcessCreationID و Step باید مربوط به همان انتظار فعال باشند. بعد از تکمیل، تکرار Trigger نباید به‌عنوان شروع نمونه تازه استفاده شود.
پنل Service Task و Receive Task
پنل ServiceTask، منبع داده انتخاب‌شده را با شناسه، عنوان و نوع نشان می‌دهد و بخش جدا برای مدیریت پارامترها دارد. تنظیمات خروجی، عنوان اختیاری، شرح ارجاع و خروجی Null نیز در همین پنل هستند. برای عملیات بدون خروجی، معنای نتیجه Null و گزینه پذیرش آن را با رفتار Provider هماهنگ کنید.
ReceiveTask نیز ابتدا Provider و ورودی‌های آن را تنظیم می‌کند و سپس انتظار ادامه بیرونی دارد. پنل آن فیلد «کاربر معتبر» را نشان می‌دهد؛ هویت فراخواننده ادامه باید با قانون انتظار سازگار باشد.
برای امکان شناسایی انتظار از بیرون، می‌توان شناسه نمونه و گام جاری را به Provider داد. نمونه جدول پارامترها، first را از @@ProcessCreationID و second را از @@CurrentSteps مقداردهی می‌کند. نام‌های first و second متعلق به Provider نمونه‌اند؛ قرارداد Provider واقعی را رعایت کنید.
این شناسه‌ها برای ادامه همان انتظار به کار می‌روند. تغییر عنوان Node یا ارسال شناسه Process به جای ProcessCreationID انتظار را شناسایی نمی‌کند. شرح روش‌های ادامه Message در مرجع API آمده است.
↑ بازگشت به فهرست آموزشقرارداد مشترک Receive Task و Message Boundary
Receive Task یک انتظار مستقل در مسیر فرآیند است. Message Boundary به User Task وصل می‌شود و با دریافت پیام، انتظار آن میزبان را قطع می‌کند. هر دو برای ادامهٔ بیرونی به شناسهٔ نمونه و گام منتظر نیاز دارند؛ این دو مقدار را با @@ProcessCreationID و @@CurrentSteps در ورودی Provider ثبت انتظار مقداردهی کنید.
مصرف‌کنندهٔ بیرونی باید همان زوج شناسه را همراه هویت مجاز در فراخوان ادامه به کار ببرد. شناسهٔ تعریف Process، شناسهٔ رکورد فرم و شناسهٔ نمونه قابل جایگزینی با یکدیگر نیستند. تنظیمات خروجی Node، نتیجهٔ Provider ثبت انتظار را نگه می‌دارد؛ آماده‌بودن آن نتیجه به معنی دریافت پیام یا تکمیل انتظار نیست.
↑ بازگشت به فهرست آموزشچرخهٔ انتظار در Receive Task
نمونه با رسیدن به Receive Task، Provider آن را اجرا می‌کند و سپس در همان گام می‌ماند تا ادامهٔ بیرونی مجاز دریافت شود. نتیجهٔ Provider می‌تواند در Variable خروجی ذخیره شود، اما موفقیت آن اجرا به‌تنهایی مسیر را جلو نمی‌برد. عنوان اختیاری و شرح ارجاع نیز طبق تنظیمات مشترک قابل تعریف‌اند.
ScriptTask؛ محاسبه و تبدیل داده با اسکریپت
ScriptTask امکان نوشتن منطق با JavaScript یا C# را فراهم می‌کند. می‌توانید پارامتر بگیرید، داده یک متغیر را بخوانید، محاسبه انجام دهید و نتیجه را برای فرم، Gateway، عنوان اجرا یا Event بعدی در متغیر نگه دارید.
تنظیم گام و ورودی‌ها
- نوع گام را Script Task انتخاب کنید و عنوان کار آن را بنویسید.
- زبان اسکریپت را انتخاب کنید.
- تنظیم مقادیر ورودی را باز کنید و برای هر ورودی، نام و منبع مقدار را تعیین کنید.
- ویرایشگر یا IDE را باز کنید و کد را در قالب زبان انتخابی بنویسید.
- اسکریپت را از پنجره اجرای آزمایشی، با پارامترهای روشن اجرا و نتیجه یا پیام خطا را بررسی کنید.
- متغیر خروجی و زمان مجاز اجرا را تنظیم کنید.
- کد، تنظیمات گام و کل فرآیند را ذخیره کنید.
قبل از تغییر زبان، متن کد خود را نگه دارید. تغییر زبان می‌تواند ویرایشگر را با قالب زبان تازه مقداردهی کند؛ رفتن از C# به JavaScript و برگشت دوباره را روش نگه‌داشتن دو نسخه کد فرض نکنید.
برای ورودی نمونه Amir، می‌توانید مقدار ثابت 123 بدهید یا مقدار آن را از یک متغیر فرآیند بخوانید. نام Amir کلیدی است که داخل اسکریپت به آن مراجعه می‌کنید؛ با عنوان نمایشی متغیر فرآیند یکسان بودن آن الزامی نیست.
قالب ورودی و خروجی در C#
در قالب C#، تابع Main پارامترها را در دیکشنری args دریافت می‌کند و نتیجه با return برگردانده می‌شود. مثال زیر زمان یک دقیقه بعد از زمان جاری را برمی‌گرداند:
using System;
using System.Collections.Generic;
namespace RTC
{
public class MyClass : ProcessRunTimePlugin
{
public override object Main(IDictionary<string, object> args)
{
return DateTime.Now.AddMinutes(1);
}
}
}
برای برگرداندن مقدار ورودی نمونه، می‌توانید دستور تابع را به return args["Amir"]; تغییر دهید. در این حالت کلید Amir باید در ورودی وجود داشته باشد. اگر کلید در دیکشنری نیست، نام و مقدار ورودی را بررسی کنید. تابعی که قرار است خروجی داشته باشد باید مقدار برگرداند؛ خطای نبودن return با انتخاب متغیر خروجی برطرف نمی‌شود.
قالب ورودی و خروجی در JavaScript
در JavaScript پارامترها از args خوانده می‌شوند و نتیجه نهایی باید در result قرار بگیرد:
result = new Date(new Date().getTime() + 60 * 1000);
برای برگرداندن ورودی، result = args.Amir; یا result = args["Amir"]; را به کار ببرید. اگر چند بار به result مقدار بدهید، آخرین مقدار آن نتیجه نهایی می‌شود؛ بنابراین خطی که در پایان result را بازنویسی می‌کند می‌تواند نتیجه محاسبه قبل را تغییر دهد.
اجرای آزمایشی و تفاوت آن با اجرای فرآیند
پنجره اجرای آزمایشی امکان واردکردن پارامتر، اجرای کد و دیدن نوع و مقدار نتیجه را می‌دهد. فهرست ورودی‌ای را که واقعاً در این پنجره ارسال می‌شود بررسی کنید. تنظیم پارامتر در پنل Task به‌تنهایی به معنی حضور مقدار مورد نیاز در هر بار اجرای آزمایشی نیست؛ در صورت نیاز پارامتر را در همان پنجره اضافه یا مقداردهی کنید.
برای مثال، اگر کد از args["Amir"] می‌خواند، همین کلید را با مقدار 1234 در اجرای آزمایشی وارد کنید. نتیجه این اجرا باید همان مقدار آزمایشی باشد، نه لزوماً مقدار 123 که در تنظیم ورودی Task گذاشته‌اید. وجود پارامتر اضافی بدون استفاده، خودبه‌خود به معنای خطا نیست؛ نبودن پارامتری که کد می‌خواند مسئله متفاوتی است.
خواندن متغیر یک نمونه فرآیند به شماره مدل و شماره ایجاد آن نمونه وابسته است. در اجرای مستقل اسکریپت، یک اجرای تازه فرآیند به‌طور ضمنی ساخته نمی‌شود تا متغیرهای آن موجود باشند. برای بررسی متغیر ذخیره‌شده، باید به اجرای مشخصی اشاره کنید که قبلاً مقدار مورد نیاز را ثبت کرده است. شناسه‌های مورد استفاده برای این بررسی را در نسخه نهایی کد ثابت رها نکنید؛ در اجرای واقعی از ورودی‌های متناسب با نمونه جاری استفاده کنید.
خواندن و محاسبه روی داده یک متغیر
اگر خروجی سرویسِ فهرست درخواست‌ها در @@PastReqVacations ثبت شده باشد، می‌توانید کل ServiceData را بخوانید و تعداد ردیف‌ها را محاسبه کنید. در اجرای واقعی Script Task، ProcessID و ProcessCreationID ورودی‌های سیستمی نسخه و نمونهٔ جاری هستند و از args خوانده می‌شوند. برای اجرای مستقل آزمایشی، مقدارهای نمونهٔ موجود را در پنجرهٔ تست تأمین کنید.
using System;
using System.Collections.Generic;
using Newtonsoft.Json;
namespace RTC
{
public class MyClass : ProcessRunTimePlugin
{
public override object Main(IDictionary<string, object> args)
{
var processId = Convert.ToInt32(args["ProcessID"]);
var creationId = Convert.ToInt32(args["ProcessCreationID"]);
var json = GetVariableValue<string>(
"@@PastReqVacations:ServiceData",
processId,
creationId);
var rows = JsonConvert.DeserializeObject<dynamic[]>(json);
return new { Count = rows.Length };
}
}
}
این مثال فرض می‌کند سرویس قبلی، JSON معتبرِ آرایه‌ای در متغیر ثبت کرده است. نبودن مقدار یا ساختار متفاوت باید پیش از استفاده از Length رسیدگی شود. تغییر اشیای حاصل از تبدیل JSON در حافظه، به‌تنهایی داده متغیر فرآیند یا جدول فرم را بازنویسی نمی‌کند. اگر نتیجه تبدیل باید در ادامه مصرف شود، آن را خروجی بدهید و متغیر مقصد را تنظیم کنید.
ساختار نتیجه ScriptTask و مسیر مصرف آن
خروجی اسکریپت را با ScriptData نخوانید. برای نتیجه ساده مانند عدد 5، ساختار مصرف به صورت زیر است:
{
"ServiceData": [
{"Result": 5}
]
}
مسیر صریح آن، با فرض متغیر @@Calculation:
@@Calculation:ServiceData[0]['Result']
اگر اسکریپت یک شیء شامل Count برگرداند، نتیجه به شکل زیر مصرف می‌شود:
{
"ServiceData": [
{"Result": {"Count": 5}}
]
}
در این حالت مسیر عدد و قالب نمایش آن در عنوان به‌ترتیب زیر است. نتیجهٔ Count را در Script Task تولید و در @@Calculation ذخیره کنید؛ این قالب عنوان باید در گام بعد از Script Task تنظیم شود، چون خروجی تازهٔ همین گام برای عنوان خودش قابل مصرف نیست.
@@Calculation:ServiceData[0]['Result']['Count']
تعداد درخواست‌ها: |V_Calculation:ServiceData[0]['Result']['Count']|
خروجی آرایه‌ای نیز می‌تواند چند مقدار یا چند شیء داشته باشد. عضو اول با Index صفر و عضو دوم با Index یک انتخاب می‌شود؛ اگر اعضا شیء باشند، پس از انتخاب عضو، نام ویژگی آن را نیز مشخص کنید. برای خروجی آرایه‌ای، قبل از تعیین مسیر مصرف، ساختار واقعی ثبت‌شده را بررسی کنید؛ مسیر نتیجه عددی را بدون بررسی به آرایه تعمیم ندهید.
برای خروجی آرایه‌ای، قبل از تعیین Index و مسیر، ساختار واقعی ثبت‌شده را بررسی کنید. قاعده پیچش نتیجه آرایه را از نتیجه عددی یا شیء نتیجه‌گیری نکنید. برای قراردادی روشن، می‌توانید خروجی را به صورت شیئی با یک ویژگی مشخص، مانند Items، تعریف کنید و همان ویژگی زیر Result را مصرف کنید. این کار همچنین نام و معنای مجموعه خروجی را روشن نگه می‌دارد.
استفاده از نتیجه زمانی و رسیدگی به خطا
اگر اسکریپت زمان اجرای بعدی را محاسبه کرده است، متغیر خروجی را در Timer مصرف کنید. وقتی خروجی همان یک مقدار تاریخ است، حالت ساده می‌تواند آن را به Timer بدهد. تفاوت زمان مطلق و مدت انتظار و محل استفاده از Timer در Eventها آمده است.
در پنل ScriptTask مقدار زمان مجاز اجرا را نیز بررسی کنید. برای خطای نام پارامتر، مسیر متغیر یا کد، همان خطا را اصلاح کنید.
در تنظیمات ScriptTask نیز گزینه مجاز بودن خروجی Null وجود دارد. خروجی مورد نیاز گام بعد را روشن تعریف کنید؛ پذیرش خروجی تهی، داده مورد نیاز مصرف‌کننده را تولید نمی‌کند. برای مسیر جایگزین در مواجهه با خطا، تنظیمات Error Event را ببینید.
زمان مجاز اجرای اسکریپت را متناسب با محاسبه تنظیم کنید. افزایش آن راه‌حل خطای نام پارامتر، مسیر متغیر یا کد نادرست نیست. اگر C# در محیط غیرفعال است، انتخاب آن به اجرای موفق منتهی نمی‌شود و باید تنظیم قابلیت با مسئول سامانه بررسی شود.
برای خروجی تهی نیز قرارداد روشن داشته باشید. اگر گام بعد به نتیجه نیاز دارد، مقدار معتبر و قابل تشخیص برگردانید؛ مانند یک شیء شامل وضعیت و مقدار. وجود گزینه پذیرش خروجی Null را جای مدیریت مقدار ناموجود در کد و مصرف‌کننده نگذارید. خطاهای اسکریپت و توقفهای اجرا از BAM و مدیریت خطاها پیگیری می‌شوند و برای مسیر جایگزین خطا می‌توانید از تنظیمات Error Event استفاده کنید.
محدودیت اجرا و قرارداد Script Task
در نسخه مستندشده، کنترل زمان مجاز Script Task مقدار ۱۰ تا ۹۰ ثانیه و پیش‌فرض ۶۰ ثانیه دارد؛ سقف تنظیم‌شده سرور می‌تواند زمان واقعی را کمتر کند. اجرای C# باید در تنظیمات سرور فعال باشد. JavaScript این محیط را با JavaScript مرورگر یا دسترسی DOM یکسان نگیرید. سه ورودی ProcessID، ProcessCreationID و CurrentElementID در مسیر اجرای مستندشده به‌صورت سیستمی افزوده می‌شوند؛ نام ورودی سفارشی نباید با آنها تصادم کند.
کنترل مسیر داده: پیش از تعیین مسیر برای خروجی آرایه، JSON واقعی Variable Log را بررسی کنید؛ مسیر نتیجهٔ عددی یا شیء را به آرایه تعمیم ندهید. پذیرش خروجی Null با گزینهٔ مربوط در Script Task کنترل می‌شود؛ فعال‌بودن آن دادهٔ جایگزین برای مصرف‌کننده تولید نمی‌کند.
نقش Script Task در گردش داده
Script Task کد C# یا JavaScript را در مسیر Process اجرا می‌کند. برای منطق محاسباتی یا عملیات خواندن و نوشتن Variableها، ورودی‌های لازم را در تنظیمات گام تعریف کنید و خروجی کد را مطابق قرارداد Variable مقصد برگردانید. تعریف Variable و مقدار اجرایی نمونه را از هم تفکیک کنید تا کد، داده همان ProcessCreation را مصرف کند.
↑ بازگشت به فهرست آموزشScript Task: زبان، Timeout، ورودی و خروجی
Script Task برای اجرای منطق کدنویسی‌شده در مسیر Process است. ابتدا زبان اجرای اسکریپت را انتخاب کنید، مقادیر ورودی را تعریف کنید، کد را در IDE تنظیم و قرارداد خروجی را مشخص کنید. مقادیر نمونه و داده فرآیند از طریق ورودی‌های صریح به اسکریپت داده می‌شوند.
| کنترل | کاربرد |
|---|---|
| زبان برنامه‌نویسی انتخابی | زبان کد را تعیین می‌کند؛ نمونه پنل C# است و مثال‌های C# و JavaScript در مرجع فنی آمده‌اند. |
| تایم‌اوت | حد زمان اجرای اسکریپت بر حسب ثانیه؛ مقدار نمایان نمونه ۶۰ ثانیه است. تجاوز از این حد خطا ایجاد می‌کند و در ProcessErrorLogs ثبت می‌شود. |
| تنظیمات مقادیر ورودی | تعریف نام و روش مقداردهی هر پارامتر. |
| IDE | بازکردن محیط ویرایش کد. |
| تنظیمات خروجی | بدون خروجی یا Variable مقصد نتیجه؛ در نمونه Variable با نام perm انتخاب شده است. |
| عنوان اختیاری و اعلان شرح ارجاع | تنظیم مستقل متن اجرایی گام و شرح آن. |
| تنظیمات null بودن خروجی | اجازه یا عدم اجازه ادامه در نتیجه تهی طبق قرارداد Node. |
| ذخیره تغییرات | ثبت تنظیمات Node پس از تنظیم زبان، کد، ورودی و خروجی. |
تعریف پارامتر ورودی
«افزودن/ویرایش پارامتر» عنوان ورودی و روش تولید مقدار را باز می‌کند. مقدار می‌تواند خالی، Variable، ثابت یا حاصل تابع باشد. در روش Variable، ساده یا پیشرفته بودن روش خواندن داده را مشخص کنید. عنوان ورودی مانند MyVariable با نام Variable مبدأ مانند perm یکی نیست؛ عنوان ورودی نامی است که کد مصرف می‌کند.
پس از ذخیره ردیف، جدول عنوان پارامتر، نوع ورودی و مقدار ورودی را نشان می‌دهد. در نمونه MyVariable از @@perm و MyVariable2 از مقدار ثابت xyx مقدار می‌گیرند. ذخیره ردیف با «ذخیره و بستن» کل پنجره تفاوت دارد؛ تغییرات نهایی Node را نیز ثبت کنید.
نمونه کد، ابزارهای Runtime و تفاوت خروجی در زبان‌های مختلف در مرجع API و Custom JS آمده است. شکل خروجی را از نتیجه واقعی کد تعیین کنید؛ یک نمونه Object یا Array را قرارداد همگانی همه اسکریپت‌ها فرض نکنید.
↑ بازگشت به فهرست آموزشTimeout و ورودی‌های Script Task
Timeout را برحسب ثانیه تعیین کنید. عبور مدت اجرای کد از این حد، خطای اجرا ایجاد می‌کند و خطا در ProcessErrorLogs ثبت می‌شود. انتخاب زبان، تعیین زمان و نوشتن کد را همراه تنظیم ورودی‌ها انجام دهید؛ دکمه IDE ویرایشگر کد را باز می‌کند.
«تنظیمات مقادیر ورودی» پارامترها را با نام و مقدار در اختیار کد قرار می‌دهد. در C# ورودی Main یک IDictionary<string,object> و در JavaScript شیء args است. کلیدهای ProcessID، ProcessCreationID و CurrentElementID به‌صورت سیستمی وجود دارند؛ CurrentElementID شناسه گام جاری Script Task است.
برای نمونه، پارامتر MyVariable را از @@perm مقدار دهید. در JavaScript مقدار از args.MyVariable یا args['MyVariable'] و در C# از args["MyVariable"] خوانده می‌شود. نوع مقدار C# از جنس object است؛ پیش از مصرف، آن را مطابق نوع واقعی داده تبدیل کنید. پارامتر دوم می‌تواند از مقدار ثابت، Variable دیگر یا تابع مقدار بگیرد.
تغییر خودِ args در کد، مقدار Variable محیطی اصلی را تغییر نمی‌دهد. اگر نتیجه باید در Process باقی بماند، از روش خروجی گام یا توابع نوشتن Variable استفاده کنید. توابع هویت جاری مانند GetUserID، GetRoleID و GetOrganizationId نیز برای خواندن هویت اجرای کد در دسترس‌اند.
↑ بازگشت به فهرست آموزشخواندن، نوشتن و خروجی کد
GetVariableRawValue آخرین مقدار خام Variable را می‌خواند. GetVariableValue برای خواندن با مسیر ساختاریافته است؛ برای نمونه @@perm:ServiceData[0]['Field'] یک عضو از ردیف اول ServiceData را می‌دهد. برای داده JSON رشته‌ایِ تو در تو، قواعد مسیر و جداکننده * را مطابق بخش ساختار Variable رعایت کنید.
SetVariableAsServiceData آرایه‌ای از Objectها را در Variable نگه می‌دارد. ساختار ServiceData با یک یا چند رکورد سازگار است؛ برای مثال، خروجی جدولی Provider و داده‌های ارسالی شروع موبایلی در این قالب مصرف می‌شوند. در مقابل، خروجی User Task به‌صورت FormData، یک Object داده فرم است. SubForm آرایه‌ای داخلی از Objectهای ردیف‌هاست که زیر نام همان فیلد SubForm در Object فرم قرار می‌گیرد.
SetVariableAsFormData در جدول واقعی Form رکورد ثبت نمی‌کند. این تابع با نام Variable، FormID و Object داده، ساختار FormData را در Variable نگه می‌دارد. FormID برای معرفی و تطبیق ساختار است؛ آن را معادل اجرای عملیات Insert یا Save فرم تلقی نکنید.
CopyVariable برای کپی مقدار از Variable مبدأ به مقصد به‌کار می‌رود. در SetVariable مستقیم، مسئولیت سازگاری ساختار داده با روش خواندن بعدی برعهده کد است؛ اگر بعداً با مسیر FormData یا ServiceData می‌خوانید، شکل نوشته‌شده نیز باید همان قرارداد را داشته باشد. برای داده خام، روش خواندن Raw را به‌کار ببرید.
در C#، کلاس MyClass و متد override Main چارچوب اجرای کد هستند. مقدار return از Main خروجی نهایی Script Task می‌شود و طبق پنل خروجی، در Variable منتخب قرار می‌گیرد. فراخوانی مستقیم چندین Get/SetVariable در بدنه کد با این خروجی نهایی متفاوت است: اولی عملیات برنامه‌نویسی‌شده در طول اجرا و دومی نتیجه‌ای است که گام برمی‌گرداند.
↑ بازگشت به فهرست آموزشخروجی Null در Script Task و Service Task
در C# مقدار return و در JavaScript آخرین مقدار متغیر result نتیجه Script Task است. اگر پنل خروجی به Variable متصل است، این نتیجه در همان Variable قرار می‌گیرد. در JavaScript، result را صریح مقدار دهید؛ در C# نیز نبودن return لازم با return null یکسان نیست و می‌تواند خطای کامپایل باشد.
اگر خروجی Null در منطق شما مجاز است، «تنظیمات null بودن خروجی» را فعال کنید تا Null به‌تنهایی خطای گام ایجاد نکند و Process ادامه یابد. همین گزینه برای خروجی خالی Provider در Service Task نیز کاربرد دارد. این مجوز مقدار جایگزین تولید نمی‌کند؛ گام‌ها و عبارت‌هایی که بعداً خروجی را می‌خوانند باید پذیرش Null را در منطق خود در نظر بگیرند.
↑ بازگشت به فهرست آموزشBusiness Rule Task و اجرای تصمیم DMN
Business Rule Task تصمیم تعریف‌شده در DMN را در مسیر Process اجرا می‌کند. ابتدا DMN را انتخاب یا ایجاد کنید، Decision مقصد را مشخص کنید، ورودی‌های تصمیم را مقداردهی و خروجی را برای استفاده در ادامه مسیر به Variable متصل کنید.
| کنترل | کاربرد |
|---|---|
| مدیریت و ایجاد DMN | انتخاب مدل موجود یا ایجاد مدل موردنیاز. |
| کارت مشخصات DMN | شناسه DMN، شناسه گروه، عنوان، ورژن و تعداد Decisions مدل. |
| انتخاب تصمیم | انتخاب Decision از مدل متصل. |
| مدیریت پارامترها | مقداردهی پارامترهای ورودی تصمیم. |
| تنظیمات خروجی | تعیین نحوه نگهداری نتیجه و Variable مقصد؛ راهنمای بیشتر شکل نتیجه را بر اساس سیاست تطابق توضیح می‌دهد. |
| عنوان اختیاری / ذخیره تغییرات | عنوان اجرایی گام در صورت نیاز و ثبت پیکربندی Node. |
در نمونه، DMN گروه ۱۸ با شناسه ۲۰۶۶ و ورژن ۱، یک Decision به نام ClassifyStudents دارد. این شناسه‌ها نمونه‌اند؛ انتخاب را با مدل واقعی استقرار خود انجام دهید.
مدل و Decision مناسب
نمای نیازمندی‌های تصمیم، سه ورودی birthDay، birthDayMod و gender را به ClassifyStudents متصل می‌کند. پنجره انتخاب تصمیم، شناسه، عنوان، نام خروجی و نوع خروجی را نشان می‌دهد؛ در نمونه نوع DecisionTable و خروجی «کلاس» است.
برای بررسی منطق، جدول تصمیم را باز کنید. در نمونه، نوع ورودی‌های روز تولد و زوج/فرد عددی، نوع جنسیت رشته‌ای و خروجی کلاس رشته‌ای است. سیاست اجرا Collect انتخاب شده است. Checkbox فعال بودن جدول و فعال بودن هر Rule جدا وجود دارد.
نوار DMN، بارگذاری فایل DMN، ذخیره فایل DMN، ذخیره و بازگشت را از هم جدا می‌کند. افزودن ردیف و افزودن ستون در خود جدول نیز دیده می‌شود. تغییر این مدل بر نتیجه مصرف‌کننده Process اثر دارد؛ پس از اصلاح، ورودی‌ها و ساختار خروجی را دوباره کنترل کنید.
مقداردهی ورودی‌ها
جدول «پارامترهای ورودی DMN» عنوان پارامتر، نوع ورودی، اجباری و مقدار ورودی دارد. انتخاب ردیف‌ها و «مقداردهی به پارامترها» برای تنظیم یک یا چند ورودی است. جستجو و فیلتر، وضعیت انتخاب‌شده/نشده و گزینه «تنظیم مقدار خالی برای تمامی پارامترها» نیز وجود دارد.
در نمونه، birthDay مقدار ثابت ۱ دارد، birthDayMod از تابع با خواندن @@perm:ServiceData[0]['Mode'] مقدار می‌گیرد و gender مقدار ثابت male دارد. جدول تصمیم تصویر قبل مقادیر فارسی جنسیت را نشان می‌دهد؛ این دو نمونه را بدون یکسان‌سازی قرارداد ورودی، سناریوی آماده اجرا در نظر نگیرید. مقدار واقعی ورودی باید با نوع و شرط Decision هماهنگ باشد.
خواندن خروجی و سیاست تطابق Ruleها
راهنمای خروجی، شکل نتیجه تکی و چندتایی را با سیاست تطابق مرتبط می‌کند. نتیجه در ساختار ServiceData و Property نمونه ResultOf نشان داده شده است.
| سیاست | منطق و نکته نتیجه |
|---|---|
| Unique (U) | تنها یک Rule باید Match شود؛ چند تطابق برای این سیاست مجاز نیست. |
| First (F) | اولین Rule منطبق، نتیجه را تعیین می‌کند. |
| Priority (P) | نتیجه دارای اولویت بالاتر انتخاب می‌شود؛ اولویت خروجی‌ها معنا دارد. |
| Any (A) | چند Rule می‌توانند Match شوند، اما خروجی آنها باید یکسان باشد؛ خروجی متفاوت خطاست. |
| Collect | خروجی تمام Ruleهای منطبق جمع‌آوری می‌شود؛ به عنوان خروجی منفرد تفسیر نشود. |
| Collect (Sum) | جمع خروجی‌های عددی منطبق؛ نمونه ۳، ۵ و ۸ برابر ۱۶ است. |
| Collect (Min) | کمترین مقدار خروجی؛ در نمونه عددی ۳ است. |
| Collect (Max) | بیشترین مقدار خروجی؛ در نمونه عددی ۸ است. |
| Collect (Count) | تعداد Ruleهای منطبق؛ سه Rule برابر مقدار ۳ و یک Rule برابر ۱ است. |
| RuleOrder | خروجی‌ها به ترتیب Ruleها ارائه می‌شوند. |
| OutputOrder (O) | خروجی‌ها بر اساس ترتیب مقدار خروجی مرتب می‌شوند؛ نمونه ترتیب الفبایی است. |
در نمونه تکی، ساختاری مانند {"ServiceData":[{"ResultOf":"Leader"}]} دیده می‌شود. برای چند خروجی Collect یا سیاست‌های ترتیبی، چند عضو در ServiceData وجود دارد. Sum، Min، Max و Count را با حالت جمع‌آوری بدون تجمیع یکی ندانید. نمونه رشته‌ای ستون تک‌ورودی در راهنما، مجوز انجام جمع عددی روی رشته نیست.
نیازمند تأیید فنی: پنل تصویری گزینه «بدون خروجی» را نشان می‌دهد، ولی اعتبارسنجی نسخه بررسیشده در منابع فنی قدیمی، انتخاب Variable خروجی را لازم میداند. امکان ذخیره و اجرای واقعی بدون Variable را در نسخه مقصد بررسی کنید؛ حضور کنترل به‌تنهایی تأیید پشتیبانی اجرایی آن نیست.
پیش از استفاده، دسترسی مدل DMN، انتخاب Decision، مقداردهی پارامترهای لازم و Variable مقصد را کنترل کنید. نتیجه واقعی را در Variable Log محیط تست ببینید و مسیر مصرف آن را مطابق یک‌ردیفی یا چندردیفی بودن تنظیم کنید.
↑ بازگشت به فهرست آموزشانتخاب مدل و تصمیم در Business Rule Task
Business Rule Task رابط فرآیند با موتور قواعد GraphBPMS است. از «مدیریت و ایجاد DMN» مدل موجود را انتخاب یا مدل موردنیاز را ایجاد کنید. سپس در «انتخاب تصمیم» تصمیم قابل اجرا را مشخص کنید؛ یک مدل می‌تواند Decision Table یا Literal Expression داشته باشد. انتخاب خود مدل، جای انتخاب تصمیمی را که باید در این گام اجرا شود نمی‌گیرد.
مشاهدهٔ تصویر همین تنظیمات — مدل DMN، گروه، نسخه، تصمیم منتخب، مدیریت پارامترها و خروجی در پنل Business Rule Task.
مشاهدهٔ تصویر همین تنظیمات — گزینهٔ تصمیم ClassifyStudents با شناسه، عنوان، خروجی و نوع آن در انتخاب‌گر تصمیم.
پس از انتخاب تصمیم، «مدیریت پارامترها» ورودی‌های تحلیل‌شدهٔ همان تصمیم را نشان می‌دهد. برای هر ورودی روش مقداردهی مناسب، مانند مقدار ثابت، Variable یا تابع، و نوع مورد انتظار را کنترل کنید. مقادیر نمونهٔ تصویر تنظیم آزمایشی‌اند؛ پیش از استفاده آنها را با قواعد و نوع ورودی تصمیم خود تطبیق دهید.
مشاهدهٔ تصویر همین تنظیمات — سه ورودی birthDay، birthDayMod و gender و روش مقداردهی آنها در نمونهٔ تصمیم.
↑ بازگشت به فهرست آموزشتغییر نسخهٔ DMN و نگاشت ورودی Process
انتخاب مدل تصمیم بر پایهٔ گروه DMN است و هنگام اجرا، نسخهٔ فعال همان گروه به کار می‌رود. در مقابل، فهرست ورودی‌هایی که در طراحی Process تنظیم کرده‌اید از نسخهٔ فعال در زمان تنظیم استخراج شده است. ثابت‌ماندن گروه، سازگاری همیشگی قرارداد ورودی را تضمین نمی‌کند.
اگر نسخهٔ جدید DMN نام، تعداد یا نوع پارامترها را تغییر داده است، نگاشت Business Rule Task را دوباره بازبینی و اصلاح کنید و نسخهٔ مناسب Process را ثبت کنید. همین بررسی برای دکمهٔ Form که همان مدل را فراخوانی می‌کند لازم است. برای یک تغییر قواعد بدون تغییر قرارداد ورودی نیز نتیجهٔ تصمیم و مسیر مصرف‌کننده را با دادهٔ نمونه کنترل کنید.
مشاهدهٔ تصویر همین تنظیمات — نمودار نیازمندی‌های تصمیم نمونه با ورودی‌های متصل به ClassifyStudents.
↑ بازگشت به فهرست آموزشخروجی تصمیم را با سیاست تطبیق آن بخوانید
در تنظیمات خروجی، «بدون خروجی» یا Variable مقصد را تعیین کنید. شکل و تعداد نتیجه‌های Decision Table به سیاست تطبیق قوانین آن بستگی دارد؛ نتیجهٔ یک تصمیم با سیاست Collect را به همهٔ سیاست‌ها تعمیم ندهید. راهنمای کنار تنظیمات خروجی، حالت تک‌تطبیقی و چندتطبیقی را مقایسه و سیاست فعلی تصمیم را برجسته می‌کند.
مشاهدهٔ تصویر همین تنظیمات — راهنمای شکل خروجی Business Rule Task؛ سیاست Collect در تصمیم انتخاب‌شده برجسته است.
در نمونهٔ ClassifyStudents، جدول تصمیم از روز تولد، زوج/فرد بودن و جنسیت برای تعیین کلاس استفاده می‌کند. خودِ انتخاب مدل یا مشاهدهٔ جدول، شاهد موفقیت همهٔ ترکیب‌های ورودی نیست؛ مسیر Variable مصرف‌کننده را با خروجی واقعیِ همان تصمیم تنظیم کنید. عنوان اختیاری این Node از همان قواعد مشترک عنوان نمونهٔ فرآیند پیروی می‌کند.
مشاهدهٔ تصویر همین تنظیمات — جدول تصمیم ClassifyStudents و سیاست Collect در مدل نمونه.
↑ بازگشت به فهرست آموزشCall Activity: اجرای Process فرزند و بازگشت خروجی
Call Activity یک Process فرزند را از داخل Process پدر اجرا می‌کند. Process پدر تا کامل شدن Process فرزند از Call Activity عبور نمی‌کند. بعد از پایان فرزند، خروجی‌های تعریف‌شده دریافت می‌شوند و اجرای پدر ادامه پیدا می‌کند.
انتخاب Process و Start Node مقصد
در پنل Call Activity، «فرآیند مقصد» و سپس «نقطه شروع» را انتخاب کنید. Process مقصد ممکن است چند Start Node داشته باشد؛ بنابراین انتخاب نام Process برای تعیین نقطه ورود کافی نیست. نقطه شروع انتخاب‌شده، Lane مقصد و در نتیجه محدودیت دسترسی را نیز تعیین می‌کند.
Accessهای Lane مربوط به Start Node مقصد باید زیرمجموعه Accessهای Lane جاری Call Activity یا برابر با آن باشند. این محدودیت باید هنگام انتخاب Start Node رعایت شود؛ صرف مجاز بودن یک کاربر برای اجرای Process مقصد جای این قاعده را نمی‌گیرد.
- Call Activity را در Lane پدر قرار دهید.
- Process مقصد را انتخاب کنید.
- از میان Start Nodeهای آن، نقطه‌ای را انتخاب کنید که شرط دسترسی Lane را رعایت کند.
- با «تنظیمات مقادیر ورودی» Variableهای مقصد را مقداردهی کنید.
- خروجی موردنیاز را در End Event نهایی فرزند تعریف کنید و با «تنظیمات مقادیر خروجی» به متغیر پدر متصل کنید.
- تنظیمات را ذخیره کنید و پس از اتمام فرزند، ادامه پدر و دریافت خروجی را کنترل کنید.
تنظیم مقادیر ورودی
پنجره ورودی دو ستون «متغیر مقصد» و «مقدار» دارد. دکمه «افزودن/ویرایش متغیر» برای مدیریت نگاشت است. جستجوی کل جدول، فیلتر ستون‌ها، تعداد رکوردهای هر صفحه، «ذخیره» و «بستن» نیز در دسترس‌اند.
در این مثال، @@CurrentRoleID به @@TargetRoleID، @@CurrentUserID به @@TargetUserID و @@FormData:ServiceData[0]['IdOfFormRecord'] به @@FormResult داده می‌شود. این نام‌ها نمونه‌اند؛ نام Variable واقعی مقصد و مسیر داده مبدأ باید با مدل شما تطابق داشته باشد.
دریافت خروجی End Event فرزند
Variable خروجی در End Event فرزند تعریف می‌شود و در پنجره خروجی Call Activity به Variable پدر نگاشت می‌گردد. جدول خروجی دارای ستون متغیر، متغیر خروجی فرآیند و Iconهای ویرایش و حذف است. دکمه «جدید» یک نگاشت اضافه می‌کند.
در نگاشت نمونه، LastNameInChildProcess خروجی Process فرزند و FormData Variable پدر است. دریافت خروجی را با انتخاب ورودی فرزند اشتباه نگیرید: ورودی قبل از شروع فرزند و خروجی پس از پایان آن کاربرد دارد.
CallActivity؛ اجرای فرآیند دیگر و دریافت نتیجه
فرزند Call Activity می‌تواند فرم انسانی، سرویس، اسکریپت، Gateway یا گام انتظار داشته باشد. وجود کار فعال یا انتظار در فرزند به معنی آماده‌شدن گام بعد پدر نیست؛ ادامهٔ پدر به پایان فرزند وابسته است. مراحل انتخاب مقصد، قاعدهٔ دسترسی و نگاشت ورودی/خروجی در بخش تنظیم کامل Call Activity همین مقاله آمده است.
آماده‌کردن فرآیند مقصد
فرآیند مقصد باید ذخیره و برای انتخاب در دسترس باشد. برای نقطه‌های شروع عنوان روشن بگذارید؛ یک فرآیند ممکن است بیش از یک Start داشته باشد و انتخاب نام فرآیند به‌تنهایی تعیین نمی‌کند از کجا آغاز شود.
در فرزند، متغیرهای ورودی مورد نیاز را تعریف کنید؛ مانند @@RequesterUser برای شناسه درخواست‌دهنده. در UserTask یا سرویس مصرف‌کننده، از همین متغیر بخوانید. برای نمونه، مقدار اولیه SelectBox درخواست‌دهنده می‌تواند مقدار ساده @@RequesterUser باشد، مشروط به اینکه فیلد مقدار SelectBox شناسه کاربر را بپذیرد.
اگر والد باید نتیجه دریافت کند، در End مناسب، مقادیر خروجی را تعریف کنید. نام کلید خروجی قرارداد ارتباط با والد است؛ لازم نیست با نام متغیر داخلی فرزند یکسان باشد.
انتخاب مقصد و نقطه شروع
- در فرآیند والد، نوع گام را Call Activity انتخاب کنید.
- در فرآیند مقصد، فرآیند مورد نیاز را انتخاب کنید.
- نقطه شروع مقصد را مشخص کنید.
- تنظیمات مقادیر ورودی را باز کنید.
- متغیرهای مورد نیاز مقصد را از داده والد مقداردهی کنید.
- در صورت نیاز، عنوان اختیاری فرآیند مقصد و نگاشت خروجی‌ها را تنظیم کنید.
- تنظیمات گام و فرآیند والد را ذخیره کنید.
دسترسی Lane حاوی Start Node منتخب در Process فرزند باید زیرمجموعهٔ دسترسی Lane جاری Call Activity در پدر یا برابر آن باشد: ChildStartLaneAccess ⊆ ParentCallActivityLaneAccess. صرف مجاز بودن یک کاربر برای آغاز مقصد جای این شرط رابطهٔ دو Lane را نمی‌گیرد؛ نقطهٔ شروع انتخاب‌شده را نیز کنترل کنید.
نگاشت ورودی از والد به فرزند
در جدول ورودی، متغیر مقصد از فرآیند فرزند انتخاب می‌شود و مقدار از سمت والد تأمین می‌شود. جهت این نگاشت را برعکس نکنید.
| متغیر مقصد نمونه | مقدار ورودی از والد | کاربرد |
|---|---|---|
@@TargetRoleID |
@@CurrentRoleID |
مقدار نقش شروع‌کننده در قرارداد ورودی مقصد. |
@@TargetUserID |
@@CurrentUserID |
مقدار کاربر شروع‌کننده در قرارداد ورودی مقصد. |
@@RequesterUser |
مقدار ساده کاربر فعلی یا مسیر شناسه درخواست‌دهنده در فرم | اطلاعاتی که منطق فرزند برای نمایش یا ادامه نیاز دارد. |
| متغیر عددی یا متنی مقصد | مقدار ثابت یا متغیر متناظر والد | داده اختصاصی مورد نیاز عملیات فرزند. |
برای هر سطر، نوع مقدار اولیه را انتخاب و مقدار را ذخیره کنید. اگر فرزند برای منطق خود به کاربر یا نقش جاری نیاز دارد، آنها را صریح به متغیر مقصد نگاشت کنید. این انتقال داده با شرط دسترسی متفاوت است و جای رابطهٔ زیرمجموعهٔ دسترسی Lane آغاز فرزند و Lane Call Activity پدر را نمی‌گیرد.
متغیرهای والد و فرزند دو مجموعه مستقل‌اند. هم‌نام بودن یک متغیر در دو فرآیند باعث انتقال خودکار داده نمی‌شود. اگر فرزند @@RequesterUser را می‌خواند، باید مقدار آن را در ورودی CallActivity مشخص کرده باشید یا خود فرزند قبل از مصرف آن را بسازد.
انتشار خروجی در پایان فرزند
در End فرزند، پنجره متغیرهای خروجی را باز کنید. یک کلید خروجی تعریف و نوع مقدار آن را تعیین کنید. برای نمونه:
| کلید خروجی فرزند | نوع مقدار | مقدار نمونه |
|---|---|---|
IsOk |
ثابت | 1 |
CreatedCustomTitle |
متغیر | @@CustomTitle |
مقدار ثابت 1 در این مثال فقط نتیجه‌ای است که برای همان End تعریف شده است. اگر فرزند پایان‌های متفاوتی برای تأیید و رد دارد، خروجی متناسب با هر پایان را تنظیم کنید. ثبت یک خروجی روی یک End را به همه مسیرهای پایان تعمیم ندهید.
دریافت خروجی در والد
در والد، متغیرهای دریافت‌کننده را بسازید؛ برای نمونه @@ChildIsOk و @@ChildTitle. سپس تنظیمات خروجی CallActivity را باز کنید و هر کلید خروجی فرزند را به یک متغیر والد وصل کنید:
| خروجی فرآیند فرزند | متغیر دریافت‌کننده در والد |
|---|---|
IsOk |
@@ChildIsOk |
CreatedCustomTitle |
@@ChildTitle |
هر ردیف جدول را ذخیره و پنجره را تأیید کنید. پس از اتمام فرزند، گام بعدی والد می‌تواند از این متغیرها در فرم، شرط یا عنوان استفاده کند. تا قبل از پایان فرزند، انتظار مقدار خروجی نهایی را نداشته باشید.
عنوان فرزند و حفظ عنوان ارسالی
CallActivity می‌تواند برای نمونه فرزند عنوان اختیاری تعیین کند. این عنوان با متغیر داخلی فرزند که نامش عنوان است تفاوت دارد. اگر گام‌های خود فرزند بعداً عنوان اجرا را جایگزین کنند، عنوان ارسالی والد نیز می‌تواند عوض شود.
اگر لازم است عنوان والد حفظ و توضیح فرزند به آن اضافه شود، در گام تغییر عنوان داخل فرزند، افزودن به ادامه عنوان قبلی را انتخاب کنید. اگر قرار است عنوان کاملاً از نو ساخته شود، حالت جایگزینی مناسب است. انتشار یک متغیر داخلی در End نیز الزاماً به معنی برگرداندن آخرین عنوان ترکیبی اجرا نیست؛ مقدار خروجی را مطابق نیاز قرارداد انتخاب کنید.
رفتار کارتابل و تغییر نسخه مقصد
کارهای انسانی فرزند در اجرای فرزند و کارتابل گیرنده آن ظاهر می‌شوند. پس از پایان فرزند، کار بعدی والد در اجرای والد قرار می‌گیرد. انتظار نداشته باشید فرم فرزند یا فرم بعدی والد همیشه به صورت ادامه مستقیم همان صفحه قبلی باز شود؛ کارتابل و عنوان فرآیند را بررسی کنید تا روی اجرای درست کار کنید.
پس از تغییر و ذخیره فرآیند مقصد، انتخاب مقصد و نقطه شروع را در والد بازبینی کنید و در صورت نیاز دوباره انتخاب کنید. ورودی‌ها، کلیدهای End و نگاشت خروجی باید همچنان با قرارداد مقصد سازگار باشند. به‌خصوص حذف یا تغییر Start و تغییر نام کلید خروجی می‌تواند ارتباطی را که قبلاً درست بوده نامعتبر کند. پس از این بازبینی، نسخه والد را نیز ذخیره کنید.
↑ بازگشت به فهرست آموزشورودی Call Activity از هویت جاری
در «تنظیمات مقادیر ورودی»، ستون «متغیر مقصد» از ستون «مقدار» جداست. نمونهٔ حاضر @@CurrentRoleID را به @@TargetRoleID و @@CurrentUserID را به @@TargetUserID نگاشت می‌کند. فهرست مقدار ورودی، شماره فرآیند، شماره ارجاع، شماره ایجاد فرآیند، سمت و کاربر فعلی، شماره رکورد فعلی فرم، اطلاعات آغاز از سرویس، شماره گام جاری و داده‌های شروع موبایلی را در اختیار می‌گذارد. این نام‌ها باید با قرارداد مقصد تطبیق داده شوند.
Graph Mobile Task؛ انجام کار محدود همراه در میانه فرآیند
Graph Mobile Task، وظیفه‌های محدود ابزار همراه را به نمونه جاری فرآیند متصل می‌کند. ساخت خود وظیفه و اتصال آن به فرآیند دو کار جداست: ابتدا وظیفه باید ایجاد و شناسه‌اش آماده شود؛ سپس Graph Mobile Task آن شناسه را مصرف می‌کند و تا اتمام کار مرتبط منتظر می‌ماند.
یک الگوی قابل استفاده چنین است: UserTask اطلاعات وظیفه را دریافت می‌کند، ServiceTask وظیفه همراه را می‌سازد، Graph Mobile Task آن را به اجرای جاری متصل می‌کند و گام بعد نتیجه ارسال‌شده از همراه را بررسی می‌کند.
ایجاد وظیفه همراه با ServiceTask
در ServiceTask، منبع داده ایجاد تسک موبایل را از محیط خود انتخاب کنید. نام و قرارداد منبع را بررسی کنید؛ شماره منبع، فرم، رکورد پیش‌فرض و ماژول در محیط‌های مختلف یکسان نیستند.
ورودی‌های مهم این منبع عبارت‌اند از:
| پارامتر | آنچه باید تعیین شود |
|---|---|
Title |
عنوان وظیفه‌ای که کاربر همراه تشخیص می‌دهد. |
TaskExplain |
توضیح کار مورد نیاز. |
FK_FormId |
شناسه تعریف فرم مورد استفاده برای ثبت داده همراه. |
DefaultData |
ساختار JSON داده و تنظیمات اولیهٔ فیلدهای وظیفه؛ نام، مقدار و نوع و وضعیت کنترل‌ها مطابق قرارداد TaskCreate. شناسهٔ خام رکورد Form جای این ساختار نیست. |
FromDateTime و ToDateTime |
ابتدا و انتهای بازه زمانی وظیفه. |
FromTime و ToTime |
محدوده ساعت انجام کار در صورت استفاده. |
IsActive |
وضعیت فعال بودن وظیفه. |
IsTemp |
نیازمند تأیید فنی: اثر دقیق این فلگ بر امکان ثبت موقت Form را در قرارداد Provider مقصد کنترل کنید. از نام IsTemp، موقت‌بودن عمر خود Task را نتیجه نگیرید. |
IsOffline |
تنظیم استفاده در حالت آفلاین. |
IsLimited |
محدود بودن وظیفه؛ برای این نوع اتصال، وظیفه محدود لازم است. |
MinCountRecord |
حداقل تعداد ثبت لازم برای امکان اتمام وظیفه. |
MaxCountRecord |
سقف تعداد رکورد وظیفه. |
MandatoryRange و Regions |
الزام و محدوده مکانی انجام کار. |
UsersList و RolesList |
گیرندگان بر اساس شناسه کاربران و نقش‌ها. |
پارامترهای صفحه‌های بعد، از جمله شناسهٔ ماژول، شناسهٔ صفحه و بازشدن متوالی را نیز در Provider انتخاب‌شده بررسی کنید. در نمونهٔ آموزشی ساخت وظیفهٔ همراه، ModuleId=7 و PageId=10120 هستند؛ این دو را جابه‌جا نکنید. شناسهٔ Form، شناسهٔ Record مبدأ و شناسهٔ Task نیز مستقل‌اند؛ اعداد نمونه را بدون تطبیق با تنظیمات محیط خود کپی نکنید.
مثال: برای دادهٔ اولیهٔ وظیفهٔ همراه، در
DefaultDataساختار JSON مربوط به فیلدها و مقدارهای اولیه را طبق قرارداد TaskCreate بدهید. نمونهٔ جاری کلیدهایی مانندName،Value،ValueType،IsVisible،IsRequiredوIsEnabledدارد. این ورودی، شناسهٔ خام یک Record نیست؛ شکل، نام فیلدها و نوع مقدارها را با Form وظیفه تطبیق دهید.
عنوان و توضیح را می‌توان از فرم دریافت کرد. برای مثال، با فرض خروجی @@TaskDetails:
Title = @@TaskDetails:FormData['TaskTitle']
TaskExplain = @@TaskDetails:FormData['TaskDesc']
برای چند گیرنده، شناسه‌های UsersList یا RolesList را مطابق قرارداد منبع با ویرگول جدا کنید. اگر محدوده مکانی را الزامی می‌کنید، محدوده معتبر نیز بدهید. فعال‌کردن الزام بدون تأمین محدوده، یک تنظیم کامل نیست.
خروجی سرویس ایجاد وظیفه را در متغیری مانند @@TaskId ذخیره کنید. گام بعد باید شناسه وظیفه ساخته‌شده را دریافت کند؛ شناسهٔ Form همراه یا یک Record جای شناسهٔ Task تولیدشده نیست.
اتصال شناسه وظیفه به Graph Mobile Task
- بعد از ServiceTask ایجاد وظیفه، Graph Mobile Task قرار دهید.
- عنوان گام را مشخص کنید.
- در متغیر حاوی شناسه وظایف کار همراه، متغیر
@@TaskIdرا انتخاب کنید. - نوع دسترسی به داده را تعیین کنید. اگر شناسه، اولین مقدار نتیجه سرویس است، حالت ساده مناسب است؛ در غیر این صورت مسیر پیشرفته را تنظیم کنید.
- متغیر خروجی داده‌های برگشتی همراه را تعیین کنید.
- گام بعد از اتمام کار همراه را متصل و تنظیمات را ذخیره کنید.
متغیر می‌تواند یک شناسه یا چند شناسه جداشده با ویرگول داشته باشد. برای داده‌ای که داخل خروجی فرم یا سرویس قرار دارد، مسیر مناسب FormData یا ServiceData را بدهید؛ اگر شناسه‌ها داخل JSON رشته‌ای هستند، قاعده مسیر * نیز کاربرد دارد. روش ساده را زمانی انتخاب کنید که همان اولین مقدار واقعاً شناسه یا فهرست شناسه‌های مورد نظر باشد.
تعداد شناسه‌های وظیفه را با حداقل و حداکثر رکوردهای هر وظیفه اشتباه نگیرید؛ اینها دو مقدار متفاوت در پیکربندی هستند.
ثبت، ارسال و اتمام در ابزار همراه
کاربر همراه وظیفه را از فهرست خود دریافت می‌کند، فرم آن را باز می‌کند و رکوردهای لازم را ثبت و ارسال می‌کند. برای وظیفه محدود با حداقل 1 و سقف 3، ارسال دو رکورد به‌تنهایی الزاماً گام فرآیند را تمام نمی‌کند. هنوز سقف سه رکورد پر نشده است؛ کاربر می‌تواند رکورد بعدی را ارسال کند یا پس از احراز حداقل، اتمام وظیفه را انتخاب کند.
ادامه فرآیند پس از تکمیل وظیفه اتفاق می‌افتد: با رسیدن به سقف تعریف‌شده یا با اتمام دستی مجاز. در حالت اتمام دستی پس از ارسال دو رکورد، وظیفه از فهرست فعال همراه خارج و همان نمونه فرآیند یک بار به گام بعد منتقل می‌شود.
ثبت محلی، ارسال داده به سرور و اتمام وظیفه را سه اتفاق جدا در نظر بگیرید. در بررسی تأخیر ادامه، مشخص کنید داده واقعاً ارسال شده و شرط اتمام وظیفه نیز برقرار شده است؛ صرف مشاهده رکورد در دستگاه کافی نیست.
دریافت داده برگشتی
نتیجه کار همراه در متغیر خروجی گام به صورت مجموعه ServiceData مصرف می‌شود. هر ردیف علاوه بر فیلدهای فرم، اطلاعاتی مانند شناسه وظیفه، شناسه فرم و اطلاعات ثبت را دارد. ساختار کوتاه زیر نمونه‌ای برای نشان دادن مسیر است؛ شناسه‌ها و داده‌ها صرفاً توضیحی‌اند:
{
"ServiceData": [
{"__TaskID__": 10, "__FormID__": 20, "Id": 101, "TextBox1": "گزارش اول"},
{"__TaskID__": 10, "__FormID__": 20, "Id": 102, "TextBox1": "گزارش دوم"}
]
}
اطلاعات ثبت می‌تواند شامل RegDate، FK_UserId، FK_RoleId، LastModifiedDate، LastModifiedFK_UserId و LastModifiedFK_RoleId نیز باشد. فیلدهای اختصاصی به فرم انتخاب‌شده وابسته‌اند؛ TextBox1 نام عمومی همه فرم‌های همراه نیست.
برای دادن کل نتیجه به زیر‌فرم، از @@MobileResult:ServiceData استفاده کنید. برای خواندن یک فیلد از نخستین ردیف، مسیر نمونه @@MobileResult:ServiceData[0]['TextBox1'] است. اگر همه رکوردها لازم‌اند، حالت ساده را جای همه داده‌ها نگذارید.
Graph Mobile Task یک وظیفهٔ محدود را به اجرای موجود متصل می‌کند و پس از تکمیل، همان اجرا را ادامه می‌دهد. Graph Mobile Start ورودی آغاز از ارسال Task همراه است؛ دادهٔ شروع در @@MobileRecordData از نوع ServiceData می‌تواند فهرست یک یا چند رکورد باشد. برای هر Process متصل، هر بار ارسال به سرور یک نمونه ایجاد می‌کند و تمام رکوردهای همان ارسال، چه یک رکورد و چه چند رکورد، در همان نمونه قرار می‌گیرند؛ برای هر Record نمونهٔ جدا ساخته نمی‌شود.
Graph Mobile Task؛ ارجاع Task محدود در نمونه جاری
Graph Mobile Task ادامه یک نمونه موجود را به انجام Task همراه محدود متصل می‌کند. ورودی این Node، Variable حاوی شناسه Task یا شناسه‌های comma-separated است؛ Task نامحدود برای Graph Mobile Start به‌کار می‌رود و ورودی این گام نیست.
در الگوی نمونه، یک Service Task پیش از این گام، Provider متصل به رویه dbo.TaskCreate را اجرا می‌کند و TaskID را در Variable می‌گذارد. سپس همان Variable در «متغیر حاوی شناسه وظایف کار همراه» انتخاب می‌شود. این الگوی ساخت Task است؛ مطابق قرارداد ورودی Node، شناسه Limited Task می‌تواند از روش معتبر دیگری نیز تولید شده باشد.
Task محدودِ آماده‌شده زمانی وارد کارتابل PWA/APK گیرندگان می‌شود که Process به Graph Mobile Task برسد. کاربر تعداد مجاز رکوردها را تکمیل و «ارسال به سرور» را اجرا می‌کند؛ پس از تکمیل این انتظار، Task از کارتابل همراه خارج می‌شود و همان نمونه Process ادامه می‌یابد. در مثال حداقل یک و حداکثر سه رکورد مجاز است، پس یک، دو یا سه رکورد می‌تواند در ارسال قرار گیرد.
داده بازگشتی این گام در Variable منتخبِ «تنظیمات خروجی» ذخیره می‌شود. Variable سیستمی @@MobileRecordData مربوط به شروع موبایلی است و محل خروجی Graph Mobile Task نیست.
اگر TaskID نخستین ستون نخستین ردیف نتیجه ServiceData باشد، نوع دسترسی «ساده» کافی است. اگر شناسه در بخش دیگری از FormData یا ServiceData قرار دارد، «پیشرفته» را انتخاب و مسیر دقیق داده را تعیین کنید. برای چند شناسه، مقدار نهایی باید با کاما جدا شده باشد.
ورودی‌های TaskCreate در سناریوی محدود
| پارامتر | کاربرد |
|---|---|
| Title و TaskExplain | عنوان و توضیحات Task همراه. |
| FK_FormId و DefaultData | Form مقصد و مقادیر/تنظیمات پیش‌فرض آن در قالب JSON. |
| FromDateTime و ToDateTime | بازه تاریخ مجاز Task. |
| FromTime و ToTime | بازه ساعت مجاز روزانه در همان دوره. |
| IsActive | فعال‌بودن Task؛ مقدار فعال در مثال 1 است. |
| MandatoryRange و Regions | الزام حضور در محدوده و خود محدوده جغرافیایی؛ Regions می‌تواند از فیلد GeoJSON/Map در Variable خوانده شود. |
| IsTemp | نیازمند تأیید فنی: اثر دقیق این فلگ بر ثبت موقت Form در Provider مقصد؛ تعریف پارامتر را از قرارداد همان Provider کنترل کنید. |
| IsOffline | قابلیت ثبت آفلاین و ارسال بعدی هنگام اتصال به سرور. |
| IsLimited | برای Task مصرف‌شونده در Graph Mobile Task، مقدار محدود/1 را تعیین کنید. |
| MinCountRecord و MaxCountRecord | حداقل و حداکثر تعداد رکورد قابل ثبت و ارسال؛ مثال 1 و 3. |
| UsersList و RolesList | شناسه کاربران و نقش‌های دریافت‌کننده، با کاما بین چند شناسه. |
| ModuleId و PageId | در رویه زیرساختی معرفی‌شده، مقادیر ثابت 7 و 10120 مطابق تنظیمات نمایش‌داده‌شده. |
| SeqReg | قابلیت ثبت متوالی؛ مقدار نمونه 1. |
| OrganizationId | سازمان مرتبط با Task. |
Graph Mobile Task: ساخت وظیفه محدود و دریافت TaskID
Graph Mobile Task با شناسه وظایف موبایلی از نوع محدود کار می‌کند. ایجاد وظیفه و انتساب آن در Process دو مرحله مستقل‌اند: ابتدا Task محدود با سازوکار مناسب ساخته و TaskID آن در Variable ذخیره می‌شود؛ سپس Graph Mobile Task شناسه را می‌خواند. تولید شناسه منحصر به یک Provider خاص نیست.
یک الگوی عملی، اجرای Provider روال dbo.TaskCreate در Service Task است. «مدیریت منبع داده» دو انتخاب دارد: استفاده از منبع داده موجود یا ایجاد منبع جدید. پس از اتصال، کارت منبع شناسه، عنوان و نوع StoredProcedure را نمایش می‌دهد.
صفحه جزئیات Provider، ورودی‌ها و خروجی TaskID از نوع Int32 (Null) را نشان می‌دهد. نام روال، نام بانک، ورودی‌های دقیق و ستون خروجی را قبل از نگاشت کنترل کنید. مقدار Null در قرارداد خروجی یعنی باید نتیجه واقعی فراخوانی را نیز بررسی کرد؛ وجود ستون به‌تنهایی ایجاد موفق Task را اثبات نمی‌کند.
مقداردهی ورودی‌های TaskCreate
پارامترها در جدول نام، نوع و مقدار نمایش داده می‌شوند. یک یا چند ردیف را انتخاب و «مقداردهی به پارامتر/پارامترها» را بزنید. Search، فیلتر ستون‌ها و صفحه‌بندی برای رسیدن به تمام پارامترها مهم‌اند؛ فقط صفحه اول را بررسی نکنید.
| پارامترها | کاربرد قابل تشخیص و نکته تنظیم |
|---|---|
| Title، TaskExplain | عنوان و توضیح وظیفه موبایلی. |
| FK_FormId | شناسه Form وظیفه؛ شناسه نمونه 106073 را با فرم استقرار خود جایگزین کنید. |
| DefaultData | داده و پیکربندی اولیه فیلدها به صورت JSON. |
| FromDateTime، ToDateTime، FromTime، ToTime | بازه تاریخ و زمان؛ قالب و تقویم قراردادی Provider باید رعایت شود. |
| IsActive، MandatoryRange، IsTemp، IsOffline، IsLimited | فلگ‌های پیکربندی وظیفه. برای این سناریو محدود بودن Task مهم است؛ معنی دقیق تعامل MandatoryRange و بازه را با تنظیمات موبایل تطبیق دهید. |
| MinCountRecord، MaxCountRecord | حداقل و حداکثر تعداد رکورد؛ در نمونه ۱ و ۳. |
| Regions | داده محدوده مکانی؛ نمونه از مسیر @@perm:ServiceData[0]['GpsField'] خوانده می‌شود. |
| UsersList، RolesList | فهرست کاربران و نقش‌ها؛ مقادیر نمونه با کاما جدا شده‌اند. |
| ModuleId، PageId | شناسه ماژول و صفحه مرتبط. |
| SeqReg، OrganizationId | پارامترهای تکمیلی صفحه دوم؛ نوع و مقدار را از قرارداد Provider استقرار مقصد تعیین کنید. |
ویرایش DefaultData با روش مقدار ثابت، امکان ارسال ساختار JSON فیلدها را می‌دهد. در نمونه، کلیدهای Name، Value، ValueType، IsVisible، IsRequired، IsEnabled، IsReadOnly، IsKey، LaneID و Label دیده می‌شوند. نوع مقدارها را مطابق قرارداد کامل موبایل رعایت کنید؛ مقدار رشته‌ای "true" را بدون بررسی با Boolean واقعی جایگزین نکنید.
پارامترهای ساخت وظیفه موبایلی
جدول ایجاد تسک موبایل نام پارامتر، نوع ورودی و مقدار ورودی را جدا می‌کند. نمونهٔ حاضر Title و TaskExplain را از @@TaskDetails:FormData می‌گیرد. پارامترهای دیگرِ قابل مشاهده شامل FK_FormId، DefaultData، FromDateTime، ToDateTime، FromTime، ToTime، IsActive، MandatoryRange، IsTemp، IsOffline، IsLimited، MinCountRecord، MaxCountRecord، Regions، UsersList و RolesList است. اعداد و تاریخ‌های مثال، مقدار توصیه‌شده برای محیط عملیاتی نیستند. IsLimited برای Task میانی محدود است؛ MinCountRecord و MaxCountRecord حداقل و سقف رکورد را تعیین می‌کنند. تنظیم محدودهٔ اجباری به Regions معتبر نیاز دارد. شناسه‌های گیرنده با کاما جدا می‌شوند و DefaultData مطابق قرارداد جاری JSON مقادیر/تنظیمات اولیه است. جدول کامل و صفحه‌های بعدی ورودی‌ها در ساخت وظیفه محدود آمده است.
اتصال TaskID به Graph Mobile Task
در «متغیر حاوی شناسه وظایف کار همراه»، Variable تولیدشده در مرحله قبل را انتخاب کنید. سپس «نوع دسترسی داده» را ساده یا پیشرفته بگذارید و در صورت نیاز Variable خروجی را تعیین کنید. در نمونه ورودی و خروجی هر دو perm هستند؛ برای جلوگیری از ابهام در داده‌های چندمرحله‌ای می‌توان متغیرهای مجزا را مطابق طراحی Process به کار برد.
TaskID می‌تواند یکی یا بیشتر باشد. چند شناسه باید در مقدار انتخاب‌شده با کاما مانند 1,2,3,4 جدا شوند. حالت ساده اولین ستون اولین ردیف داده را می‌خواند. در حالت پیشرفته، مسیر دقیق Property حاوی شناسه یا رشته شناسه‌ها را بدهید.
| منبع شناسه | نمونه |
|---|---|
| فیلد داده فرم | FormData['PropertyName'] |
| Property زیرمجموعه فرم | FormData['SubFormName']['PropertyName']؛ فقط اگر این زیرمجموعه Object باشد. برای SubForm آرایه‌ای index لازم است. |
| ردیف سرویس | ServiceData[0]['TaskID'] |
| شناسه داخل رشته JSON | ServiceData[0]['Content']*['TaskID'] |
ساختار داده را در Variable Log کنترل کنید: TaskID با ProcessID، ProcessCreationID و ReferenceID متفاوت است. در صورت چندشناسه‌ای بودن، خروجی متنی جداشده با کاما را از آرایه خام اشیا متمایز کنید. دریافت داده‌های ثبت‌شده موبایل و ادامه مسیر به قرارداد اجرایی این Node وابسته است و در شرح رفتار Graph Mobile Task توضیح داده می‌شود.
↑ بازگشت به فهرست آموزشمقدار اولیه از داده شروع موبایلی
در سناریوی آغاز از موبایل، «داده‌های ارسالی از طریق شروع موبایلی» در فهرست متغیرهای مقدار اولیه قرار دارد. در این مثال فیلد «شناسه»، روش مقداردهی از متغیر و حالت «ساده» انتخاب شده و فقط‌خواندنی است. دادهٔ شروع موبایلی در @@MobileRecordData از نوع ServiceData و شامل یک یا چند رکوردِ همان ارسال است. حالت ساده فقط نخستین مقدار را می‌خواند؛ برای فیلد یا ردیف مشخص، مسیر پیشرفته و برای کل مجموعه، «همه داده‌ها» را انتخاب کنید. در قرارداد جاری، برای هر Process متصل، یک ارسال به سرور یک نمونه ایجاد می‌کند. ساختار داده و شروع موبایلی را ببینید.
رفع اشکال تنظیمات گام
| نشانه | بررسی و اصلاح |
|---|---|
| فرم در انتخاب‌گر UserTask دیده نمی‌شود | ثبت فرم برای استفاده در فرآیند و دسترسی به فرم را بررسی کنید. |
| گام ویرایش، رکورد مورد نظر را باز نمی‌کند | حالت فرم، تعریف فرم انتخابی و مقدار Id رکورد را جداگانه بررسی کنید. |
| به جای ویرایش، رکورد تازه ساخته می‌شود | حالت جدید را به ویرایش تغییر دهید و Id همان رکورد را بدهید. |
| مقدار پیش‌فرض روی داده قبلی اثر ندارد | وجود مقدار غیرخالی رکورد و قابلیت مقدار پیش‌فرض در تعریف فیلد را بررسی کنید. |
| فیلد تازه در گام نمایش رفتار مورد انتظار ندارد | تنظیمات فیلدهای UserTask را بازخوانی، فیلد تازه را تنظیم و ذخیره کنید. |
| SelectBox مقدار خالی یا نام نامرتبط نشان می‌دهد | شناسه ورودی را با ValueField و عنوان نمایشی را با DisplayField منبع آن تطبیق دهید. |
| به جای شناسه کاربر، یک عدد نامرتبط به Lane می‌رسد | خروجی ساده فرم، Id رکورد است؛ فیلد کاربر را از FormData بخوانید. |
| زیر‌فرم با وجود سرویس قبلی خالی است | متغیر خروجی، انتخاب همه داده‌ها و تطابق نام فنی ستون‌ها را بررسی کنید. |
| فیلتر زیر‌فرم اثر ندارد | بررسی کنید داده پیش از آماده‌شدن گام حاضر است یا بعداً در مرورگر بارگذاری می‌شود. |
| تأیید هم بدون شرح پذیرفته نمی‌شود | الزام عمومی شرح در UserTask را بررسی کنید؛ برای الزام فقط در برگشت، تنظیم اقدام مربوط را به کار ببرید. |
| برگشت بدون ثبت، مقدار متفاوتی در متغیر نشان می‌دهد | داده جاری خروجی را از مقدار جدول فرم جدا کنید؛ ذخیره نشدن رکورد به معنی ثبت نشدن خروجی متغیر نیست. |
| رونوشت ذخیره نمی‌شود | حالت فرم را نمایش کنید و Id رکورد را تعیین کنید. |
| عنوان اختیاری هنگام ورود به فرم هنوز قبلی است | عنوان پس از اتمام گام اعمال می‌شود، اما دادهٔ آن باید از متغیرهای ثبت‌شدهٔ گام‌های قبلی باشد؛ خروجی تازهٔ همین Task را در عنوان گام بعد مصرف کنید. |
| سرویس پیام خروجی نامعتبر می‌دهد | نبودن مجموعه نتیجه را از ستون با مقدار Null تفکیک و نیاز به خروجی را مشخص کنید. |
| اسکریپت کلید ورودی را پیدا نمی‌کند | نام پارامتر کد و ورودی ارسال‌شده، به‌ویژه در اجرای آزمایشی، را یکسان کنید. |
| اسکریپت متغیر فرآیند را خالی می‌خواند | شماره مدل، شماره ایجاد، مسیر و ثبت شدن متغیر پیش از این گام را بررسی کنید. |
| نتیجه اسکریپت در عنوان یا فرم خالی است | مسیر ServiceData و ویژگی Result را با خروجی واقعی تطبیق دهید. |
| فرآیند فرزند شروع نمی‌شود | فعال و قابل انتخاب بودن مقصد، نقطه شروع و مجوز کاربر و نقش جاری را بررسی کنید. |
| والد بعد از CallActivity منتظر مانده است | کار یا انتظار فعال در فرزند و رسیدن آن به End را بررسی کنید. |
| خروجی فرزند در والد مقدار ندارد | کلید منتشرشده در End را با نگاشت خروجی CallActivity و متغیر مقصد والد تطبیق دهید. |
| ReceiveTask تنظیمات را نمی‌پذیرد | ورودی‌های CurrentSteps و ProcessCreationID و منبع انتخاب‌شده را بررسی کنید. |
| ادامه بیرونی رد می‌شود | هویت Token، کاربر معتبر، شماره ایجاد و Step انتظار فعال را بررسی کنید. |
| ردیف کارتابل اختصاصی بعد از ادامه باقی می‌ماند | عملیات تغییر وضعیت رکورد و بازخوانی منبع فهرست را بررسی کنید. |
| کار همراه اجرا را ادامه نمی‌دهد | شناسه وظیفه، ارسال داده، حداقل/سقف و اتمام دستی را جداگانه بررسی کنید. |
پس از تغییر تنظیمات، نسخه ذخیره‌شده را با نسخه‌ای که شروع می‌کنید تطبیق دهید. مدیریت نسخه و فعال‌بودن فرآیند در لیست فرآیندها و مدیریت فرآیندها توضیح داده شده است.
چکلیست پذیرش سناریوی دوگامی
| آزمون | انتظار قابل بررسی |
|---|---|
| گام اول در حالت افزودن | رکورد تازه ایجاد شود و شناسهٔ معتبر به متغیر خروجی برسد. |
| گام دوم در حالت ویرایش | همان شناسه و دادهٔ گام اول باز شود؛ ویرایش رکورد دوم نسازد. |
| ورودی Id خالی یا اشتباه | خطا یا نتیجهٔ نامناسب شناسایی و تنظیم ورودی اصلاح شود؛ عنوان فرم جای بررسی Id را نگیرد. |
| حساب و نقش مجاز | گیرنده بتواند کار را باز و اقدام مجاز را اجرا کند. |
| حساب غیرمجاز و نقش غیرمجاز | هر دو وضعیت جداگانه آزموده شوند؛ تغییر نقش همان حساب برای هر دو آزمون کافی نیست. |
| دو شروع مستقل | شناسهٔ نمونه و رکوردها مستقل باشند. |
| تغییر نسخهٔ فعال | شروع تازه از نسخهٔ انتخاب‌شده باشد؛ درخواست قبلی جداگانه پیگیری شود. |
| ذخیرهٔ تنظیمات و مدل | پس از بازکردن مجدد، اتصال‌ها، فرم، خروجی، Id و مجوزها باقی مانده باشند. |
| بازگشت به تب قدیمی | ارجاع بسته‌شده با ارجاع جاری اشتباه نشود. |
| سابقهٔ گردش | اقدام و گیرندهٔ هر گام با سناریوی آزمون تطبیق داشته باشد. |
این موارد معیار پیشنهادی پذیرش هستند؛ نتیجهٔ واقعی هر آزمون را برای نسخه، حساب و دادهٔ استفادهشده ثبت کنید.