/
/
/
/
REPORT-01
GraphBPMS Wiki
مدیریت گزارش‌ها
مدیریت گزارش‌ها در GraphBPMS
پیشخوان «مدیریت گزارش‌ها» در سامانه GraphBPMS، بستر یکپارچه و متمرکز برای مشاهده، دسته‌بندی، ایجاد و راهبری کلیه گزارش‌های سازمانی است. از طریق این بخش، مدیران سیستم و طراحان فرایند می‌توانند ساختار انواع گزارش‌های تحلیلی را مدیریت نموده، گزارش‌های جدید ایجاد کنند، وضعیت قالب‌های خروجی فعال را ارزیابی کرده و عملیات حیاتی نظیر بازبینی بلادرنگ داده‌ها، تنظیم مجوزهای دسترسی، واگذاری رونوشت سازمانی، تعریف اعلان‌های شرطی، کپی، ویرایش و حذف گزارش را انجام دهند.
۱. مفهوم گزارش‌ساز و جایگاه آن در چرخه داده‌های GraphBPMS
در معماری پلتفرم GraphBPMS، ماژول‌ها نقش‌های تفکیک‌شده‌ای در گردش داده دارند:
- ماژول فرم‌ساز: مسئول دریافت، اعتبارسنجی و ثبت داده‌های اولیه است.
- موتور فرایند: جریان گردش کار، ارجاعات و تغییر وضعیت وظایف را هدایت می‌کند.
- مدیریت منابع داده (Provider): وظیفه اتصال به پایگاه‌های داده و بازیابی رکوردهای خام را بر عهده دارد.
- ماژول گزارش‌ساز: سند ساخت‌یافته و هدفمندی ایجاد می‌کند تا داده‌های متفرق را در قالب‌های خوانا، تحلیلی و مدیریتی بازنمایی نماید.
گزارش‌ها می‌توانند اطلاعات را در قالب‌های پنج‌گانه زیر رندر کنند:
- خروجی جدولی (Grid): نمایش ستونی و سطری داده‌ها جهت مرور تفصیلی.
- خروجی چاپ (Stimulsoft): تولید اسناد رسمی، فیش، قبض و فرمت‌های پرینت استاندارد A4/A5.
- خروجی نموداری (Chart): تحلیل روندها و الگوهای آماری به صورت خطی، میله‌ای و دایره‌ای.
- خروجی نقشه (GIS): بصری‌سازی داده‌های دارای مختصات جغرافیایی روی نقشه.
- خروجی گالری تصویر (Media): ارائه فایل‌های چندرسانه‌ای و تصاویر به شکل کارت‌های آلبومی.
۲. دسترسی به صفحه مدیریت گزارش‌ها و ساختار پیشخوان
برای ورود به بخش مدیریت گزارش‌ها، پس از ورود با حساب کاربری دارای دسترسی راهبری سیستم:
- از منوی عمودی سمت راست، زیرمنوی راهبر سیستم را باز کنید.
- روی گزینه گزارش‌ساز کلیک نمایید.
با باز شدن صفحه، پیشخوان مدیریت گزارش‌ها با جدول رکوردهای گزارش‌های موجود و نوار ابزار بالای صفحه ظاهر می‌شود.
۳. ایجاد گزارش جدید و ورود به استودیوی طراحی
جهت طراحی و راه‌اندازی یک گزارش تازه، روی دکمه آبی‌رنگ ایجاد گزارش در گوشه بالا سمت چپ جدول کلیک کنید. با این اقدام، سامانه محیط طراحی استودیو (ReportBuilderStudio) را فراخوانی می‌کند.
در بدو ورود به استودیو، دو گام اصلی در اختیار طراح قرار می‌گیرد:
- تنظیمات عمومی: شامل درج عنوان گزارش، انتخاب گروه دسته‌بندی موضوعی، وضعیت فعال بودن و توضیحات راهنما.
- منابع داده: اتصال گزارش به یک یا چند منبع داده (Provider) معتبر جهت تغذیه داده‌های ورودی.
پیوند مرتبط
چرخه کامل تعریف پرووایدر، فرم‌دهی ستون‌های خروجی و فیلترهای کوئری در آموزش [REPORT-02] استودیوی ساخت گزارش تشریح شده است.
۴. مشخصات و ستون‌های جدول فهرست گزارش‌ها
جدول اصلی مدیریت گزارش‌ها شامل ستون‌های زیر است:
| نام ستون | شرح و عملکرد |
|---|---|
| کد | شناسه عددی یکتا که سیستم به‌صورت خودکار به هر گزارش تخصیص می‌دهد. |
| عنوان | نام نمایشی و سازمانی گزارش. |
| قالب‌های گزارش | آیکن‌های پنج‌گانه نشان‌دهنده خروجی‌های فعال (جدول، نمودار، نقشه GIS، گالری و چاپ). |
نشانگر عددی قالب‌ها (Badge Counter)
وجود نشانگر عددی رنگی روی هر یک از آیکن‌های ستون «قالب‌های گزارش»، بیانگر تعداد تمپلیت‌های طراحی‌شده و آماده بهره‌برداری برای آن قالب خاص است.
۵. جعبه‌ابزار عملیاتی ردیف گزارش (Row Actions)
جهت بهینه‌سازی فضای جدول، آیکن‌های عملیاتی هر گزارش در حالت پیش‌فرض مخفی هستند. با بردن نشانگر ماوس (Hover) روی هر سطر، نوار ابزار عملیاتی متناظر با همان ردیف فعال و نمایان می‌گردد (در محیط راست‌به‌چپ، در سمت چپ ردیف ظاهر می‌شود).
۶. مشاهده سریع و بررسی داده‌های گزارش
با کلیک بر روی نخستین آیکن از سمت راست (نماد چشم)، پیش‌نمایش مستقیم گزارش بدون ورود به محیط طراحی استودیو باز می‌شود:
- تنظیم پارامترهای فیلتر: در بخش «جستجو در فرم»، چنانچه گزارش دارای پارامتر ورودی باشد، کنترل‌های مربوطه ظاهر می‌شوند. مقادیر دلخواه را وارد کرده و در صورت نیاز تیک «ذخیره پارامترها به‌صورت پیش‌فرض» را فعال نمایید.
- اجرای کوئری: با فشردن کلید آبی‌رنگ پیش‌نمایش، داده‌ها واکشی شده و در بخش «لیست داده‌ها» بارگذاری می‌شوند.
- پیمایش رکوردها: در جدول نتایج، امکاناتی نظیر جست‌وجوی محلی، فیلتر روی هر ستون، مرتب‌سازی، خروجی اکسل و تغییر اندازه صفحه‌بندی فعال است.
۷. سامانه رونوشت خروجی گزارش به کاربران و نقش‌ها (ویژه کاربران نهایی)
سازوکار «رونوشت گزارش (Report Transcript / Dispatch)» یکی از ارکان بنیادی انتشار داده و تفکیک امنیتی در پلتفرم GraphBPMS است. این قابلیت منحصراً برای کاربران نهایی (End-Users) و ذی‌نفعان عملیاتی سازمان طراحی شده است تا بتوانند داده‌های پردازش‌شده و خروجی‌های معتبر گزارش را در محیط‌های بهره‌برداری دریافت نمایند.
قاعده اساسی معماری: رونوشت منحصراً ویژه کاربران نهایی (End-Users) است
هدف از اعطای رونوشت، توانمندسازی پرسنل و کاربران اداری جهت مشاهده، جست‌وجو، فیلترگذاری و چاپ رکوردهای گزارش در پورتال کاربری «لیست گزارش‌ها» یا میزکارهای سازمانی (Dashboards) است. کاربر دریافت‌کننده رونوشت، صرفاً «مصرف‌کننده داده (Data Consumer)» است و هیچ‌گونه مجوز یا امکانی برای ورود به محیط پیچیده طراحی گزارش‌ساز، کدنویسی کوئری‌های SQL، تغییر فیلدها یا دستکاری متادیتای سیستم نخواهد داشت.
- تب رونوشت جدید: انتخاب نوع گیرنده (کاربر یا نقش سازمانی)، انتخاب نام مخاطب از لیست و فشردن دکمه «ارسال رونوشت».
راهنمای جامع کارگاه رونوشت، پورتال کاربری و میزکارهای سازمانی
جهت مشاهدهٔ فرآیند کامل تفویض رونوشت به انواع قالب‌ها (قالب چاپ، نقشه مکانی GIS، نمودارهای تحلیلی BI)، نحوهٔ مشاهده در پورتال «لیست گزارش‌ها» و استقرار ماژول گزارشات در داشبوردهای سازمانی، به بخش ۱۶: توزیع گزارش‌ها در میزکارهای سازمانی و سامانه رونوشت مراجعه فرمایید.
- تب رونوشت‌های ارسال شده: مشاهده لیست دریافت‌کنندگان رونوشت و ابزار لغو رونوشت‌های قبلی.
- پس از ثبت رونوشت، نشانگر عددی روی آیکن رونوشت در جدول گزارش‌ها به‌روزرسانی می‌شود.
- کاربر دریافت‌کننده، گزارش را مستقیماً در کارتابل و منوی اختصاصی خود مشاهده می‌کند.
۷-۱. ارسال گزارش فیلترشده و سفارشی برای کاربران در رونوشت (ابزار راهبردی مدیریت اطلاعات)
تنظیم پارامترها در هنگام اعطای رونوشت، صرفاً یک فیلترگذاری ساده نیست؛ بلکه یک ابزار فوق‌العاده مهم، استراتژیک و سناریومحور مدیریتی است. در سازمان‌ها اغلب یک گزارش مادر و جامع طراحی می‌شود (مانند «لیست پروژه‌ها و اقلام») که کل اطلاعات سازمان را در بر دارد. اما هنگام توزیع رونوشت میان مدیران و پرسنل، اهداف مدیریتی متعددی مطرح است: تفکیک پروژه‌ها بر اساس دپارتمان‌ها، محدود کردن کارتابل هر کارمند به وظایف خودش، یا نمایش داده‌های متناسب با نقش سازمانی. سامانه رونوشت این امکان را به مدیر می‌دهد که بدون دستکاری در گزارش اصلی، انواع سناریوهای مدیریتی را با دقت بالا پیاده‌سازی کند.
یک گزارش جامع، بی‌نهایت سناریوی مدیریتی اختصاصی
به جای طراحی ده‌ها گزارش موازی و مشابه برای تک‌تک واحدها، یک گزارش جامع ساخته می‌شود و سپس با تنظیم هوشمند پارامترها در پنجره رونوشت، اطلاعات برای هر کاربر یا نقش به شکلی سفارشی، فیلترشده و حتی کاملاً پنهان ارسال می‌گردد.
سناریوی عملیاتی: نمایش پروژه‌های اختصاصی برای هر مدیر
برای پیاده‌سازی گام‌به‌گام این قابلیت، سناریوی واقعی زیر را در چرخه پروژه‌های سازمان دنبال می‌کنیم:
- دسته‌بندی موضوعی پروژه‌ها در فرم‌ساز: در فرم ثبت اطلاعات پروژه، فیلد دسته‌بندی موضوعی (
CategoryId) بر اساس یک لیست ثابت سه‌گانه مقداردهی شده است:- مقدار ۱: پروژه‌های عمرانی
- مقدار ۲: پروژه‌های فناوری اطلاعات (IT)
- مقدار ۳: پروژه‌های تأسیسات
- تعریف مدیران سه دپارتمان در جدول مدیریت کاربران: در سیستم، سه کاربر تخصصی برای راهبری این حوزه‌ها ثبت و فعال شده‌اند:
user-1: مدیر پروژه‌های عمرانیuser-2: مدیر پروژه‌های ITuser-3: مدیر پروژه‌های تأسیسات
وضعیت اولیه دسترسی‌ها در پرتال کاربری
اگر با هر یک از این سه کاربر وارد سامانه شویم، مشاهده می‌کنیم که در پیشخوان «لیست گزارش‌ها» هیچ دسترسی به گزارش «لیست پروژه‌ها و اقلام» ندارند. هدف ما اعطای رونوشت به این مدیران است، به طوری که هر مدیر دقیقاً و منحصراً پروژه‌های مربوط به دپارتمان خود را مشاهده کند و امکان دستکاری فیلتر یا مشاهده پروژه‌های دپارتمان‌های دیگر را نداشته باشد.
کارگاه عملی: گام‌به‌گام پیش‌پیکربندی پارامترها در پنجره رونوشت
گام ۱: باز کردن پنجره رونوشت گزارش «لیست پروژه‌ها و اقلام»: از جدول مدیریت گزارش‌ها، بر روی آیکن رونوشت سطر گزارش کلیک می‌کنیم. همان‌طور که در تصویر زیر مشاهده می‌شود، پنجره رونوشت باز شده و در نیمه پایینی آن، بخشی با عنوان «عنوان پارامتر عنوان منبع داده: لیست پروژه‌ها (master)» نمایان است. سیستم به صورت خودکار پارامترهای ورودی تعریف‌شده روی منبع داده (در اینجا CategoryId) را شناسایی کرده و در جدول پارامترها قرار داده است:
گام ۲: باز کردن دراپ‌داون انتخاب کاربر گیرنده: رادیوباتن «کاربر» را انتخاب کرده و بر روی کادر انتخاب کاربر کلیک می‌کنیم تا فهرست کاربران فعال باز شود:
گام ۳: انتخاب مدیر پروژه‌های عمرانی (user-1): چک‌باکس سطر user-1 (مدیر پروژه‌های عمرانی) را فعال می‌کنیم تا به عنوان گیرنده رونوشت مشخص شود:
گام ۴: توقف قبل از کلیک روی «ارسال رونوشت» و رجوع به جدول پارامترها: پس از بسته شدن دراپ‌داون و قرار گرفتن نام کاربر در کادر گیرنده، بر روی دکمه «ارسال رونوشت» کلیک نمی‌کنیم! در این مرحله به بخش پایینی تنظیمات رونوشت یعنی جدول پارامترهای منبع داده گزارش رجوع می‌کنیم:
گام ۵: ورود به حالت ویرایش سطر پارامتر (Inline Edit): با کلیک بر روی آیکن مداد سبز رنگ (ویرایش ✏️) در ستون عملیات سطر CategoryId، سطر فعال شده و دکمه‌های ذخیره (💾 دیسکت آبی) و انصراف (❌ ضربدر قرمز) آشکار می‌شوند:
گام ۶: بررسی منوی کشویی «نوع مقدار»: با کلیک بر روی دراپ‌داون ستون «نوع مقدار»، چهار منبع استراتژیک برای مقداردهی به پارامتر نمایان می‌گردد:
تحلیل جامع ستون‌ها و مؤلفه‌های جدول پارامترهای رونوشت:
| نام ستون | نوع کنترل / المان UI | عملکرد و کاربرد در گزارش |
|---|---|---|
| عنوان پارامتر | برچسب متنی (ReadOnly) | نام پارامتر ورودی متصل به کوئری پایگاه داده منبع گزارش (در این مثال پارامتر CategoryId). لازم به ذکر است که یک گزارش می‌تواند انواع و اقسام پارامترهای مختلف عددی، متنی، تاریخی و انتخابی را در این جدول داشته باشد. |
| قابل تنظیم | چک‌باکس (Checkbox) | مشخص‌کننده امکان تغییر فیلتر توسط کاربر نهایی. اگر تیک آن فعال باشد، کاربر می‌تواند مقدار ارسالی ما را در پنل فیلترهای گزارش تغییر دهد. اما اگر تیک آن برداشته شود، پارامتر برای کاربر به صورت فقط‌خواندنی (ReadOnly) قفل شده و کاربر به هیچ عنوان قادر به تغییر آن نخواهد بود. |
| نوع مقدار | منوی کشویی (Dropdown) | منبع تغذیه مقدار پارامتر را مشخص می‌کند و شامل چهار گزینه است:
• مقدار ثابت: طراح یک مقدار ایستا و مشخص (مثلاً عدد ۱) را در ستون بعدی تایپ می‌کند. • کاربر جاری: مقدار پارامتر به صورت خودکار با شناسه کاربری (User ID) کاربر لاگین‌کرده پر می‌شود. • تاریخ جاری: مقدار پارامتر با تاریخ جاری شمسی سیستم مقداردهی می‌شود. • نقش جاری: مقدار پارامتر با شناسه نقش فعال کاربر در سشن جاری مقداردهی می‌شود. |
| مقدار | کادر ورودی / خودکار | اگر گزینه «مقدار ثابت» انتخاب شده باشد، طراح مقدار دلخواه خود را در این فیلد وارد می‌کند. اما اگر یکی از «مقادیر سیستمی» (کاربر جاری، تاریخ جاری، نقش جاری) انتخاب شود، این فیلد به صورت خودکار از ناحیه کاربری پر شده و کاملاً غیرفعال (Disabled) و خاکستری می‌شود. |
| قابل نمایش | چک‌باکس (Checkbox) | کنترل نحوه رندر پارامتر در پورتال کاربری. اگر تیک آن فعال باشد، فیلد پارامتر در هدر گزارش به کاربر نمایش داده می‌شود. اما اگر تیک آن برداشته شود (Hidden)، پارامتر کاملاً از دید کاربر پنهان می‌گردد؛ این ویژگی فوق‌العاده کاربردی برای زمان‌هایی است که مایل نیستیم کاربر نهایی اصلاً متوجه شود که در حال مشاهده گزارشی فیلترشده و محدودشده است. |
| عملیات | آیکن‌های اکشن سطر | شامل آیکن ذخیره (💾 دیسکت آبی) برای ثبت و تثبیت تنظیمات این پارامتر، انصراف (❌ ضربدر قرمز) برای لغو ویرایش و بازگشت به تنظیمات قبلی، و ویرایش (✏️ مداد سبز) برای ورود مجدد به حالت تغییر مقادیر. |
گام ۷: مقداردهی پارامتر CategoryId با گزینه عمرانی و ذخیره سطر: مقدار 1 (متناظر با پروژه‌های عمرانی) را در کادر مقدار وارد می‌کنیم. در این مرحله، بر روی آیکن ذخیره (💾 دیسکت آبی) کلیک می‌نماییم تا مقدار و تنظیمات پارامتر در حافظه موقت پنجره تثبیت گردد:
گام ۸: ارسال نهایی رونوشت فیلترشده به کاربر: پس از ذخیره شدن سطر پارامتر، سطر مجدداً به حالت عادی بازمی‌گردد و دکمه «ارسال رونوشت» در بالای پنجره فعال می‌گردد. با کلیک بر روی این دکمه، رونوشت به همراه فیلتر مقیدشده برای مدیر پروژه‌های عمرانی ثبت می‌شود:
گام ۹: انتقال خودکار به تب «رونوشت‌های ارسال شده»: سامانه به صورت خودکار بلافاصله پس از ثبت موفق رونوشت، شما را به تب «رونوشت‌های ارسال شده» هدایت می‌کند. در این تب، رکورد تفویض‌شده به مدیر پروژه‌های عمرانی به زیبایی در جدول قابل رؤیت است:
گام ۱۰: ورود با حساب مدیر پروژه‌های عمرانی (user-1) و بررسی پورتال کاربری: اکنون از حساب ادمین خارج شده و با حساب کاربری user-1 (مدیر پروژه‌های عمرانی) وارد سامانه می‌شویم. با ورود به منوی «لیست گزارش‌ها» (مسیر localhost/ReportList)، مشاهده می‌کنیم که گزارش «لیست پروژه‌ها و اقلام» به پیشخوان این مدیر اضافه شده است:
گام ۱۱: اجرای گزارش و بررسی مقداردهی خودکار پارامتر: با کلیک بر روی آیکن آبی‌رنگ «مشاهده» (چشم)، پنجره پیش‌نمایش گزارش باز می‌شود. به محض باز شدن پنجره، مشاهده می‌کنید که بدون نیاز به هیچ‌گونه دخالت یا انتخاب توسط کاربر، فیلد «دسته‌بندی موضوعی» به صورت خودکار مقدار «عمرانی» را به خود گرفته است:
بررسی نتیجه فعلی و گام بعدی: مخفی‌سازی و قفل‌کردن فیلتر
همان‌طور که دیدید، چون تیک «قابل نمایش» را زده بودیم، کاربر پارامتر دسته‌بندی را در بالای گزارش می‌بیند و چون تیک «قابل تنظیم» را هم زده بودیم، کاربر می‌تواند این پارامتر را باز کرده و در صورت تمایل تغییر دهد.
اما اگر اصلاً نخواهیم کاربر این پارامتر را ببیند و نخواهیم بتواند آن را دستکاری کند، کافی است دوباره به مودال رونوشت برگردیم، وارد تب «رونوشت‌های ارسال شده» شویم، رکورد کاربر را در حالت ویرایش باز کنیم و این دو تیک را برداریم تا گزارش بدون نمایش فیلتر و کاملاً قفل‌شده در اختیار کاربر قرار گیرد.
کارگاه عملی: مخفی‌سازی کامل پارامتر ورودی و قفل‌کردن فیلتر گزارش
گام ۱۲: بازگشت به پنجره رونوشت و کلیک بر روی ویرایش رکورد کاربر: برای ویرایش تنظیمات رونوشت مدیر پروژه‌های عمرانی، مجدداً از منوی مدیریت گزارش‌ها روی آیکن رونوشت سطر گزارش کلیک کرده و وارد تب دوم، یعنی «رونوشت‌های ارسال شده» می‌شویم. در این جدول، بر روی آیکن ویرایش سبز رنگ (✏️ - مشخص‌شده با کادر قرمز) در سطر کاربر کلیک می‌کنیم:
گام ۱۳: ورود به تب «ویرایش رونوشت» و انتخاب ویرایش سطر پارامتر: سامانه به تب «ویرایش رونوشت» سوئیچ می‌کند. نام مدیر پروژه‌های عمرانی به صورت ثابت نمایش داده شده است. اکنون برای تغییر دسترسی پارامتر، بر روی آیکن ویرایش سبز رنگ (✏️ - مشخص‌شده با کادر قرمز) در سطر پارامتر CategoryId کلیک می‌کنیم:
گام ۱۴: برداشتن تیک‌های «قابل تنظیم» و «قابل نمایش» و ذخیره سطر: اکنون تیک‌های دو ستون «قابل تنظیم» و «قابل نمایش» را برمی‌داریم (هر دو چک‌باکس با کادر قرمز مشخص شده‌اند) و سپس بر روی آیکن ذخیره سطر (💾) کلیک می‌کنیم:
نکته کاربردی درباره برداشتن تیک «قابل نمایش»
توجه داشته باشید که حتی اگر صرفاً تیک «قابل نمایش» را بردارید، پارامتر دیگر در هدر گزارش به کاربر نشان داده نمی‌شود؛ و زمانی که پارامتر اصلاً در صفحه کاربر ظاهر نشود، کاربر عملاً امکانی هم برای تغییر دادن یا دستکاری آن نخواهد داشت.
گام ۱۵: ثبت نهایی با کلیک روی دکمه «ویرایش رونوشت»: پس از ذخیره شدن سطر در جدول پایین، بر روی دکمه آبی‌رنگ «ویرایش رونوشت» در بالای پنجره سمت چپ کلیک می‌کنیم تا ویرایش رونوشت نهایی و در پایگاه‌داده ذخیره گردد:
گام ۱۶: نتیجه در پورتال کاربر (مخفی شدن کامل پارامتر ورودی): اکنون مجدداً به حساب کاربری مدیر پروژه‌های عمرانی بازمی‌گردیم و در منوی «لیست گزارش‌ها» روی آیکن «مشاهده» گزارش کلیک می‌کنیم. همان‌طور که در تصویر زیر به وضوح مشخص است، در بخش «جستجو در فرم» هیچ فیلتری نمایش داده نمی‌شود! فیلد دسته‌بندی موضوعی کاملاً از دید کاربر پنهان شده و با فشردن دکمه «پیش‌نمایش»، صرفاً پروژه‌های عمرانی در جدول بارگذاری می‌شوند:
گام ۱۷: بارگذاری خروجی جدول و ارزیابی داده‌ها: اکنون بر روی دکمه آبی‌رنگ «پیش‌نمایش» کلیک می‌کنیم. همان‌طور که در تصویر زیر به زیبایی مشاهده می‌شود:
- در ستون «عنوان دسته‌بندی»، تمام سطرهای خروجی بدون استثنا مقدار «عمرانی» دارند.
- در ستون «شناسه دسته‌بندی»، تمامی ردیف‌ها کد
1را نشان می‌دهند. - کاربر بدون اینکه متوجه اعمال فیلتری باشد یا امکانی برای تغییر آن داشته باشد، منحصراً پروژه‌های عمرانی سازمان را مرور می‌کند.
نگاه کلان مدیریتی: قدرت انعطاف و سناریومحور بودن سامانه رونوشت
سناریویی که در این کارگاه عملی بررسی کردیم، صرفاً یک نمونه با یک پارامتر بود؛ اما این ابزار یک راهکار راهبردی مدیریتی برای پیاده‌سازی انواع سناریوهای سازمانی است:
- تکرار آسان برای سایر حوزه‌ها: همین روال را برای مدیر پروژه‌های IT (دسته‌بندی IT) و مدیر پروژه‌های تأسیسات (دسته‌بندی تأسیسات) انجام می‌دهیم؛ بدین ترتیب هر سه مدیر با یک گزارش واحد، داده‌های اختصاصی دپارتمان خود را بررسی می‌کنند.
- سناریوهای مقیدسازی سیستمی (کاربر جاری): در گزارش‌هایی که ورودی آنها لیست کاربران یا کارشناسان ارجاع است، به جای مقدار ثابت، نوع مقدار را روی «کاربر جاری» می‌گذاریم؛ در نتیجه سیستم به صورت خودکار شناسه پرسنلی کاربر لاگین‌کرده را به گزارش ارسال می‌کند و هر کاربر صرفاً وظایف، درخواست‌ها یا پرونده‌های ثبت‌شده توسط خودش را مشاهده می‌نماید.
- سناریوهای سازمانی و نقشی: با بهره‌گیری از مقادیر سیستمی «نقش جاری» یا «تاریخ جاری»، می‌توان بدون پیچیدگی و بدون کدنویسی اضافی، گزارش‌هایی کاملاً پویا و متناسب با سمَت و تقویم کاری پرسنل توزیع کرد.
۸. پیکربندی سطوح دسترسی و اختیارات توسعه (ویژه توسعه‌دهندگان سیستم)
بر خلاف سامانه رونوشت که منحصراً برای کاربران نهایی و مصرف‌کنندگان خروجی طراحی شده است، «سطوح دسترسی گزارش (Report Permissions)» منحصراً در اختیار کاربران توسعه‌دهنده سیستم (System Developers / Report Designers)، تحلیلگران فرآیند و راهبران فنی قرار می‌گیرد تا بتوانند ساختار فنی و چرخه مهندسی گزارش را هدایت کنند.
تفکیک بنیادین معماری: رونوشت (کاربر نهایی) در برابر دسترسی توسعه (توسعه‌دهنده سیستم)
درک دقیق مرز عملیاتی میان این دو مفهوم، از نقض حریم امنیتی داده‌ها و تداخل وظایف در سازمان جلوگیری می‌کند:
| محور مقایسه | سامانه رونوشت گزارش (Transcript) | سطوح دسترسی گزارش (Permissions) |
|---|---|---|
| جامعه هدف | کاربران نهایی (End-Users)، کارشناسان اداری و مدیران مصرف‌کننده اطلاعات | کاربران توسعه‌دهنده سیستم (System Developers)، تحلیلگران داده و طراحان گزارش |
| پورتال و مدخل ورودی | پورتال کاربری «لیست گزارش‌ها» (ReportList) و ابزارک‌های میزکار سازمانی (Dashboards) |
ماژول تخصصی «گزارش‌ساز (Report Builder)» در زیرمنوی راهبر سیستم و استودیوی طراحی |
| دامنه اختیارات | صرفاً مشاهده رکوردهای پردازش‌شده، اعمال فیلترهای جست‌وجو، دریافت خروجی اکسل و چاپ | کدنویسی کوئری‌های SQL، افزودن فیلدهای محاسباتی، دیزاین قالب‌ها، کپی و حذف دائم گزارش |
| امنیت ساختار داده | عدم دسترسی به معماری پایگاه داده، شروط SQL، متادیتا یا تنظیمات استودیو | اختیار کامل تغییر مدل داده، پیکربندی پارامترهای دیتابیس و اعطای اختیارات به سایرین |
با کلیک روی آیکن چرخ‌دنده یا کلید، پنجره مجوزها باز می‌شود. پس از انتخاب کاربر یا نقش هدف، می‌توان مجوزهای تفکیک‌شده ده‌گانه زیر را به کاربر توسعه‌دهنده اختصاص داد:
| عنوان مجوز | دامنه عملکرد تخصصی توسعه‌دهنده |
|---|---|
| مشاهده گزارش | اجازه باز کردن گزارش در پیشخوان گزارش‌ساز و بررسی پیش‌نمایش داده‌ها. |
| ویرایش گزارش | اجازه ورود به استودیوی طراحی گزارش‌ساز جهت ویرایش کوئری‌های SQL، شروط و فیلدها. |
| کپی گزارش | امکان تولید نسخه همزاد و مستقل از گزارش به همراه تمام ساختارها و قالب‌های متصل. |
| رونوشت گزارش | اختیار تفویض رونوشت خروجی گزارش به کاربران نهایی و نقش‌های سازمانی. |
| تنظیمات سطوح دسترسی | اختیار تعیین و اصلاح مجوزهای ده‌گانه توسعه برای سایر کاربران و نقش‌ها. |
| مدیریت قالب چاپ (Stimulsoft) | طراحی، ویرایش و تنظیم قالب‌های چاپی رسمی گزارش در محیط استودیو پرینت Stimulsoft. |
| مدیریت قالب نمودار | ایجاد، پیکربندی و ویرایش انواع نمودارهای آماری، تحلیلی و روندنما (Chart Studio). |
| مدیریت قالب گالری | تنظیم، چیدمان و ویرایش کارت‌های تصویری، آلبوم و قالب‌های چندرسانه‌ای (Media Gallery). |
| مدیریت قالب مکان‌محور (GIS) | پیکربندی لایه‌های نقشه، عوارض مکانی، پین‌ها و اطلاعات جغرافیایی (GIS Map Studio). |
| حذف گزارش | اختیار حذف دائم گزارش و کلیه تعاریف وابسته به آن از پایگاه‌داده سازمان. |
تبیین معماری: انواع چهارگانه قالب‌های خروجی در GraphBPMS
در موتور گزارش‌ساز GraphBPMS، چهار استودیوی مستقل برای طراحی قالب‌های تخصصی تعبیه شده است: «قالب چاپ (Stimulsoft)»، «قالب نمودار»، «قالب گالری» و «قالب مکان‌محور (GIS)». پیشوند «چاپ» منحصراً ویژه قالب‌های چاپی Stimulsoft است و سایر قالب‌ها ماهیت مستقل تحلیلی، بصری و مکانی دارند.
پس از اعطای مجوزهای توسعه، کاربر می‌تواند از منوی اصلی وارد بخش گزارش‌ساز شده و گزارش را مدیریت نماید.
۹. ایجاد نسخه همزاد با عملیات کپی گزارش
با کلیک روی آیکن کپی، یک نسخه کامل و همزاد از گزارش (شامل منابع داده، فیلدها و قالب‌ها) با شناسه مستقل ساخته می‌شود:
- در پنجره بازشده، نوع مخاطب (کاربر یا نقش) و دریافت‌کننده را تعیین نمایید.
- گزینه ارسال کپی را بزنید.
۳. گزارش جدید با کد مجزا ثبت می‌شود. جهت دسترسی و ویرایش توسط کاربر مقصد، ثبت سطح دسترسی متناظر الزامی است.
۱۰. وضعیت آیکن اطلاع‌رسانی شرطی (Notification)
آیکن زنگوله (اطلاع‌رسانی) برای گزارش‌ها در حالت پیش‌فرض خاموش و غیرفعال است. به محض اینکه حداقل یک سناریوی اعلان وابسته به داده‌های گزارش در سیستم پیکربندی شود، این آیکن فعال و روشن می‌گردد (به رنگ نارنجی تغییر حالت می‌دهد).
پیوند مرتبط
جزئیات تعریف سناریوهای اعلان، شروط و قالب پیام در بخش [REPORT-01-01] مدیریت گزارش‌ها — Notification و اطلاع‌رسانی شرطی ارائه شده است.
۱۱. ویرایش ساختار و حذف امن گزارش
ویرایش گزارش
با کلیک روی آیکن مداد سبز، گزارش مستقیماً در استودیو با ساختار .../reportBuilderStudio?id={ReportID} بارگذاری می‌شود تا بتوان فیلدها، اتصالات منابع داده و قالب‌ها را بازتعریف یا اصلاح نمود.
حذف امن گزارش
با فشردن آیکن سطل زباله قرمز، جهت پیشگیری از خطای انسانی ابتدا دیالوگ تأیید باز می‌شود:
- در صورت انتخاب «خیر»، انصراف داده شده و رکوردی دست‌نخورده باقی می‌ماند.
- در صورت تأیید («بله»)، گزارش به همراه تمامی رونوشت‌ها، دسترسی‌ها و قالب‌های متصل به آن به‌صورت پایدار از سیستم حذف می‌گردد.
۱۲. ابزارهای پیشرفته جست‌وجو، فیلترینگ، گروه‌بندی و خروجی اکسل
جهت سهولت مدیریت فهرست گزارش‌ها، جعبه‌ابزار بالای جدول امکانات کارآمدی فراهم می‌سازد:
- گروه‌بندی ستونی (Group-by Box): امکان کشیدن سرستون‌ها به نوار بالایی جهت دسته‌بندی سلسله‌مراتبی گزارش‌ها بر مبنای یک ستون مشخص.
- جست‌وجوی سراسری: فیلتر بلادرنگ متن در تمام ستون‌های موجود جدول.
- فیلتر اختصاصی ستون‌ها: درج شروط جست‌وجوی دقیق روی مقادیر هر ستون.
- خروجی اکسل: دریافت فایل جامع رکوردهای گزارش‌ها با فرمت استاندارد
.xlsx. - تنظیم صفحه‌بندی: سوئیچ بین مقادیر نمایشی ۵، ۱۰، ۲۰ و ۵۰ ردیف در هر صفحه.
بخش دوم: کارگاه عملی — پیاده‌سازی سناریوی Master-Detail (از فرم تا ایجاد در پیشخوان)
اکنون که با کلیه مفاهیم، ستون‌ها، عملیات ردیفی و ابزارهای پیشخوان مدیریت گزارش‌ها آشنا شدید، در ادامه به عنوان یک کارگاه عملیاتی واقعی، سناریوی ساخت یک گزارش جامع سازمانی را از نقطه آغاز (طراحی فرم‌ها و ایجاد منابع داده مستقل و وابسته) تا ثبت قطعی در پیشخوان مدیریت و ورود به استودیو پیاده‌سازی می‌کنیم.
۱۳. سناریوی عملیاتی، فرم‌های مبنا و معماری Master-Detail (پروژه‌ها و صورت‌وضعیت‌ها)
در چرخه استقرار راهکارهای سازمانی در سامانه GraphBPMS، گزارش‌ساز یک لایه تحلیلی متکی بر داده‌های ثبت‌شده در فرم‌های الکترونیک است. برای آنکه یک گزارش سازمانی بتواند به‌صورت همزمان خروجی‌های گرید، نمودارهای پیشرفته، تحلیل‌های مکانی GIS، گالری تصاویر و اعلان‌های شرطی را پوشش دهد، طراحی فرم مبنا با ساختار فیلدهای مهندسی‌شده اهمیتی بنیادین دارد.
رویکرد آموزشی دانشنامه: گزارش ساده تک‌جدولی در برابر معماری پیشرفته Master-Detail
در سامانه GraphBPMS، طراحی و استقرار گزارش‌های ساده و مسطح تک‌جدولی (Flat Report) که صرفاً به یک جدول یا یک کوئری ساده متصل می‌شوند بسیار روان و متداول است. با این وجود، در این سناریوی عملیاتی عمداً و به‌صورت کاملاً هدفمند، معماری پیشرفته و چندمخزنی Master-Detail (ارتباط دوگانه والد و فرزند) مبنا قرار گرفته است؛ زیرا این الگو تمامی جنبه‌های پیچیده ساخت گزارش نظیر پارامترهای ورودی شرطی، کوئری‌های وابسته، تجمیع سطوح مختلف و ارتباطات رابطه‌ای را یکپارچه پوشش می‌دهد. طراح یا کارشناسی که ساخت گزارش بر اساس الگوی Master-Detail را فرا گیرد، ساخت هرگونه گزارش تک‌جدولی ساده را با تسلط کامل و بدون کوچک‌ترین چالش پیاده‌سازی خواهد کرد.
در سناریوی محوری این دانشنامه، از فرم الکترونیک «مشخصات پروژه» (موجودیت پایگاه داده GB_Project در فرم‌ساز) به عنوان فرم والد و شناسنامه مرکزی پروژه‌ها استفاده شده است.
دیکشنری داده‌ها و مشخصات ستون‌های فرم (Data Dictionary)
جدول زیر ساختار فنی و نقش تحلیلی تک‌تک ستون‌های فرم «مشخصات پروژه» را در گزارش‌ساز تشریح می‌کند:
| نام ستون | برچسب فارسی | نوع کنترل در فرم‌ساز | نوع داده در پایگاه‌داده | نقش و کاربرد در گزارش‌ساز و استودیوها |
|---|---|---|---|---|
ProjectCode |
کد پروژه | متنی کوتاه (TextBox) | NVARCHAR(50) |
شناسه سازمانی یکتا جهت جستجو، سورت و نمایش در ستون اول گرید |
ProjectTitle |
عنوان پروژه | متنی (TextBox) | NVARCHAR(250) |
عنوان نمایشی، محور متغیر (Argument) در نمودارهای میله‌ای و پاپ‌آپ نقشه |
CategoryId |
دسته‌بندی موضوعی | انتخابی (Selective — Static) | INT |
گروه‌بندی داده‌ها، فیلتر کشویی در نوار ابزار و تحلیل سهم در نمودار دایره‌ای |
StartDate |
تاریخ شروع | انتخابگر تقویم شمسی (DatePicker) | DATE / DATETIME |
فیلتر بازه زمانی تاریخ شروع پروژه‌ها در کوئری گزارش |
DueDate |
مهلت تحویل | انتخابگر تقویم شمسی (DatePicker) | DATE / DATETIME |
سنجش سررسید پروژه و فعال‌سازی آلارم‌های خودکار در نوتیفیکیشن شرطی |
BudgetAmount |
بودجه مصوب (ریال) | عددی (Numeric TextBox) | BIGINT |
محور مقادیر (Value) در نمودارها و محاسبه سرجمع کل بودجه (Sum Summary) |
ProgressPercent |
درصد پیشرفت | عددی با نوار پیشرفت (Range / Progress) | INT (0-100) |
بصری‌سازی شاخص کلیدی در نمودار عقربه‌ای (Gauge Chart) و ردیابی وضعیت |
SitePhoto |
تصویر شاخص پروژه | بارگذاری فایل (File Upload) | XML / ARCHIVE CODE |
استخراج آدرس تصویر برای تولید کارت‌های آلبومی در استودیوی گالری مدیا و درج واترمارک |
Coordinates |
موقعیت کارگاه/پروژه | کنترل نقشه جغرافیایی (Map Control) | NVARCHAR(MAX) [GeoJSON] |
تعیین نقاط مکانی، خوشه‌بندی پین‌ها و مسیریابی در استودیوی نقشه (GIS) |
تحلیل معماری فیلد انتخابی (Selective) و مقایسه جامع ۳ روش تأمین دیتا
در طراحی فرم مشخصات پروژه، فیلد «دسته‌بندی موضوعی» از نوع فیلد انتخابی (Selective) پیکربندی شده و روش تأمین دیتای آن روی «لیست ثابت (Static List)» قرار گرفته است. در پنجره مودال «مدیریت لیست داده»، سه گزینه موضوعی تعریف شده است:
- مقدار
1: عمرانی - مقدار
2: IT - مقدار
3: تأسیسات
در مهندسی فرم‌ها و گزارش‌های سامانه GraphBPMS، طراح برای فیلدهای انتخابی با ۳ الگوی متمایز روبه‌رو است که انتخاب نادرست آنها معماری گزارش‌ساز را با چالش مواجه می‌کند:
| روش تأمین دیتا | ماهیت فنی و ذخیره‌سازی | چه زمانی باید استفاده شود؟ | مزایا در گزارش‌ساز | محدودیت‌ها و ملاحظات |
|---|---|---|---|---|
| ۱. لیست ثابت (Static List) |
اقلام کلید و مقدار (Key-Value) مستقیماً درون شناسنامه فرم ذخیره می‌شوند و نیاز به هیچ جدول کمکی ندارند. | زمانی که گزینه‌ها محدود، ثابت، ایستا و از پیش‌تعیین‌شده باشند و در طول زمان دستخوش تغییر نشوند (مانند همین ۳ دسته اصلی پروژه‌ها یا انواع شیفت کاری). | سرعت واکشی آنی بدون سربار پایگاه‌داده؛ عدم نیاز به نوشتن دستورات JOIN در کوئری گزارش‌ساز. |
تغییر گزینه‌ها نیازمند ویرایش فیزیکی فرم در فرم‌ساز است؛ در دیتابیس کلید خارجی (Foreign Key) ایجاد نمی‌کند. |
| ۲. جدول اختیارات (Options) |
گزینه‌ها از جدول سیستمی و یکپارچه Options سامانه بر مبنای یک شناسه گروه (Group ID) واکشی می‌شوند. |
زمانی که یک فهرست استاندارد، در چندین فرم و فرآیند مختلف به صورت مشترک استفاده می‌شود (مانند مقاطع تحصیلی، وضعیت‌های تاهل، جنسیت). | یکپارچگی سراسری داده‌ها در پایگاه‌داده، پشتیبانی بومی از چندزبانی و ویرایش متمرکز مقادیر بدون تغییر فرم‌ها. | در کوئری گزارش‌ساز باید حتماً دستور LEFT JOIN Options O ON O.Id = T.Field نوشته شود تا متن فارسی نمایش یابد. |
| ۳. منبع داده پویا (Lookup Provider) |
گزینه‌ها حاصل اجرای زنده یک کوئری SQL یا Stored Procedure بر روی جداول عملیاتی دیگر سیستم هستند. | زمانی که گزینه‌ها پویا، متغیر، وابسته به شرط و دائماً در حال رشد هستند (مانند لیست پروژه‌های فعال، لیست کارمندان، لیست پیمانکاران طرف قرارداد). | پشتیبانی از کلیدهای خارجی واقعی (Relational FK)، امکان اعمال فیلترهای شرطی وابسته (Cascading) در فرم و گزارش. | نیاز به طراحی منبع داده مستقل در Provider Manager؛ ایجاد وابستگی و الزام به وجود ایندکس مناسب در جداول مقصد. |
فوت کوزه‌گری در گزارش‌ساز
هنگامی که از لیست ثابت در فرم استفاده می‌کنید، در کوئری منبع داده گزارش‌ساز برای تبدیل کدهای عددی ۱، ۲ و ۳ به عناوین فارسی می‌توانید از عبارت ساده CASE CategoryId WHEN 1 THEN N'عمرانی' WHEN 2 THEN N'IT' WHEN 3 THEN N'تأسیسات' END AS CategoryTitle استفاده کنید تا بدون نیاز به هیچ JOIN اضافی، ستون متنی دسته‌بندی با بالاترین کارایی واکشی شود.
فرم فرزند (Detail): اقلام هزینه و صورت‌وضعیت‌ها (موجودیت GB_Invoice)
در گزارش‌های تحلیلی پیشرفته، همواره با رابطه یک‌به‌چند (One-to-Many) میان موجودیت اصلی و اقلام زیرمجموعه روبه‌رو هستیم. برای نمونه، هر پروژه سازمانی دارای چندین صورت‌وضعیت و فاکتور هزینه است. به همین منظور، فرم الکترونیک دوم با عنوان «اقلام هزینه و صورت‌وضعیت‌ها» (موجودیت پایگاه داده GB_Invoice در فرم‌ساز) پیاده‌سازی شده است.
ستون‌های کلیدی فرم فرزند و نقش آنها در ایجاد رابطه والد-فرزند:
- شناسه پروژه والد: فیلد انتخابی با منبع داده از نوع «موجودیت سیستم» (System Entity) متصل به موجودیت فرم پروژه‌ها (
GB_Project). این فیلد نقش کلید ارتباطی (Foreign Key) را ایفا نموده و رکوردهای هزینه را به شناسه پروژه متناظر مقید می‌کند. - شرح صورت‌وضعیت: فیلد متنی جهت درج توضیحات تفصیلی اقلام هزینه (مانند «بتن‌ریزی فونداسیون»، «خرید تجهیزات شبکه»، «مشاوره فاز ۲»).
- رسته هزینه: فیلد انتخابی (Selective) پیاده‌سازی‌شده با روش «لیست ثابت (Static List)» شامل رسته‌های چهارگانه هزینه‌ای.
- مبلغ صورت‌وضعیت: فیلد عددی بزرگ (Numeric) بیانگر رقم فاکتور به ریال.
- تاریخ ثبت هزینه: تقویم شمسی ثبت سند مالی.
- وضعیت تایید مالی: کنترل چک‌باکس (Bit) برای فیلتر هزینه‌های مصوب در برابر اقلام در جریان بررسی.
کاربرد در نمودارهای پیشرفته Drill-Down
ترکیب فیلد کلید خارجی «شناسه پروژه والد» و فیلد «رسته هزینه» مبنای خلق گزارش‌های چند سطحی و ویژگی Drill-Down در [REPORT-05] استودیوی نمودار است؛ جایی که کاربر روی میله کل بودجه یک پروژه کلیک کرده و فوراً نمودار تفکیک رسته‌های هزینه‌ای (مصالح، دستمزد، تجهیزات) همان پروژه را مشاهده می‌کند.
۱۴. ساخت منابع داده Master و Detail و تحلیل کوئری‌های SQL در Provider Manager
ماژول گزارش‌ساز GraphBPMS به گونه‌ای طراحی شده است که داده‌های مورد نیاز خود را مستقیماً از جداول خام پایگاه‌داده استخراج نمی‌کند، بلکه از طریق یک لایه واسط و مطمئن به نام «منابع داده» (Data Providers) تغذیه می‌شود. این ساختار واسط به طراحان امکان می‌دهد بدون وابستگی مستقیم به تغییرات فیزیکی دیتابیس، داده‌ها را پالایش، فرمت‌بندی، فیلتر و تجمیع نموده و تحویل موتور گزارش دهند.
برای ایجاد و راهبری منابع داده، از منوی عمودی سمت راست، زیرمنوی مدیریت منابع اطلاعاتی و سپس گزینه «مدیریت منابع داده» (در آدرس localhost/Provider/ProviderManager) فراخوانی می‌شود.
در این سناریو، پیش از ساخت کوئری سفارشی، یک منبع داده از نوع «موجودیت سیستم» (System Entity) برای جدول فرم پروژه‌ها (GB_Project) ایجاد شده است که ساختار داده‌ای فرم، اتصالات فیزیکی و فیلدهای متادیتای سیستمی را استخراج می‌نماید:
۱۴.۱ ساخت منبع داده مستقل Master (اطلاعات پروژه‌ها)
با کلیک روی دکمه آبی‌رنگ «ایجاد منبع داده جدید» در بالای پیشخوان، فرآیند گام‌به‌گام ۵ مرحله‌ای آغاز می‌شود:
گام اول: اطلاعات منبع (انتخاب نوع منبع و پایگاه‌داده)
در تب اول، مشخصات شناسنامه‌ای تعیین می‌گردد:
- نوع منبع داده: انتخاب گزینه «پرس و جو (Query)» که اجازه نگارش مستقیم دستورات بهینه‌سازی‌شده SQL را فراهم می‌سازد.
- عنوان منبع داده: درج برچسب شفاف
Master — اطلاعات پروژه‌ها. - لیست بانک‌های اطلاعاتی: انتخاب پایگاه داده عملیاتی سامانه (
bpms).
گام دوم: مدیریت Query و تحلیل تفاوت ستون‌های سیستمی و بیزینسی
در تب دوم، محیط بصری طراحی کوئری (Query Designer) بارگذاری می‌شود. جدول مبنا یعنی GB_Project با نام مستعار P فراخوانی شده است. در اینجا یک اصل معماری بنیادین در پلتفرم GraphBPMS وجود دارد که طراحان سیستم و مدل‌های هوش مصنوعی (AI / Agents) باید دقیقاً به آن تسلط داشته باشند:
معماری ۹ ستون سیستمی مشترک در پلتفرم GraphBPMS و لزوم پرهیز از SELECT *
به صورت کلی، در معماری پایگاه داده GraphBPMS، برای تمامی جداول تولیدشده توسط موتور فرم‌ساز، ۹ ستون متادیتای سیستمی مشترک به صورت خودکار ایجاد و نگهداری می‌شوند:
| نام ستون سیستمی | نوع داده SQL | شرح و کاربرد در پلتفرم | وضعیت گزینش در کوئری منبع داده |
|---|---|---|---|
Id |
BIGINT IDENTITY |
کلید اصلی یکتای رکورد در فرم. | الزامی جهت گزینش (کلید ارتباطی Master-Detail) |
RegDate |
DATETIME |
تاریخ و زمان سیستمی ثبت اولیه رکورد. | صرف‌نظر (مگر در سناریوهای ممیزی و تاریخچه ثبت) |
FK_UserId |
BIGINT |
شناسه کاربر ثبت‌کننده اولیه رکورد. | صرف‌نظر (استفاده فقط در RLS / دسترسی سطری) |
FK_OrganizationId |
BIGINT |
شناسه واحد سازمانی / شعبه کاربر در زمان ثبت. | صرف‌نظر (استفاده در فیلتر ساختار سازمانی) |
LastModifiedFK_OrganizationId |
BIGINT |
شناسه واحد سازمانی کاربری که آخرین تغییر را اعمال کرده. | صرف‌نظر در گزارش‌های عمومی |
FK_RoleId |
BIGINT |
شناسه پست و نقش سازمانی ثبت‌کننده. | صرف‌نظر در گزارش‌های عمومی |
LastModifiedDate |
DATETIME |
تاریخ و زمان آخرین ویرایش رکورد. | صرف‌نظر در گزارش‌های عمومی |
LastModifiedFK_UserId |
BIGINT |
شناسه آخرین کاربر ویرایش‌کننده. | صرف‌نظر در گزارش‌های عمومی |
LastModifiedFK_RoleId |
BIGINT |
شناسه پست سازمانی آخرین ویرایش‌کننده. | صرف‌نظر در گزارش‌های عمومی |
چرا هنگام ایجاد منابع داده در گزارش‌ساز فقط ستون‌های مورد نیاز را گزینش می‌کنیم و از SELECT * پرهیز می‌کنیم؟
- افزایش چشمگیر کارایی (Query & Network Performance): واکشی ستون‌های سیستمی حجیم و متادیتایی که در داشبورد یا گزارش نقشی ندارند، بار پردازشی سرور SQL و ترافیک شبکه را بالا می‌برد.
- تمرکز و وضوح در استودیو (Report Builder Studio): هر ستونی که در بند
SELECTبیاید به عنوان یک فیلد مجزا در استودیوی ساخت گزارش ظاهر می‌شود. در صورت واکشی همه ستون‌ها (SELECT *)، استودیو با ده‌ها کارت غیرکاربردی شلوغ شده و کاربر گمراه می‌گردد؛ بنابراین طراح صرفاً ستون‌هایی که در خروجی‌های گزارش مورد نیاز است را از جدول انتخاب می‌کند. - امنیت داده و جلوگیری از افشای متادیتا: شناسه‌های سازمانی و دسترسی‌های داخلی نباید در خروجی‌های تحلیلی مدیریتی افشا شوند.
خروجی خام پایگاه داده (نمای مقایسه‌ای ستون‌های سیستمی و بیزینسی)
برای درک کامل این تفکیک و ارائه رفرنس دقیق برای تحلیلگران داده و مدل‌های هوش مصنوعی (AI)، در ادامه خروجی کامل و بدون فیلتر (SELECT *) هر دو جدول مبنا نمایش داده شده است تا تفاوت میان ستون‌های سیستمی خودکار و فیلدهای تجاری انتخابی ملموس باشد:
۱. جدول پروژه‌ها (جدول مستر: GB_Project)
این جدول شامل ۹ ستون سیستمی اولیه + ۹ ستون بیزینسی فرم‌ساز (شامل کد، عنوان، دسته‌بندی، تاریخ‌ها، بودجه، پیشرفت، آرشیو تصویر و موقعیت مکانی) است:
| ۹ ستون سیستمی مشترک GraphBPMS | ستون‌های بیزینسی فرم‌ساز پروژه (گزینش‌شده برای منبع داده) | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Id | RegDate | FK_UserId | FK_OrgId | LastModOrgId | FK_RoleId | LastModDate | LastModUserId | LastModRoleId | ProjectCode | ProjectTitle | CategoryId | StartDate | DueDate | BudgetAmount | ProgressPercent | SitePhoto | Coordinates |
1 |
2026-10-04 20:31:32 | 1 | 1 | NULL | 1 | 2026-10-04 20:31:32 | NULL | NULL | PRJ-101 |
احداث پست برق ۴۰۰ کیلوولت غرب | 1 | 2026-04-04 | 2027-01-20 | 50000000000 | 65 | <Files ArchiveCode="B65F81B6..."/> |
{"type":"Point","coordinates":[51.182041,35.713987]} |
2 |
2026-10-04 20:35:39 | 1 | 1 | NULL | 1 | 2026-10-04 20:35:39 | NULL | NULL | PRJ-102 |
توسعه زیرساخت مرکز داده و اتاق سرور | 2 | 2026-04-21 | 2026-11-06 | 25000000000 | 40 | <Files ArchiveCode="119C47AB..."/> |
{"type":"Point","coordinates":[51.334047,35.757141]} |
3 |
2026-10-04 20:37:47 | 1 | 1 | NULL | 1 | 2026-10-04 20:37:47 | NULL | NULL | PRJ-103 |
بهسازی تأسیسات سرمایشی ساختمان مرکزی | 3 | 2026-05-31 | 2026-12-11 | 15000000000 | 85 | <Files ArchiveCode="8297FD7F..."/> |
{"type":"Point","coordinates":[51.537552,35.756012]} |
۲. جدول صورت‌وضعیت‌ها و اقلام هزینه (جدول وابسته: GB_ProjectCostItem)
این جدول نیز شامل ۹ ستون سیستمی مشترک اولیه + ۶ ستون بیزینسی تعریف‌شده در فرم اقلام هزینه است که ستون FK_ProjectId نقش کلید خارجی به جدول پروژه‌ها را ایفا می‌کند:
| ۹ ستون سیستمی مشترک GraphBPMS | ستون‌های بیزینسی فرم‌ساز اقلام هزینه (ارتباطی Master-Detail) | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Id | RegDate | FK_UserId | FK_OrgId | LastModOrgId | FK_RoleId | LastModDate | LastModUserId | LastModRoleId | FK_ProjectId | ItemTitle | CostType | InvoiceAmount | InvoiceDate | IsApproved |
4 |
2026-10-04 20:40:58 | 1 | 1 | NULL | 1 | 2026-10-04 20:40:58 | NULL | NULL | 1 |
خرید میلگرد و بتن فونداسیون | 1 (مصالح) | 1,200,000,000 | 2026-05-10 | 1 (تأییدشده) |
5 |
2026-10-04 20:40:58 | 1 | 1 | NULL | 1 | 2026-10-04 20:40:58 | NULL | NULL | 1 |
دستمزد آرماتوربندی و قالب‌بندی فاز اول | 2 (دستمزد) | 650,000,000 | 2026-06-05 | 1 (تأییدشده) |
6 |
2026-10-04 20:40:58 | 1 | 1 | NULL | 1 | 2026-10-04 20:40:58 | NULL | NULL | 1 |
اجاره جرثقیل سنگین و پمپ بتن | 3 (تجهیزات) | 350,000,000 | 2026-07-01 | 1 (تأییدشده) |
7 |
2026-10-04 20:40:58 | 1 | 1 | NULL | 1 | 2026-10-04 20:40:58 | NULL | NULL | 2 |
خرید رک‌های سرور و کابل‌های فیبر نوری | 3 (تجهیزات) | 800,000,000 | 2026-05-21 | 1 (تأییدشده) |
8 |
2026-10-04 20:40:58 | 1 | 1 | NULL | 1 | 2026-10-04 20:40:58 | NULL | NULL | 2 |
خدمات مشاوره طراحی معماری امنیت شبکه | 4 (مشاوره) | 200,000,000 | 2026-06-25 | 1 (تأییدشده) |
9 |
2026-10-04 20:40:58 | 1 | 1 | NULL | 1 | 2026-10-04 20:40:58 | NULL | NULL | 3 |
خرید چیلرهای تراکمی و لوله‌کشی موتورخانه | 3 (تجهیزات) | 900,000,000 | 2026-07-10 | 1 (تأییدشده) |
10 |
2026-10-04 20:40:58 | 1 | 1 | NULL | 1 | 2026-10-04 20:40:58 | NULL | NULL | 3 |
دستمزد نصب و راه‌اندازی تأسیسات سرمایشی | 2 (دستمزد) | 300,000,000 | 2026-08-01 | 1 (تأییدشده) |
متن کوئری بهینه‌سازی‌شده منبع داده مستقل (Master)
دستور کامل SQL تنظیم‌شده در این منبع به شرح زیر است:
SELECT
P.Id,
P.ProjectCode,
P.ProjectTitle,
P.CategoryId,
CASE P.CategoryId
WHEN 1 THEN N'عمرانی'
WHEN 2 THEN N'IT'
WHEN 3 THEN N'تأسیسات'
ELSE N'نامشخص'
END AS CategoryTitle,
FORMAT(P.StartDate, 'yyyy/MM/dd', 'fa') AS StartDateShamsi,
FORMAT(P.DueDate, 'yyyy/MM/dd', 'fa') AS DueDateShamsi,
P.BudgetAmount,
P.ProgressPercent,
P.SitePhoto,
P.Coordinates
FROM [GB_Project] P
WHERE (@CategoryId IS NULL) OR (P.CategoryId = @CategoryId)
ORDER BY P.Id;مزایای برجسته این کوئری:
- تبدیل بومی تاریخ میلادی به شمسی: استفاده از تابع استاندارد
FORMAT(P.StartDate, 'yyyy/MM/dd', 'fa')مستقیماً در بانک اطلاعاتی، داده‌ها را به تقویم جلالی خوانا تبدیل می‌کند. - نگاشت عنوان لیست ثابت: عبارت
CASE P.CategoryId ...کدهای ۱، ۲ و ۳ را بدون نیاز به هیچ JOIN اضافی به عبارات فارسی تبدیل می‌نماید. - انعطاف شرط فیلتر با الگوی Or Null: شرط
WHERE (@CategoryId IS NULL) OR (P.CategoryId = @CategoryId)تضمین می‌کند که اگر کاربر در گزارش هیچ فیلتری انتخاب نکند، تمام پروژه‌ها لود شوند؛ اما به محض انتخاب یک دسته‌بندی، خروجی دقیقاً فیلتر گردد.
گام سوم: تعریف پارامترهای ورودی
در تب پارامترهای ورودی، پارامتر CategoryId که در شرط کوئری درج شده به صورت خودکار توسط سیستم شناسایی می‌شود. نوع مقداردهی روی «پویا» تنظیم شده و مقدار پیش‌فرض آن خالی رها می‌شود تا حالت اختیاری (Or Null) فعال بماند.
گام چهارم: تست پرس‌وجو و صحت‌سنجی رکوردهای واکشی‌شده
پیش از ذخیره قطعی، در تب تست، با کلیک روی دکمه آبی‌رنگ «تست پرس و جو» (در حالت خالی بودن پارامتر)، موتور اجرای کوئری فراخوانی شده و تمامی ۳ رکورد پروژه با ستون‌های فرمت‌شده، تاریخ‌های شمسی و ساختارهای XML و GeoJSON بدون فیلتر بازیابی می‌شوند:
نمونه جدول رکوردهای واکشی‌شده از منبع داده (Data Preview)
جدول زیر مقادیر واقعی بازیابی‌شده از پایگاه‌داده را نمایش می‌دهد که مبنای خروجی‌های بعدی ماژول گزارش‌ساز خواهد بود:
| Id | کد پروژه | عنوان پروژه | دسته | عنوان دسته | تاریخ شروع | مهلت تحویل | بودجه مصوب (ریال) | پیشرفت | فایل تصویر (SitePhoto) | مختصات جغرافیایی (Coordinates) |
|---|---|---|---|---|---|---|---|---|---|---|
1 |
PRJ-101 |
احداث پست برق ۴۰۰ کیلوولت غرب | ۱ | عمرانی | ۱۴۰۵/۰۱/۱۵ | ۱۴۰۵/۱۰/۳۰ | ۵۰,۰۰۰,۰۰۰,۰۰۰ | ۶۵٪ | <Files ArchiveCode="B65F81B6..." /> |
Point [51.182041, 35.713987] |
2 |
PRJ-102 |
توسعه زیرساخت مرکز داده و اتاق سرور | ۲ | IT | ۱۴۰۵/۰۲/۰۱ | ۱۴۰۵/۰۸/۱۵ | ۲۵,۰۰۰,۰۰۰,۰۰۰ | ۴۰٪ | <Files ArchiveCode="119C47AB..." /> |
Point [51.334047, 35.757141] |
3 |
PRJ-103 |
بهسازی تأسیسات سرمایشی ساختمان مرکزی | ۳ | تأسیسات | ۱۴۰۵/۰۳/۱۰ | ۱۴۰۵/۰۹/۲۰ | ۱۵,۰۰۰,۰۰۰,۰۰۰ | ۸۵٪ | <Files ArchiveCode="8297FD7F..." /> |
Point [51.537552, 35.756012] |
گام پنجم: بررسی لیست خروجی‌ها (فیلدها)
در تب «لیست خروجی‌ها (فیلدها)»، موتور پردازشگر منبع داده تمامی ۱۱ فیلد استخراج‌شده از بند SELECT کوئری را فهرست می‌کند که در استودیوی ساخت گزارش به عنوان کارت‌های مستقل خروجی ظاهر خواهند شد.
مراحل ۵ گانه پیکربندی منبع داده Master در پنجره راهبری (اسکرول افقی جهت مشاهده گام‌ها)
۵ مرحله پیکربندی
گام ۱: اطلاعات منبع
اطلاعات پروژه‌ها
تعیین نوع پرس‌وجو (Query)، نام‌گذاری منبع و اتصال به دیتابیس bpms
گام ۲: مدیریت Query
طراحی بصری
نگارش کوئری، فرمت تاریخ شمسی و شرط اختیاری @CategoryId
گام ۳: پارامترهای ورودی
پویا (Dynamic)
شناسایی خودکار پارامتر CategoryId با نوع مقداردهی پویا
گام ۴: تست پرس‌وجو
۳ رکورد
اجرای تست بدون ورودی و بازیابی ۳ رکورد پروژه با ستون‌های کامل
گام ۵: لیست خروجی‌ها
۱۱ فیلد
تثبیت ۱۱ فیلد محاسباتی و بیزینسی خروجی جهت انتقال به استودیو
تثبیت منبع داده مستقل Master
منبع داده مستقل پروژه‌ها (Master) با موفقیت ذخیره گردید و آماده انتساب به گزارش اصلی شد.
۱۴.۲ ساخت منبع داده وابسته Detail (صورت‌وضعیت‌ها و اقلام هزینه)
منبع داده دوم در معماری دو سطحی ما، وظیفه واکشی رکوردهای ریزهزینه و صورت‌وضعیت‌ها از جدول GB_ProjectCostItem را بر عهده دارد. ویژگی کلیدی این منبع، دارا بودن یک پارامتر ورودی وابسته (@ProjectId) است که به آن اجازه می‌دهد هم به صورت مستقل و هم به عنوان منبع فرزند متصل به منبع مستر (Master-Detail) در قالب‌های چاپ، نمودارهای مته‌ای (Drill-Down) و پیشخوان‌ها عمل نماید.
گام اول: اطلاعات منبع (انتخاب نوع منبع و پایگاه‌داده)
مشخصات شناسنامه‌ای منبع داده فرزند به صورت زیر تکمیل می‌شود:
- نوع منبع داده: انتخاب گزینه «پرس و جو (Query)».
- عنوان منبع داده: درج برچسب استاندارد
Detail — صورت‌وضعیت‌ها و اقلام هزینه. - لیست بانک‌های اطلاعاتی: انتخاب پایگاه‌داده عملیاتی سامانه (
bpms).
پیوندیار: تنوع انواع منابع داده در پلتفرم GraphBPMS
اگرچه در این سناریوی عملیاتی از نوع منبع «پرس و جو (Query)» استفاده شده است، پلتفرم GraphBPMS از انواع متنوع دیگری از منابع داده نیز پشتیبانی می‌کند:
- پرس و جو (Query): نگارش مستقیم دستورات بهینه‌سازی‌شده SQL با شروط پویا، نگاشت و توابع سفارشی.
- روال‌های ذخیره‌شده (Stored Procedure): فراخوانی پروسیدجرهای پیچیده پایگاه داده همراه با پارامترهای ورودی/خروجی جهت پردازش‌های محاسباتی سنگین.
- موجودیت‌های سیستمی (System Entities): اتصال مستقیم و بدون نیاز به کوئری به جداول فرم‌ها، کاربران، چارت سازمانی و نقش‌ها (مشابه آنچه در فیلد انتخابی فرم اقلام هزینه استفاده شد).
- سرویس‌های وب (Web Services / REST API): واکشی برخط داده‌ها از سامانه‌های یکپارچه‌شده بیرونی (نظیر نرم‌افزارهای مالی، انبارداری، ERP و پورتال‌های دولتی).
(جهت آشنایی تفصیلی با تنظیمات پروتکل‌ها، احراز هویت سرویس‌ها و نگاشت داده‌ها، به مستند جامع ماژول «مدیریت منابع اطلاعاتی» مراجعه فرمایید).
گام دوم: مدیریت Query و نگارش کوئری وابسته به کلید والد
در تب دوم، جدول مبنا یعنی GB_ProjectCostItem با نام مستعار C فراخوانی شده و دستور SQL با گزینش هوشمندانه صرفاً ستون‌های مورد نیاز تنظیم می‌شود:
متن کوئری بهینه‌سازی‌شده منبع داده وابسته (Detail)
دستور کامل SQL تنظیم‌شده در این منبع به شرح زیر است:
SELECT
C.Id,
C.FK_ProjectId,
C.ItemTitle,
C.CostType,
CASE C.CostType
WHEN 1 THEN N'مصالح'
WHEN 2 THEN N'دستمزد'
WHEN 3 THEN N'تجهیزات'
WHEN 4 THEN N'مشاوره'
ELSE N'سایر'
END AS CostTypeName,
C.InvoiceAmount,
FORMAT(C.InvoiceDate, 'yyyy/MM/dd', 'fa') AS InvoiceDateShamsi,
C.IsApproved,
CASE C.IsApproved
WHEN 1 THEN N'تأیید شده'
ELSE N'در انتظار تأیید'
END AS ApprovalStatusTitle
FROM [GB_ProjectCostItem] C
WHERE (@ProjectId IS NULL) OR (C.FK_ProjectId = @ProjectId)
ORDER BY C.Id;تحلیل فنی و محاسباتی ستون‌های کوئری فرزند:
- کلید ارتباطی والد-فرزند (
C.FK_ProjectId): ستون پیونددهنده رکوردهای هزینه به شناسه پروژه در جدول مستر. - ترجمه کدهای لیست ثابت به عناوین معنادار (
CostTypeName): تبدیل کدهای عددی ۱ تا ۴ به اسامی فارسی رسته هزینه بدون نیاز به برقراری JOIN سنگین. - قالب‌بندی تاریخ شمسی جلالی (
InvoiceDateShamsi): با تابعFORMAT(C.InvoiceDate, 'yyyy/MM/dd', 'fa')جهت نمایش مستقیم در گزارش بدون پردازش سمت کلاینت. - برچسب وضعیت اعتبارسنجی مالی (
ApprovalStatusTitle): تبدیل فیلد بولیIsApproved(۰ و ۱) به عناوین گویای «تأیید شده» و «در انتظار تأیید». - الگوی رفتاری شرط اختیاری (
WHERE (@ProjectId IS NULL) OR ...): اگر پارامتر@ProjectIdمقداری دریافت نکند (مانند پیش‌نمایش کلی یا گزارش تلفیقی تمام هزینه‌ها)، تمامی ۷ رکورد صورت‌وضعیت بدون مانع بازیابی می‌شوند؛ اما هرگاه این منبع در داخل قالب چاپ یا نمودار به پروژه مشخصی متصل گردد، مقدار کلیدP.Idدر این پارامتر نشسته و کوئری فوراً تنها اقلام مرتبط با همان پروژه خاص را بازمی‌گرداند.
گام سوم: تعریف پارامترهای ورودی (ProjectId)
در تب پارامترهای ورودی، پارامتر ProjectId به صورت هوشمند از بند WHERE استخراج شده است:
- نوع مقداردهی: روی گزینه «پویا» تنظیم شده تا بتواند در سناریوهای Master-Detail، مقدار کلید پروژه انتخاب‌شده را به صورت دینامیک از کوئری مستر دریافت کند.
- مقدار پیش‌فرض: خالی رها می‌شود تا شرط Or Null همواره فعال بماند.
گام چهارم: تست پرس‌وجو و صحت‌سنجی رکوردهای واکشی‌شده
در تب تست، با خالی گذاشتن فیلد پارامتر ProjectId و کلیک روی دکمه آبی‌رنگ «تست پرس و جو»، شرط @ProjectId IS NULL فعال شده و تمام ۷ رکورد موجود در دیتابیس بدون هیچ فیلتری بازیابی می‌شوند:
جدول پیش‌نمایش خروجی تست منبع داده Detail (۷ رکورد صورت‌وضعیت)
داده‌های خروجی تست که در پایگاه‌داده ثبت و بازیابی شده‌اند به شرح جدول زیر هستند:
| Id | FK_ProjectId | شرح صورت‌وضعیت (ItemTitle) | کد رسته | عنوان رسته (CostTypeName) | مبلغ صورت‌وضعیت (ریال) | تاریخ ثبت (شمسی) | وضعیت تایید | عنوان وضعیت تایید مالی |
|---|---|---|---|---|---|---|---|---|
4 |
1 |
خرید میلگرد و بتن فونداسیون | ۱ | مصالح | ۱,۲۰۰,۰۰۰,۰۰۰ | ۱۴۰۵/۰۲/۲۰ | ✔ | تأیید شده |
5 |
1 |
دستمزد آرماتوربندی و قالب‌بندی فاز اول | ۲ | دستمزد | ۶۵۰,۰۰۰,۰۰۰ | ۱۴۰۵/۰۳/۱۵ | ✔ | تأیید شده |
6 |
1 |
اجاره جرثقیل سنگین و پمپ بتن | ۳ | تجهیزات | ۳۵۰,۰۰۰,۰۰۰ | ۱۴۰۵/۰۴/۱۰ | ✔ | تأیید شده |
7 |
2 |
خرید رک‌های سرور و کابل‌های فیبر نوری | ۳ | تجهیزات | ۸۰۰,۰۰۰,۰۰۰ | ۱۴۰۵/۰۲/۳۱ | ✔ | تأیید شده |
8 |
2 |
خدمات مشاوره طراحی معماری امنیت شبکه | ۴ | مشاوره | ۲۰۰,۰۰۰,۰۰۰ | ۱۴۰۵/۰۴/۰۴ | ✔ | تأیید شده |
9 |
3 |
خرید چیلرهای تراکمی و لوله‌کشی موتورخانه | ۳ | تجهیزات | ۹۰۰,۰۰۰,۰۰۰ | ۱۴۰۵/۰۴/۱۹ | ✔ | تأیید شده |
10 |
3 |
دستمزد نصب و راه‌اندازی تأسیسات سرمایشی | ۲ | دستمزد | ۳۰۰,۰۰۰,۰۰۰ | ۱۴۰۵/۰۵/۱۰ | ✔ | تأیید شده |
گام پنجم: بررسی لیست خروجی‌ها (فیلدها)
در تب «لیست خروجی‌ها (فیلدها)»، موتور پردازشگر منبع داده ۹ فیلد قطعی را شناسایی کرده است که در ادامه استودیوهای گزارش‌ساز، قالب چاپ، و نمودارها به عنوان المان‌های قابل نمایش و فیلتر مورد استفاده قرار می‌گیرند.
مراحل ۵ گانه پیکربندی منبع داده Detail در پنجره راهبری (اسکرول افقی جهت مشاهده گام‌ها)
۵ مرحله پیکربندی
گام ۱: اطلاعات منبع
صورت‌وضعیت‌ها
تعیین نوع پرس‌وجو (Query)، نام‌گذاری منبع و اتصال به دیتابیس bpms
گام ۲: مدیریت Query
طراحی بصری
نگارش کوئری، گزینش ستون‌ها، توابع CASE رسته و شرط @ProjectId
گام ۳: پارامترهای ورودی
پویا (Dynamic)
شناسایی پارامتر ProjectId با نوع پویا جهت اتصال به کلید پروژه مستر
گام ۴: تست پرس‌وجو
۷ رکورد
اجرای تست بدون ورودی و بازیابی تمامی ۷ رکورد صورت‌وضعیت
گام ۵: لیست خروجی‌ها
۹ فیلد
تثبیت ۹ فیلد محاسباتی و تجاری خروجی جهت انتقال به استودیو
نمای شاخص تمام‌صفحه: مشخصات و جزئیات تجمیعی منبع داده Detail
در آخرین مرحله، تب «خروجی» کارت جامع شناسنامه منبع داده را نمایش می‌دهد که در یک نگاه کلی، عنوان منبع، نوع پرس‌وجو، متن یکپارچه SQL، لیست پارامترها و تمامی فیلدهای استخراج‌شده را تأیید و با فشردن کلید آبی‌رنگ «ذخیره» در سامانه تثبیت می‌نماید:
تکمیل چرخه زیرساخت داده‌ای Master-Detail
با استقرار موفقیت‌آمیز دو منبع داده مستقل (اطلاعات پروژه‌ها — Master) و وابسته (صورت‌وضعیت‌ها و اقلام هزینه — Detail)، اکنون بستر داده‌ای لازم برای کلیه استودیوهای سامانه اعم از جدول گرید، نمودارهای Drill-Down، قالب‌های چاپ دوسطحی و نقشه‌های تعاملی GIS به طور کامل و اصولی مهیا گردیده است.
۱۵. ایجاد گزارش در پیشخوان مدیریت با منبع داده منتخب و ورود به استودیو
پس از ساخت و تثبیت منابع داده در Provider Manager، راهبر سیستم مجدداً به پیشخوان مدیریت گزارش‌ها (زیرمنوی راهبر سیستم ← گزارش‌ساز) بازمی‌گردد:
- روی دکمه «ایجاد گزارش جدید» کلیک نمایید.
- در فرم اولیه، عنوان گزارش را «پایش و مدیریت پروژه‌های سازمانی» درج کنید.
- در منوی کشویی منبع داده، منبع داده ساخته‌شده
Master — اطلاعات پروژههارا انتخاب نمایید. - با کلیک بر روی «ذخیره و ورود به استودیو»، رکورد گزارش در جدول مدیریت ثبت شده و محیط استودیوی طراحی گزارش (Studio) جهت چیدمان کارت‌ها و ستون‌ها باز می‌شود.
گام بعدی: ورود به استودیوی ساخت گزارش (Studio)
سرفصل بعدی در دانشنامه: جهت ادامه آموزش، به مستند «[REPORT-02] استودیوی ساخت گزارش (Studio)» مراجعه فرمایید.
۱۶. توزیع گزارش‌ها در میزکارهای سازمانی (Dashboards) و پورتال «لیست گزارش‌ها» از طریق سامانه رونوشت
یکی از ارکان معماری نرم‌افزار در GraphBPMS، پیوند عمیق و هوشمند میان محیط توسعه گزارش‌ها (Report Builder) و فضای میزکارهای سازمانی (Workspaces / Dashboards) است. در سازمان‌های متوسط و بزرگ که صدها گزارش عملیاتی با خروجی‌های چندگانه اعم از جداول داده‌ای، نقشه‌های مکانی GIS، نمودارهای تحلیلی، قالب‌های چاپ و گالری‌های تصویری تولید می‌شود، کاربران نهایی نباید درگیر پیچیدگی‌های فنی استودیو یا کدهای منبع داده شوند؛ بلکه باید بتوانند در ساده‌ترین و امن‌ترین حالت ممکن از طریق میزکار شخصی یا پورتال کاربری به خروجی‌های مجاز خود دسترسی داشته باشند.
۱۶-۱. تمایز بنیادین میان پیشخوان طراحی گزارش‌ساز و پورتال کاربری «لیست گزارش‌ها»
در ساختار منوهای سیستم GraphBPMS، دو مدخل متمایز برای تعامل با گزارش‌ها پیش‌بینی شده است که درک تفاوت آنها پیش‌نیاز تسلط بر معماری سامانه است:
| ویژگی / بستر | گزارش‌ساز (Report Builder) | لیست گزارش‌ها (Reports List / پورتال کاربر) |
|---|---|---|
| مسیر دسترسی | منوی اصلی ← پیکربندی سیستم / راهبر سیستم ← گزارش‌ساز | منوی اصلی ← لیست گزارش‌ها (پایین‌تر از گزارش‌ساز) |
| جامعه مخاطبان | توسعه‌دهندگان، تحلیلگران فرآیند و مدیران ارشد سیستم | کلیه کاربران نهایی، کارشناسان اداری و مدیران واحدهای عملیاتی |
| هدف عملکردی | طراحی منابع داده SQL، استودیوی ساخت، تعریف قالب‌های چاپ و فرمول‌سازی | مشاهده، پالایش، فیلترگذاری و چاپ خروجی‌های تخصیص‌یافته |
| پایه‌ریزی امنیتی | نیازمند مجوزهای دسترسی سطح ادمین و توسعه پایگاه داده | تابع محض سیاست‌های امنیتی «رونوشت» و دسترسی‌های نقش‌محور |
هنگامی که یک کاربر نهایی یا حتی خود راهبر سیستم وارد منوی «لیست گزارش‌ها» می‌شود، ممکن است در ابتدا با یک جدول کاملاً خالی مواجه شود، در حالی که در محیط گزارش‌ساز ده‌ها گزارش فعال وجود دارد:
اصل محرمانگی پیش‌فرض و فلسفه معماری «رونوشت»
در مهندسی امنیتی GraphBPMS، صرف ایجاد یک گزارش در استودیو به معنای انتشار عمومی آن در سازمان نیست. تا زمانی که توسعه‌دهنده گزارش به طور صریح اقدام به تفویض رونوشت (Report Dispatching) به یک کاربر مشخص یا نقش سازمانی ننماید، داده‌های گزارش در هیچ پورتال یا میزکاری قابل مشاهده نخواهد بود. این رویکرد ضامن انطباق کامل با استانداردهای حاکمیت داده (Data Governance) و عدم نشت اطلاعات حساس میان دوایر مختلف سازمان است.
۱۶-۲. کارگاه عملی تفویض رونوشت خروجی جدولی (Tabular Output Dispatch)
تفویض رونوشت خروجی استاندارد گزارش، امکان اجرای پیش‌نمایش جدول داده‌ها را به کاربر نهایی واگذار می‌کند. این فرآیند طبق گام‌های زیر انجام می‌پذیرد:
- در پیشخوان گزارش‌ساز، سطر گزارش مورد نظر (به عنوان نمونه گزارش «آموزش اطلاعات کاربر ثبت نامی») را یافته و روی آیکن «رونوشت خروجی جدولی» در ستون عملیات کلیک کنید:
- پنجره پاپ‌آپ «رونوشت گزارش» باز می‌شود. این مودال شامل دو زبانه اصلی است:
- رونوشت جدید: فرم پیکربندی و اعطای رونوشت به تفکیک کاربر یا نقش سازمانی.
- رونوشت‌های ارسال شده: فهرست رونوشت‌های معتبر پیشین با امکان حذف یا ابطال.
NationalCode) را مشخص کنید (تثبیت مقدار پیش‌فرض، قابلیت ویرایش توسط گیرنده یا وضعیت قابل نمایش):
- با کلیک روی منوی کشویی انتخاب مخاطب، جدول فهرست کاربران سامانه لود می‌شود. کاربر مورد نظر (مثلاً «راهبر سیستم — rahbar») را تیک زده و دکمه «ارسال رونوشت» را بفشارید:
- با ثبت موفق عملیات، در تب «رونوشت‌های ارسال شده» یک رکورد جدید به نام کاربر جاری ثبت می‌گردد:
۱۶-۳. تفویض مستقل و چندسطحی انواع قالب‌های خروجی (چاپ، نقشه مکانی، نمودار)
یکی از قدرتمندترین قابلیت‌های پلتفرم GraphBPMS، تفکیک‌پذیری کامل سیاست‌های رونوشت به ازای انواع قالب‌ها است. بدین معنی که توسعه‌دهنده گزارش مجبور نیست تمامی خروجی‌های یک گزارش را یکجا در اختیار کاربر بگذارد، بلکه می‌تواند خروجی قالب چاپ را به یک واحد، نقشه GIS را به واحد دیگر و نمودارهای آماری را به مدیران میانی رونوشت دهد:
بج عددی (Badge Counter) روی آیکن‌های قالب‌های گزارش
در ستون «قالب‌های گزارش»، چنانچه برای هر قالب خروجی (قالب چاپ، نمودار، نقشه مکانی، گالری) قالبی طراحی و ذخیره شده باشد، یک نشانگر عددی آبی‌رنگ روی آیکن آن قرار می‌گیرد که تعداد قالب‌های فعال را نمایش می‌دهد. با کلیک مستقیم روی این آیکن، پنجره مدیریت همان نوع قالب و عملیات رونوشت اختصاصی آن فراخوانی می‌شود.
در ادامه، فرآیند اعطای رونوشت برای سه فرمت خروجی متفاوت به تصویر کشیده شده است:
الف) رونوشت خروجی قالب چاپ (Print Template):
در گزارش «اطلاعات کاربر ثبت نام شده»، با کلیک بر روی آیکن قالب چاپ دارای بج عددی ۱، پنجره مدیریت قالب‌های چاپ باز شده و خروجی آن به کاربر راهبر سیستم رونوشت داده می‌شود:
ب) رونوشت خروجی نقشه مکانی (GIS Map):
در گزارش «درمانگاه‌های مشهد»، آیکن قالب نقشه دارای بج ۱ است. با کلیک روی آن و انتخاب اکشن رونوشت قالب نقشه، این لایه مکانی به حساب کاربری راهبر سیستم تفویض می‌گردد:
ج) رونوشت خروجی نمودارهای تحلیلی (Analytical Charts):
در گزارش «فراوانی جنسیت»، آیکن قالب نمودار نشان‌دهنده یک نمودار فعال است. در زبانه رونوشت‌های ارسال‌شده این قالب مشاهده می‌شود که پیش از این برای نقش سازمانی «کارشناس» رونوشت صادر شده و اکنون رونوشت جدیدی برای «راهبر سیستم» نیز ثبت می‌گردد:
۱۶-۴. پورتال کاربری «لیست گزارش‌ها» و تعاملات هوشمند (Action on Hover)
اکنون که رونوشت‌های گوناگون اعم از جدولی، نقشه، نمودار و چاپ صادر گردید، با بازگشت به زیرمنوی «لیست گزارش‌ها»، جدول خروجی‌ها با رکوردهای واگذارشده لود می‌شود:
ساختار چهارگانه ستون‌های جدول پرتال کاربری به شرح زیر است:
| ستون | ماهیت داده و مفهوم عملیاتی |
|---|---|
| عنوان | نام گزارش اصلی به همراه عنوان زیرمجموعه قالب خروجی (مشخص‌شده با فلش بازگشتی و نام والد). |
| نوع | فرمت دقیق خروجی شامل آیکن گرافیکی اختصاصی (جدولی، نقشه، نمودار، قالب چاپ، گالری تصاویر). |
| دسترسی | هویت کاربری صادرکننده رونوشت و سیاست امنیتی مرتبط با آن. |
| تاریخ ثبت | تاریخ دقیق اعطای رونوشت به کاربر یا نقش. |
الگوی تعاملی اکشن بر روی هاور (Action on Hover)
به منظور جلوگیری از شلوغی بصری جدول و بهبود تجربه کاربری (UX) برای پرسنل سازمان، دکمه‌های عملیاتی نظیر دکمه «مشاهده» در حالت عادی پنهان هستند. با قرار گرفتن نشانگر ماوس (Hover) بر روی هر سطر، آیکن آبی‌رنگ «مشاهده» (چشم) در انتهای سطر آشکار می‌گردد. با کلیک بر روی آن، خروجی در یک تب یا پنجره مستقل باز می‌شود.
اجرای مستقل خروجی نقشه GIS توسط کاربر نهایی:
با حرکت ماوس روی سطر خروجی نقشه درمانگاه‌ها، آیکن مشاهده پدیدار شده و با کلیک روی آن، پنجره رونوشت نقشه در تب جدید مرورگر اجرا می‌شود. در این محیط، کاربر می‌تواند فیلترهای مکانی را اعمال کرده و بر روی نقشه تعاملی لایه‌ها را بررسی کند:
اجرای مستقل خروجی جدولی و داده‌های تودرتوی Master-Detail:
به همین ترتیب، با هاور بر روی سطر خروجی جدولی و کلیک بر روی آیکن مشاهده، پیش‌نمایش خروجی جدولی در پورتال کاربری بارگذاری می‌شود. توجه داشته باشید که ساختار تودرتوی منابع (Master-Detail) در سایدبار راست برای کاربر نهایی نیز در دسترس است و پارامترهای فیلتر کدملی به زیبایی رندر می‌گردند:
۱۶-۵. یکپارچه‌سازی راهبردی با میزکارهای سازمانی (Workspaces / Dashboards)
اگرچه دسترسی به خروجی‌ها از طریق منوی «لیست گزارش‌ها» فراهم است، اما در استانداردهای پیشرفته تجربه کاربری (Enterprise UX)، مدیران و کارشناسان ترجیح می‌دهند به محض ورود به سامانه، تمام گزارش‌ها و پایش‌های خود را مستقیماً روی میزکار اصلی (Dashboard) مشاهده کنند. پلتفرم GraphBPMS از طریق «ویجت ماژول گزارشات» این اتصال ارگانیک را محقق ساخته است.
گام ۱: ورود به کنسول مدیریت میزکارها از صفحه اصلی
در صفحه اصلی سامانه، میزکارهای مختلف در قالب زبانه‌ها (تب‌ها) قرار دارند. در گوشه بالا سمت چپ نوار تیره سربرگ، آیکن آبی‌رنگ چرخ‌دنده (مدیریت میزکار) تعبیه شده است:
گام ۲: ایجاد و طراحی میزکار جدید
با کلیک روی چرخ‌دنده، صفحه «مدیریت میزکار» لود می‌شود. در این جدول کلیه میزکارهای سازمان، وضعیت انتشار، گروه‌بندی و مجازین دسترسی ثبت شده است. برای طراحی تب جدید، بر روی دکمه آبی‌رنگ «طراحی میزکار جدید» در بالا سمت چپ کلیک کنید:
گام ۳: استودیوی طراحی تب میزکار و انتخاب ویجت «گزارشات»
محیط استودیوی ساخت میزکار باز می‌شود. در این محیط توسعه‌دهنده می‌تواند با افزودن ویجت‌ها، رابط بصری پیشخوان کاربر را چیدمان کند. در منوی تنظیمات ویجت، دراپ‌داون «لیست ماژول‌ها» را باز کرده و گزینه «گزارشات» را برگزینید:
رفتار داینامیک ویجت گزارشات (Smart Fallback)
همان‌طور که در راهنمای پنجره تنظیمات درج گردیده است: «در صورت انتخاب نکردن گزارش خاص، لیست کلیه گزارش‌های مجاز کاربر در ویجت نمایش داده خواهد شد.» این ویژگی سبب می‌شود ویجت گزارشات یک کامپوننت هوشمند و خودتنظیم باشد؛ یعنی به محض اعطای هر رونوشت جدید به کاربر، جدول ویجت در میزکار او بدون نیاز به تغییر در طراحی، بلادرنگ به‌روزرسانی شود.
پس از فشردن دکمه ذخیره، کامپوننت گزارش‌ها در بدنه صفحه قرار گرفته و خروجی‌های چهارگانه رونوشت‌شده را به صورت زنده نمایش می‌دهد. سپس بر روی دکمه «ذخیره» در نوار ابزار بالا کلیک کنید:
گام ۴: ثبت رکورد میزکار و تخصیص سطح انتشار
پس از ذخیره، رکورد میزکار جدید با عنوان «گزارشات» در گروه فرآیندی مربوطه ثبت می‌شود. وضعیت «انتشار یافته» تیک خورده و مشخص است که برای کاربر جاری مجاز و فعال می‌باشد:
گام ۵: نتیجه نهایی — دسترسی تک‌کلیکی به گزارش‌ها در پیشخوان سازمان
با بازگشت به صفحه اول سامانه GraphBPMS، زبانه جدید «گزارشات» در هدر میزکارهای فعال افزوده شده است. کاربر با کلیک روی این تب، بلافاصله کل گزارش‌ها و قالب‌های تحلیلی خود را در مرکز صفحه با امکان اجرای سریع و بدون واسطه دریافت می‌نماید:
جمع‌بندی چرخه جامع مدیریت گزارش‌ها و ورود به استودیو
سرفصل بعدی در دانشنامه: جهت فراگیری نحوه چیدمان حرفه‌ای کارت‌ها، پیکربندی منابع داده Master-Detail و ساخت ستون‌های اکشن‌دار سفارشی، به مستند «[REPORT-02] استودیوی ساخت گزارش (Studio)» مراجعه فرمایید.