Power BI Service؛ انتشار، Workspace، Refresh، Gateway و اشتراک‌گذاری

کتاب جامع Power BI — آموزش پروژه‌محور، تصویری و کاربردی

مقدمه؛ گزارش وقتی ارزش دارد که به دست کاربر برسد

تا فصل قبل داشبورد را در Power BI Desktop ساختیم و ظاهرش را حرفه‌ای کردیم. اما در یک پروژه سازمانی فایل PBIX روی لپ‌تاپ ما پایان کار نیست. مدیر و کاربران باید گزارش را ببینند، داده باید به‌روز شود و دسترسی‌ها هم کنترل شوند.

Power BI Service محیط ابری Power BI برای انتشار، مدیریت، Refresh و توزیع محتوای تحلیلی است. در این فصل مسیر یک گزارش از Desktop تا مصرف سازمانی را قدم‌به‌قدم بررسی می‌کنیم.

۹.۱. تصویر کلی معماری انتشار

شکل ۹-۱ — مسیر کلی از Power BI Desktop تا گزارش سازمانی

در ساده‌ترین حالت گزارش را از Desktop منتشر می‌کنیم، محتوا وارد Workspace می‌شود و کاربران از طریق Report یا App به آن دسترسی پیدا می‌کنند. اگر منبع داده داخل شبکه شرکت باشد، Gateway هم وارد معماری می‌شود.

۹.۲. Publish از Desktop

بعد از آماده شدن گزارش، با Publish آن را به Workspace موردنظر ارسال می‌کنیم. قبل از انتشار باید مطمئن شویم به حساب و Tenant درست وارد شده‌ایم و مقصد انتشار را اشتباه انتخاب نکرده‌ایم.

نکته: در پروژه واقعی، Workspace شخصی را با Workspace رسمی پروژه قاطی نکن.

۹.۳. Workspace چیست؟

Workspace را می‌توان محیط کاری تیم BI دانست؛ جایی برای نگهداری و مدیریت Reportها، Semantic Modelها و سایر اقلام مرتبط.

برای مثال شرکت هانا می‌تواند Workspace جداگانه‌ای برای گزارش‌های فروش مدیریتی داشته باشد.

۹.۴. نقش‌های Workspace

شکل ۹-۲ — نمای مفهومی نقش‌های Workspace

نقش‌ها سطح توانایی کاربران را در Workspace مشخص می‌کنند. در طراحی دسترسی باید اصل حداقل دسترسی لازم را رعایت کنیم؛ یعنی هرکس فقط همان سطحی را بگیرد که واقعاً برای کارش نیاز دارد.

۹.۵. Report و Semantic Model

بعد از Publish معمولاً گزارش و مدل معنایی مرتبط با آن را در Service می‌بینیم. Report لایه ارائه و Visualهاست و Semantic Model لایه داده و مدل تحلیلی پشت گزارش را فراهم می‌کند.

Data Source → Semantic Model → Report → User

۹.۶. Refresh یعنی چه؟

وقتی داده منبع تغییر می‌کند، مدل منتشرشده باید دوباره داده جدید را دریافت کند. Refresh همان فرایندی است که مدل را با منبع هماهنگ می‌کند.

اگر فروش امروز در SQL ثبت شده ولی Semantic Model هنوز Refresh نشده باشد، داشبورد الزاماً آن فروش را نشان نمی‌دهد.

۹.۷. Scheduled Refresh

در سناریوهای مناسب می‌توان Refresh را زمان‌بندی کرد تا مدل در زمان‌های مشخص به‌روز شود.

06:00  → Refresh
12:00  → Refresh
18:00  → Refresh

تعداد و زمان Refresh باید با نیاز کسب‌وکار، نوع منبع، ظرفیت و محدودیت‌های محیط هماهنگ شود.

۹.۸. Gateway؛ پل بین شبکه شرکت و Service

شکل ۹-۳ — نقش Gateway بین منبع On-premises و Power BI Service

اگر SQL Server شرکت هانا داخل شبکه داخلی شرکت باشد و Service مستقیماً به آن دسترسی نداشته باشد، On-premises Data Gateway می‌تواند مسیر ارتباطی لازم را فراهم کند.

۹.۹. Gateway را کجا نصب کنیم؟

Gateway را روی سیستمی نصب می‌کنیم که به منبع داده دسترسی پایدار داشته باشد و برای اجرای مداوم مناسب باشد. لپ‌تاپ شخصی توسعه‌دهنده معمولاً انتخاب خوبی برای محیط Production نیست.

سرور Gateway باید از نظر شبکه، دسترسی، پایداری و نگهداری با تیم زیرساخت هماهنگ شود.

۹.۱۰. Credentials و اتصال منبع

Service برای Refresh باید بتواند با اعتبار مناسب به Data Source متصل شود. بنابراین تنظیم Credentials بخش مهم استقرار است.

اطلاعات ورود نباید به شکل ناامن در مستندات یا فایل‌های عمومی تیم پخش شوند.

۹.۱۱. Refresh Failure

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

وقتی Refresh شکست خورد، اول پیام خطا و مرحله‌ای که مشکل ایجاد کرده را بررسی کن؛ با حدس زدن جلو نرو.

۹.۱۲. Share کردن Report

اشتراک‌گذاری گزارش باید کنترل‌شده باشد. هدف این نیست که لینک را برای همه بفرستیم؛ باید بدانیم چه کسی مجاز به دیدن چه محتوایی است.

در سازمان بهتر است ساختار دسترسی، گروه‌های کاربری و مالکیت گزارش از ابتدا مشخص باشد.

۹.۱۳. Power BI App

App راهی برای بسته‌بندی و ارائه مجموعه‌ای از محتوای آماده مصرف به کاربران نهایی است. به جای اینکه مدیر وارد محیط کاری تیم توسعه شود، می‌تواند محتوای منتشرشده و مرتب‌شده را از طریق App دریافت کند.

Workspace = محیط تولید و مدیریت
App       = تجربه مصرف برای مخاطب

۹.۱۴. ساختار پیشنهادی شرکت هانا

۹.۱۵. Row-Level Security؛ مقدمه

فرض کن مدیر شعبه تهران فقط باید داده تهران را ببیند و مدیر شعبه اصفهان فقط اصفهان را. اینجا Row-Level Security یا RLS مطرح می‌شود.

User A → Tehran rows
User B → Isfahan rows
CEO    → All rows

در فصل امنیت، RLS را عمیق‌تر طراحی و تست می‌کنیم.

۹.۱۶. دسترسی با امنیت داده فرق دارد

اینکه کاربر اجازه باز کردن Report را داشته باشد الزاماً به این معنی نیست که باید همه ردیف‌های داده را ببیند. مجوز دسترسی به محتوا و امنیت سطح داده دو موضوع مرتبط ولی متفاوت‌اند.

۹.۱۷. Lineage و وابستگی

در محیط سازمانی باید بدانیم یک Report از کدام مدل و منبع تغذیه می‌شود. شناخت وابستگی‌ها هنگام تغییر مدل یا رفع خطای Refresh بسیار مهم است.

SQL → Semantic Model → Executive Report → Management App

۹.۱۸. Dev، Test و Production

برای پروژه جدی بهتر است تغییرات را مستقیم روی محیط مصرف مدیران آزمایش نکنیم. مفهوم محیط توسعه، تست و Production کمک می‌کند انتشار کنترل‌شده‌تر باشد.

۹.۱۹. انتشار نسخه جدید

قبل از جایگزین کردن نسخه Production، تغییرات DAX، Relationship، Visual، Refresh و دسترسی‌ها را تست کن. یک تغییر کوچک در مدل ممکن است چند صفحه گزارش را تحت تأثیر قرار دهد.

۹.۲۰. مدیریت مالکیت

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

۹.۲۱. Last Refresh در گزارش

همان‌طور که در فصل UI/UX گفتیم، کاربر باید بداند داده تا چه زمانی به‌روز است. در Service این موضوع مهم‌تر هم می‌شود، چون ممکن است Refresh زمان‌بندی‌شده شکست خورده باشد.

۹.۲۲. Monitoring ساده

تیم BI باید وضعیت Refreshها و خطاهای مهم را بررسی کند. اگر داشبورد مدیرعامل سه روز به‌روز نشده باشد ولی کسی متوجه نشود، اعتماد به کل سیستم BI آسیب می‌بیند.

۹.۲۳. خطاهای رایج در Service

خطای اول: Publish مستقیم به Workspace اشتباه.

خطای دوم: نصب Gateway روی سیستم ناپایدار.

خطای سوم: دادن دسترسی بیش از نیاز.

خطای چهارم: نداشتن مالک و مسئول پشتیبانی مشخص.

خطای پنجم: تغییر Schema منبع بدون بررسی Refresh.

خطای ششم: استفاده از Workspace توسعه به عنوان محیط نهایی کاربران.

خطای هفتم: نادیده گرفتن شکست Refresh.

۹.۲۴. Best Practiceهای استقرار

نام‌گذاری Workspace و Reportها را استاندارد کن.

دسترسی‌ها را بر اساس نقش سازمانی طراحی کن.

Gateway را روی زیرساخت پایدار قرار بده.

Refresh را بر اساس نیاز واقعی زمان‌بندی کن.

نسخه Production را قبل از انتشار تست کن.

مالکیت و پشتیبانی را مستند کن.

وضعیت Refresh و Last Refresh را قابل مشاهده نگه دار.

۹.۲۵. تمرین پایه

یک Workspace آزمایشی در محیط مجاز خودت در نظر بگیر و ساختار نام‌گذاری Report، Semantic Model و App را روی کاغذ طراحی کن.

هدف این تمرین فهم معماری انتشار است؛ لازم نیست برای یادگیری، اطلاعات واقعی سازمان را منتشر کنی.

۹.۲۶. تمرین متوسط

سناریویی بنویس که SQL Server داخل شبکه شرکت است و مدیر از بیرون سازمان گزارش را در Power BI Service می‌بیند. مسیر داده را از SQL تا Report رسم کن و جای Gateway را مشخص کن.

۹.۲۷. تمرین کاربردی

برای سه گروه مدیرعامل، مدیر فروش و مدیر شعبه یک ماتریس دسترسی طراحی کن. مشخص کن چه کسی Workspace را مدیریت می‌کند و چه کسی فقط مصرف‌کننده App است.

۹.۲۸. تمرین چالشی

فرض کن Refresh ساعت ۶ صبح شکست خورده است. یک Runbook کوتاه بنویس: چه چیزهایی را به چه ترتیبی بررسی می‌کنی؟ Credential، Gateway، Data Source، Schema و Query را در نظر بگیر.

۹.۲۹. پروژه نهایی فصل؛ استقرار BI شرکت هانا

برای پروژه شرکت هانا یک طرح Deployment آماده کن که مسیر Desktop تا مصرف مدیر را مشخص کند.

هدف این است که گزارش از یک فایل شخصی به یک سرویس سازمانی قابل اتکا تبدیل شود.

جمع‌بندی فصل نهم

Power BI Service جایی است که بخش بزرگی از چرخه عملیاتی BI اتفاق می‌افتد: انتشار، دسترسی، Refresh، Gateway و ارائه محتوا به کاربران.

Build in Desktop
      ↓
Publish
      ↓
Workspace + Semantic Model
      ↓
Refresh / Gateway / Security
      ↓
App / Report
      ↓
Business Users

در فصل بعد سراغ امنیت حرفه‌ای‌تر می‌رویم: RLS، Dynamic RLS، طراحی دسترسی بر اساس User، تست نقش‌ها و سناریوی مدیر شعبه در شرکت هانا.