یکی از گزارشهای اصلی و پرکاربرد سیستم مدیریت فرایندها، فهرست کارها (به همراه فیلدهای قابل تعریف) است. فیلدهای قابل تعریف امکانی است که کاربران سیستم می توانند از طریق آن، فیلدهای مورد نیاز خود را تعریف کنند و این فیلدها را به شکل یک ستون در فهرست کارها نمایش دهند. از ابتدای تولید سیستم مدیریت فرایندها، همیشه سعی بر این بوده است که قابلیتهای سیستم در مورد فیلدهای قابل تعریف افزایش یابد. در واقع امکان جدید جدولهای افزوده، امکانی است که برای توسعه فیلدهای قابل تعریف پیاده سازی شده است.
توسعه فیلدهای قابل تعریف
برای شناخت روشهای توسعه فیلدهای قابل تعریف، ابتدا باید با انواع فیلدها آشنا شویم.
- فیلدهای عادی: داده ها بطور کامل در سیستم مدیریت فرایندها وارد و ذخیره می شود که از فیلدهای عادی برای این کار استفاده می کنیم.
- فیلدهای انتخابگر حرفی: داده ها بطور کامل از یک پایگاه دیگر در خارج از سیستم مدیریت فرایندها خوانده می شود و فقط کلید داده ها در پایگاه فرایندها ذخیره می شود. برای این نوع از اطلاعات، راه حل انتخابگرهای حرفی را استفاده می کنیم. مثلا داده های کالاها یا مشتریان از طریق یک view از پایگاه سیستم مالی خوانده و نمایش داده می شود و در عین حال کلید کالا یا مشتری نیز در پایگاه ذخیره می شود.
- فیلدهای محاسباتی: داده ها در پایگاه فرایندها ذخیره نمی شود بلکه به شکل محاسباتی و در لحظه تولید می شود. این فیلدهای محاسباتی نیز چند نوع است:
- 3 وابسته به تراکنشهای گردش کار و داده های موجود در پایگاه فرایندها هستند برای مثال فرض کنید در گردش کار پشتیبانی می خواهیم سابقه رفع اشکالهای یک کارشناس را به شکل یک آرایه استخراج و نمایش دهیم.
- 3 داده ها در پایگاه فرایندها وجود دارد اما در فهرست فیلدها موجود نیستند. برای مثال فیلدهای از نوع منبع دیجیتال که گروه فیلدهای منبع دیجیتال در فهرست فیلدها موجود نیستند و یا مثلا فیلدهای از نوع کاربر که در فهرست فیلدها تنها بخشی از داده های وابسته به کاربر (UserInf) مثل ، نام، تصویر، تصویر امضا، بخش، جایگاه سازمانی اصلی وجود دارند و داده هایی نظیر شماره موبایل، آدرس ایمیل کاربر و شماره شناسایی کاربر در سایر سیستمها در فهرست فیلدها قابل دسترسی نیست.
- 3 بخشی از اطلاعات در سیستم مدیریت فرایندها وجود دارد و توسط یک کلید اتصال، به داده هایی در پایگاه خارج از سیستم فرایندها مرتبط است. مثلا در گردش کار مدیریت وامها، کد ملی کارمندان وارد شده است و این گردش کار با داده های کارمندان در مراکز تامین و مصرف در سیستم مالی از طریق کد ملی مرتبط است. حال برای نمایش مانده وام یا تاریخ استخدام کارمندان از فیلدهای محاسباتی استفاده می کنیم.
توضیح: تفاوتی که فیلدهای محاسباتی با انتخابگرهای حرفی دارد این است که در انتخابگر حرفی، مرجع داده ها بطور کلی در خارج از پایگاه است اما در فیلدهای محاسباتی، مرجع تمام یا بخشی از داده ها در داخل پایگاه فرایندهاست و در واقع داده های خوانده شده از پایگاههای خارج از سیستم، برای تکمیل اطلاعات داده های داخل پایگاه است.
بنابراین تا اینجا برای نمایش داده های خارج از پایگاه فرایندها، از دو روش استفاده می شد. یا باید از فیلدهای محاسباتی استفاده می کردیم و یا از فیلدهای انتخابگر حرفی. اما این دو روش کاستی هایی را به همراه دارد.
فیلدهای انتخابگر حرفی: همانطور که می دانید فیلدهای انتخابگر حرفی شامل فیلدهای نام (nwv_name)، کد (nwv_code)، دسته بندی (nwv_category) و جزئیات (nwv_detail) هستند که از این میان، فیلدهای نام، کد و جزئیات در فهرست کارها قابل نمایش است و حتی ستون دسته بندی نیز قابل نمایش نیست. از طرف دیگر ستون جزئیات در واقع فیلدی است که هر گونه اطلاعات تکمیلی دیگر علاوه بر کد و نام را در بر می گیرد و به همین دلیل ماهیت توصیفی دارد و معمولا ترکیبی از محتواهای عددی و حرفی با یک الگوی مشخص است. لذا محتویات ستون جزئیات به دلیل ماهیت ترکیبی بودن، امکان پردازشهای آماری مثل مجموع، میانگین، و ... و نیز مرتب سازی را ندارد و حتی اعمال شرایط به این ستون، بخصوص در مورد عملگرهای مقایسه ای نتایج صحیح را به همراه نخواهد داشت.
فیلدهای محاسباتی: این نوع از فیلدها کند هستند و در فهرست های با سطرهای زیاد، بار زیادی را به سرور تحمیل می کنند. بنابراین اگر در یک فهرست طولانی چند ستون محاسباتی داشته باشیم بطور محسوسی لختی و کندی سیستم را مشاهده خواهیم کرد. مورد دیگر این است که فیلدهای محاسباتی قابل اعمال شرایط نیستند. برای رفع کاستی های فوق، راه حل جدیدی در سیستم مدیریت فرایندها پیاده سازی شده است که توسعه فیلدهای قابل تعریف از طریق جداول افزوده می باشد.
در این روش، با استفاده از View ،جداول مجازی با ستونهای دلخواه را تولید می کنیم و با معرفی این جداول به گردش کارها، ستونهای جدولهای افزوده به فهرست فیلدهای قابل نمایش در فهرست کارها افزوده می شود.
توضیح: جدولهای افزوده علاوه بر فهرست کارها در گزارشهای محوری کارها، گزارش تفصیلی کارها به تفکیک آرایه ها و در گزارشهای محوری کارها به تفکیک آرایه ها نیز قابل استفاده است که در ادامه برای پرهیز از طولانی شدن و تکرار مفاهیم، تنها به مورد فهرست کارها اشاره می شود. لذا این توضیحات عینا برای گزارشهای ذکر شده نیز قابل استفاده می باشد.
مزایای استفاده از جدولهای افزوده
در واقع با توجه به مطالبی که در بالا ذکر شد می توانیم مزایای عمده جدولهای افزوده را در دو مورد زیر خلاصه کنیم:
- افزایش کارآیی (Performance) در نمایش فهرست کارها و گزارشهای دیگر
- امکان استفاده از شرایط در ستونهای جدول افزوده
در واقع مراحل تعریف یک جدول افزوده به شکل زیر است:
- نوشتن (یا توسعه) view
- اضافه کردن یک جدول با محتوای view و معرفی ستونهای مورد نظر جدول
- متصل کردن جدول افزوده به گردش کار
در ادامه مطلب با ذکر مثالهای واقعی سعی می کنیم مراحل فوق را به شکل ملموس تر و عینی تر شرح دهیم.
نکته مهم: جداول افزوده تنها و تنها برای نمایش در فهرست کارها (و گزارشهای یادشده) پیاده سازی شده است و امکان استفاده از این قابلیت در فرمهای انجام وظیفه وجود ندارد.
در بخشهای قبلی، انواع فیلدهای قابل تعریف را توضیح دادیم و کاربرد جدولهای افزوده را در توسعه انتخابگرهای حرفی و جایگزینی با انواع فیلدهای محاسباتی بیان کردیم. در ادامه مطلب با ذکر مثالهای واقعی این کاربردها را بیشتر توضیح می دهیم.
فرض کنید فیلد کالا که از نوع انتخابگر حرفی است، اطلاعات کالاها را از سیستم مالی خوانده و به شکل زیر به نمایش می گذارد:
ملاحظه می کنید که ستونهای کد (nwv_Code)، نام (nwv_Name)و جزئیات کالا (nwv_Detal) نمایش داده است. در ستون جزئیات نیز قیمت واحد کالا و بارکد کالا با یک جداکننده نمایش داده شده است. توجه می کنید که در این فهرست حتی دسته بندی کالا (nwv_Category) نیز نمایش داده نشده است. علاوه بر این، فیلد عددی «قیمت واحد کالا» چون بخشی از یک عبارت حرفی در جزئیات است امکان جستجو با شرایط و مرتب سازی ندارد و عملیات تجمعی مثل مجموع و میانگین را نیز نمی توانیم روی این فیلد محاسبه کنیم و نمایش دهیم.
به این ترتیب ملاحظه می کنید که ستون جزئیات تنها حالت توصیفی دارد و هیچ گونه پردازش و فیلترینگ خاصی روی این داده ها عملا امکان پذیر نیست. برای حل این مشکل، راه حل توسعه انتخابگر حرفی از طریق جداول افزوده پیاده سازی شده است.
توسعه انتخابگرهای حرفی با جدول افزوده
در مورد انتخابگرهای حرفی view از قبل وجود دارد و کافی است که ستونهای این view توسعه داده شود. برای نمونه به view مرتبط با مثال بالا (فیلد انتخابگر حرفی کالا) توجه کنید:
ALTER VIEW [dbo].[_NosaWorkView_Products] AS
SELECT mat_Code AS nwv_code, mat_Name AS nwv_name
, cast(‘قیمت واحد: ‘+(cast(mat_NormalUnitPrice as nvarchar) + ‘/ بارکد: ‘ + mat_BarCode) as nvarchar(max)) AS nwv_Detail
, st_Name AS nwv_Category
FROM [_AccXP_hamayesh992].[dbo]._Mats
inner join [_AccXP_hamayesh992].[dbo]._MatStock on mat_Key =mst_MatKey
inner join [_AccXP_hamayesh992].[dbo]._Stocks on mst_StockKey =st_Key
حال فرض کنید می خواهیم یک ستون دلخواه به این view اضافه کنیم:
مثال: افزودن ستون قیمت نرمال واحد کالا
مرحله اول: توسعه view
فرض کنید می خواهیم قیمت نرمال واحد کالا (mat_NormalUnitPrice) را نه به شکلی که در ستون جزئیات نمایش داده شده بلکه به شکل یک ستون جداگانه تعریف کنیم. برای این کار کافی است یک سطر به شکل زیر به view اضافه کنیم:
ALTER VIEW [dbo].[_NosaWorkView_Products] AS
SELECT mat_Code AS nwv_code, mat_Name AS nwv_name
, cast(‘قیمت واحد: ‘+(cast(mat_NormalUnitPrice as nvarchar) + ‘/ بارکد: ‘ + mat_BarCode) as nvarchar(max)) AS nwv_Detail
, st_Name AS nwv_Category
, mat_NormalUnitPrice AS nwv_UnitPrice
FROM [_AccXP_hamayesh992].[dbo]._Mats
inner join [_AccXP_hamayesh992].[dbo]._MatStock on mat_Key =mst_MatKey
inner join [_AccXP_hamayesh992].[dbo]._Stocks on mst_StockKey =st_Key
سطر اضافه شده با رنگ قرمز مشخص شده است.
مرحله دوم: تعریف جدول افزوده کالاها
برای این کار مطابق شکل زیر از منوی طراحی گردش کار، گزینه "جدولهای افزوده گردش کار" را کلیک می کنیم:
با این کار، محاوره جدولهای افزوده گردش کار به شکل زیر روی صفحه باز می شود:
همانطور که ملاحظه می کنید این محاوره به دو بخش تقسیم شده است. در قسمت بالا جدولهای افزوده معرفی می شود و در قسمت پایین ستونهای مورد نظر از جدول افزوده را تعیین می کنیم. حال جدول "کالاها" مرتبط با _NosaWorkView_Products را به شکل زیر به فهرست جدولهای افزوده اضافه می کنیم:
ملاحظه می کنید که در قسمت پایین، ستون "قیمت نرمال واحد کالا" را تعیین کرده ایم. حال باید این جدول را به گردش کالای مورد نظر خود معرفی کنیم.
نکته: توجه کنید که برای جداول افزوده متصل به فیلدهای انتخابگر حرفی نیازی به افزودن ستونهای کد، نام و جزئیات نیست و این ستونها به شکل پیش فرض در لیست فیلدها حضور دارند.
مرحله سوم: معرفی جدول افزوده به گردش کار
برای این کار باید مطابق شکل زیر، در محاوره تعریف و اصلاح گردش کارها، و روی گردش کار کالاها، آیکون 
را کلیک کنید:
با این کار، محاوره جدولهای افزوده متصل به گردش کار، به شکل زیر روی صفحه باز می شود:
همانطور که می بینید هنوز هیچ جدول افزوده ای به این گردش کار متصل نشده است. برای این کار یک سطر جدید به این فهرست اضافه می کنیم و موارد زیر را تعیین می کنیم:
جدول افزوده: در این ستون از طریق یک منوی باز شونده، جدول افزوده مورد نظر خود (در این مثال، جدول کالاها) را انتخاب می کنیم.
فیلد رابط اتصال به جدول افزوده: بطور کلی هر جدول افزوده باید به فیلد رابط متصل شود. در این مثال، فیلد رابط فیلد اتصال، فیلد انتخابگر حرفی «کالا» ست.
عبارت اتصال: شرط اتصال جدول افزوده به فیلد رابط اتصال در این قسمت تعیین می شود که برای انتخابگرهای حرفی نیازی به تعیین این مورد وجود ندارد و سیستم بطور خودکار کد انتخابگر حرفی را به عنوان کلید اتصال در نظر می گیرد. در مثالهای بعدی که به موارد غیر از انتخابگر حرفی اختصاص دارد، مفهوم عبارت اتصال با مثالهای واقعی روشن تر خواهد شد.
پس از تعیین موارد بالا، یک سطر جدید به شکل زیر به محاوره بالا اضافه می شود:
به این ترتیب همانطور که در شکل زیر ملاحظه می کنید، در گردش کار «کالاها» فیلد «قیمت نرمال واحد کالا» به فهرست فیلدهای قابل درج در فهرست کارها اضافه می شود:
حال با افزودن این ستون، فهرست کارها به شکل زیر به نمایش در می آید:
حال می توانیم به راحتی ستون قیمت واحد کالا را مرتب سازی کنیم و با اعمال شرایط دلخواه برای این ستون، فهرست کالاها را فیلتر کنیم. برای مثال در شکل زیر این ستون بصورت صعودی مرتب شده است:
حال فرض کنید می خواهیم کالاهای با قیمت واحد کمتر از 450000 را مشاهده کنیم:
با اعمال شرط فوق، فهرست کارها به شکل زیر محدود می شود:
توجه کنید: در اینجا ممکن است این سوال به ذهن برسد که با امکان جدولهای افزوده دیگر چه نیازی به ستون جزئیات کالا داریم ؟ در جواب باید بگوییم که چون در فرم انجام وظیفه امکان استفاده از جدولهای افزوده وجود ندارد لذا ستون جزئیات شامل اطلاعاتی است که به کاربر در هنگام انجام وظیفه، و در زمان انتخاب داده ها کمک می کند. به عبارت بهتر وقتی کاربر در فرم انجام وظیفه، تکمه انتخاب فیلد انتخابگر حرفی را کلیک می کند و فهرست داده ها نمایش داده می شود، می تواند با کلیک روی جزئیات، داده های تکمیلی بیشتری را مشاهده کند و انتخاب خود را دقیق تر انجام دهد.
همانطور که قبلا توضیح داده شد، فیلدهای محاسباتی بر چند نوع هستند:
مثال تهیه لیست رفع اشکالهای یک کارشناس یا مثلا تهیه لیست استعلام قیمتها از یک تامین کننده برای خرید کالا
تراکنشهای گردش کار، از طریق موجودات تعریف شده در سیستم (Injected Objects) و با استفاده از تابع WorkUtils.GetWorkLogInf انجام می شود لذا نوشتن View برای این تراکنشها بااستفاده از توابع TSQL بسیار پیچیده است و باید از Stored Procedure های پایگاه استفاده کنیم. لذا بنظر می رسد هزینه این کار از فایده آن بیشتر است و بهتر است این نوع از فیلدهای محاسباتی با استفاده از اسکریپت های js در برنامه گردش کار انجام شود.
برای مثال، فیلدهای نوع منبع دیجیتال که داده های گروه فیلدهای منبع دیجیتال در فهرست فیلدهای قابل نمایش در فهرست کارها وجود ندارد یا مثلا فیلدهای نوع کاربر که داده هایی مثل شماره تلفن همراه یا آدرس ایمیل در لیست فیلدها قابل دسترسی نیست. برای نمایش این دسته از فیلدها می توانیم از روش جدولهای افزوده استفاده کنیم. برای مثال به نمایش گروه فیلدهای یک فیلد منبع دیجیتال نمونه می پردازیم.
همانطور که قبلا هم گفته شد، یکی دیگر از کاربردهای مهم جداول افزوده، نمایش محتوای گروه فیلدهای منابع دیجیتال است. برای مثال در یک پایگاه نمونه بنام «تست گردش کار» یک گروه فیلد بنام «مشخصات خودرو» به شکل زیر تعریف شده است:
همانطور که می دانید فهرست فیلدهای این گروه فیلد را می توانیم با کلیک روی آیکون 
واقع در نوار ابزار، به شکل زیر مشاهده کنیم:
حال فرض کنید در گردش کار خدمات حمل و نقل، فیلدی بنام «خودرو» از نوع منبع دیجیتال وجود دارد که به این گروه فیلد متصل شده است. تا قبل از امکان جدولهای افزوده، تنها امکان نمایش کد و شرح منبع دیجیتال وجود داشت. برای نمونه به شکل زیر توجه کنید:
ملاحظه می کنید که در این فهرست هیچ نشانی از گروه فیلدها (سال ساخت خودرو، و ...) نیست. حال فرض کنید می خواهیم داده های این گروه فیلد (خودروها) را به این فهرست اضافه و در ستونهای جداگانه نمایش دهیم.
مرحله اول: نوشتن View
همانطور که در شکل می بینید کد این گروه فیلد 31 است اما این کد برای ما قابل استفاده نیست بلکه باید کلید گروه فیلد را پیدا کنیم. برای این کار باید فهرست جدولهای پایگاه ReposXP_workflow را باز کنیم و محتویات جدول _FieldClasses را مطابق شکل زیر Select کنیم.
ملاحظه می کنید که کلید گروه فیلد (fc_Key) «مشخصات خودرو» برابر با 40 است. داده های فیلدهای گروه فیلدها در در جدولهایی با نام _DigitalObjectFieldInfsNum یکه در اینجا Num همان کلید گروه فیلد (fc_Key) است. برای مثال جدولهای گروه فیلدهای پایگاه ReposXP_workflow را در شکل زیر ملاحظه کنید:
همانطور که در شکل مشخص شده است، جدول _DigitalObjectFieldInfs40 حاوی داده های فیلدهای این گروه فیلد است. در این فهرست، ستون dofi_DigitalObject40 کلید منبع دیجیتال است و ستونهای دیگر که با الگوی dofi_DONumber نمایش داده شده است، فیلدهای گروه فیلد هستند. در موارد ساده مثل مثال بالا با یک نگاه به ستونها می توانیم محتوای آنها را تشخیص دهیم برای مثال مشخص است که ستون dofi_DO65 حاوی سال ساخت خودروهاست. اما در موارد پیچیده شاید حدس زدن محتوا به این راحتی نباشد لذا برای اطلاع از محتوای ستونها می توانید مطابق شکل زیر، از جدول _FieldClassFieldDefs استفاده کنید:
ملاحظه می کنید با استفاده از این داده ها، اطلاعات جدول فیلدهای گروه فیلد خودروها (_DigitalObjectFieldInfs40) به ترتیب زیر شناسایی می شود:
dofi_DO65 سال ساخت
dofi_DO74 مجوز طرح ترافیک
dofi_DO112 روزهای ورود به طرح آلودگی هوا
پس از شناسایی ستونهای جدول فیلدهای گروه فیلد خودروها، حال باید به شکل زیرف یک view با عنوان _NosaWorkView_CarSpecs بنویسیم که داده های فوق را استخراج کند و نمایش دهد:
create view _NosaWorkView_CarSpecs AS
SELECT do_id, dofi_DO65 as productYear , dofi_DO112 as daysInAirPollutionArea
, dofi_DO74 as trafficAreaLicence
from _DigitalObjects
inner join _DigitalObjectFieldInfs40 on dofi_DigitalObject40=do_ID
برای درک این view باید در نظر داشته باشید که هر خودرو یک منبع دیجیتال است که در جدول منابع دیجیتال (_DigitalObjects) دارای یک کلید (do_ID) است. همین خودرو در جدول جدول فیلدهای گروه فیلد خودروها (_DigitalObjectFieldInfs40) نیز با فیلد dofi_DigitalObject40 قابل شناسایی است که محتوای آن از نوع کلید منبع دیجیتال (do_ID)است لذا شرط join شدن این دو جدول، برابر بودن این دو فیلد است.
مرحله دوم : تعریف یک جدول افزوده با محتوای این View
برای این کار کافی است از منوی «طراحی گردش کار» همانند شکل زیر محاوره جدولهای افزوده گردش کار را باز کنید و یک سطر با محتوای زیر به آن اضافه کنید:
ملاحظه می کنید که هر سه ستون موجود در view در اینجا تعریف شده است. دقت کنید که انتخاب ستونهای view اختیاری است و لزومی به تعریف تمام ستونها نیست. به عبارت دیگر ممکن است شما در یک پایگاه از یک تعداد از ستونها و در پایگاه دیگر از تعداد دیگری از ستونهای view استفاده کنید. یا ممکن است بعضی از ستونها را برای مرتب سازی Order By تعریف کنید و تمایلی به نمایش این ستون نداشته باشید.
مرحله سوم: معرفی جدول افزوده به گردش کار خدمات حمل و نقل
برای این کار باید مطابق شکل زیر، در محاوره تعریف و اصلاح گردش کارها، و روی گردش کار خدمات حمل و نقل، آیکون 
را کلیک کنید:
با این کار محاوره جدولهای افزوده متصل به گردش کار به شکل زیر باز می شود:
همانطور که ملاحظه می کنید در ستون جدول افزوده، جدول مشخصات خودرو و در ستون فیلد رابط اتصال، فیلد خودرو (از نوع منبع دیجیتال) تعیین شده است. مفهوم جدیدی که در فیلدهای انتخابگر حرفی وجود نداشت و در این مثال وجود دارد مفهوم «عبارت اتصال» است.
مفهوم عبارت اتصال
جداول افزوده در واقع در هنگام اجرا از طریق کلید فیلد رابط اتصال، با جدول فهرست کارها Left Outer Join می شود و از طرف دیگر می دانیم که هر join نیاز به یک شرط دارد که عبارت اتصال در واقع همان عبارت شرط (با ON) است. در واقع اتفاقی که می افتد چیزی شبیه به کوئری زیر است:
Select * from Fehrest
Left Outer Join _NosaWorkView_CarSpecs Wehicles
ON Fehrest.Car = Wehicles.do_ID
ملاحظه می کنید که شرط اتصال، برابر بودن کلید فیلد خودرو در فهرست کارها با کلید منبع دیجیتال خودرو در درخت منابع دیجیتال است. حال برای راحت تر نوشتن این عبارت اتصال، قراردادی تعیین شده که در محاوره فوق و در راهنمای عبارت اتصال توضیح داده شده است. قرارداد این است که بجای کلید فیلد رابط (Fehrest.Car) از عبارت «%0:s» و بجای نام جدول افزوده(Wehicles) از عبارت «%1:s» استفاده می کنیم. به این ترتیب عبارت اتصال به شکل زیر درج می شود:
%0:s=%1:s.do_ID
توضیح مهم: همانطور که دیدید کلید فیلد رابط اتصال بصورت دستی تعیین نمی شود چون با تعیین فیلد رابط اتصال، سیستم بطور اتوماتیک نام ستون این فیلد را در جدول فیلدهای گردش کار (WorkflowFieldInfs) تشخیص می دهد. بنابراین فقط کافی است که کلید فیلد رابط در جدول افزوده (در این مثال do_ID) را بشناسیم و در عبارت اتصال تعیین کنیم.
سوال چالشی: به نظر شما چرا برای جدول افزوده یک نام مستعار (Alias Name) مثلا در این مثال نام Wehicles را استفاده می کنیم؟
به این ترتیب در هنگام ویرایش فهرست کارها در گردش کار خدمات حمل و نقل، گروه فیلدهای فوق را به شکل زیر مشاهده خواهید کرد:
با اضافه کردن ستونهای فوق، فهرست کارها به شکل زیر نمایش داده می شود:
حال این امکان وجود دارد که فهرست را براساس نیازهای کاربر محدود و مرتب کنیم. برای مثال فرض کنید می خواهیم خدمات خودروهایی را که سال ساخت آنها بالای 1395 باشد ملاحظه کنیم. بنابراین کافی است شرط زیر را به فهرست اضافه کنیم:
در این صورت فهرست کارها به شکل زیر محدود می شود:
توضیح: نمایش گروه فیلدها با روش محاسباتی و از طریق تابع WorkUtils.GetDOState نیز قابل دسترسی و نمایش است اما همان مواردی را که در مورد فیلدهای محاسباتی گفتیم در اینجا نیز صدق می کند یعنی اینکه برای فهرست های طولانی و تعداد گروه فیلدهای زیاد، کارآیی و سرعت سیستم پایین می آید و ضمنا امکان اعمال شرایط برای گروه فیلدها وجود نخواهد داشت.
برای مثال در گردش کار درخواست وام ، فیلد «کد ملی» کلیدی است برای ارتباط با سیستم پرسنلی و خواندن داده هایی مثل مانده وام یا تاریخ استخدام
مثال: خواندن تاریخ استخدام و مانده بدهی کارمندان از سیستم پرسنلی
قبل از تعریف جدول افزوده بهتر است نگاهی به فهرست کارهای گردش کار درخواست وام بیندازیم:
ملاحظه می کنید که ستون کد ملی یکی از ستونهای این جدول کد ملی است که قرار است بر پایه این ستون، اطلاعات دیگر درخواست کننده را از طریق جدول افزوده استخراج کنیم.
مرحله اول: نوشتن view
در پایگاه سیستم پرسنلی نوسا، فهرست کارکنان در جدولی بنام _WfixInf ذخیره می شود. نمونه ای از این جدول را در مثال زیر ملاحظه می کنید:
حال باید ستونهای متناظر با کد ملی، تاریخ استخدام و مانده بدهی کارمندان را از این جدول شناسایی کنیم. همانطور که ملاحظه می کنید الگوی نام بعضی از ستونهای این جدول بصورت fi_FInum است که شناخت محتوای آنها را دشوار می سازد. اگرچه شاید با نگاهی محتوای داده ها بتوانیم این فیلدها را حدس بزنیم اما دقیق ترین کار این است که همانند شکل زیر، فهرست فیلدها را از جدول _WfixDef شناسایی کنیم:
همانطور که ملاحظه می کنید شماره ستونهای مورد نظر ما به شکل زیر است:
Fi_FI2 کدملی
Fi_FI13 تاریخ استخدام
Fi_FI82 مانده بدهی
حال این داده ها در شکل زیر مشخص می شود:
بنابراین باید در پایگاه فرایندها، یکview به شکل زیر ایجاد کنیم:
create view _NosaWorkView_WorkersInf AS
Select fi_FI2 AS melliCode, fi_FI13 AS hireDate, fi_FI82 AS debt
from [_AccXP_hamayesh992].[dbo].[_WFixInf]
مرحله دوم: تعریف یک جدول افزوده جدید
طبق مثالهای قبل یک جدول جدید را به شکل زیر در فهرست جدولهای افزوده، تعریف می کنیم:
مرحله سوم: مرتبط کردن این جدول افزوده به گردش کار درخواست وام
همانطور که قبلا هم گفته شد، فیلد رابط اتصال به جدول افزوده، فیلد "کد ملی" است، بنابراین جدول افزوده «اطلاعات پرسنلی» را به شکل زیر به گردش کار درخواست وام متصل می کنیم:
عبارت اتصال: عبارت اتصال در واقع باید به شکلی باشد که فیلد کد ملی (NationalCode) در گردش کار را به ستون کد ملی ( melliCode) در جدول افزوده متصل کند. بنابراین طبق قراردادی که در مثال قبل توضیح داده شد در ستون عبارت اتصال این عبارت تعیین شده است.
به این ترتیب ستونهای جدول افزوده به شکل زیر به فهرست فیلدهای قابل درج در فهرست کارها افزوده می شود:
حال دو ستون «تاریخ استخدام» و «مانده بدهی» را به فهرست کارها اضافه می کنیم و به این ترتیب فهرست کارها به شکل زیر نمایش داده می شود:
حال می توانیم روی مانده بدهی شرط تعیین کنیم و مثلا درخواستهای با مانده بدهی کمتر از 200 ملیون ریال را ملاحظه کنیم.
با اعمال این شرط، فهرست کارها به شکل زیر محدود می شود:
نکته مهم: تا زمانی که تعداد سطرهای فهرست کارها زیاد نیست، نیازی به جداول افزوده نیست. یعنی به عبارت دیگر از نظر تحلیل هزینه – فایده، این کار به صرفه نیست اما زمانی که به دلایل مختلف از جمله منطق تجاری ناقص و مبهم، فهرست کارها طولانی است و ادامه روند کارها به عهده تصمیمهای کارشناس گذاشته است، آنگاه جداول افزوده کمک بسیاری در بالا بردن کارآیی سیستم در فیلتر کردن کارها و نمایش داده های مورد نیاز برای تصمیم گیری کارشناس خواهد کرد.
همانطور که در ابتدا هم اشاره شد، ستونهای جدولهای افزوده علاوه بر فهرست کارها (به همراه فیلدهای قابل تعریف)، در گزارشهای زیر نیز قابل استفاده است:
- گزارش محوری (به همراه فیلدهای قابل تعریف)
- گزارش تفصیلی کارها به تفکیک آرایه ها
- گزارش محوری تفصیلی کارها به تفکیک آرایه ها
در مورد گزارشها واقعیت این است که بالا رفتن سرعت و کارآیی نمایش گزارشها مزیت اصلی استفاده از جدولهای افزوده نیست چون گزارشها معمولا فوریت ندارد و به شکل مستمر و مکرر انجام نمی شود و لذا زمانبر بودن گزارش گیری قابل تحمل است، بلکه آنچه بیشتر اهمیت دارد مزیت دوم یعنی امکان استفاده از شرایط در ستونهای جدول افزوده است. در ادامه مطلب به چند مثال در مورد گزارشهای فوق می پردازیم:
نمونه گزارش محوری (به همراه فیلدهای قابل تعریف)
در این گزارش محوری از گردش کار تامین کالاها، ستون قیمت نرمال واحد کالا از طریق اتصال به جدول افزوده به این گزارش اضافه شده است:
نمونه گزارش تفصیلی کارها به تفکیک آرایه ها
در این گزارش از گردش کار تامین کالا، آرایه استعلام قیمت نمایش داده شده است:
به این گزارش نیز ستون «قیمت نرمال واحد کالا» از روش جدول افزوده، اضافه شده است. نکته ای که در این گزارش وجود دارد این است که شرح کار، نام کالا و قیمت نرمال واحد کالا به تعداد تامین کنندگان تکرار شده است لذا توصیه می شود بجای این گزارش از گزارش محوری به تفکیک آرایه ها که در ادامه توضیح داده شده است استفاده کنید.
نمونه گزارشهای محوری به تفکیک آرایه ها: گزارش استعلام قیمت کالاها
در این گزارش (شکل زیر)، برای هر کالا ستون «قیمت نرمال واحد کالا» افزوده شده و در زیرمجموعه آن، آرایه اطلاعات استعلام کالا نمایش داده شده است.
همانطور که ملاحظه می کنید آرایه استعلام قیمت شامل نام تامین کننده کالا، محل جغرافیایی، توضیحات، قیمت پیشنهادی و درصد تخفیف کالا توسط تامین کننده است. توجه دارید که در این گزارش شرح کار، نام کالا و قیمت نرمال واحد کالا تکرار نشده است و استعلامهای هر کار، در سطر مربوط به همان کار درج شده است.