/
/
/
/
استودیو — Eventها
Event نقطه شروع، انتظار، واکنش به یک رخداد یا پایان مسیر فرآیند است. با انتخاب نوع مناسب، می‌توانید فرآیند را با اقدام کاربر، موعد زمانی، ارسال داده موبایل یا فراخوانی بیرونی آغاز کنید؛ برای انجام یک کار مهلت بگذارید؛ اجرای مسیر را تا زمان مشخصی نگه دارید؛ یا خطای یک فعالیت را به مسیر رسیدگی بفرستید.
انتخاب رویداد مناسب
| نیاز | رویداد | محل قرارگیری و نتیجه |
|---|---|---|
| آغاز فرآیند توسط کاربر مجاز | Start Event | ابتدای مسیر؛ با شروع کاربر، نمونه جدید ایجاد می‌شود |
| خاتمه مسیر و تعریف خروجی نهایی | End Event | انتهای مسیر؛ خروجی‌های تعریف‌شده در پایان قابل استفاده‌اند |
| ایجاد نمونه جدید طبق برنامه زمانی | Timer Start Event | ابتدای مسیر؛ هر نوبت زمان‌بندی، اجرای جدیدی آغاز می‌کند |
| محدودکردن مهلت انجام UserTask | Timer Boundary Event | روی مرز کار؛ با تمام‌شدن مهلت، کار جاری خاتمه می‌یابد و مسیر مرزی ادامه پیدا می‌کند |
| توقف مسیر تا موعد یا مدت معین | Timer Intermediate Catch Event | میان دو گام؛ کار بعدی پس از پایان انتظار ایجاد می‌شود |
| رسیدگی به خطای اجرای یک فعالیت | Error Boundary Event | روی مرز فعالیت؛ خطا ثبت می‌شود و مسیر رسیدگی ادامه می‌یابد |
| آغاز فرآیند از داده ارسالی یک کار همراه نامحدود | Graph Mobile Start Event | ابتدای مسیر؛ ارسال رکورد به سرور محرک شروع است |
| امکان تکمیل کار از کارتابل یا از فراخوانی بیرونی | Message Boundary Event | روی مرز UserTask؛ یکی از دو راه تکمیل می‌تواند مسیر را جلو ببرد |
| شروع فرآیند از دکمه فرم یا درخواست سرویس | Message Start Event | ابتدای مسیر مقصد؛ فراخوانی مجاز، نمونه جدید را شروع می‌کند |
رویداد میانی مستقل را روی خط اصلی مسیر قرار دهید. رویداد مرزی باید به بدنه فعالیت میزبان متصل باشد؛ نزدیک‌بودن ظاهری آن به فعالیت کافی نیست. برای رویداد مرزی، مسیر خروجی مستقلی رسم کنید تا مقصد واکنش مشخص باشد.
برای افزودن رویداد، در استودیوی فرآیند شکل مناسب را روی بوم قرار دهید، منوی تغییر نوع آن را باز کنید و نوع موردنظر را برگزینید. سپس عنوان، اتصالها و تنظیمات اختصاصی را تکمیل کنید. دایره شروع، رویداد میانی و رویداد پایان محل یکسانی در مدل ندارند؛ پیش از انتخاب علامت داخلی، محل استفاده را مشخص کنید.
تنظیمات مشترک: عنوان و توضیحات رویداد و ذخیره تغییرات از پنل استودیو در دسترس‌اند. برای کار با پنل و بوم به استودیوی فرآیند مراجعه کنید؛ زمان، خروجی، داده آغاز یا رفتار مرزی را در بخش اختصاصی همان رویداد تنظیم کنید.
↑ بازگشت به فهرست آموزشStart Event؛ شروع توسط کاربر
برای فرآیندی که کاربر باید آن را از فهرست فرآیندهای قابل اجرا آغاز کند، Start عادی را در ابتدای مسیر قرار دهید. آن را به نخستین Task وصل کنید و مسیر را تا پایان ادامه دهید.
- Start را داخل Lane شروع‌کننده قرار دهید.
- دسترسی شروع را در همان Lane تنظیم کنید؛ برای نمونه، یک نقش یا کاربر مشخص.
- خروجی Start را به نخستین گام متصل کنید.
- فرم، داده و دریافت‌کنندگان گام‌های بعدی را تکمیل کنید.
- فرآیند را ذخیره و نسخه موردنظر را برای اجرا فعال کنید.
- با کاربر و نقش مجاز، فرآیندهای قابل شروع را باز و اجرای آن را بررسی کنید.
دسترسی Start به آغاز نمونه مربوط است. اینکه پس از آغاز، کار به چه کسی ارجاع شود، به Lane و تنظیمات Task مقصد بستگی دارد. جابه‌جایی Start به Lane دیگر می‌تواند دسترسی آغاز را تغییر دهد؛ جابه‌جایی کار بعدی نیز می‌تواند گیرنده آن کار را عوض کند. تنظیم کامل نقش، کاربر و دسترسی متغیری در Pool و Lane آمده است.
↑ بازگشت به فهرست آموزشتنظیمات عمومی Event و شروع عادی
پنل تنظیمات هر Event، نوع نماد و شناسه آن را در بالای صفحه نمایش می‌دهد. عنوان برای نام‌گذاری خوانای گام روی بوم به‌کار می‌رود؛ توضیحات، شرح تکمیلی همان گام است. دکمه «تنظیمات رفتارها و عملکردها» و آیکون راهنمای بخش‌های اختصاصی را با تنظیمات ویژه نوع Event اشتباه نگیرید.
ویرایشگر توضیحات ابزارهای اندازه و خانواده قلم، قالب متن، ضخیم، مورب، زیرخط، تراز، فهرست و درج محتوا دارد. در فیلد عنوان، علامت × برای پاک‌کردن مقدار در دسترس است.
Start Event عادی ورودی شروع دستی Process از مسیر «کارتابل فرآیند ← فرآیندهای قابل شروع» است. دسترسی آغاز از Lane حاوی آن تعیین می‌شود؛ بنابراین نخست Lane شروع را تنظیم کنید و سپس مسیر خروجی Start را به گام بعد وصل کنید. عنوانی مانند «شروع درخواست» به کاربر کمک می‌کند ورودی درست مدل را تشخیص دهد.
↑ بازگشت به فهرست آموزشپیشنیاز اجرای زمان‌بندی
Timer Start، Timer Boundary و Timer میانی به اجرای فعال زمان‌بند وابسته‌اند. ذخیره یک علامت ساعت روی مدل، زمان‌بند را فعال نمی‌کند. پیش از طراحی و بررسی سناریوی زمانی، تنظیمات وب‌سایت، حساب اجرای تایمر و موتور زمان‌بندی را آماده کنید.
↑ بازگشت به فهرست آموزشتنظیم وب‌سایت و Application Pool
در IIS، وب‌سایت میزبان GraphBPMS و Application Pool مربوط به همان وب‌سایت را مشخص کنید. تنظیمات را روی همان استقرار انجام دهید تا تایمر به برنامه و پایگاه داده موردنظر متصل باشد.
- در Advanced Settings وب‌سایت، Preload Enabled را روی True قرار دهید.
- در Advanced Settings مربوط به Application Pool، Start Mode را روی AlwaysRunning قرار دهید.
- آدرس پایه برنامه را با آدرس قابل دسترسی از خود سرور تطبیق دهید؛ پورت و مسیر برنامه نیز باید درست باشند.
- پیکربندی حساب اجرای تایمر و فعال‌سازی موتور را تکمیل کنید.
- پس از تغییر تنظیمات، Application Pool را Recycle و وب‌سایت را Restart کنید تا تنظیمات جدید در برنامه بارگذاری شوند.
مقدار AlwaysRunning را برای Application Pool وب‌سایت GraphBPMS انتخاب کنید.
↑ بازگشت به فهرست آموزشپیکربندی موتور و حساب اجرا
پارامترهای زمان‌بند در تنظیم سیستمی DynamicTimerConfigs نگهداری می‌شوند. آدرس پایه، نام کاربری و رمز حساب تایمر باید با همان محیط هماهنگ باشند. حساب سیستمی اجرای فرآیند، مانند حساب اختصاصی BpmsTimer، باید فعال و قابل احراز هویت باشد؛ قفل‌شدن حساب یا نامعتبر بودن رمز، اجرای داخلی تایمر را مختل می‌کند.
| تنظیم | مقدار موردنیاز |
|---|---|
DynamicTimerConfigs |
پیکربندی زمان‌بند همان استقرار |
custom.appUrl.baseUrl |
آدرس پایه برنامه که سرور به آن دسترسی دارد |
custom.appUser.userName |
نام حساب اختصاصی اجرای تایمر |
custom.appUser.password |
رمز معتبر همان حساب |
EnableTimer |
مقدار true در تنظیمات برنامه برای فعال‌شدن موتور |
برای رفع خطای احراز هویت، وضعیت حساب، تلاش‌های ناموفق و تطابق رمز را بررسی کنید. پس از تغییر نام یا رمز حساب اجرای تایمر، مقدار متناظر را در پیکربندی زمان‌بند نیز اصلاح کنید.
پس از هر تغییر مؤثر در آدرس پایه، حساب یا فعال‌سازی تایمر، برنامه را دوباره راه‌اندازی کنید. سپس صفحه مدیریت تایمر را باز کنید و فعال‌بودن زمان‌بند را بررسی کنید. برنامه زمانی یک فرآیند باید با شناسه همان نسخه در فهرست کارهای زمان‌بندی‌شده قابل شناسایی باشد.
نکته — آدرس بیرون از محیط محلی: استفاده از
HTTPبرای آدرس غیرمحلی به تنظیمات ارتباطی زیرساخت برنامه وابسته است. آدرس و پروتکل را با پیکربندی همان محیط هماهنگ کنید؛ صرف تغییر آدرس پایه، این پیش‌نیاز را برطرف نمی‌کند.
جزئیات عمومی Timer
در برنامه Timer Start بخش‌های دقیقه و ساعت باید فعال و کامل باشند. روز، ماه یا سال غیرفعال به حالت همه تبدیل می‌شود. در تعیین بازه سال، ابتدای بازه نباید بزرگتر از انتها باشد. گزینه‌های روز شامل روزهای هفته یا ماه، الگوی افزایشی، روزهای مشخص، آخر ماه یا هفته، آخرین روز انتخابی هفته در ماه، فاصله تا انتهای ماه و بازه روز هفته یا ماه است. زمان‌بندی با ساعت و منطقه زمانی سرور انجام می‌شود.
در Timer Boundary، انتخاب روش زمان ضروری است؛ مدت دستی کاملاً صفر یا متغیر موعد خالی پذیرفته نمی‌شود. فیلد تعداد تکرار در نسخه مستندشده غیرفعال است و نباید به‌عنوان قابلیت تکرار تایمر مرزی آموزش داده شود. کلید custom.error.retryInterval در پیکربندی عمومی زمان‌بند، فاصله تلاش دوباره پس از خطای زمان‌بند را برحسب دقیقه تعیین می‌کند؛ این مفهوم با تکرار کسب‌وکاری Timer Boundary متفاوت است.
Timer Start؛ آغاز طبق برنامه زمانی
Timer Start برای کاری مناسب است که باید بدون شروع دستی کاربر و در زمان‌های مشخص اجرا شود؛ برای نمونه بررسی دوره‌ای درخواست‌های منقضی‌شده یا اجرای یک سرویس نگهداری داده. هر نوبت شروع زمان‌بندی‌شده، نمونه جدیدی ایجاد می‌کند. این رفتار را با نگه‌داشتن یک نمونه موجود در Timer میانی اشتباه نگیرید.
↑ بازگشت به فهرست آموزشساخت مسیر زمان‌بندی‌شده
- Start را روی بوم قرار دهید و نوع آن را به Timer Start تغییر دهید.
- عنوان روشنی برای شروع زمانی بنویسید.
- آن را به کار بعدی وصل کنید؛ برای مسیر کاملاً خودکار می‌تواند ServiceTask باشد.
- ادامه کار و End را متصل کنید.
- Timer Start را انتخاب و تنظیمات زمان اجرای فرآیند را باز کنید.
- نوع تقویم و برنامه زمانی را تنظیم و تأیید کنید.
- فرآیند را ذخیره کنید و اجرای تایمر این نسخه را از عملیات مدیریتی آغاز کنید.
در یک فرآیند یک Timer Start تعریف کنید. همین فرآیند می‌تواند علاوه بر مسیر زمانی، Start عادی و مسیر شروع دستی نیز داشته باشد. برای نمونه، در یک Lane مسیر دستی ثبت درخواست قرار می‌گیرد و در Lane دیگر مسیر زمانی بررسی دوره‌ای درخواست‌ها اجرا می‌شود.
↑ بازگشت به فهرست آموزشمثال — پاک‌سازی درخواست‌های بی‌نتیجه: یک سرویس دوره‌ای می‌تواند درخواست‌هایی را پاک کند که هم نتیجه بررسی آن‌ها خالی مانده و هم تاریخ پایانشان گذشته است. هر دو شرط را با هم در عملیات سرویس لحاظ کنید تا درخواست‌های تأییدشده یا درخواست‌های دارای زمان معتبر وارد این پاک‌سازی نشوند. مسیر این کار از Timer Start به ServiceTask و سپس End می‌رود؛ تنظیم خود سرویس در مقاله Taskها و Activityها توضیح داده شده است.
انتخاب تقویم و زمان اجرا
در پنجره زمان‌بندی، تقویم میلادی یا شمسی را متناسب با تقویم کاری انتخاب کنید. سپس بخش‌های دقیقه، ساعت، روز، ماه و سال را تنظیم کنید. انتخاب تقویم باید پیش از نهایی‌کردن مقادیر روز و ماه روشن باشد.
| بخش | انتخاب‌های کاربردی |
|---|---|
| دقیقه و ساعت | هر مقدار، شروع از مقدار معین با گام مشخص، مقادیر منتخب یا بازه |
| روز | روزهای هفته یا ماه، روزهای مشخص و الگوهای انتهای ماه یا هفته |
| ماه | همه ماه‌ها، ماه‌های منتخب، افزایش با گام یا بازه |
| سال | همه سال‌ها، سال‌های منتخب، افزایش با گام یا بازه |
برای اجرای آزمایشی هر دقیقه، برنامه را طوری بسازید که همه دقیقه‌ها و ساعت‌ها و روزهای موردنظر را پوشش دهد. این فاصله فقط انتخاب سناریو است؛ برای کار دوره‌ای واقعی، تناوب را براساس حجم کار و نیاز کسب‌وکار تعیین کنید.
برای محدودکردن اجرا به سال‌های مشخص، بازه سال را همراه ماه‌ها، روزها و ساعت‌های موردنظر تعیین کنید. انتخاب آخرین روز ماه نیز برای کارهایی مانند آماده‌سازی صورتحساب پایان ماه کاربرد دارد. نتیجه برنامه را در مدیریت تایمر با موعد اجرای موردنظر تطبیق دهید.
در تنظیمات نهایی، دقیقه و ساعت را فعال و کامل کنید. اگر روز، ماه یا سال را محدود می‌کنید، محدودهها را با تقویم انتخاب‌شده تطبیق دهید. برای بازه سال، ابتدای بازه نباید از انتهای آن بزرگتر باشد. رشته زمان‌بندی تولیدشده را صرفاً با یک عبارت Cron پنجبخشی سیستم‌عامل جایگزین نکنید؛ برنامه زمانی را با همین پنجره بسازید.
زمان اجرای کار به ساعت و منطقه زمانی سرور وابسته است. اگر موعدی که در مدیریت تایمر دیده می‌شود با انتظار شما فاصله دارد، علاوه بر شرطهای تقویم، ساعت و منطقه زمانی سرور را بررسی کنید.
Timer Start و Wizard کامل تنظیمات Cron
Timer Start یک اجرای جدید Process را مطابق برنامه زمانی آغاز می‌کند. پس از انتخاب نماد، دکمه «تنظیمات اجرای تایمر» پنجره «تنظیمات Cron» را باز می‌کند. عنوان و توضیحات Event را جدا از برنامه زمان‌بندی تنظیم کنید.
در ابتدای Wizard نوع تقویم را بین «میلادی» و «شمسی» تعیین کنید. سپس با سایدبار بین بخش‌های دقیقه، ساعت، روز، ماه و سال جابه‌جا شوید. هر بخش Checkbox فعال‌سازی خود را دارد. ردیف پایین پنجره اجزای عبارت حاصل را در ستون‌های دقیقه، ساعت، روز ماه، ماه، روز هفته و سال نشان می‌دهد. پس از تکمیل همه بخش‌ها، «تأیید» تنظیمات را اعمال می‌کند؛ «لغو» و × برای خروج در دسترس‌اند.
دقیقه و ساعت
| بخش | انتخاب‌های برنامه زمانی |
|---|---|
| دقیقه | هر دقیقه؛ از دقیقه انتخابی به صورت افزایشی؛ انتخاب دقایق موردنظر؛ بازه دقایق |
| ساعت | هر ساعت؛ از ساعت انتخابی به صورت افزایشی؛ انتخاب ساعت/های موردنظر؛ بازه ساعت/ها |
روزهای هفته و ماه
بخش روز امکان ساخت الگوهای تقویمی را بدون نوشتن دستی عبارت Cron فراهم می‌کند. انتخاب روز هفته و روز ماه را با توجه به هدف برنامه انجام دهید؛ فهرست کامل گزینه‌ها در جدول زیر آمده است.
| گروه | گزینه‌ها |
|---|---|
| هر روز | هر روز هفته؛ هر روز ماه |
| افزایشی | از روز در هفته انتخابی به صورت افزایشی؛ از روز در ماه انتخابی به صورت افزایشی |
| انتخاب مشخص | روز/های خاص هفته؛ روز/های خاص ماه |
| انتهای ماه | آخرین روز ماه؛ آخرین روز هفته در ماه؛ آخرین روز انتخابی هفته در ماه؛ تعداد روز مانده به پایان ماه |
| بازه | بازه روزهای هفته؛ بازه روزهای ماه |
ماه و سال
| بخش | انتخاب‌ها |
|---|---|
| ماه | هر ماه؛ از ماه انتخابی به صورت افزایشی؛ انتخاب ماه/های موردنظر؛ بازه ماه/ها |
| سال | هر سال؛ از سال انتخابی به صورت افزایشی؛ انتخاب سال/های موردنظر؛ بازه سال/ها |
برای محدودکردن برنامه به سال مشخص، بخش سال را نیز تکمیل کنید. انتخاب روز و ماه به تنهایی به معنی محدودیت سال نیست. در نمونه زیر مقدار سال 2026 است؛ مقادیر این نمونه را به برنامه کسب‌وکار خود تعمیم ندهید و موعد اجرای حاصل را با تقویم منتخب بررسی کنید.
در نمونهٔ جدول برنامه، دقیقه‌ها 1-5 و ساعت 0 انتخاب شده‌اند؛ یعنی محدودیت دقیقه و ساعت جداگانه تنظیم می‌شود. مقدار روز ماه در تصویر L-30، ماه *، روز هفته ? و سال 2026 است. تعبیر دقیق L-30 در تقویم و موتور همین سامانه نیازمند تأیید فنی است؛ آن را بدون بررسی به «روز سی‌ام» یا «روز سی‌ویکم» تبدیل نکنید.
با محدودکردن سال به یک سال یا بازه مشخص، پس از پایان همان محدوده نوبت زمان‌بندی بعدی ایجاد نمی‌شود. این محدودیت، تکرار داخل محدوده را از بین نمی‌برد: مثلاً برنامه می‌تواند در ساعت‌های انتخاب‌شده هر ۱۰ دقیقه اجرا شود، اما فقط در سال ۲۰۲۶. محدودبودن دوره و تکرارشونده‌بودن درون دوره دو تنظیم مستقل‌اند؛ این توضیح رفتار Timer Start را با انتظار Timer میانی یا مهلت Timer مرزی یکسان نمی‌کند.
برای نمونهٔ پرداخت دوره‌ای حقوق، Timer Start می‌تواند در روز انتخابی ماه فرآیندی را آغاز کند که فهرست کارکنان و اطلاعات حقوق را می‌خواند و به مراحل بعدی می‌رود. معتبر بودن روز منتخب را در ماه‌ها و تقویم برنامه بررسی کنید؛ وجود روز سی‌ویکم را برای همه ماه‌ها فرض نکنید. آغاز فرآیند اعلان دوره‌ای نیز کاربرد دیگری از همین زمان‌بندی است.
Lane شروع تایمری و هویت اجرای زمان‌بندی
با قرارگرفتن Timer Start در Lane، سامانه دسترسی آن Lane را به «کاربر مجری فرآیند» اختصاص می‌دهد و پیام مربوط به این تغییر را نمایش می‌دهد. تنظیم دسترسی مبتنی بر کاربر و انتخاب حساب مجری در پنجره سطح دسترسی قابل مشاهده است. تنظیمات دسترسی این Lane به حالت Read-only درمی‌آید و امکان جایگزین‌کردن آن با کاربران دیگر وجود ندارد.
اگر علاوه بر شروع تایمری به شروع دستی نیاز دارید، Start عادی را در Lane جداگانه با دسترسی کاربران یا نقش‌های کاری قرار دهید. وجود هر دو Start در یک Lane باعث می‌شود دسترسی کل Lane از Timer Start تأثیر بگیرد. سپس Sequence Flow هر ورودی را به گام مقصد متصل کنید. ورود با حساب مجری فرآیند برای دورزدن این تفکیک، الگوی شروع دستی کاربران نیست.
اگر بعد از اجرای خودکار به اقدام یک کاربر کاری نیاز است، User Task مقصد باید در Lane با دسترسی مناسب همان کاربر یا نقش قرار گیرد. هویت اجرای زمان‌بند الزاماً هویت درخواست‌کننده نیست؛ در قواعدی که به کاربر جاری، نقش جاری یا مافوق آن‌ها وابسته‌اند، گیرنده بعد از تایمر را با هویت کسب‌وکار محاسبه کنید.
فعال‌کردن Timer Start، تنظیمات عمومی موتور زمان‌بندی را جایگزین نمی‌کند. آماده‌سازی IIS، حساب اجرای تایمر، آدرس برنامه، DynamicTimerConfigs و EnableTimer باید مطابق بخش «آماده‌سازی اجرای تایمر» همین مقاله انجام شود.
↑ بازگشت به فهرست آموزشخود ورودی Timer Start فقط با محرک زمان‌بندی آغاز می‌شود؛ آن را از «فرآیندهای قابل شروع» مانند Start عادی، با فراخوانی بیرونی مانند Message Start، یا با Broadcast مانند Signal Start آغاز نمی‌کنید. اگر مدل به این محرک‌ها هم نیاز دارد، ورودی مناسب هر محرک را جداگانه طراحی کنید.
تعیین دریافت‌کننده کار انسانی بعد از تایمر
تایمر فرآیند را با حساب اجرای سیستمی شروع می‌کند. اگر UserTask بعد از آن باید به یک کاربر کاری برسد، آن را در Lane با دریافت‌کننده صریح قرار دهید. نگه‌داشتن کار انسانی در زمینه اجرای تایمر می‌تواند باعث شود کار به حساب سیستمی برسد و در کارتابل کاربر موردنظر دیده نشود.
برای نمونه، مسیر Timer Start → ServiceTask → End می‌تواند کاملاً خودکار باشد. اگر بعد از شروع زمانی نیاز به تأیید انسان دارید، UserTask تأیید را در Lane با کاربر یا نقش مناسب قرار دهید و وصول واقعی آن را در کارتابل همان گیرنده بررسی کنید.
شروع، توقف و شناسایی تایمر نسخه
پس از ذخیره مدل، در لیست و مدیریت فرآیندها عملیات شروع تایمر همان نسخه را اجرا کنید. سپس در مدیریت تایمر، کار ثبت‌شده را با شناسه فرآیند و موعد اجرای آن تطبیق دهید. برای متوقف‌کردن شروع‌های بعدی، از توقف تایمر استفاده کنید.
فعال‌بودن نسخه و شروع تایمر دو تنظیم جدا هستند. برای بررسی اجرا، هم نسخه هدف و هم وضعیت برنامه زمانی آن را کنترل کنید. متوقف‌کردن Timer Start، شروع دستی از Start عادی همان مدل را به خودی خود حذف نمی‌کند.
↑ بازگشت به فهرست آموزشکنترل نتیجهٔ عملیات زمان‌بندی‌شده
زمان «اجرای قبلی» در مدیریت تایمر، به‌تنهایی اثر کسب‌وکاری سرویس را ثابت نمی‌کند. پس از یک نوبت اجرا، نمونهٔ ایجادشده، وضعیت گام سرویس و دادهٔ هدف را نیز کنترل کنید. در مثال پاک‌سازی درخواست‌های منقضی و بی‌نتیجه، تعداد رکوردهای مشمول دو شرط را پیش و پس از اجرا مقایسه کنید؛ صرف جابه‌جایی زمان اجرای بعدی کافی نیست. این بررسی را روی دادهٔ آزمون انجام دهید و فقط نتیجهٔ همان دامنه را به موفقیت عملیات نسبت دهید.
↑ بازگشت به فهرست آموزشقرارداد مقدار Timer میانی و مرزی
Timer میانی مسیر را پیش از ایجاد گام بعد نگه می‌دارد. Timer مرزی به فعالیت میزبان متصل است و برای آن مهلت تعیین می‌کند. قرار دادن شکل ساعت نزدیک User Task کافی نیست؛ نماد مرزی باید به بدنه همان Task متصل باشد و Sequence Flow خروجی مستقل داشته باشد.
| تنظیم | رفتار |
|---|---|
| انتخاب نوع مقدار: مقدار دستی | میزان توقف با اجزای ماه، روز، ساعت و دقیقه تعیین می‌شود. نمونه یک‌دقیقه‌ای: صفر ماه، صفر روز، صفر ساعت و یک دقیقه. |
| انتخاب نوع مقدار: انتخاب از متغیر | متغیر موعد را انتخاب کنید؛ حالت ساده مقدار ابتدایی را مصرف می‌کند و حالت پیشرفته برای تعیین مسیر داده به‌کار می‌رود. |
| استفاده از شرح ارجاع سفارشی | فعال‌سازی تنظیم شرح ارجاع برای ادامه ناشی از تایمر. |
| ذخیره تنظیمات | ثبت تنظیمات اختصاصی Timer پس از تکمیل مقادیر. |
در روش دستی، مقدار یک فاصله زمانی است؛ در روش متغیر، موعد تاریخ و ساعت مورد انتظار است. عدد 1 در Variable را خودبه‌خود معادل یک دقیقه فرض نکنید. داده موعد باید به تاریخ و ساعت قابل تفسیر تبدیل شده باشد؛ برای داده ساختاریافته، مسیر عضو مناسب را تعیین کنید.
↑ بازگشت به فهرست آموزشIntermediate Timer Catch؛ انتظار میان گام‌ها
Timer Intermediate Catch Event مسیر جاری را تا زمان تعیین‌شده نگه می‌دارد. کار بعدی هنوز ایجاد نشده است؛ پس از پایان انتظار، مسیر ادامه می‌یابد و اگر مقصد UserTask باشد، آن زمان به گیرنده ارجاع می‌شود.
برای نمونه، پس از تأیید درخواست یک دقیقه فاصله قرار دهید و سپس کار بررسی مدیر را ایجاد کنید. اگر روی کار مدیر نیز Timer Boundary قرار داده باشید، مهلت مدیر بعد از ایجاد همان کار آغاز می‌شود. فاصله قبل از ارجاع و مهلت پاسخ بعد از ارجاع دو انتظار جدا هستند.
↑ بازگشت به فهرست آموزشافزودن انتظار به مسیر
- در محل فاصله موردنظر، رویداد میانی اضافه کنید و نوع Timer Catch را انتخاب کنید.
- خروجی گام قبلی را به آن وصل کنید.
- خروجی تایمر را به گامی که باید پس از انتظار انجام شود متصل کنید.
- روش مدت دستی یا موعد متغیری را با همان معنای شرح‌داده‌شده برای تایمر تنظیم کنید.
- فرآیند را ذخیره کنید و اجرا را تا رسیدن به تایمر ادامه دهید.
- پیش از موعد، نبودن کار بعدی در کارتابل را بررسی کنید؛ پس از موعد، ایجاد همان کار را ببینید.
انتظار میانی با مقدار دستی یا Variable
Intermediate Timer با رسیدن جریان به آن، زمان تعیین‌شده منتظر می‌ماند و سپس مسیر عادی را ادامه می‌دهد. زمان می‌تواند مقدار دستی یا دادهٔ Variable باشد؛ برای Variable، روش ساده یا پیشرفته و مسیر عضو مناسب را انتخاب کنید.
↑ بازگشت به فهرست آموزشحفظ هویت کاری هنگام ادامه از تایمر
ادامه خودکار از تایمر با حساب و نقش سیستمی اجرای تایمر انجام می‌شود. بنابراین کاربر جاری و نقش جاری در آن نقطه الزاماً همان درخواست‌کننده یا آخرین بررسی‌کننده نیستند. این تفاوت روی قواعد ارجاعی مانند انتخاب بالادست نقش جاری اثر دارد.
نکته — گیرنده بعد از انتظار: اگر بعد از تایمر باید کار به مدیر درخواست‌کننده برسد، مقصد را از هویت درخواست‌کننده محاسبه کنید. انتخاب بالادست حساب تایمر ممکن است کار را به مدیر حساب سیستمی بفرستد. صرف جابه‌جایی شکل تایمر به Lane درخواست‌کننده، هویت اجرای خودکار را به او تبدیل نمی‌کند.
دو الگوی کاربردی برای تعیین گیرنده عبارت‌اند از:
- هویت یا نقش لازم را پیش از انتظار در متغیر نگه دارید؛ گیرنده کسب‌وکار را براساس همان داده محاسبه و در دسترسی متغیری Lane مقصد استفاده کنید.
- وقتی فرآیند برای یک بخش مشخص طراحی شده است، شروع را به نقش همان بخش محدود و Lane بررسی بعد از تایمر را به نقش مدیر همان بخش نسبت دهید.
برای بازگشت کار به شخصی که واقعاً قبلاً اقدام کرده است، تنظیم نمایش کارتابل براساس کاربر جاری و قواعد دریافت‌کننده را متناسب با مسیر در Pool و Lane بررسی کنید. گیرنده را با اجرای نمونه و کارتابل واقعی کنترل کنید؛ درست‌بودن نام Lane به‌تنهایی اثبات‌کننده درست‌بودن ارجاع نیست.
↑ بازگشت به فهرست آموزشقواعد مشترک رویدادهای مرزی
در GraphBPMS، Timer Boundary و Message Boundary برای User Task به کار می‌روند. Timer Boundary مهلت یک کار انسانی را کنترل می‌کند؛ آن را جای Timeout داخلی Script Task یا محدودیت اجرای Provider در Service Task قرار ندهید.
هر سه نوع Boundary موجود، Timer، Message و Error، Interrupting هستند: با وقوع رویداد، منطق جاری میزبان قطع می‌شود و مسیر مرزی ادامه می‌یابد. برای هر Boundary مسیر خروجی خودش را رسم کنید. نزدیک‌بودن Event به Task یا داشتن خروجی معمولی برای Task، جای اتصال مرزی و خروجی آن را نمی‌گیرد.
↑ بازگشت به فهرست آموزشTimer Boundary؛ مهلت انجام فعالیت
Timer Boundary را وقتی به‌کار ببرید که کار به کاربر ارجاع شده است، اما نباید برای همیشه منتظر اقدام او بماند. برای نمونه، مدیر یک دقیقه برای بررسی درخواست فرصت دارد و پس از آن درخواست به جانشین می‌رود. مقدار یک دقیقه متعلق به این مثال است؛ مهلت واقعی باید با زمان پاسخ مورد انتظار سازمان هماهنگ باشد.
↑ بازگشت به فهرست آموزشاتصال رویداد به کار و طراحی مسیر مهلت
- رویداد مرزی را روی لبه UserTask قرار دهید و نوع Timer را انتخاب کنید.
- اتصال آن به بدنه همان کار را بررسی کنید.
- از خود رویداد مرزی یک Sequence Flow به مقصد پس از مهلت رسم کنید؛ برای مثال UserTask جانشین.
- مسیر عادی UserTask را نیز به مقصد اقدام کاربر متصل نگه دارید.
- Timer Boundary را انتخاب و روش تعیین زمان را تنظیم کنید.
- فرم و گیرنده کار مقصد مسیر مرزی را تکمیل و فرآیند را ذخیره کنید.
انتخاب منبع مقدار تایمر مرزی
در تنظیمات TimerEventDefinition، «انتخاب نوع مقدار» دو گزینهٔ «انتخاب از متغیر» و «مقدار دستی» دارد. این انتخاب را پیش از تعیین مقدار انجام دهید. تنظیمات رویدادِ متصل به یک وظیفه با تقویم Cron رویداد شروع یکسان نیست.
تعیین مهلت با مقدار دستی
برای فاصله ثابت از زمان رسیدن فرآیند به کار، روش ورود دستی را انتخاب و میزان توقف را تکمیل کنید. مدت با اجزای ماه، روز، ساعت و دقیقه مشخص می‌شود. در مثال مهلت یک دقیقه، اجزای دیگر صفر و دقیقه برابر یک است.
↑ بازگشت به فهرست آموزشنکته — مدت نسبی و موعد مشخص: این مقدار یک فاصله زمانی است. برای نمونه یک دقیقه از زمان ورود به کار محاسبه می‌شود؛ نوشتن ساعت روز در جای مدت، معنای تنظیم را تغییر می‌دهد. اگر نیاز به یک موعد تقویمی مشخص دارید، روش متغیر را انتخاب کنید.
تعیین موعد از متغیر
در روش متغیر، مقدار ورودی تاریخ و ساعت موعد است. متغیر را در گامی پیش از انتظار آماده کنید؛ برای نمونه سرویس مقدار تاریخ و ساعت را برگرداند و خروجی آن در متغیر فرآیند قرار گیرد.
- روش متغیر را در تنظیم تایمر انتخاب کنید.
- متغیر حاوی موعد را مشخص کنید.
- اگر موعد عضو یک خروجی ساختاریافته است، حالت پیشرفته و مسیر عضو مناسب را تنظیم کنید.
- بررسی کنید مقدار نهایی یک تاریخ و ساعت میلادی قابل تفسیر باشد؛ مقدار
DateTimeیاDateTime2خروجی سرویس نمونه مناسبی است. می‌توانید موعد را پیش از رسیدن به تایمر با ScriptTask محاسبه و در متغیر ذخیره کنید؛ روش ساخت این خروجی در Taskها و Activityها آمده است. - موعد را با ساعت مورد انتظار روی سرور تطبیق دهید.
↑ بازگشت به فهرست آموزشنکته — نوع مقدار موعد: متغیر حاوی عدد
1به معنای «یک دقیقه بعد» نیست. همچنین نمایش شمسی یک تاریخ در فرم را بدون تبدیل مناسب به‌عنوان مقدار موعد ندهید. روش دستی، مدت نسبی می‌گیرد؛ روش متغیر، زمان وقوع را مشخص می‌کند.
نتیجه اقدام کاربر و پایان مهلت
اگر کاربر پیش از موعد کار را ثبت کند، مسیر عادی UserTask ادامه می‌یابد و تایمر متعلق به آن انتظار لغو می‌شود. اگر مهلت تمام شود و کار هنوز منتظر باشد، کار از کارتابل دریافت‌کنندگان آن خارج و مسیر خروجی Timer Boundary اجرا می‌شود.
این انتقال، یک رونوشت اضافی برای جانشین نیست. کار قبلی دیگر برای ادامه عادی در اختیار دریافت‌کنندگان باقی نمی‌ماند. برای بررسی درست، هم کارتابل گیرنده قبلی و هم کارتابل مقصد مسیر مرزی را مشاهده کنید.
تایمرهای مرزی تک‌موعد پس از اجرای انتظار از فهرست انتظار زمان‌بند حذف می‌شوند. آن‌ها را با کار تکرارشونده Timer Start که همچنان برای نوبت‌های بعد وجود دارد مقایسه نکنید؛ شناسه فرآیند و نوع کار زمان‌بندی‌شده را هنگام بررسی تطبیق دهید.
↑ بازگشت به فهرست آموزشاگر کاربر پیش از پایان مهلت User Task را ثبت کند، مسیر عادی ادامه می‌یابد و انتظار تایمر همان کار خاتمه پیدا می‌کند. اگر مهلت در زمان انتظار کار تمام شود، کار قبلی از دسترس اقدام خارج می‌شود و مسیر مرزی ادامه پیدا می‌کند. این انتقال به معنی ایجاد رونوشت اضافی از همان کار نیست.
↑ بازگشت به فهرست آموزشپایان مهلت و لغو انتظارهای همان کار
Timer Boundary روی User Task برای مهلت همان انتظار است. اگر زمان بگذرد و کاربر هنوز گام را ثبت نکرده باشد، User Task از کارتابل خارج می‌شود و جریان از خروجی Timer Boundary ادامه می‌یابد. Boundaryهای دیگر همان گام، مانند Message Boundary منتظر، نیز از مدار خارج می‌شوند؛ مسیرهای معلق آن گام پس از عبور Timer مستقل ادامه پیدا نمی‌کنند.
↑ بازگشت به فهرست آموزشMessage Start؛ آغاز با فراخوانی بیرونی
Message Start نقطه ورودی فرآیندی است که باید با فراخوانی یک فرم یا سرویس آغاز شود. برای نمونه، کاربر در یک فرم مستقل متن درخواست را می‌نویسد و با دکمه شروع فرآیند، آن متن را به متغیر ورودی فرآیند مقصد می‌فرستد.
↑ بازگشت به فهرست آموزشآمادهسازی فرآیند مقصد
- Start را به نوع Message Start تغییر دهید.
- Lane شروع را برای کاربر یا نقش مجاز تنظیم کنید.
- متغیرهای ورودی موردنیاز مقصد را بسازید.
- مسیر بعد از Start را تکمیل کنید؛ مانند ServiceTask پردازش ورودی و UserTask نمایش نتیجه.
- End را به انتهای مسیر وصل و خروجی‌های لازم را در آن تعریف کنید.
- فرآیند را ذخیره و نسخه قابل اجرا را فعال کنید.
خود Message Start برای انتخاب سرویس فراهم‌کننده، پنل تنظیمات Message Boundary را ندارد. داده شروع از فراخواننده به متغیرهای فرآیند می‌رسد. مجازبودن شروع نیز باید با دسترسی Lane و هویت فراخوانی هماهنگ باشد.
↑ بازگشت به فهرست آموزشMessage Start به‌عنوان ورودی فراخوانی بیرونی
برای شروع Process با سرویس عمومی GraphBPMS، REST API، ESB، دکمه Form یا Custom.js و RunProcess، ورودی Message Start را در مدل قرار دهید. این انتخاب فقط نحوه آغاز را تعیین می‌کند: Process می‌تواند پس از شروع بیرونی به User Task برسد و منتظر اقدام کاربر بماند.
فراخواننده باید دسترسی Lane حاوی Message Start را داشته باشد و فراخوانی را با ورودی‌ها و هویت معتبر انجام دهد. این مسیر آغاز با منوی فرآیندهای قابل شروع، زمان‌بندی Timer Start و دریافت Broadcast در Signal Start متفاوت است.
↑ بازگشت به فهرست آموزشMessage Start و Message Boundary در رابط تنظیمات
Message Start نقطه آغاز یک نمونه جدید با فراخوانی بیرونی است؛ Message Boundary به User Task موجود متصل می‌شود و راه دیگری برای تکمیل انتظار جاری فراهم می‌کند. در تنظیم Message Start، پنل عمومی شناسه، عنوان، توضیحات و رفتارها نمایش داده می‌شود؛ داده آغاز از فراخواننده و Variableهای ورودی تأمین می‌شود.
شروع از دکمه فرم
در فرم مبدأ، دکمه‌ای با عملکرد شروع فرآیند تنظیم کنید. فرآیند مقصد را انتخاب و عنوان نمونه و ورودی‌های آن را تعریف کنید.
- در تنظیمات دکمه، نوع عملکرد شروع فرآیند را انتخاب کنید.
- در فرآیند مورد نظر، مقصد دارای Message Start را برگزینید.
- عنوان فرآیند را تنظیم کنید. می‌توانید عنوان را از قطعات ثابت و مقادیر کنترلی یا سیستمی بسازید.
- برای افزودن هر قطعه عنوان، نوع و مقدار را تعیین و دکمه افزودن را بزنید؛ نتیجه نهایی را بررسی کنید.
- پارامترهای ورودی را تنظیم کنید؛ برای مثال متغیر مقصد
@@Var1از مقدار یک کنترل متنی فرم مبدأ تغذیه شود. - نحوه شروع، به صورت سرویس یا به صورت معمولی، را انتخاب کنید.
- فرم را ذخیره و با کاربر مجاز اجرا کنید.
برای عنوان ترکیبی، ترتیب قطعات را بررسی کنید تا جمله نهایی خوانا باشد. متن عنوان برای شناسایی نمونه است؛ مقدارهای موردنیاز منطق فرآیند را در پارامترهای ورودی جداگانه بفرستید.
↑ بازگشت به فهرست آموزششروع Process از دکمه یک Form مستقل
در تنظیمات اختصاصی دکمه Form مبدأ، «نوع عملیات» را «شروع فرآیند» قرار دهید و Process مقصد را انتخاب کنید. برای عنوان نمونه، قطعات موردنظر را از مقدار ثابت، مقدار سیستمی، کنترل، کوئری استرینگ یا پارامتر فرم اضافه کنید. علامت + قطعه را به «نتیجه نهایی» اضافه می‌کند و × روی هر قطعه آن را حذف می‌کند.
در «نحوه شروع فرآیند»، حالت «به صورت سرویس» برای اجرای فراخوانی بدون بازشدن خودکار Form کار بعدی در همان محل و حالت «به صورت معمولی» برای نمایش ادامه Process است. در حالت معمولی، Target محل بازشدن را تعیین می‌کند؛ نمونه «بازکردن روی صفحه فعلی» است. «افزودن پارامتر» برای مقداردهی ورودی‌های Process مقصد به‌کار می‌رود. عنوان نمونه، ورودی منطق Process را جایگزین نمی‌کند.
↑ بازگشت به فهرست آموزشتفاوت شروع به صورت سرویس و معمولی
| نحوه شروع | رفتار قابل انتظار |
|---|---|
| به صورت سرویس | فرآیند اجرا می‌شود و نتیجه فراخوانی به فرم برمی‌گردد؛ UserTask ایجادشده می‌تواند در کارتابل قرار گیرد، اما فرم آن در همان محل به‌طور خودکار باز نمی‌شود |
| به صورت معمولی | شروع همراه با نمایش ادامه فرآیند است؛ می‌توانید بازشدن در صفحه فعلی یا تب جدید را تنظیم کنید |
در حالت سرویس، می‌توانید پس از موفقیت فراخوانی، پیام مناسب در فرم مبدأ نمایش دهید. این پیام نشان‌دهنده موفقیت شروع در همان مرحله است؛ به معنی پایان تمام کارهای انسانی فرآیند نیست. اگر مسیر به UserTask رسیده باشد، نمونه منتظر اقدام بعدی باقی می‌ماند.
در حالت معمولی، انتخاب صفحه فعلی یا تب جدید را متناسب با تجربه کاربر تعیین کنید. سپس هم نمایش فرم بعدی و هم وصول کار به گیرنده درست را بررسی کنید. تنظیم ظاهر شروع، دسترسی Lane مقصد را تغییر نمی‌دهد.
↑ بازگشت به فهرست آموزششرط نمایش Form بعد از شروع معمولی
دکمه Form در حالت «به صورت سرویس»، Process را آغاز می‌کند و لازم نیست Form مقصد را در همان محل باز کند. در حالت «به صورت معمولی»، انتظار این است که Form User Task مقصد در صفحه فعلی یا صفحه جدید نمایش داده شود.
برای استفاده از این قابلیت، از Message Start تا User Task موردنظر نباید Node انتظارپذیر دیگری قرار داشته باشد. Nodeهای انتظارپذیر مطرح‌شده در موتور عبارت‌اند از User Task، Graph Mobile Task، Receive Task، Timer Intermediate Catch Event، Signal Intermediate Catch Event و Call Activity Task. User Task مقصد، پایان این مسیر قابل نمایش است؛ محدودیت مربوط به انتظارهای واسط پیش از رسیدن به آن است.
برای مثال، اگر مسیر ابتدا به Receive Task برسد، آن گام منتظر فراخوانی ادامه می‌ماند و هنوز Form User Task بعدی برای نمایش آماده نیست. در این مدل، تنظیم دکمه برای نمایش فوری Form با مسیر واقعی Process سازگار نیست.
↑ بازگشت به فهرست آموزششروع با درخواست سرویس
برای فراخوانی از یک سرویس، درخواست POST به مسیر /Process/RunProcess در آدرس پایه برنامه بفرستید. درخواست باید با هویت معتبر انجام شود. اگر از توکن خصوصی استفاده می‌کنید، مقدار توکن حاصل از احراز هویت را در سرآیند PrivateToken قرار دهید.
در نگاشت خروجی احراز هویت، نام عضو داده را دقیق انتخاب کنید. برای خروجی دارای عضو PrivateToken، مسیر عضو همان PrivateToken است؛ حروف نام عضو JSON را با یک نام متفاوت جایگزین نکنید. مقدار واقعی توکن باید از خروجی احراز هویت همان اجرا گرفته شود.
| فیلد بدنه | کاربرد و نحوه تنظیم |
|---|---|
ProcessGroup |
شناسه گروه فرآیند؛ با تعیین آن، نسخه فعال گروه برای شروع انتخاب می‌شود |
Process |
شناسه یک نسخه مشخص؛ برای انتخاب از گروه، این فیلد را خالی بگذارید |
RunType |
برای Message Start مقدار 500002 |
Variables |
متغیرهای ورودی مقصد |
ProcessTitle |
عنوان نمونه جدید |
UserID و RoleID |
برای الگوی شروع با کاربر جاری، به‌ترتیب از متغیر کاربر جاری و نقش جاری مقداردهی کنید |
VerboseLevel |
مقدار اختیاری برای تعیین جزئیات پاسخ |
برای استفاده از نسخه فعال گروه، ProcessGroup را با شناسه واقعی گروه مقصد تنظیم و Process را خالی بگذارید. شناسه گروه و شناسه نسخه دو مقدار متفاوت‌اند؛ مقدار نمایش‌داده‌شده برای یک فرآیند را به فرآیند دیگر تعمیم ندهید.
نکته — انتقال ورودی: پارامتر
Variablesرا متناسب با ورودی‌های مقصد مقداردهی کنید. خالی‌گذاشتن آن، مقدارهای فرآیند فراخواننده را خودکار به مقصد نمی‌فرستد؛ اگر مقدار لازم را ارسال نکنید، کنترل نمایش‌دهنده آن در مقصد می‌تواند خالی باشد.
حداقل یکی از شناسه‌های گروه یا نسخه لازم است. برای استفاده از نسخه فعال گروه، فقط ProcessGroup را مبنای انتخاب قرار دهید؛ وقتی هر دو مقدار داده شوند، انتخاب گروه بر شناسه نسخه تقدم دارد. هیچ‌یک از شناسه‌های یک محیط را بدون جایگزینی با شناسه واقعی مقصد در محیط دیگر استفاده نکنید.
ارسال UserID یا RoleID در بدنه به‌تنهایی مجوز اجرای فرآیند یا جانشینی کاربر ایجاد نمی‌کند. رابطهٔ این فیلدها با هویت توکن و هویت مؤثر اجرا باید طبق قرارداد همان endpoint و استقرار کنترل شود. برای جزئیات نام ورودی، پوستهٔ پاسخ و احراز هویت، مرجع فنی API و Custom JS را ببینید.
ساختار هر ردیف متغیر ورودی، نام و مقدار است. برای نمونه، اگر مقصد متغیری به نام @@Var1 دارد، بخش Variables می‌تواند چنین باشد:
این قطعه فقط محتوای فیلد Variables است. نام متغیر را با نام واقعی مقصد یکسان قرار دهید و مقدار را از ورودی موردنظر نگاشت کنید. خالی‌گذاشتن این فهرست، داده کنترل فرم یا متغیر فرآیند فراخواننده را خودکار منتقل نمی‌کند.
اندازه پاسخ و معنای موفقیت
برای کاهش جزئیات پاسخ می‌توانید VerboseLevel را برابر 0 قرار دهید تا نتیجه بر متغیرهای خروجی فرآیند متمرکز شود. اگر این پارامتر را نفرستید، پاسخ کامل‌تر برمی‌گردد. متغیرهای خروجی موردنیاز را در End مقصد تعریف کنید؛ کم‌کردن جزئیات پاسخ، جای تعریف خروجی را نمی‌گیرد.
شروع با Message Start، اجرای مستقل فرآیند مقصد را آغاز می‌کند. اگر فراخواننده خودش یک فرآیند باشد، ادامه آن و ادامه فرآیند مقصد را جدا بررسی کنید. برای سناریویی که فرآیند فراخواننده باید در یک فعالیت منتظر پایان فرآیند فرزند بماند و خروجی‌هایش را تحویل بگیرد، Call Activity را به‌کار ببرید.
برای کاهش جزئیات پاسخ می‌توانید VerboseLevel را برابر 0 قرار دهید. در این حالت محتوای نتیجه به خروجی‌های رویداد برمی‌گردد و اطلاعات عمومی وضعیت پاسخ، مانند موفقیت یا خطا، همچنان باید بررسی شود. این تنظیم دادهای را که هنوز تولید نشده ایجاد نمی‌کند؛ اگر مقصد در انتظار UserTask باشد، نباید نتیجه نهایی End را پیش از رسیدن به آن گام انتظار داشته باشید.
اگر VerboseLevel را نفرستید، پاسخ با جزئیات پیشفرض برمی‌گردد. ابتدا وضعیت موفقیت یا خطا را بررسی کنید و سپس عضو موردنیاز نتیجه را بخوانید. صرف دریافت یک پاسخ HTTP یا نمایش یک پیام ثابت، اثبات‌کننده دریافت درست متغیرهای مقصد نیست.
Message Boundary؛ ادامهٔ انتظار جاری
Message Boundary امکان ادامه یک کار را از فراخوانی بیرونی فراهم می‌کند، در حالی که همان UserTask از کارتابل معمول نیز قابل انجام است. نمونه کاربرد آن کار تأیید درخواست است: مسئول می‌تواند فرم کارتابل را ثبت کند یا از یک فهرست اختصاصی درخواست‌ها، همان مورد را تأیید کند.
در این الگو یک انتظار کاری، دو راه تکمیل دارد. پس از تکمیل از یکی از راه‌ها، راه دیگر نباید دوباره همان کار را ادامه دهد. Message Boundary را از Message Start تفکیک کنید: مرزی، کار موجود را ادامه می‌دهد؛ شروع، نمونه جدید می‌سازد.
↑ بازگشت به فهرست آموزشآمادهسازی UserTask و رویداد مرزی
- UserTask تأیید را در Lane مسئول مربوط قرار دهید و مسیر عادی خروجی آن را تکمیل کنید.
- Message Boundary را روی مرز همین UserTask قرار دهید.
- مسیر خروجی خود رویداد را به گام بعد از تأیید بیرونی وصل کنید؛ برای نمونه سرویس ثبت وضعیت تأیید.
- سرویس فراهم‌کننده داده رویداد و پارامترهای آن را تنظیم کنید.
- خروجی موردنیاز سرویس را در متغیر ذخیره کنید.
- کاربر مجاز برای ادامه بیرونی و تنظیم دسترسی مربوط را مشخص کنید.
- فرآیند را ذخیره کنید و هر دو راه تکمیل را با نمونه‌های جدا بررسی کنید.
↑ بازگشت به فهرست آموزشنکته — مسیر ادامه بیرونی: خروجی رویداد مرزی را حتماً متصل کنید. کامل‌بودن مسیر عادی UserTask، نبودن مسیر خروجی Message Boundary را جبران نمی‌کند؛ فراخوانی بیرونی باید مقصد مشخصی برای ادامه داشته باشد.
تنظیمات Message Boundary
در Message Boundary، منبع داده و ورودی‌ها را همراه هویت معتبر اجرای ادامه بیرونی تعیین کنید. این تنظیمات با تنظیمات آغاز یک نمونه جدید یکسان نیستند.
| گزینه | کاربرد |
|---|---|
| مدیریت منبع داده | انتخاب منبع داده؛ پس از انتخاب، شناسه، عنوان و نوع منبع داده در پنل دیده می‌شود. |
| مدیریت پارامترها | مقداردهی ورودی‌های منبع داده. |
| تنظیمات خروجی | بدون خروجی یا نگهداری خروجی در Variable. |
| کاربر معتبر | انتخاب هویت مجاز برای تکمیل بیرونی. |
| اعمال سطح دسترسی لین جاری | کنترل دسترسی با توجه به Lane جاری. |
| تنظیمات عنوان اختیاری | فعال‌سازی و تنظیم عنوان اختیاری نمونه. |
| تنظیمات اعلان شرح ارجاع | فعال‌سازی تنظیم مربوط به شرح ارجاع. |
| ذخیره تغییرات | ثبت تنظیمات Message Boundary. |
برای تکمیل بیرونی باید نمونه منتظر و گام صحیح آن مشخص باشند؛ شناسه Record فرم، ProcessCreationID و شناسه گام یا ارجاع را به جای یکدیگر استفاده نکنید. وقتی ادامه از یکی از مسیرهای کارتابل یا فراخوانی بیرونی انجام شد، همان انتظار نباید بار دوم ادامه پیدا کند.
↑ بازگشت به فهرست آموزشMessage Boundary: ثبت انتظار در ابتدا، ادامه پس از پیام
Providerِ Message Boundary هنگام رسیدن نمونه به User Task اجرا می‌شود تا اطلاعات انتظار را در محل موردنیاز کسب‌وکار ثبت کند. دریافت پیام، محرک ادامهٔ بعدی است؛ اجرای Provider تا آن لحظه عقب نمی‌افتد. نوع منبع داده می‌تواند SQL، REST، WSDL یا منبع مناسب دیگری باشد. شباهت تنظیمات منبع داده با Service Task، رفتار این دو عنصر را یکسان نمی‌کند.
Provider باید دو ورودی متناظر با @@ProcessCreationID و @@CurrentSteps داشته باشد. شناسهٔ نمونه، اجرای موردنظر را مشخص می‌کند و شناسهٔ گام، محل انتظار را. در تصویر، نام پارامترهای نمونه first و second است؛ آنچه باید با قرارداد Provider هماهنگ شود مقدارهای دو شناسه است، نه کپی‌کردن این نام‌های نمونه در همهٔ منبع‌های داده.
در بخش «تنظیمات خروجی»، نتیجهٔ همین Provider را در صورت نیاز در Variable نگه دارید؛ برای مثال، شناسهٔ ردیفی که انتظار را در فهرست اختصاصی ثبت کرده است. این خروجی را با پیام ادامه‌ای که بعداً دریافت می‌شود یکی نگیرید.
↑ بازگشت به فهرست آموزشثبت اطلاعات انتظار برای ادامه بیرونی
سرویس رویداد می‌تواند اطلاعات لازم برای فهرست درخواست‌های قابل اقدام را ثبت کند. برای اینکه درخواست بیرونی بداند کدام نمونه و کدام گام را ادامه دهد، شناسه نمونه و مشخصات گام جاری باید همراه رکورد درخواست نگهداری شوند.
| داده | کاربرد |
|---|---|
@@ProcessCreationID |
شناسایی نمونه فرآیندی که منتظر ادامه است |
@@CurrentSteps |
اطلاعات گام جاری برای اتصال درخواست بیرونی به همان انتظار |
| شناسه رکورد درخواست | ارتباط داده کسب‌وکار و ردیف فهرست اختصاصی با فرآیند |
| کاربر مجاز | تعیین هویتی که اجازه تکمیل بیرونی دارد |
دو متغیر سیستمی نمونه و گام را به ورودی‌های سرویس مربوط نگاشت کنید. شناسه جدول درخواست، شناسه نمونه فرآیند و شناسه گام یکسان نیستند؛ برای هرکدام فیلد و نگاشت جدا داشته باشید. خروجی سرویس، مانند شناسه رکورد درخواست ثبت‌شده، می‌تواند در متغیر فرآیند قرار گیرد و در ادامه استفاده شود.
در دکمه ادامه بیرونی، ابتدا احراز هویت معتبر انجام شود و سپس فراخوانی ادامه فرآیند با اطلاعات همان انتظار اجرا شود. ساخت توکن، پارامترهای ادامه و سرویس واسط با الگوی Receive Task در Taskها و Activityها مرتبط است؛ در Message Boundary، انتظار به UserTask موجود متصل است.
↑ بازگشت به فهرست آموزشادامهٔ مجاز و رقابت با Timer Boundary
سامانهٔ فراخواننده دو شناسهٔ ذخیره‌شده را برای ادامهٔ همان انتظار، از مسیر ContinueProcess در سرویس عمومی یا helper مربوط به absoluteMethodHelper ارسال می‌کند. هویت فراخوان باید با Token یا نشست معتبر احراز شده و مطابق تنظیم «کاربر معتبر» مجاز باشد؛ داشتن شناسهٔ صحیح نمونه و گام، به‌تنهایی مجوز ادامه نمی‌دهد.
| رخداد | نتیجهٔ انتظار میزبان |
|---|---|
| پیام معتبر پیش از سررسید می‌رسد. | User Task از کارتابل خارج می‌شود، مسیر Message Boundary ادامه می‌یابد و Timer Boundary دیگرِ همان انتظار لغو می‌شود. |
| پیامی نرسیده و Timer نیز هنوز فعال نشده است. | User Task در انتظار کاربر باقی است؛ زمان‌بندی Timer همچنان برقرار است. |
| Timer Boundary زودتر فعال می‌شود. | مسیر Timer ادامه می‌یابد و Message Boundary همان انتظار لغو می‌شود؛ ادامهٔ دوبارهٔ همان گام از مسیر پیام مجاز نیست. |
برای آزمون، دو اجرای مستقل بسازید: در یکی پیام را پیش از موعد بفرستید و در دیگری اجازه دهید Timer زودتر فعال شود. کارتابل میزبان و تاریخچهٔ همان نمونه را بررسی کنید تا فقط مسیر مربوط به رخداد تکمیل‌کننده ادامه یافته باشد.
↑ بازگشت به فهرست آموزشMessage Boundary در مدل درخواست سفارشی
در این مدل، رویداد Message Boundary به لبهٔ UserTask متصل است و مسیر خروجی آن به ServiceTask «تغییر وضعیت درخواست» می‌رود. تنظیمات MessageEventDefinition مدیریت منبع داده، خروجی و «کاربر معتبر» را نشان می‌دهد. این نمای طراحی، اتصال رویداد و وظیفه را روشن می‌کند؛ احراز مجوز فرستنده و رفتار پیام تکراری باید جداگانه آزمون شود.
رفتار پس از یکی از دو روش تکمیل
اگر ادامه بیرونی موفق شود، کار معمول UserTask از کارتابل خارج می‌شود و دیگر برای ثبت دوباره در اختیار کاربر باقی نمی‌ماند. سابقه اجرا مشخص می‌کند ادامه از سرویس خارجی انجام شده است.
اگر کاربر از کارتابل معمول فرم را ثبت کند، انتظار Message Boundary همان کار نیز خاتمه می‌یابد و فراخوانی بیرونی بعدی نباید آن را دوباره ادامه دهد. در فهرست اختصاصی نیز وضعیت رکورد درخواست را با سرویس بعد از تأیید به‌روز کنید تا درخواست انجام‌شده همچنان در فهرست «در انتظار» نمایش داده نشود.
برای نمونه، اگر فهرست فقط رکوردهای تأییدنشده را نشان می‌دهد، سرویس ادامه باید وضعیت تأیید رکورد را ثبت کند. خارج‌شدن از کارتابل فرآیند، به‌تنهایی شرط فیلتر جدول اختصاصی شما را تغییر نمی‌دهد.
↑ بازگشت به فهرست آموزشکلید و انواع رویداد Signal
در Eventهای سیگنال، «کلید سیگنال» رابط فرستنده و گیرنده است. نماد Catch مثلث توخالی دارد و نماد Throw با مثلث پُر نمایش داده می‌شود. عنوان روی بوم نام قابل‌خواندن گام است؛ آن را جای کلید سیگنال در تنظیمات در نظر نگیرید.
↑ بازگشت به فهرست آموزشSignal Start؛ آغاز با دریافت سیگنال
Signal Start با دریافت سیگنال همکلید، ورودی آغاز یک نمونهٔ جدید است. کلید انتخاب‌شده، این رویداد را به فرستندهٔ سیگنال مرتبط می‌کند.
در Start دریافت‌کننده سیگنال، بخش «انتخاب کلید سیگنال» را باز و کلید موردنظر را از Dropdown انتخاب کنید. همین انتخاب در Intermediate Catch Signal Event نیز وجود دارد؛ تفاوت جای رویداد در مدل است: Start ورودی آغاز و Intermediate Catch انتظار در مسیر جاری است.
Intermediate Catch Signal؛ دریافت سیگنال در مسیر جاری
Intermediate Catch Signal در مسیر یک نمونهٔ در حال اجرا منتظر دریافت سیگنال می‌ماند. در «انتخاب کلید سیگنال»، کلید موردنظر را از فهرست برگزینید؛ این انتظار، آغاز یک نمونهٔ تازه نیست.
Intermediate Throw Signal؛ ارسال سیگنال و ادامهٔ مسیر
Intermediate Throw Signal سیگنال و مقادیر ورودی مقصد را منتشر می‌کند و سپس مسیر همان نمونه ادامه می‌یابد.
در Intermediate Throw Signal Event، «کلید سیگنال» و سپس «تنظیمات مقادیر ورودی» را تکمیل کنید. برای انتقال داده، Variable مقصد را مشخص و روش مقداردهی آن را انتخاب کنید.
| روش ورودی | تنظیم لازم |
|---|---|
| بدون مقدار اولیه و خالی | برای این ورودی مقدار اولیه‌ای تعیین نمی‌شود. |
| ورود مقدار اولیه از متغیر | انتخاب Variable مبدأ و روش ساده یا پیشرفته خواندن داده. |
| ورود مقدار اولیه ثابت | ثبت مقدار ثابت برای Variable مقصد. |
| ورود مقدار اولیه از تابع | تعیین تابعی که مقدار ورودی را تولید می‌کند. |
جدول ورودی‌ها ستون‌های «متغیر مقصد»، «نوع ورودی» و «مقدار ورودی» دارد. با «افزودن/ویرایش متغیر» نگاشت را باز کنید، متغیر مقصد و مقدار را تنظیم و «ذخیره» را بزنید. «لغو» ویرایش همان نگاشت را کنار می‌گذارد. مثال SomeMayVariable و perm فقط نام‌های یک نگاشت نمونه‌اند.
End Throw Signal؛ ارسال سیگنال در پایان مسیر
End Throw Signal در پایان مسیر سیگنال منتشر می‌کند. ورودی‌های همراه سیگنال و خروجی‌های نهایی End دو تنظیم مستقل هستند.
Signal End Event افزون بر کلید سیگنال و تنظیمات مقادیر ورودی، «مدیریت متغیرهای خروجی» را دارد. خروجی نهایی End با ورودی‌هایی که همراه سیگنال مقداردهی می‌شوند دو تنظیم جدا هستند و باید هرکدام با مقصد خود هماهنگ باشند.
ابتدا یک Node از جنس End را انتخاب کنید؛ سپس در منوی Change element، نوع Signal end event را برگزینید. گزینه‌های کم‌رنگ در زمینه انتخاب جاری قابل انتخاب نیستند؛ پیش از تغییر نوع، محل و اتصالات گام را بررسی کنید.
ترتیب عملیات در End Throw Signal
End Throw Signal ابتدا عملیات Throw Signal را انجام می‌دهد و سپس رفتار End عادی را اجرا می‌کند: تولید متغیرهای خروجی و، هنگام تحقق پایان واقعیِ نمونه و باقی‌نماندن ارجاع منتظر، ثبت پایان رسمی. رسیدن یک شاخه به End در حضور انتظار فعالِ شاخهٔ دیگر، به‌تنهایی پایان کل نمونه نیست. بنابراین تنظیم Signal جای تنظیم خروجی End را نمی‌گیرد. در مدل داده، پایان رسمی با وضعیت IsFinish در dbo.ProcessCreation منعکس می‌شود؛ شرح و خروجی آخرین Node به‌تنهایی جای بررسی وضعیت نمونه را نمی‌گیرد.
رفتار اجرا، دسترسی و دادهٔ Signal
Signal یک ارتباط چندبه‌چند است. یک Throw می‌تواند هم‌زمان برای Start Catchهای چند Process نمونه جدید بسازد و چند ProcessCreation را که از قبل در Intermediate Catch منتظرند ادامه دهد. چند Throw در یک Process یا Processهای مختلف نیز می‌توانند از یک کلید مشترک استفاده کنند.
دریافت سیگنال دو شرط دارد: کلید فرستنده و گیرنده یکسان باشد و دسترسی Lane گیرنده شامل دسترسی فرستنده باشد. جهت این رابطه مهم است: دسترسی Lane حاوی Throw باید زیرمجموعه دسترسی Laneهای Catch باشد. برای نمونه، کاربری که User Task پیش از Throw را ادامه داده باید در Lane گیرنده نیز دسترسی داشته باشد.
در Throw، کلید را تایپ می‌کنید؛ در Catch، آن را از فهرست کلیدهای تعریف‌شده برمی‌گزینید. اگر کلید در فهرست دیده نمی‌شود، وجود Throw متناظر و ذخیره‌شدن Processی را بررسی کنید که آن Throw را تعریف کرده است. کلیدِ Throw در Process ذخیره‌نشده هنوز برای انتخاب گیرنده آماده نیست.
گیرنده می‌تواند در همان ProcessCreation جاری باشد. برای مثال، یک شاخه موازی به Intermediate Catch رسیده و منتظر است؛ اجرای Throw در شاخه دیگر می‌تواند همان انتظار را آزاد کند. Intermediate Catch در این حالت نیز Creation تازه نمی‌سازد.
ورودی‌های سیگنال براساس نام Variable مقصد نگاشت می‌شوند. یک نام ممکن است فقط در بعضی گیرندگان وجود داشته باشد؛ مقدار برای مقصدی اعمال می‌شود که Variable هم‌نام را دارد. برای شناسایی فرستنده می‌توانید، برای مثال، ProcessCreationID جاری را به Variable مقصد با نام SourceCreationID بدهید. Start Catch این مقدار را هنگام ساخت نمونه می‌گیرد و Intermediate Catch آن را در نمونه موجود، پیش از ادامه مسیر، دریافت می‌کند.
اجرای Throw به‌صورت Async و Fire-and-forget است: فرستنده منتظر پایان هیچ‌یک از Processهای دریافت‌کننده نمی‌ماند. Intermediate Throw پس از انتشار، مسیر خودش را ادامه می‌دهد؛ Signal End Event پس از انتشار، رفتار پایان Process را اجرا می‌کند. این تفاوت را هنگام انتخاب Event و مقایسه آن با Call Activity در نظر بگیرید.
↑ بازگشت به فهرست آموزشEnd Event؛ پایان مسیر و خروجی نهایی
End را به آخرین گام مسیر وصل کنید. در فرآیند دارای تصمیم، ممکن است مسیرهای تأیید و عدم تأیید پایان‌های متفاوتی داشته باشند. عنوان پایان را متناسب با نتیجه بنویسید تا تشخیص آن در نمودار آسان باشد.
اگر چند شاخه هم‌زمان دارید و پایان باید بعد از انجام همه کارها باشد، پیش از End جمع‌کننده مناسب قرار دهید. صرف رساندن یکی از شاخه‌ها به End، طراحی هماهنگی شاخه‌های دیگر را انجام نمی‌دهد. انتخاب و تنظیم جمع‌کننده در Gatewayها توضیح داده شده است.
↑ بازگشت به فهرست آموزشتعریف متغیرهای خروجی در End
وقتی فرآیند باید نتیجه‌ای را به فراخواننده برگرداند، خروجی را در End تعریف کنید. این خروجی، قرارداد نتیجه فرآیند است؛ برای نمونه وضعیت پذیرفته‌شدن درخواست یا عنوانی که هنگام اجرای فرآیند ساخته شده است.
- End را انتخاب کنید و مدیریت متغیرهای خروجی را باز کنید.
- افزودن/ویرایش متغیر را انتخاب کنید.
- نام کلید خروجی را تعیین کنید؛ فراخواننده همین نام را برای دریافت نتیجه به‌کار می‌برد.
- نوع مقداردهی و مقدار خروجی را مشخص کنید. خروجی می‌تواند یک مقدار ثابت یا مقدار متغیر فرآیند باشد.
- ردیف‌های لازم را اضافه و تغییرات را ذخیره کنید.
- برای هر مسیری که پایان و نتیجه متفاوت دارد، تنظیم End همان مسیر را بررسی کنید.
در Call Activity، دو تنظیم جدا لازم است: End فرآیند مقصد کلیدها و مقادیر خروجی را تعیین می‌کند؛ Call Activity در فرآیند فراخواننده مشخص می‌کند هر کلید در کدام متغیر خودش ذخیره شود. تعریف یکی جای دیگری را نمی‌گیرد. چرخه کامل ورودی، انتظار برای فرآیند مقصد و دریافت نتیجه در Taskها و Activityها آمده است.
↑ بازگشت به فهرست آموزشEnd Event و قرارداد Variableهای خروجی
برای دریافت نتیجه از Process، End Event مسیر نهایی را انتخاب و «مدیریت متغیرهای خروجی» را باز کنید. نام کلید خروجی قرارداد دریافت نتیجه است؛ برای یکپارچگی یا Call Activity، نام کلید و روش نگاشت آن باید در هر دو طرف یکسان باشد.
- دکمه «افزودن/ویرایش متغیر» را انتخاب کنید.
- نام کلید خروجی را تعیین کنید.
- نوع ورودی را از مقدار ثابت، بدون مقدار، متغیر یا تابع انتخاب کنید.
- مقدار یا مسیر داده متناظر را کامل کنید.
- برای کلیدهای دیگر همین مراحل را تکرار و «ذخیره و بستن» را اجرا کنید.
جدول امکان جستجوی کل جدول، فیلتر ستون‌ها و صفحه‌بندی دارد. ستون‌های «نام کلید»، «نوع ورودی» و «مقدار ورودی» برای بازبینی قرارداد خروجی کنار هم نمایش داده می‌شوند. تابعی مانند Concat می‌تواند مقدار خروجی را از چند جزء بسازد؛ خواندن Variable نیز می‌تواند داده ServiceData را به خروجی متصل کند.
در Process دارای چند مسیر پایان، خروجی همان End که مسیر به آن رسیده است اهمیت دارد. در Call Activity، Process فرزند باید به پایان برسد تا Process پدر از فعالیت فراخوانی عبور کند؛ نگاشت خروجی‌های فرزند در تنظیم Call Activity پدر تکمیل می‌شود.
↑ بازگشت به فهرست آموزشیک قرارداد خروجی روشن در End
متغیرهای خروجی End، نتیجه‌ای را تعریف می‌کنند که مصرف‌کنندهٔ فرآیند دریافت می‌کند. مدل فرآیند می‌تواند چند End داشته باشد، اما اگر شاخه‌ها خروجی‌هایی با نام یا شکل متفاوت بسازند، فراخواننده دیگر یک قرارداد ثابت ندارد. برای فرآیندی که از سرویس یا کد backend شروع و همان‌جا کامل می‌شود، شاخه‌های پایانی را با Sequence Flow به یک End مشترک برسانید و خروجی را همان‌جا تعریف کنید.
این طراحی در کاربرد Process به‌عنوان ESB الزام دارد؛ فرآیند ESB را با یک End واحد تنظیم کنید. در سایر مدل‌ها، یک End توصیه‌ای برای یکنواختی نتیجه و نگهداری ساده‌تر است و نباید آن را ممنوعیت عمومی چند End در همهٔ فرآیندها تلقی کرد.
چهار روش ساخت Property خروجی
در «مدیریت متغیرهای خروجی»، برای هر Property یک نام کلید و روش مقداردهی تعیین کنید. نام کلید، نام نتیجه‌ای است که مصرف‌کننده می‌بیند؛ لازم نیست با نام Variable داخلی یکی باشد. مقدار می‌تواند ثابت، بدون مقدار، انتخاب‌شده از Variable یا حاصل تابع باشد.
| کلید نمونه | روش مقداردهی | مقدار نمایش‌داده‌شده |
|---|---|---|
OutPutOfThisProcessNumber_1 | مقدار ثابت | some constant value |
OutPutOfThisProcessNumber_2 | بدون مقدار | none در جدول تنظیمات |
OutPutOfThisProcessNumber_3 | متغیر | @@perm:ServiceData |
OutPutOfThisProcessNumber_4 | تابع | ترکیب پیشوند Bearer با @perm:ServiceData[0]['Token'] توسط Concat |
این مقادیر مثال‌اند. برای تنظیم واقعی، نام Variable و مسیر Property را با دادهٔ موجود در اجرای خود تطبیق دهید. عبارت «بدون مقدار» را با رشتهٔ دلخواه "none" در کد فراخواننده یکی نگیرید؛ جدول تنظیمات نمایش رابط است و شکل نهایی پاسخ به قرارداد API و سطح خروجی انتخاب‌شده نیز بستگی دارد.
اگر نتیجه ساختاریافته لازم دارید، کل دادهٔ Variable را انتخاب کنید؛ اگر فقط یک Token یا شناسه لازم است، مسیر همان Property را بخوانید. خروجی پایان فرآیند می‌تواند در دکمهٔ Form یا Custom JS مصرف و در Field یا SubForm مقصد قرار گیرد. تنظیم خروجی به‌تنهایی این داده را در Form مقصد نمی‌نویسد؛ نگاشت مصرف‌کننده باید جداگانه تعریف شود.
↑ بازگشت به فهرست آموزشError Boundary؛ هدایت خطای فعالیت
Error Boundary برای طراحی واکنش به خطای فعالیت میزبان به‌کار می‌رود. برای نمونه، اگر ServiceTask یا ScriptTask در اجرا خطا داد، به جای ادامه عادی، اطلاعات خطا در متغیر ذخیره شود و یک کار رسیدگی به مسئول مربوط برسد.
این رویداد روی مرز فعالیت قرار می‌گیرد. خطای فعالیت میزبان محرک آن است؛ برای شروع مسیر مرزی لازم نیست یک Checkbox یا شرط Gateway را فعال کنید.
↑ بازگشت به فهرست آموزشمیزبانهای مجاز Error Boundary
Error Boundary روی User Task به کار نمی‌رود؛ برای رسیدگی به استثنای فعالیت‌های خودکار، مانند Service Task، Script Task، Business Rule Task و Call Activity، کاربرد دارد.
↑ بازگشت به فهرست آموزشتمایز خطای Form با خطای موتور Process
در سناریوی User Task، Timer و Message برای پایان مهلت یا ادامه از بیرون مطرح‌اند. خطاهای کنترل یا ثبت Form را با خطاهای موتور Process که به Error Boundary مربوط‌اند یکسان نگیرید.
↑ بازگشت به فهرست آموزشتنظیم مسیر خطا
- Error Boundary را روی مرز فعالیتی که خطای آن باید رسیدگی شود قرار دهید.
- از رویداد یک مسیر خروجی به گام رسیدگی رسم کنید؛ مانند UserTask نمایش و بررسی خطا.
- متغیری برای نگهداری اطلاعات خطا بسازید.
- در تنظیمات Error Boundary، همان متغیر را به‌عنوان محل ذخیره خروجی انتخاب کنید.
- در صورت نیاز شرح ارجاع سفارشی بنویسید تا دریافت‌کننده علت ارجاع را بداند.
- فرم و دریافت‌کننده گام رسیدگی را تکمیل کنید.
- مسیر عادی فعالیت را نیز کامل نگه دارید تا در اجرای موفق ادامه عادی انجام شود.
Error Boundary؛ ذخیره اطلاعات خطا و شرح ارجاع
Error Boundary را به فعالیتی متصل کنید که خطای آن باید به مسیر رسیدگی منتقل شود. در فیلد «ذخیره خطا در...» Variable مقصد خطا را انتخاب کنید. در صورت نیاز «استفاده از شرح ارجاع سفارشی» را فعال کنید و پس از تنظیم، «ذخیره تنظیمات» را بزنید.
متغیر خطا باید همان Variableای باشد که گام رسیدگی از آن می‌خواند. اطلاعات خطا می‌تواند شامل پیام، نوع و محل وقوع باشد؛ برای نمایش در Form، منبع ServiceData و مسیر موردنیاز را تعیین کنید. خروجی خالی مجاز در Service Task یا Script Task را با استثنای اجرا یکسان ندانید: وقتی خروجی Null مجاز است، نبودن داده به‌تنهایی شرط ورود به مسیر خطا نیست.
↑ بازگشت به فهرست آموزشنگهداری دادهٔ استثنا برای رسیدگی بعدی
نیازمند تأیید فنی: پشتیبانی اجرایی Error Boundary روی Receive Task باید تأیید شود؛ آن را از فهرست میزبان‌های قطعی Service Task، Script Task، Business Rule Task و Call Activity نتیجه نگیرید.
Error Boundary به استثنای فعالیت میزبان واکنش نشان می‌دهد و مانند مسیر Catch برای آن عمل می‌کند. در بخش «ذخیره خطا در...» Variable مقصد را انتخاب کنید تا اطلاعات خطا در گام رسیدگی مصرف شود. انتخاب Variable، اتصال مسیر خروجی مرزی را بی‌نیاز نمی‌کند؛ فرم رسیدگی یا سرویس ثبت گزارش باید در همان مسیر قرار بگیرد.
«استفاده از شرح ارجاع سفارشی» برای متن شرح مسیر است و از دادهٔ ساختاریافتهٔ خطا مستقل است. عنوان یا شرحی با واژهٔ «خطا» به‌تنهایی استثنا ایجاد نمی‌کند؛ نتیجهٔ رد کسب‌وکار را با وقوع Exception فنی یکی نگیرید.
استفاده از اطلاعات خطا
خروجی خطا یک متن ساده منفرد نیست؛ اطلاعاتی مانند پیام خطا، نوع خطا و محل وقوع آن در ساختار داده ذخیره می‌شود. برای نمایش آن در فرم رسیدگی، ورودی کنترل را از متغیر خطا و داده سرویس تنظیم کنید. با انتخاب همه داده‌ها می‌توانید مجموعه اطلاعات خطا را برای بررسی دریافت کنید؛ برای نمایش محدودتر، عضو موردنیاز را از همان ساختار انتخاب کنید.
نام متغیر خطا را با متغیر خروجی موفق سرویس اشتباه نگیرید. اگر فرم رسیدگی خالی است، نخست بررسی کنید متغیر انتخاب‌شده در Error Boundary همان متغیری باشد که ورودی فرم از آن می‌خواند و مسیر عضو داده درست تنظیم شده باشد.
↑ بازگشت به فهرست آموزشنمایش دادهٔ خطا در مسیر رسیدگی
در یک مسیر رسیدگی به خطا، دادهٔ خطا را می‌توان در خروجی تعیین‌شده و سپس در فرم مرحلهٔ بعد بررسی کرد. نمونهٔ نمایش‌شده بخشی از Exception@@ را با ExceptionType و ExceptionMessage در فیلد متنی دارد. متن پیام «داده‌های خروجی سرویس نامعتبر است» و نوع InvalidOperationException دیده می‌شود. مقدار فیلد به‌صورت افقی بریده است؛ این نما قرارداد کامل JSON خطا را مشخص نمی‌کند.
تفاوت خروجی خالی مجاز با خطای اجرا
تنظیم مجاز بودن خروجی Null در ServiceTask بر تفسیر نتیجه خالی اثر دارد. اگر خروجی خالی سرویس را مجاز کرده باشید، خالی‌بودن داده به‌تنهایی باعث ورود به Error Boundary نمی‌شود. اما وقوع استثنا در اجرای سرویس یا اسکریپت همچنان خطا است و می‌تواند مسیر مرزی را فعال کند.
گزینه مجاز بودن خروجی Null در تنظیمات ScriptTask نیز وجود دارد. تنظیم و مصرف خروجی اسکریپت را همراه جزئیات Taskها و Activityها بررسی کنید.
ابتدا تعیین کنید نبودن داده در فرآیند شما نتیجه معتبر است یا وضعیت خطا. سپس تنظیم خروجی خالی و مسیر Error Boundary را هماهنگ کنید. انتظار برای ورود به مسیر خطا، در حالی که همان وضعیت را خروجی خالی مجاز اعلام کرده‌اید، طراحی متناقضی ایجاد می‌کند. جزئیات تنظیم خروجی Task در Taskها و Activityها آمده است.
برای مشاهده سابقه ارجاع و مسیر ادامه، کارتابل سوابق را بررسی کنید. فرم رسیدگی به خطا نیز باید اطلاعات ثبت‌شده در متغیر Error Boundary را در اختیار مسئول مربوط قرار دهد.
↑ بازگشت به فهرست آموزشNotification Event؛ اعلان و اطلاع‌رسانی
Notification Intermediate Throw Event در زمان رسیدن اجرای فرآیند، اعلان را با پیکربندی همین Node به ماژول اطلاع‌رسانی می‌سپارد. Node را انتخاب کنید و از دکمهٔ تنظیمات اعلان‌ها و اطلاع‌رسانی وارد صفحهٔ تنظیمات شوید. عنوان و توضیحات روی بوم، مشخصات خود Event هستند؛ موضوع و بدنهٔ اعلان در پنجرهٔ ارسال تنظیم می‌شوند.
این صفحه دو حالت ساده و پیشرفته دارد. منطق عمومی آن با صفحهٔ ارسال اعلان در «پیکربندی سیستم» متناظر است و در Process می‌توان مقدارها را از Variableهای اجرا تأمین کرد.
| نیاز | حالت مناسب |
|---|---|
| کاربرها و نقش‌های معین؛ ارسال با Portal یا OS | ساده؛ انتخاب گیرندگان از دو فهرست |
| گیرنده از Variable، حتی برای Portal یا OS | پیشرفته؛ مقداردهی پارامتر پویای گیرنده |
| رویهٔ اطلاع‌رسانی سفارشی یا ترکیب چند رویه | پیشرفته؛ افزودن و تنظیم کارت‌های ارسال |
حالت ساده؛ کاربرها و نقش‌های گیرنده
در تب اول کاربرهای مقصد را علامت بزنید. فهرست، جست‌وجو در ستون‌ها، صفحه‌بندی و انتخاب ردیف دارد. در تب دوم نقش‌های مقصد را انتخاب کنید. انتخاب یک کاربر یا یک نقش محدودیت تعداد نیست: چند کاربر و چند نقش را می‌توان هم‌زمان انتخاب کرد تا اعلان برای مجموعهٔ گیرندگان تعیین‌شده ارسال شود.
حالت ساده برای دو رویهٔ سیستمی Portal و OS و گیرندگان قابل انتخاب از این لیست‌ها مناسب است. اگر فهرست UserID یا RoleID باید هنگام اجرا از Variable خوانده شود، به حالت پیشرفته بروید.
محتوای اعلان؛ موضوع، URL، بدنه و روش اطلاع‌رسانی
پس از تعیین گیرندگان، تب محتوای اطلاع‌رسانی را تکمیل کنید. موضوع، آدرس URL و بدنه، دادهٔ اعلان را می‌سازند. کنترل مقداردهی امکان مقدار خالی، ثابت، Variable با حالت ساده/پیشرفته/همهٔ داده‌ها و تابع را ارائه می‌کند؛ خروجی انتخاب‌شده باید با مصرف همان فیلد سازگار باشد. در نمونه، موضوع از فیلد فرمِ Variable به نام perm خوانده شده است:
@@perm:FormData['NotificationMessageTextField']پیش‌نمایش مسیر را بررسی کنید. نام فیلد باید با دادهٔ واقعی Variable یکسان باشد. در قسمت روش اطلاع‌رسانی، اعلان پورتال و اعلان سیستم‌عامل را مطابق نیاز انتخاب کنید؛ نمونهٔ تصویر هر دو را فعال کرده است.
مقدار ترکیبی با تابع
برای ساختن مقدار از چند جزء، نوع مقداردهی را «تابع» قرار دهید. نمونهٔ Concat متن ثابت و مقدار یک Variable را به هم متصل می‌کند. آرگومان‌ها را به ترتیب مورد نظر تنظیم و پیش‌نمایش را کنترل کنید.
در این تصویر از ورودی URL برای نمایش کار تابع استفاده شده است. در تنظیم واقعی اعلان، حاصل نهایی این ورودی باید آدرس مناسب مقصد باشد؛ هر متن ترکیبی، URL قابل استفاده نیست.
↑ بازگشت به فهرست آموزشآیکن، مرور نهایی و زمان ارسال
آیکن اعلان را انتخاب کنید؛ فایل در Archive نگهداری می‌شود و نشانی آن در اعلان به کار می‌رود. در تب آخر، کاربران و نقش‌ها، موضوع، URL، بدنه، رویه‌های انتخاب‌شده و آیکن را مرور کنید و ذخیره تنظیمات اعلان را بزنید. سپس ذخیرهٔ Node و فرآیند را مطابق روال استودیو تکمیل کنید.
ذخیرهٔ این پنجره، تنظیمات را برای اجرای Event آماده می‌کند. ارسال اعلان هنگام رسیدن نمونهٔ فرآیند به این Event انجام می‌شود؛ عنوان تب «تأیید و ارسال» را به معنی ارسال مستقل و فوری در زمان طراحی تفسیر نکنید.
↑ بازگشت به فهرست آموزشحالت پیشرفته؛ گیرندهٔ پویا و رویهٔ سفارشی
در حالت پیشرفته، موضوع، URL و بدنه همچنان همان روش‌های مقداردهی را دارند. سپس یک پیکربندی ارسال اضافه و رویهٔ مقصد را انتخاب کنید. پنل فقط پارامترهای پویای تعریف‌شده در همان رویه را برای مقداردهی این اجرا نمایش می‌دهد. پارامترهای ثابت و دیگر تنظیمات تعریف رویه، ورودی پویای دوباره در این پنل نیستند.
برای مثال تصویر، موضوع s1 و بدنه متن ثابت‌اند؛ URL از نخستین سطر ServiceData گرفته می‌شود:
@@perm:ServiceData[0]['UrlAddressTextField']نام Variable، نام فیلد و Index را با دادهٔ خروجی گام‌های قبلی تطبیق دهید. مقدارهای ثابتِ تصویر، الزام محصول یا مقدار عمومی همهٔ فرآیندها نیستند.
↑ بازگشت به فهرست آموزشپارامترهای Portal در نمونهٔ پیشرفته
کارت Portal در تصویر چهار پارامتر پویا دارد. نام‌های فنی زیر به همین نمونه مربوط‌اند؛ برای رویهٔ دیگر، فهرست پارامترهای تعریف‌شدهٔ خود آن رویه را مبنا قرار دهید.
| پارامتر | مقداردهی و کاربرد نمونه |
|---|---|
RecipientUserId | شناسه‌های کاربران مقصد به‌صورت رشته با جداکنندهٔ کاما؛ از فیلد متغیر زیر خوانده می‌شود. |
Icon | نشانی فایل آیکن در Archive؛ مانند /Archive/GetFile?id=<archive-file-id> با شناسهٔ فایل معتبر همان محیط. |
RecipientRoleId | شناسه‌های نقش‌های مقصد به‌صورت رشته با جداکنندهٔ کاما؛ مشابه ورودی کاربران. |
NotificationGroupId | در آموزش می‌تواند خالی باشد یا شناسهٔ گروه تعریف‌شده در ماژول اطلاع‌رسانی را بگیرد. عدد 5 در تصویر فقط یک نمونه است. |
RecipientUserId:
@@perm:ServiceData[0]['UsersIdsCommaBasedConcatinatedField']
RecipientRoleId:
@@perm:ServiceData[0]['RolesIdsCommaBasedConcatinatedField']نام‌های UsersIdsCommaBasedConcatinatedField و RolesIdsCommaBasedConcatinatedField نام فیلدهای نمونه‌اند؛ املای فنی فیلد موجود در خروجی خودتان را دقیق استفاده کنید. در این مثال محتوا یک رشتهٔ شناسه‌هاست، نه نام نمایشی کاربران یا عنوان نقش‌ها. شناسهٔ فایل آیکن و شناسهٔ گروه را نیز از همان محیط مقصد بردارید.
چند رویه در یک Notification Event
در سربرگ هر کارت، نماد سطل زباله برای حذف پیکربندی و پیکان باز و بسته‌کردن جزئیات دیده می‌شود. این کنترل‌ها به همان کارت مربوط‌اند؛ علامت بستنِ بالای پنجره، کنترل جداگانهٔ صفحهٔ تنظیمات است.
با افزودن پیکربندی جدید می‌توانید در یک Event چند کارت ارسال داشته باشید؛ برای مثال یک کارت Portal، یک کارت OS و یک کارت برای رویهٔ سفارشی. هر کارت رویه و پارامترهای پویای خودش را دارد. پیکربندی را به یک رویه محدود فرض نکنید و مقدارهای گیرنده و سایر ورودی‌های هر کارت را جدا تکمیل کنید.
پیش از ذخیره، هر کارت را مرور کنید: رویهٔ صحیح انتخاب شده باشد، پارامترهای پویا با نوع دادهٔ مورد انتظار سازگار باشند، گیرندگان از مسیر درست خوانده شوند و مقدار URL و Icon به مقصد معتبر اشاره کند. تعریف و مدیریت داخلی رویه‌ها و گروه‌های اعلان در ماژول اطلاع‌رسانی انجام می‌شود؛ این Event محل مصرف آن‌ها در اجرای Process است.
↑ بازگشت به فهرست آموزشNotification Event؛ Wizard ساده و تنظیمات پیشرفته اعلان
Notification Event برای تنظیم اعلان و اطلاع‌رسانی در مسیر Process به‌کار می‌رود. از پنل نماد، «تنظیمات اعلان‌ها و اطلاع‌رسانی» را باز کنید. این پنجره دو شیوه «ساده» و «پیشرفته» دارد.
مشاهدهٔ تصویر همین تنظیمات — ورود به تنظیمات اعلان‌ها و اطلاع‌رسانی از Notification Event
گام اول: انتخاب کاربران
در حالت ساده، Wizard چهار مرحله دارد: انتخاب کاربران، انتخاب نقش‌ها، محتوای اطلاع‌رسانی و تأیید و ارسال. وضعیت «فعال»، «در انتظار» و «طی‌شده» روند تکمیل را نشان می‌دهد. با Checkbox ردیف‌ها کاربران موردنظر را انتخاب کنید. جدول کد کاربری، نام کاربری و نام را نمایش می‌دهد و فیلتر، مرتب‌سازی، انتخاب کلی و صفحه‌بندی دارد. اندازه صفحه 5، 10، 20 یا 50 ردیف قابل انتخاب است.
مشاهدهٔ تصویر همین تنظیمات — گام اول Wizard اعلان: انتخاب کاربران
گام دوم: انتخاب نقش‌ها
نقش‌های دریافت‌کننده را در جدول کد نقش و عنوان نقش انتخاب کنید. کنترل‌های پیمایش پایین Wizard برای بازگشت به مرحله قبل یا رفتن به مرحله بعد در دسترس‌اند؛ هنگام قرارداشتن در اولین مرحله، بازگشت به مرحله قبلی غیرفعال است.
مشاهدهٔ تصویر همین تنظیمات — گام دوم Wizard اعلان: انتخاب نقش‌ها
گام سوم: محتوا، آیکون و روش اطلاع‌رسانی
| گزینه | شرح |
|---|---|
| موضوع | موضوع اعلان؛ با متن ثابت یا مقداردهی پویا. |
| آدرس URL | مقصد مرتبط با اعلان؛ قابل مقداردهی پویا. |
| بدنه | متن غنی اعلان با ابزارهای قالب‌بندی و درج محتوا. |
| مقداردهی پویا | روش خالی، Variable، مقدار ثابت یا تابع؛ در روش Variable، حالت ساده/پیشرفته، منبع داده، همه داده‌ها یا مسیر عضو قابل تنظیم است. |
| آیکون اعلان | انتخاب تصویر، نمایش پیش‌نمایش و امکان حذف تصویر انتخاب‌شده. |
| Portal | نمایش در پنل کاربری. |
| OS | اعلان سیستم‌عامل. |
برای خواندن فیلدی از داده FormData، در مقداردهی پویا Variable را انتخاب، حالت پیشرفته و منبع داده فرم را تعیین کنید و مسیر عضو را بنویسید؛ برای مثال ['NotificationMessageTextField']. پیش‌نمایش مقدار نهایی به بازبینی ترکیب کمک می‌کند؛ مقدار واقعی Variable در زمان اجرا خوانده می‌شود. دکمه تأیید سبز و لغو آبی داخل ویرایشگر، انتخاب همین مقدار را نهایی یا کنار می‌گذارند.
مشاهدهٔ تصویر همین تنظیمات — مقداردهی پویا به محتوای اعلان از داده FormData
برای موضوع، URL و بدنه می‌توان منابع متفاوت انتخاب کرد. مثلاً موضوع از Variable خوانده شود و بدنه متن ثابت داشته باشد. تابع Concat برای ترکیب اجزای مقدار در دسترس است؛ هنگام استفاده در URL، نتیجه باید با مقصد موردنظر هماهنگ باشد.
ویرایشگر بدنه ابزارهای تصویر و پیوند، قلم و رنگ، فهرست، تراز، زیرخط، خط‌خورده، مورب، ضخیم، سبک و اندازه متن، undo/redo، نقل‌قول، کد و پاک‌کردن قالب را فراهم می‌کند. انتخاب Portal و OS با Checkboxهای مستقل انجام می‌شود و می‌توان هر دو را فعال کرد.
مشاهدهٔ تصویر همین تنظیمات — موضوع و URL پویا، بدنه غنی و کانالهای Portal و OS
گام چهارم: بازبینی و ذخیره
در مرحله نهایی، کاربران و نقش‌های انتخاب‌شده، موضوع، URL، بدنه، آیکون و روش اطلاع‌رسانی را بررسی کنید. «ذخیره تنظیمات اعلان» تنظیمات Event را ثبت می‌کند. عنوان مرحله «تأیید و ارسال» است؛ عمل ثبت تنظیمات طراحی را با اجرای اعلان هنگام عبور Process از Event اشتباه نگیرید.
مشاهدهٔ تصویر همین تنظیمات — بازبینی دریافت‌کنندگان و محتوای اعلان پیش از ذخیره تنظیمات
حالت پیشرفته
در حالت پیشرفته، موضوع، URL و بدنه همچنان قابلیت مقداردهی پویا دارند. در «تنظیمات ارسال اعلان»، برای هر «پیکربندی ارسال» رویه اطلاع‌رسانی را انتخاب و پارامترهای آن را مقداردهی کنید. هر پیکربندی را می‌توان باز/بسته یا با آیکون سطل حذف کرد؛ «افزودن پیکربندی جدید» ردیف پیکربندی دیگری اضافه می‌کند.
| کلید در پیکربندی Portal | مقدار موردنیاز |
|---|---|
| RecipientUserId | شناسه دریافت‌کننده کاربری؛ قابل اتصال به مقدار پویا. |
| RecipientRoleId | شناسه دریافت‌کننده نقشی؛ قابل اتصال به مقدار پویا. |
| Icon | آدرس یا مقدار تصویر اعلان طبق رویه منتخب. |
| NotificationGroupId | شناسه گروه اعلان. |
برای داده دریافت‌کنندگان می‌توان از فیلد Variable حاوی شناسه‌ها استفاده کرد. پیکربندی هر رویه را با ورودی‌های همان رویه تکمیل کنید؛ کلیدهای جدول بالا متعلق به پیکربندی Portal هستند. در پایان «ذخیره تنظیمات اعلان» را انتخاب کنید.
مشاهدهٔ تصویر همین تنظیمات — پیکربندی پیشرفته اعلان و پارامترهای کانال ارسال
↑ بازگشت به فهرست آموزشGraph Mobile Start؛ آغاز با ارسال دادهٔ همراه
Graph Mobile Start دریافت داده یک کار همراه نامحدود را به آغاز فرآیند وصل می‌کند. برای نمونه، کاربر همراه فرم مأموریت را تکمیل می‌کند و پس از ارسال رکورد به سرور، فرآیند بررسی همان مأموریت آغاز می‌شود.
↑ بازگشت به فهرست آموزشپیشنیاز و انتخاب کار همراه
پیش از تنظیم رویداد، کار همراه نامحدود موردنظر را در مدیریت کار آماده کنید. فرم، دریافت‌کنندگان و تنظیمات لازم آن باید آماده باشند تا کاربران بتوانند رکورد را در همراه تکمیل و ارسال کنند. فهرست این رویداد برای انتخاب کار همراه نامحدود است؛ یک کار محدود را به جای آن در نظر نگیرید.
- Start را به نوع Graph Mobile Start تغییر دهید.
- در پنل رویداد، لیست وظایف همراه نامحدود را باز کنید.
- کار همراهی را که داده آن باید فرآیند را آغاز کند انتخاب کنید.
- Start را به گام دریافت و پردازش داده متصل کنید؛ برای نمونه یک ServiceTask.
- ادامه مسیر، کارهای انسانی و پایان را تنظیم کنید.
- فرآیند را ذخیره و نسخه موردنظر را فعال کنید.
Graph Mobile Start؛ از Task نامحدود تا ارسال به سرور
Graph Mobile Start یک Node اختصاصی GraphBPMS است که بر پایهٔ Start Event، ماژول برداشت اطلاعات میدانی را به Process متصل می‌کند. داده ارسالی یک وظیفه همراه نامحدود از این ورودی آغاز Process را ایجاد می‌کند. پیش از تنظیم رویداد، Task مربوط را از مسیر «برداشت اطلاعات میدانی ← مدیریت کار» آماده کنید؛ نوع وظیفه باید «نامحدود» باشد.
آماده‌سازی Task همراه
در پنجره «ایجاد/ویرایش کار»، تب «اطلاعات کار» شامل عنوان، انتخاب Form، «تنظیمات فیلدهای فرم»، توضیحات، از/تا تاریخ، از/تا ساعت، نوع وظیفه، حداقل و حداکثر کار است. Checkboxهای «فعال»، «ثبت آنلاین»، «محدوده اجرایی»، «قابلیت درج به صورت متوالی» و «ذخیره موقت» رفتار Task همراه را تنظیم می‌کنند. این گزینه‌ها تنظیمات Task همراه‌اند و نباید آن‌ها را Property خود Event معرفی کرد.
در تب «مدیریت کاربران»، نوع «کاربر» یا «نقش» را انتخاب، مورد مجاز را از Dropdown برگزینید و «افزودن» را بزنید. جدول، نام و نوع دسترسی را نشان می‌دهد. پس از ثبت دریافت‌کنندگان، «ذخیره» را انتخاب کنید.
انتخاب Task در Event و تنظیم Lane
در پنل Graph Mobile Start، «لیست وظایف همراه نامحدود» را باز کنید، Task موردنظر را انتخاب و «ذخیره تغییرات» را بزنید. سامانه تنظیمات Lane را براساس تنظیمات Task انتخاب‌شده اعمال و پیام موفقیت این تطبیق را نمایش می‌دهد.
اجرای Task در PWA
کاربر مجاز Task نامحدود را در فهرست وظایف PWA با نماد بی‌نهایت می‌بیند. «دریافت وظایف» فهرست را دریافت می‌کند. با انتخاب Task، پنجره جزئیات شامل بازه تاریخ، ساعت مجاز روزانه، فرصت باقیمانده، توضیحات و دو Action «لیست داده‌ها» و «جدید» باز می‌شود.
«جدید» Form مرتبط با Task را باز می‌کند. فیلدهای الزامی و Tabهای فرم را تکمیل و «ثبت» را انتخاب کنید. شکل و فیلدهای این Form تابع طراحی همان فرم‌اند؛ برای نمونه یک Form ممکن است چند Tab و دکمه «بعدی» داشته باشد.
ارسال به سرور؛ نقطه شروع Process
ذخیره محلی Form به‌تنهایی Process را آغاز نمی‌کند. در لیست داده‌های Task، «ارسال به سرور» همان رکورد را اجرا کنید. کارت رکورد، کد، تاریخ ثبت، نقش و Actionهای ارسال به سرور، ویرایش و حذف را نمایش می‌دهد. «لیست داده‌ها» و «لیست داده‌های آنلاین» وضعیت داده‌های محلی و آنلاین را جدا نشان می‌دهند.
مسیر دیگر، منوی سه‌نقطه Task در صفحه وظایف است. این منو «سنجاق به اول لیست»، «ارسال به سرور» و «لیست داده‌ها» دارد. با هر عملیات ارسال به سرور، برای هر Process متصل به آن Task از طریق Graph Mobile Start یک نمونه آغاز می‌شود. تمام رکوردهای همان ارسال، چه یک رکورد و چه چند رکورد، در همان نمونه قرار می‌گیرند. داده‌های ارسالی از طریق Variable سیستمی شروع موبایلی در اختیار Process قرار می‌گیرند.
داده آغاز از Variable سیستمی «داده‌های ارسالی از طریق شروع موبایلی» با نام MobileRecordData قابل دریافت است. این داده از جنس ServiceData است و می‌تواند لیست رکوردهای ارسالی Task را در خود داشته باشد؛ آن را FormData تک‌رکوردی فرض نکنید. در گام بعدی، برای مصرف کل رکورد از همه داده‌ها و برای یک فیلد از مسیر عضو ServiceData استفاده کنید. انتخاب Event به‌تنهایی عملیات ذخیره‌سازی یا پردازش دلخواه را انجام نمی‌دهد؛ آن منطق را در گام بعدی Process تنظیم کنید.
↑ بازگشت به فهرست آموزشدر یک نمونهٔ کاربرد، مسئول جمع‌آوری کالاهای تحویل‌گرفته‌شده یا بازنگشته، طی روز رکوردهای متعددی را با گوشی ثبت می‌کند. Task نامحدود برای این ثبت‌های پی‌درپی مناسب است؛ رکوردهای ارسال‌شده به سرور وارد Process مرتبط می‌شوند.
همان مجوزهای کاربر و نقشِ Task تعیین می‌کنند کار در PWA یا APK برای چه کاربرانی نمایش داده شود.
دریافت داده ارسالی در فرآیند
داده شروع موبایلی از متغیر سیستمی داده‌های ارسالی از طریق شروع موبایلی در دسترس است. در تنظیم ورودی ServiceTask، این متغیر را انتخاب کنید و در حالت پیشرفته از ServiceData و عضو موردنظر یا همه داده‌ها استفاده کنید.
اگر سرویس باید کل رکورد همراه را پردازش کند، همه داده‌ها را بدهید. اگر تنها یک مقدار لازم است، مسیر همان فیلد را انتخاب کنید. متغیر سیستمی را با یک متغیر دستی هم‌نام جایگزین نکنید؛ داده آغاز، از ارسال همراه تأمین می‌شود.
ثبت لاگ یا ذخیره داده در جدول به رفتار سرویس بعدی وابسته است. انتخاب Graph Mobile Start به‌تنهایی به معنی اجرای هر عملیات ذخیره‌سازی دلخواه نیست؛ ServiceTask باید همان عملیات موردنیاز شما را انجام دهد.
↑ بازگشت به فهرست آموزشساختار داده شروع موبایلی
پس از ارسال Task همراه به سرور و آغاز Process، داده‌ها در Variable سیستمی @@MobileRecordData با عنوان «داده‌های ارسالی از طریق شروع موبایلی» در دسترس‌اند. با هر ارسال به سرور، برای هر Process متصل به Task یک نمونه آغاز می‌شود و تمام رکوردهای همان ارسال در همان نمونه قرار می‌گیرند. این داده از جنس ServiceData است و لیست رکوردهای ارسالی را نگه می‌دارد. آن را FormData تک‌رکوردی فرض نکنید؛ برای خواندن داده، نوع منبع و در صورت نیاز Index و مسیر عضو را متناسب با ServiceData تنظیم کنید.
زمان ایجاد نمونه و ارسال چند رکورد
ذخیره محلی فرم در همراه، به‌تنهایی نمونه فرآیند را آغاز نمی‌کند. محرک شروع، ارسال به سرور است. بنابراین پس از تکمیل فرم، ارسال موفق به سرور را بررسی کنید و سپس نمونه ایجادشده و کارتابل مقصد را ببینید.
در ارسال گروهی همراه، دادهٔ آغاز در
@@MobileRecordDataبا ساختار ServiceData و به‌صورت فهرست رکوردهای ارسالی در دسترس است. برای خواندن همهٔ رکوردها از کل ServiceData و برای عضو مشخص از Index و مسیر مناسب استفاده کنید. برای هر Process متصل، هر ارسال یک ProcessCreation ایجاد می‌کند و کل رکوردهای همان ارسال در همان نمونه می‌آیند. این رفتار با ایجاد یک نمونهٔ جدا برای هر رکورد تفاوت دارد.
شروع موبایلی برای دریافت این ارسال تنظیم می‌شود؛ آغاز آن را از فهرست شروع عادی کاربر دنبال نکنید. اگر بعد از ارسال باید یک UserTask به مسئول بررسی برسد، دسترسی Lane مقصد را مستقل از رویداد شروع مشخص کنید.
↑ بازگشت به فهرست آموزشبررسی نتیجه و رفع اشکال
پس از ذخیره مدل، برای هر محرک یک نمونه واقعی بررسی کنید. در تایمر مرزی، یک بار پیش از موعد اقدام کنید و یک بار اجازه دهید مهلت تمام شود. در Message Boundary، ادامه عادی و بیرونی را روی نمونه‌های جدا انجام دهید. در شروع موبایلی، ذخیره محلی را از ارسال به سرور جدا ببینید.
| نشانه | بررسی لازم |
|---|---|
| Timer Start نمونه ایجاد نمی‌کند | فعال‌بودن موتور، حساب اجرا، آدرس پایه، شروع تایمر همان نسخه، تقویم و موعد ثبت‌شده |
| پس از تغییر تنظیمات تایمر رفتار قبلی ادامه دارد | بارگذاری تنظیمات جدید با راه‌اندازی مجدد برنامه |
| کار بعد از تایمر در کارتابل فرد موردنظر نیست | Lane مقصد، هویت اجرای سیستمی و محاسبه گیرنده از درخواست‌کننده واقعی |
| موعد متغیری اجرا نمی‌شود | مقدار واقعی تاریخ و ساعت و مسیر عضو متغیر حاوی موعد |
| کار قبل از رسیدن به تأییدکننده باید تأخیر داشته باشد | استفاده از Timer میانی پیش از UserTask؛ Timer Boundary مهلت پس از ایجاد کار است |
| پس از اتمام مهلت به مقصد نمی‌رسد | اتصال واقعی Boundary به میزبان، خط خروجی رویداد و تنظیمات کار مقصد |
| خروجی خالی سرویس وارد Error Boundary نمی‌شود | مجاز بودن خروجی Null در ServiceTask و تفاوت آن با استثنای اجرای فعالیت |
| فرم رسیدگی به خطا خالی است | متغیر خروجی Error Boundary و مسیر خواندن ساختار داده خطا |
| فرم همراه ذخیره شده، اما نمونه‌ای ایجاد نشده | ارسال موفق به سرور و انتخاب کار همراه نامحدود صحیح |
| درخواست بیرونی نمی‌تواند کار منتظر را ادامه دهد | نمونه و گام صحیح، وضعیت انجام‌نشدن انتظار، کاربر مجاز و توکن معتبر |
| شروع سرویس موفق است، اما فرم بعدی باز نمی‌شود | انتخاب به صورت سرویس؛ برای نمایش ادامه، نحوه شروع معمولی را بررسی کنید |
| متغیر ورودی مقصد خالی است | فهرست Variables، نام دقیق متغیر و نگاشت مقدار در فراخواننده |
| خروجی نهایی فراخوانی هنوز موجود نیست | رسیدن واقعی مسیر مقصد به End و تعریف خروجی در همان End |
برای دنبالکردن تاریخچه ارجاعها و مسیر انجام‌شده، کارتابل سوابق را باز کنید؛ وصول کار بعدی را در کارتابل ورودی بررسی کنید.
↑ بازگشت به فهرست آموزش