انجمن‌ها

در روند یک گردش کار، مواردی وجود دارد که محتوا یا رفتار بعضی از فیلدها وابسته به وضعیت و محتوای فیلدهای دیگر است. در این موارد باید یک سری محاسبات و کنترلها برای فیلدها در سطح فرم انجام شود و به همین خاطر، به این تنظیمات، تنظیمات رفتار در فرم گفته می شود. برای مثال فرض کنید قرار است در شرایط خاصی یک فیلد غیرقابل ویرایش (read only) شود. یا مثلا محتوای یک فیلد دیگر قرار است تحت شرایطی از یک مقدار خاص بیشتر نشود و مواردی از این قبیل.

نکته مهم: این کنترلها و رفتارها ارتباطی با انجام وظیفه ندارند و تنها با تصویب فرم، عملیاتی می شوند. به عبارت دیگر، کنترل رفتار فیلدها در مرحله ورود اطلاعات در فرم و در واقع قبل از انجام وظیفه انجام می شود. 

 در ادامه با انواع رفتارهایی که قابل تنظیم در فرم هستند آشنا می شویم:

انواع رفتار فیلدها در فرم

در سیستم مدیریت فرایندها سه نوع رفتار فیلدها در فرمها قابل تنظیم است: اعتبار سنجی ، محاسبه مقدار و تعیین وضعیت ویرایش که به ترتیب توضیح داده می شود:

اعتبارسنجی

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

مثال : اعتبارسنجی میزان تخفیف در گردش کار فروش

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

سوال: در محاوره تعریف فیلد، امکان تعیین محدوده برای انواع فیلدها وجود دارد پس چه نیازی به اعتبارسنجی در سطح کلاینت و فرم وجود دارد؟

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

همانطور که می بینید، تعیین محدوده برای فیلدهای عددی، مبلغ، تاریخ، زمان و مدت امکان دارد و برای انواع دیگر از جمله فیلدهای منطقی، و بویژه فیلدهای حرفی، تعیین محدوده امکان ندارد. بنابراین به دلایل گفته شده، نیاز به اعتبار سنجی داریم. حال برای این کار باید در محاوره تدوین یک فیلد گردش کار،  برگه رفتار در فرم را باز کنید:

توابع اعتبار سنجی با پیشوند WorkFieldValid شروع می شوند لذا اگر این تابع را قبلا نوشته باشید، در اینجا می توانید فهرست توابع اعتبارسنجی را باز کنید و تابع مورد نظر را از فهرست انتخاب کنید در غیر این صورت می توانید در این ناحیه نام مورد نظر خود (مثلا WorkFieldValidDiscount ) را تایپ کنید و با دبل کلیک وارد محیط برنامه نویسی در کلاینت شوید:

ملاحظه می کنید که یک تابع اعتبارسنجی با نامی که تعیین کرده ایم، ایجاد می شود که می توانیم این تابع را براساس شرایطی که در نظر داریم، تکمیل کنیم. با در نظر گرفتن شرایط گفته شده، تابع اعتبار سنجی مثال فوق، به شرح زیر خواهد بود:

همانطور که می بینید، در سطر دوم از این تابع، شرط قیمت  (kalaPrice) کمتر از 1000000 (یک میلیون تومان) بررسی شده و در سطر سوم، تعیین شده که اگر مقدار درصد تخفیف (discountCoef) بیش از 10 باشد آنگاه عملیات متوقف و پیغام غیرمجاز بودن میزان تخفیف نمایش داده شود.

نکته مهم: دقت کنید که در توابع تحت کلاینت بطور کلی وقتی می خواهیم مقدار و محتوای یک فیلد را استفاده کنیم، بجای WorkState از FormFields استفاده می کنیم.

در شکل زیر، مشاهده می کنید که قیمت کمتر از یک ملیون یعنی 900000  است و به دلیل اینکه درصد تخفیف، 45 انتخاب شده، سیستم این مقدار را اعتبارسنجی کرده و بیش از حد مجاز اعلام کرده است:

تعیین وضعیت ویرایش

اگر می خواهید تحت شرایط خاصی، یک فیلد خاص در فرم، غیرقابل ویرایش (read only) شود، آنگاه باید از این امکان استفاده کنید.  برای مثال به فرم زیر که در یک گردش کار اطلاع رسانی استفاده شده است، توجه کنید:

در این فرم، ابتدا نوع اطلاع رسانی مشخص می شود و در میان انواع اطلاع رسانی، فقط گزینه دوم یعنی اعلام سررسید (قراردادها) ست که باید محدوده زمانی سررسید مشخص شود. بنابراین برای انواع دیگر اطلاع رسانی، تعیین محدوده تاریخی بی معنی است و لذا باید در این موارد، فیلدهای آغاز محدوده و پایان محدوده را غیرقابل ویرایش (read only) کنیم. برای مثال برای فیلد محدوده آغاز سررسید و در محاوره تدوین این فیلد، برگه رفتار در فرم را باز کنید و مطابق شکل زیر در ناحیه تابع تعیین وضعیت ویرایش، تابع مورد نظر خود را انتخاب کنید:

حال برای آشنایی با نحوه کار کرد این تابع، بهتر است نگاهی به این تابع در مثال فوق بیندازیم:

تابع تعیین وضعیت ویرایش برای این مثال

عنوان این توابع با عبارت پیشوند WorkFieldReadOnly آغاز می شود. در این تابع و در سطر دوم شرط نوع اطلاع رسانی (noticeKind) چک شده و تعیین شده که اگر نوع اطلاع رسانی اعلام سررسید ^*باشد، آنگاه خروجی false باشد یعنی اینکه read only نباشد و در غیر این صورت در انواع دیگر اطلاع رسانی، خروجی تابع true یعنی read only  باشد.

*: این فیلد از نوع گزینه ای تعریف شده و مقدار 1 برای این فیلد برابر با گزینه دوم یعنی اعلام سررسید است.

نکته مهم: در ابتدا و در مورد این نوع از رفتار فیلدها در فرم، ممکن است این اشتباه پیش بیاید که خروجی true به معنی قابل ویرایش و false به معنی read only  است اما همانطور که در مثال هم ملاحظه کردید دقیقا برعکس این است یعنی خروجی true به معنی read only  و غیرقابل ویرایش است.

محاسبه مقدار

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

در این فرم، تعداد و قیمت واحد کالا (فی) وارد شده است. حال فرض کنید می خواهیم کل وجه پرداختی این تعداد کالا را در همین فرم ملاحظه کنیم. در این صورت باید مقدار فیلد تعداد کالا را در مقدار قیمت واحد کالا ضرب کنیم و نتیجه را در فیلد وجه پرداختی نمایش دهیم. برای این کار، همانطور که در شکل زیر مشاهده می کنید، فیلد وجه پرداختی باید از نوع محاسباتی در کلاینت باشد.

سوال: چرا برای این کار از فیلدهای از نوع محاسباتی در سرور استفاده نمی کنیم؟

جواب: در فیلدهای از نوع محاسباتی در سرور، ابتدا باید مقدار فیلدهای تعداد کالا و قیمت کالا در سرور ذخیره شود و سپس با اجرای یک وظیفه (Task) و از طریق یک تابع اجرایی، وجه پرداختی محاسبه و نمایش داده شود. در حالی که در فیلدهای از نوع  محاسباتی در کلاینت، هیچ اطلاعاتی ذخیره نمی شود و تمام مقادیر در فرم وجود دارند و در پایگاه ذخیره نشده اند.

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

حال باید در برگه رفتار در فرم، تابع محاسبه مقدار را برای این فیلد تعیین کنید.

همانطور که مشاهده می کنید، توابع محاسبه مقدار با عبارت پیشوند WorkFieldCalc مشخص می شوند. حال برای آشنایی با نحوه کارکرد این تابع، بهتر است نگاهی به متن تابع داشته باشیم.

تابع محاسبه مقدار برای مثال فوق

در سطر دوم این تابع، حاصلضرب مفادیر فیلدهای تعداد کالا (kalaNumbers) در قیمت کالا (kalaPrice) در متغیر pay قرار داده شده و این مقدار به عنوان خروجی تابع در فیلد وجه پرداختی نمایش داده می شود. نتیجه این کار را در فرم زیر ملاحظه می کنید:

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

ضمیمه: فیلدهای "محاسباتی در سرور" در برنامه کلاینت برای تعیین رفتار در فرم

تا قبل از این نسخه، امکانات برنامه کلاینت و تعیین رفتار فیلدها در فرم، تنها برای فیلدهای تعریف شده در فرمهای اختصاصی امکان پذیر بود. اما از نسخه جدید (15.27)، امکان استفاده از فیلدهای از نوع "محاسباتی در سرور" نیز در برنامه کلاینت فراهم شده است. برای نمونه به مثال زیر توجه کنید:

مثال: فیلد قیمت کالا از نوع محاسباتی در سرور

فرض کنید در یک گردش کار فروش، برای قیمت کالاها یک فیلد از نوع "محاسباتی در سرور" با نام در برنامه unitPrice تعریف شده است که قیمت واحد کالا را از سیستم فروش می خواند. تابع این فیلد در برنامه گردش کار به شکل زیر است:

function WorkFieldUnitPrice() {
   var price=SaleUtils.GetMatPrice(WorkState.matKey);
   return price;
}

در این تابع، قیمت کالا توسط تابع کتابخانه ای SaleUtils.GetMatPrice از سیستم فروش خوانده می شود. قیمت کالا را در فرم زیر مشاهده می کنید:

حال فرض کنید می خواهیم در این فرم، معتبر بودن فیلد درصد تخفیف (discountPercent) را وابسته به قیمت کالا نماییم. در این صورت در برنامه کلاینت، تابع زیر را می نویسیم:

function WorkFieldValidDiscount() {
  if (FormFields.unitPrice<1000000) {
    if (FormFields.discountPercent>10) {throw "ميزان تخفيف بيش از حد مجاز است"}
  }
}

در این تابع تعیین شده است که اگر قیمت کالا از 1000000  ریال کمتر باشد آنگاه تخفیف بیش از 10 درصدر مجاز نباشد. ملاحظه می کنید که در این تابع از فیلد unitPrice که از نوع "محاسباتی در سرور" است استفاده شده است.

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