/
/
کارتابل اختصاصی نمای اجرایی وظایف را با ستونهای غنیشده، گروهبندیهای پویا و دادههای تکمیلی کسبوکار در اختیار کاربران یا نقشهای سازمان قرار میدهد. این سند نحوه دسترسی و کاربری کارتابل در پرتال، کالبدشکافی ساختار URL با پارامترهای کوئری استرینگ، اجرای وظایف، عیبیابی و همچنین معماری سناریوهای پیشرفته Tableless را تشریح میکند.
هنگامی که کاربر روی منوی کارتابل اختصاصی کلیک میکند یا صفحه کارتابل را در مرورگر مشاهده مینماید، ساختار آدرس اینترنتی (URL) در مرورگر حاوی پارامترهای معنادار و حیاتی است.
آدرس مرورگر مطابق تصویر فوق به صورت زیر است:
https://developer.graphbpms.ir/inboxManager/InboxViewConfig?forwardId=100000017&Receiver=3اجزای این آدرس به شرح زیر عمل میکنند:
| بخش URL | نوع | نقش و عملکرد فنی |
|---|---|---|
/inboxManager/InboxViewConfig | Action Route | کنترلر و اکشن اصلی رندرکننده نمای کارتابل اختصاصی در زیرساخت نرمافزاری GraphBPMS. |
forwardId=100000017 | Query Parameter | شناسه یکتای رونوشت (Forward ID) صادرشده برای کاربر/نقش جاری. موتور سیستم با این شناسه متوجه میشود کدام تعریف کارتابل و با چه مجوزی باید لود شود. |
Receiver=3 | Dynamic Parameter | پارامتر پویا با نام کلید Receiver که طراح در بخش منبع داده کارتابل اختصاصی تعریف کرده و در زمان ارسال رونوشت به این کاربر، مقدار 3 را برای آن ثبت نموده است. |
موتور فرآیندساز با دریافت درخواست فوق:
Receiver=3 را مستقیماً از URL میخواند.Where (@ReceiverUserId Is Null) Or (LT_dayli.FK_UserId = 3)FK_UserId = 3 دارند.Id = FormsRecordID با رکوردهای کارتابل وظایف کاربر جاری Join میشوند.Receiver در آدرس URL، محتوای کارتابل بدون تغییر در کد یا تنظیمات، به صورت آنی بر اساس شناسه ارسالی فیلتر خواهد شد.کارتابل اختصاصی علاوه بر نمایش اطلاعات، یک محیط کامل برای تعامل کاربر با گردش کار است:
در گوشه سمت چپ بالای صفحه، دکمه آبیرنگ شاخص با عنوان «ادامه فرآیند» (همراه با آیکن ارسال) قرار دارد. کاربر با کلیک روی هر یک از ردیفهای جدول و فشردن این دکمه، مستقیماً وارد فرم وظیفه (User Task) مربوطه در آن گام فرآیند میشود.
FormsRecordID معتبر کار میکند. در نتیجه، فرم متصل در حالت «نمایش» (View) یا «ویرایش» (Edit) باز شده و کاربر اطلاعات را بررسی یا تکمیل مینماید. پس از ثبت و ارسال در فرم، گردش کار به گام بعدی منتقل شده و ردیف مربوطه از کارتابل جاری خارج میگردد.در بالای جدول کارتابل، ابزارهای کاربردی زیر در دسترس هستند:
در صورت بروز هرگونه مغایرت یا مشکل در کارتابلهای اختصاصی، جدول زیر به عنوان چکلیست عیبیابی توسعهدهندگان و پشتیبانان سیستم عمل میکند:
| نشانه یا خطا | علت ریشهای | اقدام اصلاحی و مسیر بررسی |
|---|---|---|
| کارتابل در منوی کاربر ظاهر نمیشود | رونوشت ارسال نشده، یا کارتابل غیرفعال است. | در صفحه مدیریت کارتابلها (PROCESS-08)، وضعیت فعال بودن کارتابل را کنترل کنید. سپس در زبانه «رونوشتهای ارسال شده» بررسی کنید که رونوشت به کاربر یا نقش وی صادر شده باشد. |
| ستونهای منبع داده خالی (Null) هستند | عدم انطباق کلید الحاق با FormsRecordID. | در استودیو، فیلد انتخابشده در «فیلد کلید ارتباطی منبع داده» را بررسی کنید. این فیلد باید دقیقاً برابر با شناسه رکورد فرم (Identity Key جدول فرم) باشد. همچنین مطمئن شوید نوع داده کلیدها یکسان است. |
| وظایف جدید با فرم در کارتابل ظاهر نمیشوند | فرم در User Task از نوع «افزودن» (Add) است. | کارتابل اختصاصی از User Task با مد Add پشتیبانی نمیکند؛ زیرا شناسه فرم هنوز ساخته نشده است. تسک ورودی کارتابل باید از نوع View یا Edit باشد. |
| دادههای منبع داده بر اساس کاربر فیلتر نمیشوند | عدم تنظیم صحیح پارامتر کوئری استرینگ. | بررسی کنید که در منبع داده کوئری شرطی به درستی نوشته شده باشد. سپس نام پارامتر Query String در استودیو و مقدار اختصاصیافته به آن در زمان ارسال رونوشت (Forward) را با یکدیگر تطبیق دهید. |
| خطای دسترسی در زمان باز کردن فرم | محدودیت دسترسیهای Lane در فرآیند پایه. | کاربر باید در فرآیند پایه BPMN به Lane مربوط به آن گام دسترسی سازمانی داشته باشد. دسترسی کارتابل اختصاصی جایگزین مجوزهای گردش کار فرآیند نمیشود. |
علاوه بر کارتابلهای اختصاصی استاندارد مبتنی بر FormsRecordID، در برخی سازمانها نیاز به طراحی کارتابلهای کاملاً سفارشی مبتنی بر فرمهای بدون جدول (Tableless) وجود دارد. در این معماری، ادامه فرآیند نه از طریق User Task مستقیم، بلکه از طریق Receive Task یا Message Intermediate Boundary Event هدایت میشود. این بخش جهت پوشش کامل این معماری پیشرفته نگهداری شده است.
سناریوی جدول درخواستهای سفارشی از یک Provider با نام نمونهٔ Add received request استفاده میکند. جدول سفارشی AllReceivedRequests ستونهای ProcessStepId، ProcessCreationId، RequestTitle، RequestDescription و Accepted دارد و خروجی اعلامشده reqid از نوع Int32 است. این سناریو مبتنی بر فرم و منبع دادهٔ سفارشی است.
در تنظیم پارامترها، نمونهٔ حاضر ProcessStepId را از @@CurrentSteps، ProcessCreationId را از @@ProcessCreationID، عنوان را از @@Req:FormData['ReqTitle'] و توضیح را از @@Req:FormData['ReqDesc'] میگیرد. Accepted یک مقدار ثابت صفر است. تطبیق شناسهٔ گام با گام منتظرِ دریافت پیام، بخش ضروری آزمون همین سناریو است.
منبع دادهٔ Get All Received Requests در مثال، ردیفهای جدول AllReceivedRequests را با شرط Accepted = 0 به فرم متصل میکند. این شرط وضعیت تعریفشده در جدول سفارشی را فیلتر میکند تا تنها اقلام در انتظار نمایش داده شوند.
کنترل «ادامه فرآیند درخواست مربوطه» با نام ContinueProcess در فرم سفارشی یک عملیات اتصال داده دارد. در این مرحله، پارامتر privateToken از کنترل «توکن احراز هویت سامانه» خوانده شده و فراخوانی API ادامه فرآیند با شماره نمونه و شماره گام انجام میشود.
در مرحلهٔ «تغییر وضعیت درخواست»، منبع داده با نام update received request در یک Service Task پس از ادامه فرآیند فراخوانی میشود تا با کلید رکورد ورودی، وضعیت رکورد را از حالت منتظر خارج کند.
نمای اجرایی فرم سفارشی برای هر ردیف، شناسهٔ درخواست، شناسهٔ گام فرآیند، شناسهٔ نمونهٔ فرآیند، عنوان، توضیحات و دکمهٔ «قبول درخواست» دارد. این دکمه پس از احراز هویت، شماره نمونه و گام را به عملیات ادامه ارسال میکند و ServiceTask با تغییر مقدار Accepted از صفر به یک، ردیف را از درخواستهای منتظر خارج میسازد.